Recycle Bin for Amazon EBS, which helps you recover accidentally deleted snapshots and EBS-backed AMIs, now supports EBS Volumes. If you accidentally delete a volume, you can now recover it directly from Recycle Bin instead of restoring from a snapshot, reducing your recovery point objective with no data loss between the last snapshot and deletion. Your recovered volume can immediately achieve the full performance without waiting for data to download from snapshots.

To use Recycle Bin, you can set a retention period for deleted volumes, and you can recover any volume within that period. Recovered volumes are immediately available and will retain all attributes—tags, permissions, and encryption status. Volumes not recovered are deleted permanently when the retention period expires. You create retention rules to enable Recycle Bin for all volumes or specific volumes, using tags to target which volumes to protect.

EBS Volumes in Recycle Bin are billed at the same price as EBS Volumes, read more on the pricing page. To get started, read the documentation. The feature is now available through the AWS Command Line Interface (CLI), AWS SDKs, or the AWS Console in all AWS commercial, China, and AWS GovCloud (US) Regions.

 

​Recycle Bin for Amazon EBS, which helps you recover accidentally deleted snapshots and EBS-backed AMIs, now supports EBS Volumes. If you accidentally delete a volume, you can now recover it directly from Recycle Bin instead of restoring from a snapshot, reducing your recovery point objective with no data loss between the last snapshot and deletion. Your recovered volume can immediately achieve the full performance without waiting for data to download from snapshots. To use Recycle Bin, you can set a retention period for deleted volumes, and you can recover any volume within that period. Recovered volumes are immediately available and will retain all attributes—tags, permissions, and encryption status. Volumes not recovered are deleted permanently when the retention period expires. You create retention rules to enable Recycle Bin for all volumes or specific volumes, using tags to target which volumes to protect. EBS Volumes in Recycle Bin are billed at the same price as EBS Volumes, read more on the pricing page. To get started, read the documentation. The feature is now available through the AWS Command Line Interface (CLI), AWS SDKs, or the AWS Console in all AWS commercial, China, and AWS GovCloud (US) Regions.  

Amazon OpenSearch Serverless now supports AWS PrivateLink for secure and private connectivity to management console. With AWS PrivateLink, you can establish a private connection between your virtual private cloud (VPC) and Amazon OpenSearch Serverless to create, manage, and configure your OpenSearch Serverless resources without using the public internet. By enabling private network connectivity, this enhancement eliminates the need to use public IP addresses or relying solely on firewall rules to access OpenSearch Serverless. With this feature release the OpenSearch Serverless management and data operations can be securely accessed through PrivateLinks. Data ingestion and query operations on collections still requires OpenSearch Serverless provided VPC endpoint configuration for private connectivity as described in the OpenSearch Serverless VPC developer guide.

You can use PrivateLink connections in all AWS Regions where Amazon OpenSearch Serverless is available. Creating VPC endpoints on AWS PrivateLink will incur additional charges; refer to AWS PrivateLink pricing page for details. You can get started by creating an AWS PrivateLink interface endpoint for Amazon OpenSearch Serverless using the AWS Management Console, AWS Command Line Interface (CLI), AWS Software Development Kits (SDKs), AWS Cloud Development Kit (CDK), or AWS CloudFormation. To learn more, refer to the documentation on creating an interface VPC endpoint for management console.

Please refer to the AWS Regional Services List for more information about Amazon OpenSearch Service availability. To learn more about OpenSearch Serverless, see the documentation. 

 

​Amazon OpenSearch Serverless now supports AWS PrivateLink for secure and private connectivity to management console. With AWS PrivateLink, you can establish a private connection between your virtual private cloud (VPC) and Amazon OpenSearch Serverless to create, manage, and configure your OpenSearch Serverless resources without using the public internet. By enabling private network connectivity, this enhancement eliminates the need to use public IP addresses or relying solely on firewall rules to access OpenSearch Serverless. With this feature release the OpenSearch Serverless management and data operations can be securely accessed through PrivateLinks. Data ingestion and query operations on collections still requires OpenSearch Serverless provided VPC endpoint configuration for private connectivity as described in the OpenSearch Serverless VPC developer guide. You can use PrivateLink connections in all AWS Regions where Amazon OpenSearch Serverless is available. Creating VPC endpoints on AWS PrivateLink will incur additional charges; refer to AWS PrivateLink pricing page for details. You can get started by creating an AWS PrivateLink interface endpoint for Amazon OpenSearch Serverless using the AWS Management Console, AWS Command Line Interface (CLI), AWS Software Development Kits (SDKs), AWS Cloud Development Kit (CDK), or AWS CloudFormation. To learn more, refer to the documentation on creating an interface VPC endpoint for management console. Please refer to the AWS Regional Services List for more information about Amazon OpenSearch Service availability. To learn more about OpenSearch Serverless, see the documentation.   

