An update has been applied to the Stax Identity Service to improve performance and reliability.
These changes have been applied automatically by Stax during the advertised maintenance window. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.
Stax has added a new Stax Workload default parameter, StaxAwsOrgId, to allow access to your AWS Organization ID when deploying Stax Workloads.
Use this new parameter to easily access your AWS Organization ID value to allow Organization-wide IAM permissions.
For more information on using AWS Organizational IAM permissions, see this blog post from AWS.
The following example grants s3:GetObject on a S3 bucket access to all accounts in your AWS Organization. ```yaml AWSTemplateFormatVersion: "2010-09-09" Parameters: StaxAwsOrgId: Type: "String" Resources: S3Bucket: Type: "AWS::S3::Bucket" Properties: BucketName: "my-s3-bucket" S3BucketPolicy: Type: "AWS::S3::BucketPolicy" Properties: Bucket: !Ref S3Bucket PolicyDocument: Statement: - Action: - "s3:GetObject" Effect: Allow Resource: Fn::Join: - "" - - "arn:aws:s3:::" - !Ref S3Bucket - /Principal: "" Condition: StringEquals: aws:PrincipalOrgID: - !Ref StaxAwsOrgId
Stax has added new functionality to the Data page which allows you to group your costs.
With this new functionality, you can quickly and easily drill into the different areas of your AWS spend. Group your costs by pre-configured views, AWS accounts, tags values, or any other field on the Data page.
Multiple groups can be applied. Some scenarios of this which we have found helpful include:
Grouping by account and then by service for a quick breakdown of the how we are using AWS
Filtering to RDS and grouping by ARN to view the costs of our specific databases
Grouping by kind to show the breakdown between AWS credits, saving plan charges, and our usage
Stax has made changes to the Stax Workloads API to make it easier to find Workloads you have deployed into your Stax-managed AWS accounts. These filters are available in the API and the SDK.
The new filters available are:
| Filter Name | Description | | --- | --- | | account_names | Comma-delimited list of Stax Account Names. Returns all Workloads deployed to these Accounts Names. | | account_types | Comma-delimited list of Stax Account Types. Returns all Workloads deployed to these Account Types. | | account_ids | Comma-delimited list of Stax Account IDs. Returns all Workloads deployed to these Account IDs. | | catalogue_names | Comma-delimited list of Stax Workload Catalogue Names. Returns all Workloads deployed with these Workload Catalogue Names. | | catalogue_ids | Comma-delimited list of Stax Workload Catalogue IDs. Returns all Workloads deployed with these Catalogue IDs. | | catalogue_version | Only return Workloads launched from this Stax Workload Catalogue Version (eg. 1.0.0). Requires catalogue_ids to also be provided. |
GET https://api.au1.staxapp.cloud/20190206/workloads?account_types=billing
GET https://api.au1.staxapp.cloud/20190206/workloads?catalogue_ids=b5e1c1a5-ee96-4ea3-8343-8704f5f67596&catalogue_version=2.0.1
AWS VPC Flow Logs must be directed to a CloudWatch Log group within the same AWS account, and same AWS region as the VPC.
A bug has been resolved where the CloudWatch Log group only existed in the Stax Tenancy's AWS region in the format vpcflowlogs-{AwsAccountId}. A change to Stax Networking will now create these CloudWatch Log groups on demand and per-region with the format vpcflowlogs-{AwsAccountId}-{Region}.
Existing Stax Networking VPCs will continue to log to the legacy destination but upon next update of the VPC, the VPC Flow Log destination will be updated to the new CloudWatch Log group. Log entries that have been created in the existing CloudWatch Log group will not be deleted.
If you have any questions about how this change may impact you, please raise a support case.
A bug has been resolved that prevented the deployment of Fargate containers into a private subnet within a Stax Networks VPC. When trying to deploy a container, you may have received an error message similar to the following:
CannotPullContainerError: failed to resolve ref "123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/nginx:latest": failed to do request: Head https://123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/v2/nginx/manifests/latest: dial tcp: lookup 751463547...
This error was caused by the absence of a specific DNS record for the ECR VPC Interface endpoint.
To resolve this issue, when the ECR Interface endpoint is enabled in a Networking Hub, a new Route 53 resource record will be created for *.dkr.ecr.<region>.amazonaws.com. This resource record will permit images to be pulled from ECR for use within Fargate.
If you have existing Networking Hubs in place, you must disable and enable the ECR Interface endpoint to create the new Route 53 resource record.
API Tokens are security credentials that can be used to authenticate to the Stax API via the Stax SDK for Python. They have been accessible via Preview mode in the Console, whilst we have expanded and improved upon the functionality. We have released API Tokens out of Preview and the feature is now available for general use.
To access API Tokens, click the Customer Menu in the left-hand nav, then choose API Tokens from the drop-down menu.
For more information, see:
Stax has updated the Global Filters drop-down to include data that you are needing access to every day or every week. With this change, you will be able to quickly scan through the list of Views and Segments that you use the most and quickly change between them. By adding this functionality, we've removed a few unnecessary clicks each and every time you want to change the data that you are looking at.
Stax has made changes to improve the speed of Workloads development and deployment.
Validation of the Workload Manifest and AWS CloudFormation templates for the Create Workload Catalogue Item and Update Workload Catalogue Item APIs has been modified.
Previously, these APIs processed this validation asynchronously. This necessitated users to check either the Task results or the Status of the item to determine if the action was successful.
This validation will, instead, now occur synchronously. Any issues with validation will return a HTTP Status 400 and an appropriate error detailing the issue.
If a changelog is published in the forest, and nobody sees it, did it really happen?
We want you to know about great new Stax features as soon as they're available. Stax has today introduced an RSS/Atom feed for changelog entries, so you can subscribe to receive them in whichever fashion suits your needs best.
You can subscribe to the feeds using the following URLs: