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

Recent Announcements

AWS CLI now supports bulk skill updates and version checks for the Agent Toolkit for AWS

Today, AWS expanded the AWS Command Line Interface (CLI) commands for the Agent Toolkit for AWS with two new capabilities that make it easier to keep agent skills up to date. Customers can now run aws agent-toolkit check-skill-updates to compare all installed skills against the latest versions available in the registry, and use aws agent-toolkit update-skill –all to update every outdated skill in a single command.\nThe Agent Toolkit for AWS consists of the AWS MCP Server (which provides a secure, auditable agent interface to 15,000+ AWS APIs), agent skills (which give agents expert guidance across storage, networking, analytics, and more), and plugins (which bundle the MCP server and curate sets of skills into a single install). Previously, customers needed to check and update each skill individually. With these additions to AWS CLI, developers can quickly identify which skills have newer versions available and bring their entire skill set current without managing updates one at a time. This is especially useful for teams that have installed many skills across serverless, storage, networking, analytics, and other domains, and want to ensure their coding agents always operate with the latest guidance. These new commands are added to the existing set of AWS CLI capabilities for the Agent Toolkit, which already allows customers to install, search, and configure the AWS MCP Server and agent skills across Kiro, Claude Code, Codex, Cursor, and other popular coding agents.  To get started, see AWS CLI in the Agent Toolkit for AWS user guide. Make sure you have AWS CLI version 2.37.0 or later installed. The AWS MCP Server is available in the US East (N. Virginia) and Europe (Frankfurt) Regions.

Amazon S3 Vectors introduces metadata pre-filtering for up to 5x higher recall on filtered search

Amazon S3 Vectors now supports pre-filtering, which evaluates metadata filters before running similarity search, returning up to 5x more of the matching vectors when your filter is selective. S3 Vectors also adds a prefix match operator ($startsWith) for filtering on values like paths and URLs. Together, these improvements give your retrieval-augmented generation (RAG), agentic, and semantic-search applications more complete results when you filter, so your applications return more relevant answers.\nS3 Vectors provides native support to store and query vectors in Amazon S3, delivering purpose-built, cost-optimized vector storage and query at billion-vector scale. With this launch, indexes in new vector buckets use metadata pre-filtering by default, with no change to how you write vectors with PutVectors or run filtered queries with QueryVectors. To use pre-filtering on an existing index, update it in place with the UpdateIndexMode API. You can also compare pre-filtering against your current filtering on the same index, using a per-query parameter on QueryVectors, before you update. Metadata pre-filtering is available at no additional cost in all commercial AWS Regions where Amazon S3 Vectors is available, and in the AWS China Regions. We are in the process of deploying this change and plan to complete the deployment in the coming days. To get started, use the AWS CLI, AWS SDKs, or the Amazon S3 console. To learn more, visit the Amazon S3 Vectors documentation and the AWS News blog.

Amazon Managed Grafana now supports creating Grafana 13.2 workspaces

Amazon Managed Grafana now supports creating new workspaces with Grafana version 13.2. This release brings features from open-source Grafana versions 13.0 to 13.2, including Git Sync for dashboards, dynamic dashboards, and PromQL query support in the Amazon CloudWatch data source plugin.\nWith Git Sync, you can treat dashboards as code by linking a workspace to a Git repository, enabling version control for tracking, reviewing, and reverting dashboard modifications. Dynamic dashboards provide a more adaptable approach to layout and paneling, constructing responsive views driven by conditions that respond to data and variables. The Amazon CloudWatch data source plugin now supports PromQL queries, allowing you to use Prometheus Query Language to query metrics that CloudWatch ingests via its OpenTelemetry (OTLP) endpoint, complementing the existing Metric Search and Metrics Insights query types. Grafana 13.2 is available in all AWS regions where Amazon Managed Grafana is generally available. To learn more about creating Amazon Managed Grafana workspaces with version 13.2, visit the user documentation. For more information about Amazon Managed Grafana features and pricing, visit the product page and pricing page.

OpenAI GPT-6 Astra now supports UltraFast mode on Amazon Bedrock

Today, AWS announces the availability of UltraFast mode for GPT-6 Astra from OpenAI on Amazon Bedrock. Ultrafast is a premium speed tier for GPT-6 Astra built for workloads where speed matters most. According to OpenAI, Ultrafast delivers up to 6x faster inference in the API, with up to 300 tokens per second. The Amazon Bedrock inference engine delivers the performance, security, and reliability required for production workloads.\nUse GPT-6 Astra Ultrafast for latency-sensitive applications such as real-time coding assistants, interactive agents, and customer-facing experiences that require fast, high-quality responses. Established AWS controls help you secure workloads, govern access, and audit model invocation activity. You can get started in the Amazon Bedrock console or programmatically through supported Amazon Bedrock APIs. For information about supported AWS Regions, endpoints, APIs, features, inference profiles and pricing, see the Amazon Bedrock documentation.

AWS Parallel Computing Service now supports scaling logs

AWS Parallel Computing Service (AWS PCS) now supports scaling logs, which record how AWS PCS scales the compute node groups in your cluster. Each log entry records one state transition for one compute node—for example, an instance launch, a node registration, a scale-down, or a launch failure with its reason. Using scaling logs, you can more easily troubleshoot scaling issues. For example, you can determine why a compute node group did not reach its target size, which launches failed for capacity reasons, and when a specific node started or stopped. Scaling log delivery is opt-in, and you can configure AWS PCS to emit scaling logs to Amazon CloudWatch Logs, Amazon S3, and Amazon Data Firehose.\nAWS PCS is a managed service that simplifies running and scaling HPC workloads on AWS using Slurm. You can build complete, elastic environments that integrate compute, storage, networking, and visualization tools, while the service handles cluster operations with managed updates and built-in observability features. This feature is available in all AWS Regions where AWS PCS is available. To get started, see the AWS PCS User Guide.

Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads

Amazon Aurora serverless now scales in even larger steps, adding up to 16 ACUs to its current capacity within a second and continuing to scale up to 256 ACUs as your workload grows. With this launch, your workload will scale faster and reach capacity that it requires. When the workload finishes, Aurora serverless automatically scales down to zero, so you only pay for what you use. This makes it especially well-suited for agentic AI applications, which typically have bursts of activity, long idle windows, and unpredictable traffic patterns.\nThis enhancement is enabled by default on all Aurora serverless clusters running on platform version 3 or 4, with no configuration changes required. Existing clusters on platform versions 1 and 2 can upgrade directly to the latest platform version 4 to benefit from these improvements. You can verify your cluster’s platform version in the AWS Management Console under the instance configuration section, or via the RDS API’s ServerlessV2PlatformVersion parameter. For pricing details and Region availability, visit Amazon Aurora Pricing. To learn more, read the Aurora serverless scaling documentation, and get started by creating an Aurora serverless database in just a few steps in the AWS Management Console.

Amazon Aurora and RDS now support AMD-based R8a instances

Amazon Aurora and Amazon RDS now support R8a database instances powered by 5th generation AMD EPYC processors, expanding the choice available for your database workloads. Each vCPU in R8a database instances corresponds to a physical CPU core, which delivers consistent per-core performance. For workloads with high I/O requirements, R8a instances provide up to 75 Gbps of network bandwidth and 60 Gbps of Amazon EBS bandwidth. All R8a instances are built on the AWS Nitro System using sixth-generation Nitro Cards.\nR8a database instances are supported for Amazon Aurora PostgreSQL-Compatible Edition, Amazon Aurora MySQL-Compatible Edition, RDS for PostgreSQL, MySQL and MariaDB. R8a database instances are available in US East (N. Virginia, Ohio), US West (Oregon), Canada (Central), Asia Pacific (Tokyo, Taipei) and Europe (Ireland, Frankfurt, Spain) regions.  You can get started with R8a database instances through the Amazon RDS Management Console or by using the AWS Command Line Interface (CLI). For the specific engine versions that support these instance classes, see the Aurora and RDS documentation. For pricing, see the Amazon Aurora pricing page  and the Amazon RDS pricing page.

Amazon RDS now supports AMD-based M8a instances

Amazon RDS for PostgreSQL, MySQL, and MariaDB now support M8a database instances powered by 5th generation AMD EPYC processors, expanding the choice available for your database workloads. Each vCPU in M8a database instances corresponds to a physical CPU core, which delivers consistent per-core performance. For workloads with high I/O requirements, M8a instances provide up to 75 Gbps of network bandwidth and 60 Gbps of Amazon EBS bandwidth. All instances are built on the AWS Nitro System using sixth-generation Nitro Cards.\nM8a database instances are available in US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Tokyo, Hyderabad) and Europe (Ireland, Frankfurt, Spain) regions. You can get started with M8a database instances through the Amazon RDS Management Console or by using the AWS Command Line Interface (CLI). For the specific engine versions that support these instance classes, see the RDS documentation. For pricing , see the Amazon RDS pricing page.

Aurora PostgreSQL now supports querying of Apache Iceberg and Parquet data

Starting today, you can directly query operational data together with data stored in data lakes in Apache Iceberg and Parquet formats using your existing PostgreSQL applications and tools, without extract, transform, and load (ETL) pipelines or data duplication.\nApplications increasingly need access to data from data lakes, often stored in Apache Iceberg and Parquet formats, to make more informed decisions and automate business processes. Accessing it has typically required pipelines that copy data from your data lake into Aurora, driving up costs and engineering work as schemas evolve. With this launch, you can create PostgreSQL foreign tables that reference your Iceberg or Parquet data in Amazon S3, Amazon S3 Tables, or AWS Glue Data Catalog. When customers query these foreign tables, Aurora uses DuckDB’s high-performance query engine, embedded in PostgreSQL, to execute the query against the underlying Iceberg and Parquet data. Your existing applications and BI tools continue to use the same PostgreSQL interface. You can also query tables from external Iceberg REST Catalog (IRC)-compatible catalogs federated through AWS Glue Data Catalog, without moving or duplicating data. For latency-sensitive workloads, you can materialize Iceberg or Parquet data into native Aurora PostgreSQL tables using standard SQL statements, without an ETL pipeline. The capability is generally available on Aurora PostgreSQL starting 17.11, 18.6 and higher in all AWS commercial and GovCloud (US) Regions, at no additional charge. To get started, use the Amazon RDS console or any PostgreSQL client. To learn more, see the blog post or documentation.

Amazon RDS for MySQL supports MySQL 26.7 in Amazon RDS Database Preview Environment

Starting today, Amazon RDS for MySQL 26.7 is available in the Amazon RDS Database Preview Environment, allowing you to evaluate the pre-release of MySQL 26.7 on Amazon RDS for MySQL.\nMySQL 26.7 is the first Innovation release to adopt the new YY.M (Year.Month) calendar versioning model. It includes bug fixes, security patches, and new features such as Change Stream Applier, a modular replication applier that improves apply throughput and backlog recovery in test workloads. For more details, refer to the MySQL 26.7 release notes. Amazon RDS Database Preview Environment database instances are retained for a maximum of 60 days and are automatically deleted after the retention period. Database snapshots created in the Preview Environment can only be used within the Preview Environment. Preview Environment database instances are priced according to pricing in the US East (Ohio) Region. To learn more, visit the Amazon RDS Database Preview Environment documentation.

Uncover blind spots in AWS data plane operations with CloudTrail Event Coverage

AWS CloudTrail introduces Event Coverage, a new console experience that gives customers visibility into their data plane operations coverage at the account and organization level. You can now see which AWS services and resource types in your environment have data event logging enabled and which do not. This helps you quickly identify gaps in your logging posture without manually scanning accounts in your organization.\nData events enable you to track data plane operations in AWS services. For example, you can log Amazon S3 object-level operations like GetObject and PutObject to detect unauthorized data access or exfiltration attempts. Without comprehensive data events coverage, these activities can go unnoticed, leaving blind spots in your security monitoring. With Event Coverage, you can view coverage across all supported data event sources in one place and subscribe to data events directly from the dashboard. This makes it easier to close coverage gaps in a few clicks, especially for organizations managing multiple accounts where tracking coverage across services can be time-consuming. You can access Event Coverage from the AWS CloudTrail console. This feature is available in all commercial AWS Regions where AWS CloudTrail is supported. To learn more about logging Data Events, visit the AWS CloudTrail documentation.

Partner Revenue Measurement adds Multi-Partner support to Resource Tagging

Partner Revenue Measurement (PRM) provides measurement of AWS consumption driven by Partner solutions. Today, PRM adds multi-Partner support to Resource Tagging, so that multiple AWS Partners can receive revenue attribution for the same AWS resource. Previously, a resource carried only one Partner tag, aws-apn-id, so when multiple Partners contributed to the same workload, only one Partner received attribution. \nWith this update, each Partner tags the resources they contribute to using a new key in the format aws-apn-id-. When more than one Partner tags the same resource, each tagged Partner receives revenue attribution. This benefits Partners that co-deliver solutions, such as a consulting Partner that deploys and operates a software Partner’s product in an AWS account. The existing aws-apn-id key continues to work, and resources tagged with it require no additional changes.   Multi-Partner support in Resource Tagging is available today in all commercial AWS regions. Revenue attributed through the existing aws-apn-id key and the new key both appear under the “Resource Tagging” method in the Attributed Revenue Dashboard, with no changes to the dashboard. To learn more, see the Partner Revenue Measurement product page and the Resource Tagging onboarding guide.

AWS Transfer Family now automatically approves SFTP connector quota increases up to 1,000

AWS Transfer Family now automatically approves requests to increase your SFTP connector quota up to 1,000 connectors per AWS account in each AWS Region. You can add more connectors as your file transfer needs grow without waiting for manual approval.\nThe default quota remains 100 SFTP connectors per AWS account in each AWS Region, and you continue to request increases in the AWS Service Quotas console. Previously, all quota increases required manual approval. Automatic approval applies to connectors using either service-managed or Amazon VPC Lattice egress. If you need more than 1,000 connectors, submit a higher quota request in the Service Quotas console. This feature is available in all AWS Regions where Transfer Family SFTP connectors are offered. To learn more, visit the AWS Transfer Family SFTP connectors documentation.