Amazon EC2 now supports Microsoft SQL Server 2025 with License-Included (LI) Amazon Machine Images (AMIs), providing a quick way to launch the latest version of SQL Server. By running SQL Server 2025 on Amazon EC2, customers can take advantage of the security, performance, and reliability of AWS with the latest SQL Server features.

Amazon creates and manages Microsoft SQL Server 2025 AMIs to simplify the provisioning and management of SQL Server 2025 on EC2 Windows instances. These images support version 1.3 of the Transport Layer Security (TLS) protocol by default for enhanced performance and security. These images also come with pre-installed software such as AWS Tools for Windows PowerShell, AWS Systems Manager, AWS CloudFormation, and various network and storage drivers to make your management easier.

SQL Server 2025 AMIs are available in all commercial AWS Regions and the AWS GovCloud (US) Regions.

To learn more about the new AMIs, see SQL Server AMIs User Guide or read the blog post.

 

​Amazon EC2 now supports Microsoft SQL Server 2025 with License-Included (LI) Amazon Machine Images (AMIs), providing a quick way to launch the latest version of SQL Server. By running SQL Server 2025 on Amazon EC2, customers can take advantage of the security, performance, and reliability of AWS with the latest SQL Server features. Amazon creates and manages Microsoft SQL Server 2025 AMIs to simplify the provisioning and management of SQL Server 2025 on EC2 Windows instances. These images support version 1.3 of the Transport Layer Security (TLS) protocol by default for enhanced performance and security. These images also come with pre-installed software such as AWS Tools for Windows PowerShell, AWS Systems Manager, AWS CloudFormation, and various network and storage drivers to make your management easier. SQL Server 2025 AMIs are available in all commercial AWS Regions and the AWS GovCloud (US) Regions. To learn more about the new AMIs, see SQL Server AMIs User Guide or read the blog post.  

AWS Organizations Tag Policies announces Reporting for Required Tags, a new validation check that proactively ensures your CloudFormation, Terraform, and Pulumi deployments include the required tags critical to your business. Your infrastructure-as-code (IaC) operations can now be automatically validated against tag policies to ensure tagging consistency across your AWS environments. With this, you can ensure compliance for your IaC deployments in two simple steps: 1) define your tag policy, and 2) enable validation in each IaC tool.

Tag Policies enables you to enforce consistent tagging across your AWS accounts with proactive compliance, governance, and control. With this launch, you can specify mandatory tag keys in your tag policies, and enforce guardrails for your IaC deployments. For example, you can define a tag policy that all EC2 instances in your IaC templates must have “Environment”, “Owner”, and “Application” as required tag keys. You can start validation by activating AWS::TagPolicies::TaggingComplianceValidator Hook in CloudFormation, adding validation logic in your Terraform plan, or activating aws-organizations-tag-policies pre-built policy pack in Pulumi. Once configured, all CloudFormation, Terraform, and Pulumi deployments in the target account will be automatically validated and/or enforced against your tag policies, ensuring that resources like EC2 instances include the required «Environment», «Owner», and «Application» tags.

You can use Reporting for Required Tags feature via AWS Management Console, AWS Command Line Interface, and AWS Software Development Kit. This feature is available with AWS Organizations Tag Policies in AWS Regions where Tag Policies is available. To learn more, visit Tag Policies documentation. To learn how to set up validation and enforcement, see the user guide for CloudFormation, this user guide for Terraform, and this blog post for Pulumi.

 

​AWS Organizations Tag Policies announces Reporting for Required Tags, a new validation check that proactively ensures your CloudFormation, Terraform, and Pulumi deployments include the required tags critical to your business. Your infrastructure-as-code (IaC) operations can now be automatically validated against tag policies to ensure tagging consistency across your AWS environments. With this, you can ensure compliance for your IaC deployments in two simple steps: 1) define your tag policy, and 2) enable validation in each IaC tool. Tag Policies enables you to enforce consistent tagging across your AWS accounts with proactive compliance, governance, and control. With this launch, you can specify mandatory tag keys in your tag policies, and enforce guardrails for your IaC deployments. For example, you can define a tag policy that all EC2 instances in your IaC templates must have “Environment”, “Owner”, and “Application” as required tag keys. You can start validation by activating AWS::TagPolicies::TaggingComplianceValidator Hook in CloudFormation, adding validation logic in your Terraform plan, or activating aws-organizations-tag-policies pre-built policy pack in Pulumi. Once configured, all CloudFormation, Terraform, and Pulumi deployments in the target account will be automatically validated and/or enforced against your tag policies, ensuring that resources like EC2 instances include the required «Environment», «Owner», and «Application» tags. You can use Reporting for Required Tags feature via AWS Management Console, AWS Command Line Interface, and AWS Software Development Kit. This feature is available with AWS Organizations Tag Policies in AWS Regions where Tag Policies is available. To learn more, visit Tag Policies documentation. To learn how to set up validation and enforcement, see the user guide for CloudFormation, this user guide for Terraform, and this blog post for Pulumi.  

Amazon Relational Database Service (Amazon RDS) for SQL Server now supports Multi-AZ deployment for SQL Server Web Edition. SQL Server Web Edition is specifically designed to support public and internet-accessible web pages, websites, web applications, and web services, and is used by web hosters and web value-added providers (VAPs). These applications need high availability, and automated failover to recover from hardware and database failures. Now customers can use SQL Server Web Edition with Amazon RDS Multi-AZ deployment option, which provides a high availability solution. The new feature eliminates the need for customers to use more expensive options for high availability, such as using SQL Server Standard Edition or Enterprise Edition.

To use the feature, customers simply configure their Amazon RDS for SQL Server Web Edition instance with Multi-AZ deployment option. Amazon RDS automatically provisions and maintains a standby replica in a different Availability Zone (AZ), and synchronously replicates data across the two AZs. In situations where your Multi-AZ primary database becomes unavailable, Amazon RDS automatically fails over to the standby replica, so customers can resume database operations quickly and without any administrative intervention.

For more information about Multi-AZ deployment for RDS SQL Server Web Edition, refer to the Amazon RDS for SQL Server User Guide. See Amazon RDS for SQL Server Pricing for pricing details and regional availability.

 

​Amazon Relational Database Service (Amazon RDS) for SQL Server now supports Multi-AZ deployment for SQL Server Web Edition. SQL Server Web Edition is specifically designed to support public and internet-accessible web pages, websites, web applications, and web services, and is used by web hosters and web value-added providers (VAPs). These applications need high availability, and automated failover to recover from hardware and database failures. Now customers can use SQL Server Web Edition with Amazon RDS Multi-AZ deployment option, which provides a high availability solution. The new feature eliminates the need for customers to use more expensive options for high availability, such as using SQL Server Standard Edition or Enterprise Edition. To use the feature, customers simply configure their Amazon RDS for SQL Server Web Edition instance with Multi-AZ deployment option. Amazon RDS automatically provisions and maintains a standby replica in a different Availability Zone (AZ), and synchronously replicates data across the two AZs. In situations where your Multi-AZ primary database becomes unavailable, Amazon RDS automatically fails over to the standby replica, so customers can resume database operations quickly and without any administrative intervention. For more information about Multi-AZ deployment for RDS SQL Server Web Edition, refer to the Amazon RDS for SQL Server User Guide. See Amazon RDS for SQL Server Pricing for pricing details and regional availability.  

AWS announces the general availability of Cloud WAN Routing Policy providing customers fine-grained controls to optimize route management, control traffic patterns, and customize network behavior across their global wide-area networks.

AWS Cloud WAN allows you to build, monitor, and manage a unified global network that interconnects your resources in the AWS cloud and your on-premises environments. Using the new Routing Policy feature, customers can perform advanced routing techniques such as route filtering and summarization to have better control on routes exchanged between AWS Cloud WAN and external networks. This feature enables customers to build controlled routing environments to minimize route reachability blast radius, prevent sub-optimal or asymmetric connectivity patterns, and avoid over-running of route-tables due to propagation of unnecessary routes in global networks. In addition, this feature allows customers to set advanced Border Gateway Protocol (BGP) attributes to customize network traffic behavior per their individual needs and build highly resilient hybrid-cloud network architectures. This feature also provides advanced visibility in the routing databases to allow rapid troubleshooting of network issues in complex multi-path environments.

The new Routing Policy feature is available in all AWS Regions where AWS Cloud WAN is available. You can enable these features using the AWS Management Console, AWS Command Line Interface (CLI) and the AWS Software Development Kit (SDK). There is no additional charge for enabling Routing Policy on AWS Cloud WAN. For more information, see the AWS Cloud WAN documentation pages.

 

