Today, AWS Marketplace announces the availability of automated archival of old, unused product versions that are no longer available publicly for subscription (restricted). This feature is available for Amazon Machine Image (AMI), AMI with CloudFormation templates, and container products.

With this release, AWS Marketplace is streamlining the version management experience for AWS customers and sellers. With automated version archival, any product version that has already been restricted by a seller for longer than two years will be archived. Archived versions will no longer be available to launch from AWS Marketplace for new customers; however, existing users can continue to use them through launch templates and Amazon EC2 Auto Scaling groups by specifying the AMI ID. Any archived version that has not been used to launch any new instances in the previous 13 months will be deleted. Once an archived version is deleted, it is no longer available to launch for new or existing users.

Now AWS customers see only the latest versions of the products in AWS Marketplace, reducing the risk of using outdated versions. For sellers, it simplifies product management by automatically removing unused older versions.

This capability is enabled for all AMI and container products, and no additional action is needed from sellers. To learn more about this feature, see the AWS Marketplace Seller Guide.
 

 

​Today, AWS Marketplace announces the availability of automated archival of old, unused product versions that are no longer available publicly for subscription (restricted). This feature is available for Amazon Machine Image (AMI), AMI with CloudFormation templates, and container products. With this release, AWS Marketplace is streamlining the version management experience for AWS customers and sellers. With automated version archival, any product version that has already been restricted by a seller for longer than two years will be archived. Archived versions will no longer be available to launch from AWS Marketplace for new customers; however, existing users can continue to use them through launch templates and Amazon EC2 Auto Scaling groups by specifying the AMI ID. Any archived version that has not been used to launch any new instances in the previous 13 months will be deleted. Once an archived version is deleted, it is no longer available to launch for new or existing users. Now AWS customers see only the latest versions of the products in AWS Marketplace, reducing the risk of using outdated versions. For sellers, it simplifies product management by automatically removing unused older versions. This capability is enabled for all AMI and container products, and no additional action is needed from sellers. To learn more about this feature, see the AWS Marketplace Seller Guide.    

With AWS Elastic Beanstalk, you can easily deploy and manage applications in AWS without worrying about configuring the infrastructure that runs those applications. Now, AWS Elastic Beanstalk will support EC2 Launch Template in Elastic Beanstalk environments by default after the deprecation of EC2 Launch Configuration. With this feature, you will not need to manually set certain configuration options in any AWS accounts, as described in documentation, to direct AWS Elastic Beanstalk to use the EC2 Launch Template when creating new environments.

Elastic Beanstalk’s support for EC2 Launch Template is generally available in commercial regions where Elastic Beanstalk is available including the AWS GovCloud (US) Regions. For a complete list of regions and service offerings, see AWS Regions.

For more information about with Launch Template support in Elastic Beanstalk please read our developer guide. To learn more about Elastic Beanstalk, visit the Elastic Beanstalk product page.

 

​With AWS Elastic Beanstalk, you can easily deploy and manage applications in AWS without worrying about configuring the infrastructure that runs those applications. Now, AWS Elastic Beanstalk will support EC2 Launch Template in Elastic Beanstalk environments by default after the deprecation of EC2 Launch Configuration. With this feature, you will not need to manually set certain configuration options in any AWS accounts, as described in documentation, to direct AWS Elastic Beanstalk to use the EC2 Launch Template when creating new environments.
Elastic Beanstalk’s support for EC2 Launch Template is generally available in commercial regions where Elastic Beanstalk is available including the AWS GovCloud (US) Regions. For a complete list of regions and service offerings, see AWS Regions.
For more information about with Launch Template support in Elastic Beanstalk please read our developer guide. To learn more about Elastic Beanstalk, visit the Elastic Beanstalk product page.  

Today, AWS Resource Groups is adding support for an additional 172 resource types for tag-based Resource Groups. Customers can now use Resource Groups to group and manage resources from services such as AWS Entity Resolution, Amazon Personalize, and Amazon Q Apps.

AWS Resource Groups enables you to model, manage and automate tasks on large numbers of AWS resources by logically grouping your resources. You can create collections of resources such as applications, projects, or workloads, and manage them on dimensions such as cost, performance, and compliance in AWS services such as myApplications, AWS Systems Manager and Amazon CloudWatch.

AWS Resource Groups expanded resource type coverage is available in all AWS Regions, including the AWS GovCloud (US) Regions. You can access AWS Resource Groups through the AWS Management Console, the AWS SDK APIs, and the AWS CLI.

For more information about grouping resources, see the AWS Resource Groups user guide and the list of supported resource types. To get started, visit AWS Resource Groups console.

 

​Today, AWS Resource Groups is adding support for an additional 172 resource types for tag-based Resource Groups. Customers can now use Resource Groups to group and manage resources from services such as AWS Entity Resolution, Amazon Personalize, and Amazon Q Apps. AWS Resource Groups enables you to model, manage and automate tasks on large numbers of AWS resources by logically grouping your resources. You can create collections of resources such as applications, projects, or workloads, and manage them on dimensions such as cost, performance, and compliance in AWS services such as myApplications, AWS Systems Manager and Amazon CloudWatch. AWS Resource Groups expanded resource type coverage is available in all AWS Regions, including the AWS GovCloud (US) Regions. You can access AWS Resource Groups through the AWS Management Console, the AWS SDK APIs, and the AWS CLI. For more information about grouping resources, see the AWS Resource Groups user guide and the list of supported resource types. To get started, visit AWS Resource Groups console.  

Starting today, you can easily connect Amazon ElastiCache clusters to an Amazon Elastic Compute Cloud (Amazon EC2) instance directly from the AWS Management Console. You can also connect to your cache using AWS CloudShell to execute commands without additional setup.

With a single click, you can establish secure connectivity between your cache and an EC2 instance, following AWS recommended best practices. ElastiCache automatically configures VPCs, security groups, and network settings, eliminating the need for manual tasks like setting up subnets and ingress/egress rules. This streamlines the process for new users and developers, enabling them to launch a cache instance and connect it to an application within minutes.

You can also choose to connect to your cache from the Console using AWS CloudShell. Just click the “Connect to cache” button in the new “Connectivity and Security” tab. This will open a new AWS CloudShell session and connect to your cache using the valkey-cli tool. Once connected, you can execute common Valkey commands, including reading data (e.g. GET <key>) and writing data (e.g. SET <key> <value>). This lets you test cache functionality directly in the console, without needing to connect to it from an EC2 instance.

Learn more about setting up connectivity to a compute resource from your ElastiCache cluster in the Amazon ElastiCache user guide.

 

​Starting today, you can easily connect Amazon ElastiCache clusters to an Amazon Elastic Compute Cloud (Amazon EC2) instance directly from the AWS Management Console. You can also connect to your cache using AWS CloudShell to execute commands without additional setup. With a single click, you can establish secure connectivity between your cache and an EC2 instance, following AWS recommended best practices. ElastiCache automatically configures VPCs, security groups, and network settings, eliminating the need for manual tasks like setting up subnets and ingress/egress rules. This streamlines the process for new users and developers, enabling them to launch a cache instance and connect it to an application within minutes. You can also choose to connect to your cache from the Console using AWS CloudShell. Just click the “Connect to cache” button in the new “Connectivity and Security” tab. This will open a new AWS CloudShell session and connect to your cache using the valkey-cli tool. Once connected, you can execute common Valkey commands, including reading data (e.g. GET <key>) and writing data (e.g. SET <key> <value>). This lets you test cache functionality directly in the console, without needing to connect to it from an EC2 instance. Learn more about setting up connectivity to a compute resource from your ElastiCache cluster in the Amazon ElastiCache user guide.  

Today, AWS announces the general availability of concurrent VPN connections for AWS Client VPN. This feature allows you to securely connect to multiple Client VPN connections simultaneously, enabling access to your resources across different work environments.

AWS Client VPN allows your users to securely connect to your network remotely from any location. Previously, you could only connect to one VPN profile at a time. This limited your access to only one network. To access another network, you were required to disconnect and reconnect to a different VPN profile. With this launch, you can connect to multiple VPN profiles simultaneously without switching. For example, software developers using AWS client for VPN can now connect to development, test, and production environment concurrently. This feature allows seamless parallel connections to all required environments, significantly improving productivity for end users.

This feature is available only with AWS-supplied Client VPN client version 5.0+. You can download this version following the steps here. This feature and the required client version are available at no additional cost in all AWS regions where AWS Client VPN is generally available.

To learn more about Client VPN:

• Visit the AWS Client VPN product page
• Read the AWS Client VPN documentation

 

​Today, AWS announces the general availability of concurrent VPN connections for AWS Client VPN. This feature allows you to securely connect to multiple Client VPN connections simultaneously, enabling access to your resources across different work environments. AWS Client VPN allows your users to securely connect to your network remotely from any location. Previously, you could only connect to one VPN profile at a time. This limited your access to only one network. To access another network, you were required to disconnect and reconnect to a different VPN profile. With this launch, you can connect to multiple VPN profiles simultaneously without switching. For example, software developers using AWS client for VPN can now connect to development, test, and production environment concurrently. This feature allows seamless parallel connections to all required environments, significantly improving productivity for end users. This feature is available only with AWS-supplied Client VPN client version 5.0+. You can download this version following the steps here. This feature and the required client version are available at no additional cost in all AWS regions where AWS Client VPN is generally available. To learn more about Client VPN:

Visit the AWS Client VPN product page
Read the AWS Client VPN documentation  

Amazon Connect now provides daily headcount projections in capacity plan downloads, enhancing your ability to review staffing requirements with greater precision. While capacity plans already provided weekly and monthly projections, this launch allows you to access day-by-day headcount requirements for up to 64 weeks into the future. This granular view simplifies key staffing and hiring decisions, such as how many workers to hire while accounting for seasonality and applying different shrinkage assumptions at a day level.

This feature is available in all AWS Regions where Amazon Connect agent scheduling is available. To learn more about Amazon Connect agent scheduling, click here.
 

 

​Amazon Connect now provides daily headcount projections in capacity plan downloads, enhancing your ability to review staffing requirements with greater precision. While capacity plans already provided weekly and monthly projections, this launch allows you to access day-by-day headcount requirements for up to 64 weeks into the future. This granular view simplifies key staffing and hiring decisions, such as how many workers to hire while accounting for seasonality and applying different shrinkage assumptions at a day level. This feature is available in all AWS Regions where Amazon Connect agent scheduling is available. To learn more about Amazon Connect agent scheduling, click here.    

You can now enable Amazon CloudWatch Observability add-on on your EKS cluster with 1-click when provisioning. With 1-click enablement, CloudWatch Observability add-on turns on CloudWatch Container Insights and Application Signals together, enabling you to the understand the health and performance of your applications out of the box. CloudWatch Observability add-on integrates with EKS Pod Identity such that you can simply create a recommended IAM role for the add-on and re-use it across your clusters when creating them, saving you time and effort.

Previously, you need to create your clusters first, wait for their status to become active and install the CloudWatch Add-on next while managing the required IAM permissions separately. With this launch, you can now install the Amazon CloudWatch Observability add-on when creating your clusters and launch them observability enabled, making observability telemetry available in CloudWatch out of the box. You can then use curated dashboards from CloudWatch Application Signals and CloudWatch Container Insights to take proactive actions in reducing application disruptions by isolating anomalies and troubleshooting faster.

CloudWatch Observability add-on is now available on Amazon EKS in all commercial AWS Regions, including the AWS GovCloud (US) Regions. You can install, configure, and update the add-on with just a few clicks in the Amazon EKS console, APIs, AWS Command Line Interface (AWS CLI), and AWS CloudFormation. To get started, follow the user guide.
 

 

​You can now enable Amazon CloudWatch Observability add-on on your EKS cluster with 1-click when provisioning. With 1-click enablement, CloudWatch Observability add-on turns on CloudWatch Container Insights and Application Signals together, enabling you to the understand the health and performance of your applications out of the box. CloudWatch Observability add-on integrates with EKS Pod Identity such that you can simply create a recommended IAM role for the add-on and re-use it across your clusters when creating them, saving you time and effort. Previously, you need to create your clusters first, wait for their status to become active and install the CloudWatch Add-on next while managing the required IAM permissions separately. With this launch, you can now install the Amazon CloudWatch Observability add-on when creating your clusters and launch them observability enabled, making observability telemetry available in CloudWatch out of the box. You can then use curated dashboards from CloudWatch Application Signals and CloudWatch Container Insights to take proactive actions in reducing application disruptions by isolating anomalies and troubleshooting faster. CloudWatch Observability add-on is now available on Amazon EKS in all commercial AWS Regions, including the AWS GovCloud (US) Regions. You can install, configure, and update the add-on with just a few clicks in the Amazon EKS console, APIs, AWS Command Line Interface (AWS CLI), and AWS CloudFormation. To get started, follow the user guide.    

Amazon DynamoDB now supports a new warm throughput value and the ability to easily pre-warm DynamoDB tables and indexes in the AWS GovCloud (US) Regions. The warm throughput value provides visibility into the number of read and write operations your DynamoDB tables can readily handle, while pre-warming let’s you proactively increase the value to meet future traffic demands.

DynamoDB automatically scales to support workloads of virtually any size. However, when you have peak events like product launches or shopping events, request rates can surge 10x or even 100x in a short period of time. You can now check your tables’ warm throughput value to assess if your table can handle large traffic spikes for peak events. If you expect an upcoming peak event to exceed the current warm throughput value for a given table, you can pre-warm that table in advance of the peak event to ensure it scales instantly to meet demand.

Warm throughput values are available for all provisioned and on-demand tables and indexes at no cost. Pre-warming your table’s throughput incurs a charge. See Amazon DynamoDB Pricing page for pricing details. See the Developer Guide to learn more.
 

 

​Amazon DynamoDB now supports a new warm throughput value and the ability to easily pre-warm DynamoDB tables and indexes in the AWS GovCloud (US) Regions. The warm throughput value provides visibility into the number of read and write operations your DynamoDB tables can readily handle, while pre-warming let’s you proactively increase the value to meet future traffic demands. DynamoDB automatically scales to support workloads of virtually any size. However, when you have peak events like product launches or shopping events, request rates can surge 10x or even 100x in a short period of time. You can now check your tables’ warm throughput value to assess if your table can handle large traffic spikes for peak events. If you expect an upcoming peak event to exceed the current warm throughput value for a given table, you can pre-warm that table in advance of the peak event to ensure it scales instantly to meet demand. Warm throughput values are available for all provisioned and on-demand tables and indexes at no cost. Pre-warming your table’s throughput incurs a charge. See Amazon DynamoDB Pricing page for pricing details. See the Developer Guide to learn more.    

Today, Amazon Redshift announces the launch of history mode for zero-ETL integrations. This new feature enables you to build Type 2 Slowly Changing Dimension (SCD 2) tables on your historical data from databases, out-of-the-box in Amazon Redshift, without writing any code. History mode simplifies the process of tracking and analyzing historical data changes, allowing you to gain valuable insights from your data’s evolution over time.

With history mode, you can easily run advanced analytics on historical data, build lookback reports, and perform trend analysis across multiple zero-ETL data sources, including Amazon DynamoDB, Amazon RDS for MySQL, Amazon Aurora MySQL, and Amazon Aurora PostgreSQL. By preserving the complete history of data changes without maintaining duplicate copies across data sources, history mode helps organizations meet data storage requirements while significantly reducing storage needs and operational costs. History mode is available for both existing and new integrations. You can selectively enable historical tracking for specific tables within your integration for enhanced flexibility in your data analysis.

To learn more and get started with zero-ETL integration, visit the getting started guides for Amazon Redshift. For more information on history mode and its benefits, visit the documentation.
 

 

​Today, Amazon Redshift announces the launch of history mode for zero-ETL integrations. This new feature enables you to build Type 2 Slowly Changing Dimension (SCD 2) tables on your historical data from databases, out-of-the-box in Amazon Redshift, without writing any code. History mode simplifies the process of tracking and analyzing historical data changes, allowing you to gain valuable insights from your data’s evolution over time. With history mode, you can easily run advanced analytics on historical data, build lookback reports, and perform trend analysis across multiple zero-ETL data sources, including Amazon DynamoDB, Amazon RDS for MySQL, Amazon Aurora MySQL, and Amazon Aurora PostgreSQL. By preserving the complete history of data changes without maintaining duplicate copies across data sources, history mode helps organizations meet data storage requirements while significantly reducing storage needs and operational costs. History mode is available for both existing and new integrations. You can selectively enable historical tracking for specific tables within your integration for enhanced flexibility in your data analysis. To learn more and get started with zero-ETL integration, visit the getting started guides for Amazon Redshift. For more information on history mode and its benefits, visit the documentation.    

Amazon EC2 introduces new capabilities that make it easy for customers to target instance launches on their On-Demand Capacity Reservations (ODCRs). On-Demand Capacity Reservations help you reserve compute capacity for your workloads in a specified Availability Zone for any duration. You can now ensure instance launches are fulfilled exclusively by ODCRs, or prefer unutilized ODCRs before falling back to On-Demand capacity.

To get started, you can specify your capacity reservation preferences for your EC2 Auto Scaling groups via the AWS Console or the AWS CLI. These preferences can also be configured using EC2 RunInstances API calls.

These features are available in both of the AWS GovCloud (US) Regions. To learn more, see the Capacity Reservations user guide and EC2 Auto Scaling user guide.
 

 

​Amazon EC2 introduces new capabilities that make it easy for customers to target instance launches on their On-Demand Capacity Reservations (ODCRs). On-Demand Capacity Reservations help you reserve compute capacity for your workloads in a specified Availability Zone for any duration. You can now ensure instance launches are fulfilled exclusively by ODCRs, or prefer unutilized ODCRs before falling back to On-Demand capacity. To get started, you can specify your capacity reservation preferences for your EC2 Auto Scaling groups via the AWS Console or the AWS CLI. These preferences can also be configured using EC2 RunInstances API calls. These features are available in both of the AWS GovCloud (US) Regions. To learn more, see the Capacity Reservations user guide and EC2 Auto Scaling user guide.