8/20/2026, 12:00:00 AM ~ 8/21/2026, 12:00:00 AM (UTC)

Recent Announcements

AWS announces the general availability of a new AWS Local Zone in Las Vegas, Nevada

AWS Local Zone in Las Vegas, Nevada is now generally available. The new AWS Local Zone supports Amazon Elastic Compute Cloud (Amazon EC2) C7i, M7i, R7i, and C8gn instances, Amazon Elastic Block Store (Amazon EBS) volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Application Load Balancer, and AWS Direct Connect.\n AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.

To get started, enable the Las Vegas Local Zone (us-west-2-las-2a) from the Regions and Zones tab in the AWS Global View or by using the ModifyAvailabilityZoneGroup API. For pricing information, visit the AWS Local Zones pricing page. To learn more, visit the AWS Local Zones overview page.

Amazon Timestream for InfluxDB now supports customer managed keys

Amazon Timestream for InfluxDB now supports AWS Key Management Service (AWS KMS) customer managed keys for encrypting data at rest in InfluxDB 2 database instances, InfluxDB 2 Read Replicas, and InfluxDB 3 clusters. Customers select a symmetric AWS KMS key when creating a database resource.\n Timestream for InfluxDB uses the selected key to encrypt the underlying database storage for InfluxDB 2 and InfluxDB 3 resources. The key must be in the same AWS account and AWS Region as the database resource. Customers specify the key during resource creation. The key cannot be changed after the resource is created.

Customer managed key support is available through the AWS Management Console, AWS Command Line Interface (AWS CLI), and Timestream for InfluxDB application programming interface (API). The feature is available in all AWS Regions where Timestream for InfluxDB is available. There is no additional Timestream for InfluxDB charge for using customer managed keys. Standard AWS KMS charges apply. Support for Customer managed keys is available in all AWS Regions where Amazon Timestream for InfluxDB is available. To get started, open the Amazon Timestream console. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.

Amazon EKS now supports certificate authority (CA) rotation with automated lifecycle management

Today, Amazon Elastic Kubernetes Service (Amazon EKS) announced certificate authority (CA) rotation, enabling customers to rotate their cluster’s CA through a managed lifecycle with automated safeguards. Each Amazon EKS cluster has its own CA that allows encrypted connections to the cluster’s Kubernetes API, and now you can rotate the CA before it expires to ensure your cluster remains operational and secure.\n Amazon EKS clusters created since launch in 2018 have CAs with a 10-year validity period, and clusters from that era are now approaching the point where CA rotation activities should begin. CA rotation in Amazon EKS is a shared responsibility. Amazon EKS manages the rotation lifecycle and automatically updates AWS-managed components to trust the successor CA. Customers are responsible for replacing their worker nodes and updating external clients to trust the successor CA before it is activated. EKS Auto Mode instances and AWS Fargate nodes are updated automatically by AWS, but customers are still responsible for updating any external clients that connect to the cluster’s API server. Amazon EKS provides automated safeguards to support customers through this process, including advance notifications before CA expiration, automatic appending of a successor CA if one is not created by the customer, and automatic activation if the customer does not activate on their own schedule. A rollback capability allows customers to revert to the previous CA to resolve any issues that may arise with their updates during the transition to the successor CA.

Amazon EKS CA rotation is available at no additional cost in all commercial AWS Regions. To get started with CA rotation, you can use the AWS CLI, EKS APIs, CloudFormation, and the AWS console. For more information, see the Amazon EKS documentation and Deep dive into Amazon EKS certificate authority rotation.

Amazon CloudFront now supports Origin Access Control (OAC) for Amazon S3 Multi-Region Access Points

Starting today, customers can protect their origins using Amazon S3 Multi-Region Access Points (MRAP) by using CloudFront Origin Access Control (OAC) to only allow access from designated CloudFront distributions.\n Customers use Amazon S3 MRAP with CloudFront to serve content from a single global endpoint that automatically routes to the closest available replicated bucket across regions during a cache miss, improving performance and resilience for globally distributed users. Previously, customers had to compute and forward their own Asymmetric Signature Version 4 (SigV4a) Authorization header using a custom Lambda@Edge Function. Now, CloudFront natively signs requests to S3 MRAP origins. Customers get faster cache-miss fills from the nearest region and restricted, OAC-secured MRAP access without  custom Authorization header computation.

CloudFront OAC support for Amazon S3 MRAP origins is available worldwide, except in the CloudFront China region. To get started, use the CloudFront Console, SDK, CLI, or CloudFormation to enable OAC when configuring your Amazon S3 MRAP endpoint with CloudFront. For more information, refer to the CloudFront Developer Guide. There are no additional fees associated with this feature

AWS Partner Central agents MCP Server now supports OAuth with AWS Sign-In

AWS partners can now access AWS Partner Central agents from tools they already use, such as Amazon Quick and Kiro, using OAuth through AWS Sign-In. Partners can authorize agent access with their existing AWS identities, sign-in methods, IAM permissions, and governance controls without installing or maintaining additional authentication software.\n Previously, AWS Partners needed to set up an MCP proxy with SigV4 credentials to access Partner Central agents from their existing tools, or sign in to AWS Partner Central through the AWS Management Console with IAM credentials. OAuth simplifies this by allowing partners to use AWS Sign-In to authorize tools such as Amazon Quick and Kiro to access Partner Central agents. Partners can use OAuth from their existing tools for co-sell engagements, AWS funding applications, and AWS Marketplace seller setup. Administrators can govern access with IAM policies, global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events.

OAuth support is available to AWS Partners through AWS Partner Central agents MCP Server, which is available in the US East (N. Virginia) Region. To learn more, visit  Getting started with the Partner Central agents MCP Server , and  Sign-In with OAuth 2.0 .

ARC Region switch adds Amazon RDS Switchover Read Replica execution block 

Today, we are launching the Amazon RDS Switchover Read Replica execution block in ARC Region switch, which automates recovery orchestration for Amazon RDS databases running Oracle Data Guard in multi-Region workloads. Amazon Application Recovery Controller (ARC) Region switch helps customers orchestrate the failover of their multi-Region applications to achieve a bounded recovery time in the event of a Regional impairment.\n To recover an Amazon RDS database running Oracle Data Guard during a Regional failover, customers perform manual steps to reverse the roles of the primary database and its read replica or to promote a read replica to a primary database instance. Region switch now allows you to automate this recovery with the RDS Switchover Read Replica execution block. The same execution block automates the role transition between the primary database and read replica with zero data loss during a planned failover scenario, or promotion of the read replica to a primary database during an unplanned failover where recovery speed is of the essence. With native cross-account support, you can orchestrate recovery of Amazon RDS instances that are hosted in a different account from your Region switch plan, enabling centralized management of recovery across your organization.

To get started, see the documentation for Amazon RDS Switchover Read Replica execution block . To learn more about ARC Region switch, visit the Application Recovery Controller page .

Generative AI Inference Recommendation for Amazon SageMaker now available in the SageMaker AI Studio

Amazon SageMaker AI now offers Generative AI Inference Recommendations in SageMaker AI Studio, giving customers a guided, low-code, no-code path to find the best inference configuration for their workload. This builds on the API-based launch in April 2026, extending the same benchmarking infrastructure to teams that prefer a visual workflow over programmatic access.\n Deploying generative AI models in production requires finding the right combination of instance type, serving container, and optimization strategy. Getting this right typically involves weeks of manual benchmarking, configuration tuning, and trial-and-error, with no easy way to know if the final setup is actually optimal. With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.

With the new experience, customers describe their workload and what matters most, whether that’s latency, throughput, or cost, and SageMaker AI does the rest. It benchmarks multiple configurations on real GPU infrastructure using NVIDIA AIPerf, applies goal-aligned techniques like speculative decoding for throughput or kernel tuning for latency, and returns ranked, production-ready recommendations with measured performance data. Teams get to a validated configuration in hours instead of weeks, without needing to decide which techniques to apply or how to configure them.

In SageMaker AI Studio under Jobs, Inference optimization, customers select a use-case profile (Interact, Generate, Summarize, or Custom), choose an optimization goal (minimize latency, maximize throughput, or minimize cost), and pick their model from JumpStart, S3, Model Registry, or an existing SageMaker model. Recommendations are ranked by TTFT, inter-token latency, throughput, and cost, and can be compared visually before deploying to a SageMaker real-time endpoint directly from Studio.

There is no additional cost for generating recommendations. Standard compute costs apply for optimization jobs and endpoints provisioned during benchmarking. This capability is available in US East (N. Virginia), US West (Oregon), US East (Ohio), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo). To learn more, visit the blog post or the documentation.

AWS Direct Connect introduces inbound prefix controls and higher prefix scale

Today, AWS Direct Connect announced inbound prefix controls, a new capability that lets you allocate and manage inbound route-prefix allocations for your private and transit virtual interfaces (VIFs) based on your workload’s needs. You can now allocate up to 1,000 prefixes each for IPv4 and IPv6 on your VIFs on dedicated and hosted connections.\n Previously, Direct Connect VIFs accepted a maximum of 100 route prefixes advertised from your on-premises network to AWS on a private or transit VIF. If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections. With inbound prefix controls, you can allocate up to 1,000 prefixes to a single VIF and advertise your routes directly.