​AWS announces the general availability of Cloud WAN Routing Policy providing customers fine-grained controls to optimize route management, control traffic patterns, and customize network behavior across their global wide-area networks. AWS Cloud WAN allows you to build, monitor, and manage a unified global network that interconnects your resources in the AWS cloud and your on-premises environments. Using the new Routing Policy feature, customers can perform advanced routing techniques such as route filtering and summarization to have better control on routes exchanged between AWS Cloud WAN and external networks. This feature enables customers to build controlled routing environments to minimize route reachability blast radius, prevent sub-optimal or asymmetric connectivity patterns, and avoid over-running of route-tables due to propagation of unnecessary routes in global networks. In addition, this feature allows customers to set advanced Border Gateway Protocol (BGP) attributes to customize network traffic behavior per their individual needs and build highly resilient hybrid-cloud network architectures. This feature also provides advanced visibility in the routing databases to allow rapid troubleshooting of network issues in complex multi-path environments. The new Routing Policy feature is available in all AWS Regions where AWS Cloud WAN is available. You can enable these features using the AWS Management Console, AWS Command Line Interface (CLI) and the AWS Software Development Kit (SDK). There is no additional charge for enabling Routing Policy on AWS Cloud WAN. For more information, see the AWS Cloud WAN documentation pages.  

Amazon MQ now supports RabbitMQ version 4.2 which introduces native support for the AMQP 1.0 protocol, a new Raft based metadata store named Khepri, local shovels, and message priorities for quorum queues. RabbitMQ 4.2 also includes various bug fixes and performance improvements for throughput and memory management.

A key highlight of RabbitMQ 4.2 is the support of AMQP 1.0 as a core protocol offering enhanced features like modified outcome which allow consumers to modify message annotations before requeueing or dead lettering, and granular flow control, which offers benefits including letting a client application dynamically adjust how many messages it wants to receive from a specific queue. Amazon MQ has also introduced configurable resource limits for RabbitMQ 4.2 brokers which you can modify based on your application requirements. Starting from RabbitMQ 4.0, mirroring of classic queues is no longer supported. Non-replicated classic queues are still supported. Quorum queues are the only replicated and durable queue type supported on RabbitMQ 4.2 brokers, and now offer message priorities in addition to consumer priorities.

To start using RabbitMQ 4.2 on Amazon MQ, simply select RabbitMQ 4.2 when creating a new broker using the m7g instance type through the AWS Management console, AWS CLI, or AWS SDKs. Amazon MQ automatically manages patch version upgrades for your RabbitMQ 4.2 brokers, so you need to only specify the major.minor version. To learn more about the changes in RabbitMQ 4.2, see the Amazon MQ release notes and the Amazon MQ developer guide. This version is available in all regions where Amazon MQ m7g type instances are available today. 

 

​Amazon MQ now supports RabbitMQ version 4.2 which introduces native support for the AMQP 1.0 protocol, a new Raft based metadata store named Khepri, local shovels, and message priorities for quorum queues. RabbitMQ 4.2 also includes various bug fixes and performance improvements for throughput and memory management. A key highlight of RabbitMQ 4.2 is the support of AMQP 1.0 as a core protocol offering enhanced features like modified outcome which allow consumers to modify message annotations before requeueing or dead lettering, and granular flow control, which offers benefits including letting a client application dynamically adjust how many messages it wants to receive from a specific queue. Amazon MQ has also introduced configurable resource limits for RabbitMQ 4.2 brokers which you can modify based on your application requirements. Starting from RabbitMQ 4.0, mirroring of classic queues is no longer supported. Non-replicated classic queues are still supported. Quorum queues are the only replicated and durable queue type supported on RabbitMQ 4.2 brokers, and now offer message priorities in addition to consumer priorities. To start using RabbitMQ 4.2 on Amazon MQ, simply select RabbitMQ 4.2 when creating a new broker using the m7g instance type through the AWS Management console, AWS CLI, or AWS SDKs. Amazon MQ automatically manages patch version upgrades for your RabbitMQ 4.2 brokers, so you need to only specify the major.minor version. To learn more about the changes in RabbitMQ 4.2, see the Amazon MQ release notes and the Amazon MQ developer guide. This version is available in all regions where Amazon MQ m7g type instances are available today.   

You can now connect your Apache Kafka applications to Amazon MSK Serverless in the South America (São Paulo) AWS Regions.

Amazon MSK is a fully managed service for Apache Kafka and Kafka Connect that makes it easier for you to build and run applications that use Apache Kafka as a data store. Amazon MSK Serverless is a cluster type for Amazon MSK that allows you to run Apache Kafka without having to manage and scale cluster capacity. MSK Serverless automatically provisions and scales compute and storage resources, so you can use Apache Kafka on demand.