AWS accounts now support phone number verification

AWS Accounts now support phone number verification for primary contact phone numbers. Previously, phone numbers in AWS account contact information were validated for format but never verified through an out-of-band mechanism. Now, customers can verify their phone numbers via SMS one-time passcode (OTP).\nTo verify a phone number, customers initiate verification through the AWS Management Console or programmatically via the new SendPhoneNumberVerification API, which sends a 6-digit OTP. After entering the code, the VerifyPhoneNumber API validates and persists the verified status. When a phone number is changed through the PutContactInformation API, customers will be prompted to complete verification again. The GetContactInformation API now exposes verification status, enabling customers to confirm which phone numbers have been verified. For AWS Organizations customers, phone number verification supports inheritance from the management account. When a verified phone number is applied to member accounts from the management account, those member accounts inherit the verified status if the number matches the management account, eliminating the need to verify the same number across thousands of accounts. Member accounts that independently change their own phone numbers will need to complete verification separately. This feature is available in all AWS commercial regions. To learn more about phone number verification, visit the AWS Account Management documentation.

AWS IAM Identity Center Identity Store APIs now accept resource ARNs in addition to resource IDs

AWS IAM Identity Center’s Identity Store APIs now accept the Amazon Resource Name (ARN) for a user, group, group membership, or identity store anywhere the APIs previously accepted the resource ID. ARN support is additive and existing integrations continue to work unchanged.\nIf you build on the Identity Store APIs, you may already hold resource ARNs — for example, from IAM policy evaluation, CloudTrail events, or cross-service integrations. Previously, you had to strip the ARN down to the resource ID before calling Identity Store APIs. With this change, you can pass either form directly, simplifying application code and eliminating potential parsing errors. The change applies to every request identifier field across the Identity Store API surface. Responses continue to return resource IDs as they did before. Malformed or wrong-resource-type ARNs return a ValidationException. This capability is available in all AWS Regions where AWS IAM Identity Center is offered, at no additional cost. To learn more, see the Identity Store API Reference.

AWS Marketplace launches an AI agent skill for usage-based metering integration

AWS announces the general availability of the AWS Marketplace metering agent skill, an AI-guided experience that helps sellers build, deploy, and validate a usage-based (pay-as-you-go) SaaS metering integration from within their AI coding assistant. The skill guides sellers through the complete integration journey — gathering their product type, pricing model, and usage dimensions; recommending the correct metering API; generating integration code and a customized AWS CloudFormation stack tailored to their configuration; and running an end-to-end test against AWS Marketplace before any production code ships.\nPreviously, sellers integrating metering navigated documentation, workshops, and trial-and-error API calls, where common mistakes such as mismatched dimension names or invalid timestamps create billing gaps discovered days later. The metering agent skill cross-validates dimensions against the seller’s actual product configuration, applies built-in guardrails, deploys a serverless metering pipeline (using ResolveCustomer API, BatchMeterUsage API, and Amazon EventBridge for subscription events), and verifies the integration with a live test. It also supports Concurrent Agreements and helps existing sellers inspect, debug, and analyze their metering records. The skill is available through the AWS MCP Server in any AI coding assistant that supports MCP, including Amazon Q Developer, Kiro, and other MCP-compatible clients, with no plugin installation required. To get started, visit Configuring metering for usage with SaaS subscriptions.

Amazon S3 Tables now support all Apache Iceberg V3 data types

Amazon S3 Tables add support for geometry, geography, unknown, and nanosecond timestamp data types, along with column default values, as defined in the Apache Iceberg Version 3 (V3) specification. You can now store geospatial coordinates and nanosecond-precision event times natively instead of encoding them in strings or integers. This helps simplify data architecture while improving storage efficiency and performance. With this launch, S3 Tables support all data types introduced in V3, adding to existing support for the Variant data type, deletion vectors, and row lineage.\nGeometry and geography columns store points, lines, and polygons natively, so fleet tracking and asset mapping workloads can filter on location at query time. Nanosecond timestamps let telemetry and financial workloads record event times at source precision. Column default values populate a newly added column for existing rows, with no backfill required. S3 Tables provide automatic table maintenance and compaction for Apache Iceberg tables, so tables using V3 data types stay performant and cost effective as data scales. Support for these data types in S3 Tables is available in all AWS Regions where S3 Tables are available. To learn more, see Amazon S3 Tables, Apache Iceberg V3 on AWS, and the AWS Prescriptive Guidance for working with Iceberg table format specification version 3.

AWS Blogs

AWS Japan Blog (Japanese)

AWS News Blog

AWS Open Source Blog

AWS Architecture Blog

AWS Contact Center

Containers

AWS Database Blog

AWS DevOps & Developer Productivity Blog

AWS HPC Blog

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

Open Source Project

AWS CLI

AWS CDK