Version 1.4.0 of stax2aws has been released. This update contains the following changes:

• Increased the number of roles a user can be assigned to. In previous versions of stax2aws users may have encounterd an error too many roles - SAML assertion is greater than 100kb. Upgrading to version 1.4.0 or greater of stax2aws resolves this error.
• Account names (as configured in Stax) are now displayed alongside the account info. Previously the AWS IAM Account Alias was displayed, however relying on this information restricted the number of roles a user could have access to (See above). It also inhibited the user experience when accounts did not have an IAM Alias set. Stax2aws now integrates closely with Stax and will display the Stax account name for all roles.
• Default session duration changed to 1 hour (3600 seconds). In line with best practice the default session duration has been adjusted to be 1 hour. This can be increased at log in time by passing the session's desired duration (in seconds) with the new --session-duration parameter. This value can be up to the max-session-duration of the IAM Role being assumed. Providing a value for the --profile parameter will save the provided session duration for future executions.
• Apple Silicon and M1 support. stax2aws is now available natively for M1 Mac users.

Stax's user and group APIs have been updated to enable more comprehensive management and recreation of deleted resources.

Previously when a user was deleted from Stax, the email address was unable to be reused to invite a new user and a suport case was required. Users can now be invited with the same email address as a previously deleted user.

Additionally, once a user is deactivated in Stax, they can now be deleted from the Stax console. Previously, deletion was only supported in the API and SDK. This option is available by clicking the vertical ellipsis (⋮) next to the deactivated user's details.

Previously when a group was deleted from Stax, the group name was unable to be reused to create a new group with the same name. Any groups deleted from 13 October 2021 onwards can have their name reused for creation of new groups. For any groups deleted prior to this date, raise a support case to have the change applied to it retroactively.

An update has been applied to the Stax Identity Service to improve performance and reliability.

The update implements security and stability updates to the underlying software as well as laying the foundation for upcoming feature releases. No functional changes have been introduced.

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.

To ensure you receive notice of upcoming changes to Stax, make sure you're subscribed to the status page.

When the UserCreateEvent, UserUpdateEvent, and UserDeleteEvent events occur, Stax Events now includes the user's status in the userStatus property.

See the Security Events Schema documentation for this property's expected values.

An update has been applied to Stax Workloads to improve performance and reliability:

• Fixed an issue where the Workloads API would accept a Catalog Item Version from a different Catalog Item resulting in the Workload being created/updated with a Version from an incorrect Catalog. If an invalid Catalog Item Version is used, the API will now return a 400 "Bad Request" response, along with an error payload detailing the error.

These changes have been applied automatically by Stax. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

Stax now supports daily Compliance notifications, in addition to the existing daily Cost notifications. These notifications allow you to retrieve a proactive summary of your organization's compliance posture based on Rules configured in the Compliance module.

This new notification shows:

• Count of new high priority rules failing since the day before
• Count of new high priority resources failing since the day before
• A list of high priority resource changes since the day before

This notification can be received by all supported channels for Notifications. To get started, see Create a Notification.

On the Data page, the new Marketplace Product property can be used to filter and group records by whether or not they are AWS Marketplace purchases. This is particularly useful when comparing AWS consumption in Stax to that which appears on your AWS invoice, and when considering chargeback/showback models internally. This information was previously only available when exporting data from the Data page using the Export Data button. Read more.

Additionally, a number of minor improvements have been made to the Data page:

• Common properties such as Kind, Account, Region, etc. have been moved to the top of the property list when configuring filters or groupings
• When grouping data, the Sum of Usage Cost field has been renamed to Total Usage Cost. Sum of Financial Cost has been renamed to Total Financial Cost
• Formatting of negative numbers has been improved

The Stax Accounts API has been uplifted to expose the AWS account Canonical user ID.

This change extends the Stax Accounts API to display the AwsAccountCanonicalUserId.

Stax has introduced support for the Center for Internet Security's Amazon Web Services Foundations Benchmark version 1.4.0. This introduces the following changes over the previous iteration, version 1.3.0:

Three new rules were added to the Benchmark:

• 2.1.3: Ensure MFA Delete is enabled on S3 buckets
• 2.1.4: Ensure all data in Amazon S3 has been discovered, classified and secured when required (This rule cannot be automatically checked by Stax, see below for more details)
• 2.3.1: Ensure that encryption is enabled for RDS instances

One rule changed category:

• 2.1.5: Ensure that S3 Buckets are configured with 'Block public access (bucket settings)' was moved from Identity and Access Management to Storage.

The Rule Bundle cannot validate all components of the Benchmark, so the following items must be evaluated manually:

• 1.1: Maintain current contact details
• 1.2: Ensure security contact information is registered
• 1.3: Ensure security questions are registered in the AWS account
• 1.18: Ensure IAM instance roles are used for AWS resource access from instances
• 1.21: Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments
• 2.1.4: Ensure all data in Amazon S3 has been discovered, classified and secured when required
• 5.4: Ensure routing tables for VPC peering are "least access"

To enable this new version of the Bundle, see Keep Bundles Up To Date. If you have automatic updates enabled, no action is required.

Stax has introduced new functionality on the Policies page which lets you attach Policies to Account Types or detach Policies. In addition, you can now see which Account Types have Policies attached. These changes make it easier to adjust Policy attachments and discern which Policies are in use.