1/30/2026, 12:00:00 AM ~ 2/2/2026, 12:00:00 AM (UTC)

Recent Announcements

Amazon RDS now supports IPv6 for VPC endpoints of RDS Service APIs

Amazon RDS now supports Internet Protocol version 6 (IPv6) for VPC endpoints of RDS Service APIs, in addition to the existing IPv6 support for public endpoints. This allows you to configure dual-stack (IPv4 and IPv6) connectivity to access RDS Service APIs directly from within your VPC without internet traversal.\n IPv6 provides an expanded address space, enabling you to scale your application on AWS beyond the limitations of IPv4 addresses. With IPv6, you can assign easy to manage contiguous IP ranges to micro-services and can get virtually unlimited scale for your applications. Moreover, with support for both IPv4 and IPv6, you can gradually transition applications from IPv4 to IPv6, enabling safer migration. This feature is available in all commercial AWS regions and AWS GovCloud (US) regions. Get started with the RDS Service APIs here. To learn more about configuring your environment for IPv6, please refer to the IPv6 User Guide.

Amazon SageMaker Unified Studio now supports AWS PrivateLink

Today, Amazon SageMaker announced a new capability allowing you to establish connectivity between your Amazon Virtual Private Cloud (VPC) and Amazon SageMaker Unified Studio without customer data traffic going through the public internet. Customers needing to go beyond the standard data transfer protocol (HTTPS/TLS2) can choose to configure their VPC so data transfer stays within the AWS network.\n Through AWS PrivateLink, Network Administrators can now onboard AWS service endpoints to their VPC used by Amazon SageMaker Unified Studio. With the endpoints are onboarded, IAM policies used by Amazon SageMaker will enforce that customer data stay within the AWS network. Amazon SageMaker private access using AWS PrivateLink is available in all AWS Regions where Amazon SageMaker Unified Studio is supported, including: Asia Pacific (Tokyo), Europe (Ireland), US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), South America (São Paulo), Asia Pacific (Seoul), Europe (London), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), Asia Pacific (Mumbai), Europe (Paris), Europe (Stockholm) To learn more, visit Amazon SageMaker then get started with the network isolation documentation.

Amazon ECS now publishes container health status as a CloudWatch metric

Amazon Elastic Container Service (Amazon ECS) now publishes container health status as a new metric in CloudWatch Container Insights with enhanced observability. Customers can now track the operational health of their containers through a dedicated CloudWatch metric and create alarms to respond proactively to unhealthy containers.\n When customers configure a container health check in the container definition of an ECS task definition, Container Insights now publishes the UnHealthyContainerHealthStatus metric in the ECS/ContainerInsights namespace. The metric reports 0 for HEALTHY and 1 for UNHEALTHY. Container health state information is also available in embedded metric format (EMF) logs, providing additional context while health checks are being evaluated during the UNKNOWN state. The metric is available across cluster, service, task, and container-level dimensions, enabling customers to monitor health at their preferred level of granularity. Customers can create CloudWatch alarms on the metric to receive notifications when containers become unhealthy, allowing teams to take immediate action and maintain application reliability. To get started, enable Container Insights with enhanced observability on your ECS cluster and configure a container health check in your task definition to start collecting the metric in CloudWatch. Container health metric is available in all AWS Regions where Amazon ECS Container Insights is supported. For more information, see the Amazon ECS container health checks documentation and the CloudWatch Container Insights documentation.

AWS Lambda launches enhanced observability for Kafka event source mappings

AWS Lambda launches enhanced observability for Kafka event source mappings (ESM) that provides Amazon CloudWatch Logs and metrics to monitor event polling setup, scaling, and processing state of Kafka events. This capability allows customers to quickly diagnose setup issues and take timely corrective actions to operate resilient data streaming workloads. This capability is available for both Amazon Managed Streaming for Apache Kafka (Amazon MSK) and self-managed Apache Kafka (SMK) event source mappings.\n Customers use Kafka event source mappings (ESM) with their Lambda functions to build mission-critical applications. However, the lack of visibility into event polling setup, scaling, and processing state for events slows down troubleshooting for issues resulting from faulty permissions, misconfiguration, or function errors, which increases mean time to resolution and adds operational overhead. With this launch, customers can enable CloudWatch Logs and metrics to monitor their Kafka polling setup, scaling, and event processing state. Customers can select from multiple log level options that provide logs ranging from warnings and errors to detailed information about event processing progress. Similarly, customers can enable one or more metrics groups—EventCount, ErrorCount, and KafkaMetrics—to monitor various aspects of event processing. Customers can view all their metrics and logs via a dedicated monitoring page on AWS Console for ESM. This capability allows customers to utilize their observability tooling to quickly diagnose setup issues and track performance metrics to meet their stringent business requirements. This feature is available in all AWS Commercial Regions where AWS Lambda’s Provisioned mode for Kafka ESM is available. You can enable ESM logs and metrics for your Kafka ESM using AWS Lambda’s Create and Update ESM APIs, AWS Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS SAM. To learn more about these capabilities, visit the Lambda Kafka ESM developer documentation. These logs and metrics are charged at standard CloudWatch pricing.

New Partner Revenue Measurement gives visibility into AWS service consumption

Today, AWS announces the launch of Partner Revenue Measurement, a new capability that gives AWS Partners visibility into how their solutions impact AWS service consumption across partner-managed and customer-managed accounts.\n Partner Revenue Measurement allows Partners to better understand their AWS revenue impact and product consumption patterns. Partners can now tag AWS resources using the product code from their AWS Marketplace listing with tag key: aws-apn-id and tag value: pc: to quantify and measure the AWS revenue impact of that solution.

Partner Revenue Measurement is generally available in all commercial regions. To learn more about implementing Partner Revenue Measurement, review the onboarding guide for more information.

Amazon GameLift Streams expands streaming capability to six new regions

Starting today, Amazon GameLift Streams provides streaming capabilities in six new locations - eu-west-2 (London), eu-north-1 (Stockholm), sa-east-1 (São Paulo), ap-south-1 (Mumbai), ap-northeast-2 (Seoul), and ap-southeast-2 (Sydney) for all customers.\n New streaming locations enable customers to provide low latency streaming experiences to their players in Europe, South America, India, and Asia regions. Additionally, these locations increase overall GPU availability, enabling customers to scale their streaming services more effectively. The service supports all stream classes in these new regions. To get started, customers need to edit Location and capacity configurations to add new locations to their new or existing stream groups via console or CLI. For more details, see Amazon GameLift Streams developer guide: AWS Regions and remote locations

Amazon EC2 R8a instances are now available in Europe (Spain) and Europe (Frankfurt) Regions

Starting today, Amazon EC2 R8a instances are now available in Europe (Spain) and Europe (Frankfurt) Regions. These instances, feature 5th Gen AMD EPYC processors (formerly code named Turin) with a maximum frequency of 4.5 GHz, deliver up to 30% higher performance, and up to 19% better price-performance compared to R7a instances.\n R8a instances deliver 45% more memory bandwidth compared to R7a instances, making these instances ideal for latency sensitive workloads. Compared to Amazon EC2 R7a instances, R8a instances provide up to 60% faster performance for GroovyJVM, allowing higher request throughput and better response times for business-critical applications. Built on the AWS Nitro System using sixth generation Nitro Cards, R8a instances are ideal for high performance, memory-intensive workloads, such as SQL and NoSQL databases, distributed web scale in-memory caches, in-memory databases, real-time big data analytics, and Electronic Design Automation (EDA) applications. R8a instances offer 12 sizes including 2 bare metal sizes. Amazon EC2 R8a instances are SAP-certified, and providing 38% more SAPS compared to R7a instances. To get started, sign in to the AWS Management Console. For more information about the new instances, visit the Amazon EC2 R8a instance page.

Amazon RDS for Oracle now supports cross-Region replicas with additional storage volumes

Amazon RDS for Oracle now supports cross-Region replicas with additional storage volumes. With additional storage volumes, customers can add up to three storage volumes, each with up to 64 TiB, in addition to the primary storage volume for their database instance. As a result, customers get flexibility to add or remove storage with evolving workload demands, without incurring application downtime, and set up their database instance with up to 256 TiB storage. Now, with support for cross-Region replicas, customers that set up database instances with cross-Region replicas for business-critical applications also get the benefit of using additional storage volumes for storage flexibility.\n When you create a cross-Region replica for a database instance that is set up with additional storage volumes, Amazon RDS for Oracle automatically configures the same storage layout on the replica. Subsequently, you can apply changes to additional storage volumes on the primary instance and the replica using the AWS Management Console, AWS CLI, or AWS SDK. In disaster recovery situations, you can promote a cross-Region replica to serve as the new standalone database, or execute a switchover to reverse roles between the primary database and the replica to meet low recovery point objective (RPO) and recovery time objective (RTO) for business critical applications. You will need an Oracle Database Enterprise Edition (EE) license to use replicas in mounted mode, and an additional Oracle Active Data Guard license to use replicas in read-only mode. We recommend consulting your legal team or licensing expert to verify Oracle license requirements for your specific use case. Amazon RDS for Oracle cross-Region replicas with additional storage volumes is available in all AWS Regions including the AWS GovCloud (US) Regions. To learn more, see Amazon RDS for Oracle User Guide.

AWS Blogs

AWS Japan Blog (Japanese)

AWS Architecture Blog

AWS Cloud Financial Management

AWS Compute Blog

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

AWS Security Blog

Open Source Project

AWS CLI

Amazon EKS Anywhere