Inbound prefix controls introduce new prefix capacity pools at the dedicated connection level and at the Direct Connect gateway (DXGW) level. When you create or update a VIF, you allocate a specific number of prefixes to it, and that allocation draws from the dedicated connection’s pool and the DXGW’s pool when you attach it. This lets you right-size prefix capacity per workload—for example, a large allocation for a transit VIF carrying many routes and a smaller allocation for a private VIF on the same connection. Connection pool sizes scale with connection speed, and link aggregation group (LAG) pools scale with the number of member connections.

You can configure prefix allocations using the AWS Direct Connect console or CLI/API. Inbound prefix controls are available at no additional cost in all commercial AWS Regions where AWS Direct Connect is available, AWS GovCloud Regions (US-East and US-West), as well as the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD.

To learn more, see Inbound prefix controls for AWS Direct Connect in the AWS Direct Connect User Guide.

Amazon Redshift introduces long-term system table retention with Amazon S3 Tables integration

Amazon Redshift now supports long-term retention for system table data through native integration with Amazon S3 Tables. With this feature, you can configure your Redshift system table data retention beyond the current 7-day limit to meet your compliance, auditing, and observability requirements. Once enabled, AWS automatically writes system table data to S3 Tables in Apache Iceberg format and manages partitioning, compaction, and retention.\n Customers use Redshift system tables to monitor query performance, audit data warehouse activity, and meet compliance requirements. Previously, extending retention required building and maintaining custom extract transform load (ETL) pipelines to copy system table data, adding development effort and ongoing operational overhead. Customers operating multiple data warehouses faced additional complexity, relying on Redshift data sharing to consolidate system table data from each warehouse into a central location for cross-warehouse analysis. With this feature, system table data is replicated automatically, eliminating the need for custom ETL pipelines and any resource contention with your production workloads.  If you operate multiple data warehouses, you can consolidate their system table data into a single location for cross-warehouse observability and analysis. Because the data is stored in the open Apache Iceberg format, you can query it through Redshift, Amazon Athena, or any Iceberg-compatible engine, and build observability dashboards using AWS services or third-party tools without additional operations overhead. Additionally, the AWS Agent Toolkit provides skills for querying system table data to surface performance insights and optimization recommendations.

This feature is available for Amazon Redshift Provisioned RG and RA3 instances and Amazon Redshift Serverless in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Africa (Cape Town), Asia Pacific (Hong Kong), Asia Pacific (Taipei), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka), Asia Pacific (Mumbai), Asia Pacific (Hyderabad), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Jakarta), Asia Pacific (Melbourne), Asia Pacific (Malaysia), Asia Pacific (Thailand), Canada (Central), Europe (Frankfurt), Europe (Zurich), Europe (Stockholm), Europe (Milan), Europe (Spain), Europe (Ireland), Europe (London), Europe (Paris), Israel (Tel Aviv), and South America (Sao Paulo). To learn more, visit our documentation or read the blog.

AWS Marketplace now supports category-based notifications and multi-channel delivery for partners

AWS partners can now configure category-based notifications and multi-channel delivery for AWS Marketplace notifications through AWS User Notifications. Previously, partners received their AWS Marketplace notifications through their AWS account’s root email address or custom email aliases, with no way to select notification categories or route each category to the teams responsible for managing it. With this launch, partners can choose which contacts receive each notification category and how those notifications are delivered.\n Four notification categories are available. Product listings notifications cover open product tasks, recurring scan findings for AMI and container products, and Vendor Insights security profile snapshots for SaaS products. Offers and agreements notifications cover private offers, reseller activity, professional services requests, agreement starts and cancellations, cancellation requests, and agreement creation failures. Payments and disbursements notifications cover payment requests, billing adjustments, invoice submission outcomes, payment failures, and disbursement issues. Account management notifications cover business and bank account verification actions, approvals, expirations, and rejections.

By default, notifications are delivered by email to the AWS account’s root email address. Partners can add recipients through additional email addresses and distribution lists. Partners can also receive notifications through the AWS Console Mobile Application or Amazon Q Developer in chat applications such as Slack and Microsoft Teams. After enabling managed notifications, partners can select the contacts and delivery channels that receive each category.

AWS Marketplace category-based notifications are available in all AWS Commercial Regions where AWS Marketplace is available. To learn more, see Managing email notifications for AWS Marketplace events in the AWS Marketplace documentation. To enable managed notifications, visit the AWS User Notifications console.

AWS Blogs

AWS Japan Blog (Japanese)

AWS Architecture Blog

AWS Big Data Blog

AWS Compute Blog

AWS Database Blog

Desktop and Application Streaming

AWS for Industries

Artificial Intelligence

AWS Security Blog

AWS Storage Blog

Open Source Project

AWS CLI