With these launches, Amazon MSK Serverless is now generally available in Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Tokyo), Asia Pacific (Seoul), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Europe (Paris), Europe (London), South America (São Paulo), US East (N. Virginia), US East (Ohio), and US West (Oregon) AWS regions. To learn more and get started, see our developer guide.

 

​You can now connect your Apache Kafka applications to Amazon MSK Serverless in the South America (São Paulo) AWS Regions. Amazon MSK is a fully managed service for Apache Kafka and Kafka Connect that makes it easier for you to build and run applications that use Apache Kafka as a data store. Amazon MSK Serverless is a cluster type for Amazon MSK that allows you to run Apache Kafka without having to manage and scale cluster capacity. MSK Serverless automatically provisions and scales compute and storage resources, so you can use Apache Kafka on demand. With these launches, Amazon MSK Serverless is now generally available in Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Tokyo), Asia Pacific (Seoul), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Europe (Paris), Europe (London), South America (São Paulo), US East (N. Virginia), US East (Ohio), and US West (Oregon) AWS regions. To learn more and get started, see our developer guide.  

AWS Database Migration Service (DMS) Schema Conversion is a fully managed feature of DMS that automatically assesses and converts database schemas to formats compatible with AWS target database services. Today, we’re excited to announce that Schema Conversion now supports conversions from SAP Adaptive Server Enterprise (ASE) database (formerly known as Sybase) to Amazon RDS PostgreSQL and Amazon Aurora PostgreSQL, powered by Generative AI capability.

Using Schema Conversion, you can automatically convert database objects from your SAP (Sybase) ASE source to an to Amazon RDS PostgreSQL and Amazon Aurora PostgreSQL target. The integrated generative AI capability intelligently handles complex code conversions that typically require manual effort, such as stored procedures, functions, and triggers. Schema Conversion also provides detailed assessment reports to help you plan and execute your migration effectively.

To learn more about this feature, see the documentation for using SAP (Sybase) ASE as a source for AWS DMS Schema Conversion and using SAP (Sybase) ASE as a source for AWS DMS for data migration. For details about the generative AI capability, please refer to the User Guide. For AWS DMS Schema Conversion regional availability, please refer to the Supported AWS Regions page.

 

​AWS Database Migration Service (DMS) Schema Conversion is a fully managed feature of DMS that automatically assesses and converts database schemas to formats compatible with AWS target database services. Today, we’re excited to announce that Schema Conversion now supports conversions from SAP Adaptive Server Enterprise (ASE) database (formerly known as Sybase) to Amazon RDS PostgreSQL and Amazon Aurora PostgreSQL, powered by Generative AI capability. Using Schema Conversion, you can automatically convert database objects from your SAP (Sybase) ASE source to an to Amazon RDS PostgreSQL and Amazon Aurora PostgreSQL target. The integrated generative AI capability intelligently handles complex code conversions that typically require manual effort, such as stored procedures, functions, and triggers. Schema Conversion also provides detailed assessment reports to help you plan and execute your migration effectively. To learn more about this feature, see the documentation for using SAP (Sybase) ASE as a source for AWS DMS Schema Conversion and using SAP (Sybase) ASE as a source for AWS DMS for data migration. For details about the generative AI capability, please refer to the User Guide. For AWS DMS Schema Conversion regional availability, please refer to the Supported AWS Regions page.  

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in the Asia Pacific (Melbourne) Region. C7i instances are supported by custom Intel processors, available only on AWS, and offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers.

C7i instances deliver up to 15% better price-performance versus C6i instances and are a great choice for all compute-intensive workloads, such as batch processing, distributed analytics, ad-serving, and video encoding. C7i instances offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads.

C7i instances support new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML. Customers can attach up to 128 EBS volumes to a C7i instance vs. up to 28 EBS volumes to a C6i instance. This allows processing of larger amounts of data, scale workloads, and improved performance over C6i instances.

To learn more, visit Amazon EC2 C7i Instances. To get started, see the AWS Management Console.

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in the Asia Pacific (Melbourne) Region. C7i instances are supported by custom Intel processors, available only on AWS, and offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers. C7i instances deliver up to 15% better price-performance versus C6i instances and are a great choice for all compute-intensive workloads, such as batch processing, distributed analytics, ad-serving, and video encoding. C7i instances offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads. C7i instances support new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML. Customers can attach up to 128 EBS volumes to a C7i instance vs. up to 28 EBS volumes to a C6i instance. This allows processing of larger amounts of data, scale workloads, and improved performance over C6i instances. To learn more, visit Amazon EC2 C7i Instances. To get started, see the AWS Management Console.