129 posts tagged with "Added"

Stax account tags are now applied to cost and compliance data in Stax. This enriched data allows you to organize, view, and group your resources using account tags to better meet your business needs.

As a result of Stax's improvement to propagate account tags to AWS accounts, these tags are now available in Stax's cost and compliance data. This means they can be used with Views on the Dashboard, Cost, Data and Rules pages of Stax. Within 24 hours of adding or modifying an account tag, the tag will be applied to all of that account's resources represented in Stax's cost and compliance data. Tags added via Stax take the format of stax:user:<tag_key>.

If you're subscribed only to the Stax Cost & Compliance module, you can make use of this feature by tagging AWS account resources directly. Tags will propagate to all resources in cost and compliance data in the same <tag_key> format as they appear in AWS.

While changes made to account tags directly within AWS will be represented in cost and compliance data, it is recommended that changes are made to Stax-managed account tags from within Stax using the console, API, or SDK.

Account tags in Stax will now propagate to the AWS account in AWS Organizations.

Since inception, Stax has permitted assigning tags to Stax-managed accounts. Those tags will now be propagated to the underlying AWS account. Tags will be in the format of stax:user:<tag_key>.

In addition to any tags you create, Stax assigns other tags to Stax-managed AWS accounts, including:

• stax:organisationid (The identifier for your Stax tenancy, in UUID format)

• stax:accounttypeid (The identifier for the account's Account Type, in UUID format)

• stax:accounttypename (The name of the account's Account Type)

• stax:accountname (The name of the account)

It is important to note that changes made to account tags directly within AWS will not be reflected in Stax, so it is recommended that you make changes to account tags from within Stax using the console, API, or SDK.

Advanced Routing for Stax Networks allows for modification of Transit Gateway and VPC subnet route tables using prefix lists.

This new feature allows for configuration of route table entries in both Networking Hubs or VPCs directly. These entries can direct traffic to other VPCs, VPNs, on-premises networks, or black holes.

To get started, see Advanced Routing in the docs. You'll need to have at least one Stax Networking Hub already in place.

Stax Networks will now create an additional *.s3.{region}.amazonaws.com wildcard Hosted Zone record when enabling the S3 Interface Endpoint.

This additional hosted zone record will simplify the use of the S3 Interface Endpoint and allow it to work with other AWS services, such as AWS SSM Session Manager.

If you are currently using an S3 Interface Endpoint, then you can edit your Networking Hub to toggle the S3 Interface Endpoint off, then on to perform the update.

Stax Networks now supports the Lambda Interface Endpoint for VPCs that are part of a Networking Hub.

You can enable the Lambda Interface Endpoints for new and existing Networking Hubs using the Stax Console, API, or SDK. See Manage Networking Hubs for more.

Stax Networks has created an additional NACL entry for the Restricted Subnet. This allows return TCP traffic from the Networking Hub's Endpoint subnets.

By allowing this return traffic your resources within the Restricted Subnet will be able to utilize the Networking Hub's Interface Endpoints.

The new NACL entry will be created as rule number 130 on the Restrict subnet NACL and will be created on the next update of your VPC with Stax.

If you would like to update your VPC without making any changes to its configuration, you can edit your Networking Hub to modify the tags and trigger an update.

Stax Networks now supports enabling five additional Interface Endpoints for VPCs that are part of a Networking Hub:

• CodeDeploy (codedeploy)

• CodeDeploy Commands Secure (codedeploy-commands-secure)

• RDS (rds)

• RDS Data (rds-data)

• S3 (s3-interface)

You can enable these Interface Endpoints for new and existing Networking Hubs using the Stax Console, API, or SDK. See Manage Networking Hubs for more.

The Data page now has a date picker to make it easier to select a time range. You can choose either a single month, or a range of months.

Navigate to the Data page now to try it out!

The Notifications page has been redesigned to provide a more intuitive and simple user experience. Notifications are now managed through a tabulated window, with each delivery channel located on a seperate tab.

Stax also now supports sending notifications via Microsoft Teams, in addition to the existing email, webhook, and Slack delivery channels. Simply create an incoming webhook for your Teams channel and select the notifications you'd like to receive. For more information, see the documentation.

When deploying Networking Hubs using Stax Networks, a NAT Gateway can be deployed for egress connectivity from private subnets. By default, when enabled, Stax provisions a single NAT Gateway which resides in a single Availability Zone (AZ). An outage of that AZ would result in egress connectivity failing for private subnets in that Networking Hub.

Stax has introduced a new feature to allow deployment of highly available NAT Gateways that are redundant at the Availability Zone level. These can be deployed into networks provisioned using Stax Networks. You can make use of this feature when creating a new, or updating an existing, Networking Hub.

At this time, the feature is available via the Stax API and the Python SDK.