AWS Config now supports 77 additional AWS resource types across key services including Amazon EC2, Amazon S3 Files, and Amazon Q Business. This expansion provides greater coverage over your AWS environment, enabling you to more effectively discover, assess, audit, and remediate an even broader range of resources. With this launch, if you have enabled recording for all resource types, then AWS Config will automatically track these new additions. The newly supported resource types are also available in Config rules and Config aggregators. You can now use AWS Config to monitor the following newly supported resource types in all https://docs.aws.amazon.com/config/latest/developerguide/what-is-resource-config-coverage.html where the resources are available: Resource Types: AWS::ApplicationAutoScaling::ScalableTarget AWS::GuardDuty::ThreatEntitySet AWS::PCS::Queue AWS::ApplicationSignals::Discovery AWS::GuardDuty::TrustedEntitySet AWS::QBusiness::DataSource AWS::APS::AnomalyDetector AWS::HealthLake::DataTransformationProfile AWS::QBusiness::Index AWS::APS::ResourcePolicy AWS::InspectorV2::CodeSecurityScanConfiguration AWS::QBusiness::Permission AWS::ARCRegionSwitch::Plan AWS::IoT::Logging AWS::QBusiness::Plugin AWS::Batch::QuotaShare AWS::IoTWireless::WirelessDeviceImportTask AWS::QBusiness::Retriever AWS::Batch::ServiceEnvironment AWS::LicenseManager::Grant AWS::QBusiness::WebExperience AWS::BedrockAgentCore::PaymentConnector AWS::LicenseManager::License AWS::QuickSight::OAuthClientApplication AWS::BedrockAgentCore::ResourcePolicy AWS::Lightsail::DatabaseSnapshot AWS::RTBFabric::InboundExternalLink AWS::Braket::SpendingLimit AWS::MediaConnect::RouterInput AWS::RTBFabric::RequesterGateway AWS::CleanRooms::IdMappingTable AWS::MediaConnect::RouterNetworkInterface AWS::S3Files::AccessPoint AWS::CleanRoomsML::ConfiguredModelAlgorithm AWS::MediaLive::Multiplex AWS::S3Files::FileSystem AWS::CloudWatch::AlarmMuteRule AWS::MediaLive::Node AWS::S3Files::FileSystemPolicy AWS::Connect::UserHierarchyStructure AWS::MediaLive::SdiSource AWS::S3Files::MountTarget AWS::ConnectCampaignsV2::Campaign AWS::MediaPackageV2::ChannelPolicy AWS::SecurityAgent::Application AWS::CUR::ReportDefinition AWS::MediaPackageV2::OriginEndpointPolicy AWS::SecurityAgent::TargetDomain AWS::DataSync::LocationAzureBlob AWS::MediaTailor::ChannelPolicy AWS::SES::MailManagerAddressList AWS::DataSync::LocationFSxONTAP AWS::NeptuneGraph::GraphSnapshot AWS::SSM::MaintenanceWindow AWS::DataSync::LocationFSxOpenZFS AWS::Notifications::EventRule AWS::SSO::Application AWS::EC2::TransitGatewayMeteringPolicy AWS::Notifications::NotificationHub AWS::Timestream::InfluxDBCluster AWS::EC2::VPCCidrBlock AWS::Omics::Configuration AWS::Timestream::InfluxDBInstance AWS::ECR::RegistryScanningConfiguration AWS::Omics::WorkflowVersion AWS::Transcribe::VocabularyFilter AWS::EKS::Capability AWS::OpenSearchServerless::CollectionGroup AWS::Wisdom::AIGuardrail AWS::ElementalInference::Feed AWS::PCAConnectorAD::ServicePrincipalName AWS::Wisdom::Assistant AWS::EntityResolution::IdNamespace AWS::PCS::Cluster AWS::WorkSpacesWeb::NetworkSettings AWS::Glue::Blueprint AWS::PCS::ComputeNodeGroup  

AWS now offers Claude Haiku 5.5, the fastest and most efficient model in the Claude 5.5 family, built for subagents and high-volume, cost-sensitive work. According to Anthropic, it costs around 75% less than Claude Haiku 4.5 for most tasks. Claude Haiku 5.5 is Anthropic's most capable Haiku yet, a significant step up from Haiku 4.5 across coding, tool use, computer use, and agents. It's also the first Haiku with effort controls, so teams can tune cost against intelligence for each task. Haiku 5.5 fits work where speed and cost matter most: real-time experiences like voice agents, live support, and in-app assistants, and high-volume tasks like classification, summarization, and pulling key fields from documents. It's also a fast, cost-efficient subagent. A more capable model like Claude Opus 5.5 can plan the work and hand off well-defined coding, tool use, and browser automation tasks to Haiku, making it practical to run many agents in parallel. Customers have two ways to access Claude Haiku 5.5: Amazon Bedrock and Claude Platform on AWS. Amazon Bedrock gives you Haiku's capabilities while keeping your data within AWS infrastructure with regional data residency and provides access through a unified service with AWS-managed features like Guardrails and Knowledge Bases. To learn more, see the Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html and regional https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html#model-regions-anthropic. Claude Platform on AWS gives you direct access to Anthropic's native platform experience and capabilities via the AWS Console. Build, test, and deploy with the same APIs, features, and console experience you'd get working with Anthropic directly, unified with AWS billing and authentication. To get started, see the https://docs.aws.amazon.com/claude-platform/latest/userguide/welcome.html documentation.

AWS GovCloud (US) now offers Claude Haiku 5.5, the fastest and most efficient model in the Claude 5.5 family, built for subagents and high-volume, cost-sensitive work. According to Anthropic, it costs around 75% less than Claude Haiku 4.5 for most tasks. Claude Haiku 5.5 is Anthropic's most capable Haiku yet, a significant step up from Haiku 4.5 across coding, tool use, computer use, and agents. It's also the first Haiku with effort controls, so teams can tune cost against intelligence for each task. Haiku 5.5 fits work where speed and cost matter most: real-time experiences like voice agents, live support, and in-app assistants, and high-volume tasks like classification, summarization, and pulling key fields from documents. It's also a fast, cost-efficient subagent. A more capable model like Claude Opus 5.5 can plan the work and hand off well-defined coding, tool use, and browser automation tasks to Haiku, making it practical to run many agents in parallel. Amazon Bedrock gives you Haiku's capabilities while keeping your data within AWS infrastructure with regional data residency and provides access through a unified service with AWS-managed features like Guardrails and Knowledge Bases. To learn more, see the Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html and regional https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html#model-regions-anthropic.

Starting today, Amazon EC2 Hpc8a instances are available in Asia Pacific (Singapore) region. These instances are powered by 5th Gen AMD EPYC processors (formerly code named Turin). With a maximum frequency of 4.5GHz, Hpc8a instances deliver up to 40% higher performance and up to 25% better price performance compared to Hpc7a instances, helping customers accelerate compute-intensive workloads while optimizing costs. Compared to Hpc7a instances, Hpc8a instances also provide up to 42% higher memory bandwidth, further improving performance for memory-intensive simulations and scientific computing workloads. Built on the latest sixth-generation https://aws.amazon.com/ec2/nitro/, Hpc8a instances are designed for compute-intensive, latency-sensitive HPC workloads. They are ideal for tightly coupled applications such as computational fluid dynamics (CFD), weather forecasting, explicit finite element analysis (FEA), and multiphysics simulations that require fast inter-node communication and consistent high performance. To get started, sign in to the https://console.aws.amazon.com/ec2/?trk=d8ec3b19-0f37-4f8c-8c12-189f913e205c&sc_channel=el. For more information visit the https://aws.amazon.com/ec2/instance-types/hpc8a/ or https://aws.amazon.com/blogs/aws/amazon-ec2-hpc8a-instances-powered-by-5th-gen-amd-epyc-processors-are-now-available.

AWS Batch now publishes job metrics to Amazon CloudWatch, providing native observability for batch workloads. AWS Batch emits metrics throughout the job lifecycle, giving you visibility into job queue health, failure rates, and job durations. AWS Batch automatically publishes job state transition and duration metrics to the AWS/Batch namespace in Amazon CloudWatch, with JobQueueName dimension. State transition metrics track how many jobs entered a given state, such as submitted, running, succeeded, or failed. Duration metrics track how long jobs spent between states, such as time from submission to runnable or total execution time. You can view these metrics in the AWS Batch console, the Amazon CloudWatch console, or through the AWS CLI and AWS SDKs. AWS Batch CloudWatch metrics are now published in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where AWS Batch is available. For more information, see CloudWatch Metrics page in the https://docs.aws.amazon.com/batch/latest/userguide/using_cloudwatch_metrics.html.

Amazon EC2 now supports AMI tag sharing, a new feature that lets AMI owners make selected tags visible to all AWS accounts an AMI is shared with. Whether an AMI is shared with an account, across an organization, or made public, a shared tag is automatically shared alongside the AMI, eliminating the need to build and maintain custom tag replication workflows. AMI owners simply add the 'ec2:SharedTag/' prefix to any tag key, and every account the AMI is shared with can immediately see it. This removes the operational burden of replicating tags into each account after sharing an AMI. Shared tags are read-only for recipient accounts, so only the owner can create, modify, or delete them. They count only against the owner's 50 tag per resource quota, allowing recipient accounts to continue adding their own private tags without any impact to their limits. This feature is available in all AWS Regions at no additional cost. To learn more, please visit the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html and read the https://aws.amazon.com/blogs/compute/introducing-ec2-ami-tag-sharing-share-ec2-tags-across-aws-accounts/.

AWS Control Tower Account Factory for Terraform (AFT) now supports plan-only customization runs, giving administrators the ability to preview Terraform changes before applying them across their managed accounts. AFT is an open-source Terraform module that automates account provisioning and customization in AWS Control Tower environments. Previously, invoking customizations always triggered a full Terraform apply with no way to preview changes, making it difficult to validate expected outcomes or catch unintended configuration drift before a broad rollout. With plan-only runs, administrators can now trigger a Terraform plan for global and account customizations without applying any changes. This capability supports safe pre-rollout validation, drift detection, and integration into CI/CD review workflows. Plan-only runs are compatible across all AFT-supported Terraform distributions, including open source, Terraform Cloud, and Terraform Enterprise. This feature is available in all AWS Regions where AWS Control Tower Account Factory for Terraform is supported. To get started, see the https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html and the https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.22.0 for configuration details. For more information, see the https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html.

AWS Certificate Manager (ACM) now supports AWS PrivateLink for ACME public certificate issuance, allowing you to request and renew public TLS certificates over a private network path that stays within the AWS network. You can now create a VPC interface endpoint to the ACM ACME service and route issuance traffic from any ACMEv2-compatible client through your VPC. If you're already using ACME with ACM, setup requires no changes to your ACME clients. After you create your managed ACME endpoint in ACM, you create a standard VPC interface endpoint using the VPC console, AWS CLI, or AWS CloudFormation. Private DNS resolves your existing ACME directory URL to the interface endpoint inside your VPC automatically, so the same client configuration and directory URL continue to work with no reconfiguration. Issuance operations—account creation, order creation, domain validation, finalization, and certificate retrieval—then flow over PrivateLink. All activity remains visible in the ACM console with AWS CloudTrail logging and Amazon CloudWatch metrics for auditability. AWS PrivateLink support for ACME certificate issuance is available in all commercial AWS Regions. Standard AWS PrivateLink charges apply for interface endpoints; see the AWS PrivateLink pricing page. For ACM pricing details, see the  https://aws.amazon.com/certificate-manager/pricing/. To get started with ACME and PrivateLink, visit the   https://aws.amazon.com/blogs/aws/automate-public-tls-certificate-issuance-with-acme-support-in-aws-certificate-manager/ or read the https://docs.aws.amazon.com/acm/latest/userguide/acm-acme.html.

Amazon Bedrock now supports GLM 5.3 from Z.ai, giving you a powerful new option for agentic coding and long-horizon software engineering work. Customers using GLM 5.3 on Amazon Bedrock have access to the latest open weight model with the AWS security and compliance posture. GLM 5.3 is Z.ai’s flagship model, a mixture-of-experts architecture with 753B total parameters and roughly 40B active per token, built on the same base model as GLM 5.2 with all improvements driven by scaled post-training. It combines a 1-million-token context window with up to 128K output tokens, and reasoning is always enabled with selectable effort levels so you can trade latency and token consumption against task performance. Bedrock support for GLM 5.3 includes explicit prompt caching with cache points on system prompts and messages, helping you reduce latency and input costs when reusing context across model calls. GLM 5.3 is available to eligible enterprise customers, and is accessible through the US and Global cross-Region inference profiles. To get started with GLM 5.3, you can access the model in thehttps://us-east-1.console.aws.amazon.com/bedrock/home?region=us-east-1#/ or programmatically through supported Amazon Bedrock APIs. For information about supportedhttps://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html, endpoints, APIs, features, inference profiles and pricing, see the https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-zai-glm-5-3.html. To learn more, read the launch https://aws.amazon.com/blogs/machine-learning/introducing-glm-5-3-on-amazon-bedrock/.

Today, we announce the general availability of Amazon Nova 2.5 Sonic, our latest speech-to-speech model for natural, real-time voice agents. This release brings improved reasoning, instruction following, and tool-calling accuracy to real-time voice applications. The model also delivers lower latency, enabling faster, more natural interactions. Nova 2.5 Sonic helps voice agents maintain context, follow multi-step instructions, and use connected tools to complete customer tasks. For example, a customer-service agent can look up an order, check return eligibility, and initiate a return within a conversation. These improvements help developers build more capable voice agents for customer service, personal AI assistants, and real-time conversational applications. Nova 2.5 Sonic builds on existing capabilities, including robust speech understanding, expressive voices in seven languages, and controllable turn-taking, alongside support for voice and text in the same session, asynchronous tool calling, and a 256K context window. Developers can also use Nova 2.5 Sonic with Strands Bidi Agents, now generally available, to build production voice agents in a few lines of code, with longer conversations and connections to other agents. Nova 2.5 Sonic is available in Amazon Bedrock in the US East (N. Virginia), US West (Oregon), Europe (Stockholm), and Asia Pacific (Tokyo) AWS Regions, at the same pricing as Nova 2 Sonic. To learn more, visit the https://aws.amazon.com/nova/models/. To get started, see the https://docs.aws.amazon.com/nova/latest/nova2-userguide/what-is-nova-2.html, and https://strandsagents.com/blog/bidi-agents-now-ga/.

AWS Client VPN now supports device posture assessment, allowing you to verify that connecting user devices meet your security and compliance requirements before granting network access. This feature integrates with your existing device posture providers, so only trusted, compliant devices can access your AWS resources through Client VPN. Previously, Client VPN authenticated users through certificates, SAML, or Active Directory. With device posture assessment, you can now also integrate   https://www.crowdstrike.com/,   https://www.jamf.com/, or   https://jumpcloud.com/ with Client VPN to automatically evaluate device security signals such as compliance scores, encryption status, and risk level before allowing a connection. You define these requirements using   https://cedarpolicy.com/, giving you fine-grained control over which devices can connect. To help you author and validate these policies, Client VPN provides you a Test Policy tool that guides you through creating Cedar policies for your device posture requirements. This feature continuously re-evaluates device compliance during active sessions, and automatically disconnects a session if a device falls out of compliance, such as when risk score or security settings change. You can also use this feature in monitoring-only mode, which logs posture evaluation results without disconnecting sessions, so you can assess the impact of your policies before enforcing them. Device posture assessment works alongside your existing authorization rules to provide defense in depth. This feature is available in all AWS Regions where AWS Client VPN is available, at no additional cost. This feature requires AWS VPN Client version 6.2.0 or later. To learn more about Client VPN: Visit the AWS Client VPN  https://aws.amazon.com/vpn/client-vpn/ Download the  https://aws.amazon.com/vpn/client-vpn-download/ Read the AWS Client VPN  https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html Read the AWS Client VPN  https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html

Amazon Elastic Kubernetes Service (EKS) Auto Mode now lets you tune kubelet settings, Linux kernel sysctls, and hugepages directly in the NodeClass Kubernetes resource. You can now run workloads that require specific node tuning on EKS Auto Mode, which automates node provisioning, scaling, patching, and upgrades for you. With the new advancedCompute field in NodeClass, you can configure user namespaces for rootless container builds in CI/CD pipelines, tune eviction thresholds and container log rotation to protect nodes from disk and memory pressure, raise network and ARP cache limits for large clusters, and pre-allocate 2Mi or 1Gi hugepages for HPC, database, and latency-sensitive workloads. You apply these settings declaratively using the Kubernetes API. EKS Auto Mode validates them, applies them at node boot, and preserves them through scaling and upgrade events, so your workloads get the tuning they need while EKS Auto Mode continues to manage the underlying infrastructure, with no EC2 launch templates, custom AMIs, or privileged DaemonSets to maintain. Amazon EKS Auto Mode advanced compute configuration is available in all AWS Regions where EKS Auto Mode is available. To get started, see the https://aws.amazon.com/eks/auto-mode/ product page, and see https://docs.aws.amazon.com/eks/latest/userguide/create-node-class.html#kubelet-config in the Amazon EKS documentation.

Amazon Redshift now supports the creation and refresh of Apache Iceberg materialized views. Materialized views pre-compute expensive joins and aggregations once and store the results in an Apache Iceberg table in Amazon S3 or Amazon S3 table buckets, registered in the AWS Glue Data Catalog. Materialized views are created using familiar SQL — CREATE MATERIALIZED VIEW ... USING ICEBERG and the results are instantly queryable by any Iceberg-compatible engine, including Amazon Athena, Apache Spark on Amazon EMR and AWS Glue, and third-party engines such as Trino, or Snowflake. Redshift keeps them current by recomputing only what has changed with manual incremental refresh, and because the results are Iceberg tables in the Glue Data Catalog, they are governed and discovered like any other catalog table. Data teams often build analytics in stages, stitching together different engines to clean and transform raw data before serving it. This adds pipeline orchestration overhead and can introduce semantic differences between engines. Iceberg materialized views deliver value in two ways. First, instead of hundreds of users and teams re-running the same expensive joins and aggregations, and re-scanning source tables on every query, you compute the result once and everyone reads the precomputed table. Second, you can run an end-to-end pipeline using a single engine like Apache Spark and now Amazon Redshift, and every downstream consumer shares the same open result without the overhead of orchestrating multiple engines. Either way, the output is an open Iceberg table that any engine can read without copies or conversion. You can still load these tables into Redshift Managed Storage (RMS) as native RMS materialized views for your most performance-sensitive dashboards. You can create Iceberg Materialized Views in any region where Redshift Serverless and provisioned Graviton instances are supported. To learn more, see https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-iceberg.html in the Amazon Redshift Database Developer Guide, the https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html command reference, and the https://aws.amazon.com/blogs/big-data/materialize-once-query-anywhere-introducing-iceberg-materialized-views-in-amazon-redshift/ blog post.

AWS Continuum for Penetration Testing now integrates continuous penetration testing directly into your CI/CD pipeline (public preview) AWS Continuum for Penetration Testing (formerly AWS Security Agent) already provides continuous, on-demand penetration testing without the need to contract third-party pentest vendors. Now, in public preview, Continuum for Penetration Testing shifts security testing even further left by integrating directly into your existing CI/CD systems, making penetration testing a deploy-time event. Development teams ship code daily, but even with on-demand penetration testing available, security validation often happens outside the deployment workflow. CI/CD integration closes this gap. Developers receive findings, including severity, affected endpoints, and remediation guidance, directly in pipeline output. Non-security changes complete with no meaningful delay, and the pipeline automatically re-tests and verifies fixes after remediation without requiring manual re-triggers. Getting started requires no security expertise. An auto-generated pipeline snippet can be pasted into any existing pipeline and is completable in under five minutes. Application context bootstraps automatically on the first run, with no prior full penetration test required. Continuous penetration testing is available today. To get started, visit our https://docs.aws.amazon.com/securityagent/latest/userguide/cicd-pentest.html.

AWS IAM Identity Center helps you configure the single sign-on experience for your workforce to AWS accounts and applications. IAM Identity Center now supports network access controls for Identity Store, which stores your users and groups. You can restrict access to the Identity Store API and the SCIM API based on the network that requests originate from. Your custom applications and user provisioning workflows use the Identity Store API to manage and look up users and groups, and your external identity provider uses the SCIM API to synchronize users and groups. For the Identity Store API, you can require that requests arrive only through allowed VPC endpoints in your account or organization, or from specific source VPCs. For both APIs, you can allow requests only from specific IP ranges. Within the same configuration, you can apply different restrictions to each API. For example, you can require that Identity Store API requests arrive only through VPC endpoints, while allowing SCIM requests from your external identity provider's published IP ranges. Network access controls are optional and turned off by default. Requests that AWS services make on your behalf are exempt. You configure network access controls by using the Identity Store API through the AWS SDKs and AWS CLI. This capability is available in all AWS Regions where IAM Identity Center is offered. To learn more about IAM Identity Center, visit the https://aws.amazon.com/iam/identity-center/. To get started with network access controls, see the https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_UpdateIdentityStore.html.

AWS Batch now supports Amazon EKS access entry authentication for compute environments. EKS access entries provide an API-driven approach to granting IAM principals access to Kubernetes clusters, complementing the existing aws-auth ConfigMap. AWS Batch can now authenticate to your cluster through the access entry mechanism, simplifying cluster setup and authentication lifecycle management. To get started, use the CreateComputeEnvironment or UpdateComputeEnvironment APIs to set accessEntry.desiredState to ENABLED on all AWS Batch compute environments targeting your cluster. AWS Batch creates one access entry per cluster and associates the AWSBatchClusterPolicy with it. You can configure access entries through the AWS CLI, AWS SDKs, or AWS Management Console. Access entry authentication for AWS Batch on Amazon EKS is now supported in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where AWS Batch is available. For more information, see Amazon EKS access entry authentication in the https://docs.aws.amazon.com/batch/latest/userguide/eks-access-entries.html.

The Amazon Web Services (AWS) Advanced Ruby Driver Wrapper is now generally available for use with https://aws.amazon.com/rds/ and https://aws.amazon.com/rds/aurora/ PostgreSQL and MySQL-compatible databases. This advanced database driver reduces RDS Blue/Green switchover, Aurora Global database switchover and database failover times, improving application availability. Additionally, it supports multiple authentication mechanisms for your database, including AWS Secrets Manager authentication, and token-based authentication with AWS Identity and Access Management (IAM). The AWS Advanced Ruby Driver Wrapper builds on top of the community https://rubygems.org/gems/pg (PostgreSQL), and the https://rubygems.org/gems/mysql2 (MySQL) drivers to provide enhanced functionality beyond standard database connectivity. The wrapper is natively integrated with Aurora and RDS databases, enabling it to monitor database cluster status and quickly connect to newly promoted writers during unexpected failures that trigger database failovers. Furthermore, the wrapper seamlessly integrates with the ActiveRecord through provided aws_postgresql and aws_mysql2 adapters, so you can enable it without changing your application code. The driver is available as an open-source project under the Apache 2.0 license. Refer to the instructions on the https://github.com/aws/aws-advanced-ruby-driver-wrapper to get started.

Today, AWS announces feature-level availability notifications and advanced filters for https://builder.aws.com/build/capabilities/explore in AWS Builder Center. Builders can now set availability notifications for AWS service, or to an individual feature of an AWS service, in the AWS Regions they are interested in, and receive an in-app notification and a weekly email digest covering all the capabilities that became available since the builder enabled availability notifications. Setting availability notifications for a service covers every feature within it, and an 'All regions' option covers every Region, including AWS Regions that launch in the future. In addition to the flexibility enabled by feature-level availability notifications, builders can now filter API operations and CloudFormation resources by availability status to see only what is available, or only what is unavailable, in their selected AWS Regions. Builders can also choose how AWS Regions are compared: show all capabilities, show only capabilities with the same availability status in every selected Region, or show only capabilities whose availability differs between selected AWS Regions. With more than 19,000 API operations and more than 5,000 CloudFormation resource types in the comparison, these filters let builders move from a full listing to the specific gaps between two AWS Regions in a few selections. The filters work alongside search and the existing display preferences.

Today, AWS announces enhanced visualization for Amazon Q Developer in the AWS Management Console. Amazon Q now reasons across hundreds of AWS APIs to answer complex questions and deliver complete answers about your entire account—across all regions and services. Beyond the resource tables and cost charts introduced earlier this year, Amazon Q now renders health dashboards with status indicators, time-series charts with trend and anomaly detection, troubleshooting diagnostics, and resource detail views. Previously, asking “Show me the health of my production environment” returned a text summary that customers had to read line by line. Today, Amazon Q orchestrates calls across multiple services, gathers health data, and renders a dashboard with status indicators—giving customers a complete picture at a glance. Similarly, “Graph network utilization for my EC2 instances over 12 hours” now generates an interactive time-series chart with trend lines and anomaly highlighting —making it faster to spot issues and take action. These responses are also noticeably faster, so customers get complete answers in seconds rather than waiting on multi-step, text-only replies. To use Amazon Q in the AWS Management Console, click on the Q icon on the top left after you sign-in to the AWS Management Console. Enhanced visualization features for Amazon Q Developer are available in all AWS Regions where Amazon Q Developer is https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/regions.html. To learn more, see the https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-artifacts.html

AWS Private CA announces detailed certificate issuance logs, a new AWS CloudTrail service event that records the complete certificate content, issuing CA information, requester identity, and signing status for every issuance. You can use these events for compliance auditing, certificate inventory, algorithm migration tracking, and failed-issuance monitoring. Previously, the CloudTrail management event for the IssueCertificate API confirmed that the API call succeeded by providing a certificate ARN but did not capture the certificate content, information about the CA that signed it, or issuances that failed before signing. The new IssueCertificateDetails event captures the complete to-be-signed (TBS) certificate with all X.509 fields and extensions, plus convenience fields for the subject, issuer, serial number, validity period, template, and signing algorithm. Events are emitted for both successful and failed issuance, so pre-signing failures such as name constraints violations now produce a record with a failure explanation. Each event identifies the requester: the account and IAM principal for direct API callers, or the service principal for certificates issued through AWS Private CA connectors or integrated AWS services. In cross-account configurations, the event is delivered to the CA owner account. The event is delivered automatically as a CloudTrail management event, with no configuration or opt-in required and no additional cost beyond standard AWS CloudTrail pricing. Because it flows through CloudTrail, you can act on it in real time with Amazon EventBridge or query it in batch with Amazon Athena for certificate auditing, inventory, tracking, and monitoring. This feature is available in all AWS Regions where AWS Private CA is offered. To learn more, see the https://docs.aws.amazon.com/privateca/latest/userguide/logging-using-cloudtrail-pca.html#pca-service-events.

Last week, we announced a public preview of Amazon Bedrock Managed Agents powered by OpenAI, built on a customized version of OpenAI’s Agents API engineered to be AWS-native and integrated with AWS resources. You can now build agents optimized for OpenAI models that run entirely inside AWS with the identities, permissions, and governance controls you […]

https://aws.amazon.com/ecs/ (Amazon ECS) now supports built-in blue/green, linear, and canary deployment strategies for ECS services using https://aws.amazon.com/vpc/lattice/. Applications that use VPC Lattice for service-to-service communication across VPCs and AWS accounts can now take advantage of managed traffic shifting natively from Amazon ECS when rolling out updates. With this launch, ECS customers using VPC Lattice can shift traffic in a controlled manner during deployments, choosing how quickly traffic moves based on their confidence in each release: all at once with blue/green, in equal increments with linear, or starting with a small percentage with canary. Teams can validate new versions with test traffic before shifting production traffic, and run custom validation steps or manual approvals with deployment lifecycle hooks, including Lambda and pause hooks. These services can also use Amazon CloudWatch alarms and the Amazon ECS deployment circuit breaker to automatically roll back deployments if issues are detected, with bake time keeping the previous version ready for a quick rollback without downtime. To get started, select your VPC Lattice target groups, listener rule, and preferred deployment strategy in the ECS service configuration using the AWS Management Console, AWS CLI, AWS SDKs, or Infrastructure-as-Code tools. This functionality can be enabled for both new and existing ECS services in all AWS https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where VPC Lattice is available. For more information, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-lattice-resources-for-blue-green.html.

Amazon Bedrock AgentCore Gateway now supports TLS certificates signed by private certificate authorities (CAs) on MCP, OpenAPI, and HTTP proxy targets. This feature enables you to connect securely to gateway targets that use TLS certificates issued by your own private certificate authority. With this feature, you can establish native connections to private endpoints in your VPC without requiring an intermediate Application Load Balancer. You can register a private CA certificate with gateway targets that use private endpoints powered by Amazon VPC Lattice. The gateway fetches your PEM-encoded CA certificate from Amazon S3 or AWS Secrets Manager and uses it as the trust anchor for outbound TLS connections. Private CA support is available for MCP server targets, OpenAPI targets, and HTTP proxy (passthrough) targets. Support for private certificates on AgentCore Gateway is available in all Regions where both AgentCore Gateway and Amazon VPC Lattice are available. To learn more, see the https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-vpc-egress.html#gateway-private-certificate.

https://aws.amazon.com/rds/aurora/dsql/ now lets you build an index over a specific subset of a table, storing only qualifying rows rather than every row in the entire table, which improves query performance and lowers index storage cost. Many tables hold a small working set alongside a much larger history, such as open orders among years of completed ones. Add a WHERE clause to CREATE INDEX to index just that working set. The index stays small as the table grows, and queries that target those rows read less data. Aurora DSQL uses a partial index for any query whose filter falls within the index's condition. Partial indexes are available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where Aurora DSQL is available. To learn more, see https://docs.aws.amazon.com/aurora-dsql/latest/userguide/create-index-syntax-support.html in the Aurora DSQL User Guide.

Today, AWS Health introduces the version catalog which provides a centralized source of lifecycle information for software versions across AWS services. The version catalog helps customers move from reactive to proactive management of version upgrades and end-of-support risk. It is available in the AWS Health Dashboard, and customers on Business Support Plus, Enterprise Support, or Unified Operations can use the AWS Health API to integrate lifecycle data into their operational workflows. Customers running applications on AWS need to stay current with software versions to maintain a strong security and operational posture. AWS Health already sends account and resource-specific Planned Lifecycle Events well in advance for major version end-of-support milestones. The version catalog adds service-wide view of supported versions and their timelines, so customers can build upgrade schedules, governance controls, and move to newer supported versions before receiving an account-specific Planned Lifecycle Event. At launch, the version catalog covers multiple AWS services including Amazon RDS, Amazon EKS, and AWS Lambda with more services being added over time. The version catalog is available across all AWS Commercial Regions. To get started, visit the version catalog in the https://health.console.aws.amazon.com/health/home?region=us-east-1#/account/version-catalog or read the https://docs.aws.amazon.com/health/latest/ug/aws-health-version-catalog.html to learn more.

https://aws.amazon.com/elasticache/ for Valkey now publishes OpenTelemetry metrics to Amazon CloudWatch for your node-based clusters, and each metric carries attributes you can filter and aggregate on with Prometheus Query Language (PromQL) expressions. ElastiCache now offers two monitoring modes. Standard monitoring, the existing experience, continues to publish CloudWatch Metrics (Classic) every 60 seconds and now also publishes a core set of OpenTelemetry metrics at the same interval at no additional charge. Detailed monitoring, the new mode, lets you select from the full set of OpenTelemetry metrics and publish them every 15 seconds. With OpenTelemetry metrics, you can detect any node in a cluster nearing its connection limit, break errors down by type during an incident, or forecast if a node will run out of memory. You can run these queries in CloudWatch and Grafana, keeping PromQL skills your team already has. With detailed monitoring, you can balance diagnostic depth and cost, with 15-second metrics enabling detection of short-lived events like latency spikes. The core set of OpenTelemetry metrics also powers https://console.aws.amazon.com/cloudwatch/home#dashboards/insights/elasticache, a pre-built dashboard in Amazon CloudWatch. To get started, open the Metrics tab for a cluster in the https://console.aws.amazon.com/elasticache/, select Detailed, and choose Configure detailed metrics. OpenTelemetry metrics and detailed monitoring are available for node-based Valkey clusters in all AWS Regions where Amazon CloudWatch supports OpenTelemetry metrics. There is no additional charge from ElastiCache for detailed monitoring. https://aws.amazon.com/cloudwatch/pricing/ applies to the detailed monitoring metrics you select, alarms you create, and PromQL API queries you run. To learn more, see https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/otel-metrics.html in the Amazon ElastiCache User Guide.

The AWS MCP Server is now available in six additional AWS Regions: Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Ireland), Europe (London), and US West (Oregon). The AWS MCP Server, part of the https://aws.amazon.com/products/developer-tools/agent-toolkit-for-aws, is a managed Model Context Protocol server that gives AI coding agents a single interface to AWS APIs, so agents can discover and call AWS services without building and maintaining per-service integrations. With this expansion, customers in these Regions can run the AWS MCP Server closer to their developers with lower latency, and keep request data within the Region to meet data residency requirements. For example, a development team in London can point its coding agents at a local endpoint to provision infrastructure, inspect running workloads, and debug failures without routing requests to another geography. The AWS MCP Server can access services in all commercial AWS Regions, while the AWS MCP Server itself runs in the Regions listed below. You can use AWS MCP Server in the following AWS Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (London). To get started, see the following resources: - https://docs.aws.amazon.com/aws-mcp/latest/userguide/getting-started-aws-mcp-server.html - https://docs.aws.amazon.com/general/latest/gr/aws-mcp.html

AWS Brazil now provides an automated distribution workflow through the AWS Brazil 2P Distribution Program that enables eligible non-Brazilian independent software vendors (ISVs) to distribute their Software-as-a-Service (SaaS) product licenses to customers in Brazil. AWS Brazil is the seller of record, acquiring the rights to distribute SaaS product licenses to Brazilian customers and invoicing them in Brazilian Reais (BRL) with applicable Brazilian taxes. The distribution authorizations, seller disbursements, withholding tax calculation, invoicing, and seller reporting are automated. Eligible ISVs agree to the applicable Brazil 2P distribution seller terms to grant AWS Brazil the right to distribute SaaS product licenses locally by creating distribution authorizations through AWS Partner Central or public APIs. AWS Brazil, as the seller of record, creates private offers for Brazilian buyers, determines the buyer-facing price, and automatically generates invoices, calculates and withholds taxes, and disburses payments. ISVs track transactions and payment status through the Seller Insights dashboard.  Buyers in Brazil see private offers priced in USD and invoiced in BRL by AWS Brazil, using the exchange rate on the invoice date. Buyers can pay by credit card (Visa, Mastercard, American Express) or Pay by Invoice (PBI), add a purchase order number, and access invoices in the AWS Billing Console. To learn more about the AWS Brazil 2P Distribution Program, visit the https://docs.aws.amazon.com/marketplace/latest/userguide/brazil-2p-getting-started.html and the https://docs.aws.amazon.com/marketplace/latest/buyerguide/brazil-2p-buyer-faq.html. 

Kubernetes version 1.37 introduced several new features and bug fixes, and AWS is excited to announce that you can now use https://aws.amazon.com/eks/ (EKS) and https://aws.amazon.com/eks/eks-distro/ to run Kubernetes version 1.37. Starting today, you can create new EKS clusters using version 1.37 and upgrade existing clusters to version 1.37 using the EKS console, the eksctl command line interface, or through an infrastructure-as-code tool. Kubernetes version 1.37 introduces several key improvements, promoting the Metrics API to general availability as metrics.k8s.io/v1. This API provides Pod and node CPU and memory usage for the Horizontal Pod Autoscaler and kubectl top. Dynamic Resource Allocation (DRA) device taints and tolerations also graduate to general availability, letting DRA drivers and administrators taint devices such as GPUs so the scheduler avoids them unless tolerated. Horizontal Pod Autoscaler scale-to-zero graduates to beta and is enabled by default, allowing autoscalers with minReplicas: 0 that use object or external metrics to scale workloads to zero Pods when idle and back up when demand returns. To learn more about Kubernetes version 1.37, see our https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html and the Kubernetes project https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md EKS now supports Kubernetes version 1.37 in all the AWS Regions where EKS is available, including the AWS GovCloud (US) Regions. You can learn more about the Kubernetes versions available on EKS and instructions to update your cluster to version 1.37 by visiting EKS documentation. You can use https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html to check if there are any issues that can impact your Kubernetes cluster upgrades. EKS Distro builds of Kubernetes version 1.37 are available through ECR Public Gallery and GitHub. Learn more about the EKS version lifecycle policies in the https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html.

Today, AWS announces that Amazon GuardDuty Runtime Monitoring is now included in the AWS Security Hub Threat Analytics plan. Runtime Monitoring inspects operating system, network, and file activity to surface threats such as container escapes, privilege escalation, and cryptomining on Amazon EC2 instances, Amazon EKS clusters, and Amazon ECS tasks on AWS Fargate. Security Hub now bills this coverage through streamlined pricing. If you have Security Hub enabled in an account and region, you no longer receive separate Amazon GuardDuty charges for Runtime Monitoring for that account and region. That usage now appears on your bill under AWS Security Hub, where Security Hub meters it as a single usage type that spans Amazon EC2, Amazon EKS, and Amazon ECS on AWS Fargate rather than as separate charges for each resource type. Your detection coverage, your finding types, and your GuardDuty security agents all remain the same, and you do not need to reconfigure anything. Please note that the free trial for the Threat Analytics plan remains separate from the free trial for the Security Hub Essentials plan, and that this change does not add a new free trial for Runtime Monitoring. To see how the change affects your bill, you can use AWS Cost Explorer or the Security Hub usage page. For a list of AWS Regions where Security Hub is available, see the https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/. For pricing details, see the AWS Security Hub https://aws.amazon.com/security-hub/pricing/. To get started, visit the AWS Security Hub https://aws.amazon.com/security-hub/ or https://console.aws.amazon.com/securityhub/v2/home.

Today, Amazon Quick adds support for building applications that use live data directly from your Quick datasets, so the KPIs, charts, tables, and insights in your application always reflect the latest data. These applications go beyond viewing data. They facilitate intelligent, data-driven business operations workflows where each person can act on what they see, from handling requests and approvals to triggering the next step. Each application user sees data under their own Amazon Quick permissions, so the row-level and column-level security you already set up is applied. To build one, give the app builder chat agent the name of the dataset you want to use and describe in plain language what you want to build. This lets you enrich an application, such as a team portal that handles requests and approvals and now also shows current pipeline numbers, where each application user sees only the data their permissions allow. This feature is available in https://docs.aws.amazon.com/quick/latest/userguide/apps-limitations.html#apps-regional-availability. To see how it works, read the https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/. To learn more, see https://docs.aws.amazon.com/quick/latest/userguide/connecting-datasets-apps.html in the Amazon Quick User Guide.  

AWS Continuum for Penetration Testing now available in 6 additional Regions AWS Continuum for Penetration Testing (AWS Security Agent) is a managed security service that enables AWS customers to conduct  penetration testing against their web applications and APIs. Previously limited in geographic reach, the service now addresses the growing need for localized security testing by expanding into six additional AWS Regions: Asia Pacific (Seoul), Canada (Montreal), Europe (London), US East (Columbus), Europe (Paris), and Europe (Stockholm). This expansion helps organizations operating across these geographies meet data residency requirements while maintaining robust security testing programs. With this regional expansion, customers can now run penetration testing workloads closer to their production environments. Security and compliance teams can leverage AWS Continuum for Penetration Testing for critical use cases including vulnerability assessments, compliance validation against frameworks such as PCI DSS and ISO 27001, and continuous security posture evaluations. This expansion is now generally available in Asia Pacific (Seoul), Canada (Montreal), Europe (London), US East (Ohio), Europe (Paris), and Europe (Stockholm), with existing supported Regions remaining fully operational. To learn more about AWS Continuum for Penetration Testing and how to get started in these newly supported Regions, visit https://aws.amazon.com/continuum/.

https://aws.amazon.com/aws-cost-management/aws-budgets/ lets you set custom cost and usage thresholds and alerts you by email when your spending crosses the threshold. AWS Budgets now verifies new email subscribers before sending them budget alerts. When you add an email address to a budget notification, AWS Budgets sends a verification email to that address, and the address begins receiving notifications once the recipient confirms it. Verification applies to email addresses added from 9/30/26 onward. Addresses already subscribed on existing budgets are unaffected and need no action. For a new address, the recipient confirms it by following the link in the verification email, which opens the AWS Management Console. The AWS Budgets console shows the verification status of every subscriber, with a resend option for addresses still pending confirmation. AWS Budgets delivers these notifications through AWS User Notifications, and recipients can opt out at any time. AWS Budgets email verification is available in all AWS Regions, except the AWS GovCloud (US) Regions and the China Regions. To learn more, see https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-email-recipients.html in the AWS Billing and Cost Management User Guide.

AWS Transfer Family now lets you choose a custom log group in Amazon CloudWatch Logs for managed workflow execution logs. You can organize workflow logs to monitor individual workflows separately or bring logs from related workflows together. Previously, every workflow attached to a Transfer Family server sent its execution logs to that server’s CloudWatch log group, so you could not set a separate log destination for each workflow. When creating a workflow through the AWS Transfer Family console or API, you can now select a workflow-level log group that is separate from the server’s log group. Transfer Family delivers workflow logs only to the selected group, so no server logging role is required. Workflow logs retain their existing structured JSON format and remain queryable using Amazon CloudWatch Logs Insights. You can also send logs from multiple workflows to a shared log group to create consolidated metrics and dashboards for tracking workflow execution. If you do not select a structured log destination, workflow logs continue using the server’s role-based logging configuration when configured. Existing workflows continue using their current logging configuration. This feature is available in all AWS Regions where Transfer Family managed workflows are offered. To learn more, visit the https://docs.aws.amazon.com/transfer/latest/userguide/transfer-workflows.html.

AWS Security Hub now offers remediation plans that group related exposure findings sharing a root cause. Instead of addressing each exposure individually, you can now fix a single underlying resource, such as a misconfigured setting or overly permissive policy, and resolve or reduce the severity of multiple exposures at once. Each remediation plan includes prioritization guidance (Critical, High, Medium, or Low), impact assessment, and detailed step-by-step instructions with examples in multiple formats including AWS CLI, Terraform, CloudFormation, Python, and CDK. Security Hub automatically prioritizes plans so those reducing the most risk appear first, helping you focus remediation efforts where they matter most. AI agents can also programmatically consume remediation plans through the API to automate security fixes across your environment. Remediation plans are available in every AWS Region where AWS Security Hub is available and at no additional cost under AWS Security Hub Essentials plan. To learn more, visit the https://docs.aws.amazon.com/securityhub/.

Amazon Redshift now supports querying Amazon S3 data lake tables located in a different AWS Region. With enhanced VPC routing, data lake query traffic between Amazon S3 and Amazon Redshift stays within your own VPC. Both capabilities are powered by the integrated data lake query engine that runs directly on the compute of RG provisioned and Serverless clusters. These features are aimed at enterprises with globally distributed data and at security-sensitive customers who need tight control over how their data travels. With cross-Region support, you can use Amazon Redshift to query S3 data in another Region directly, without first copying or replicating it. This makes it easier to run global analytics, consolidate reporting across Regions, and query data that must remain in a specific Region for residency requirements. Cross-Region queries incur standard data transfer charges. Because the query engine runs on your cluster's compute, data moving between Amazon S3 and Amazon Redshift flows entirely over your VPC when you use enhanced VPC routing, never over public networks. Regulated industries such as financial services, healthcare, and government benefit from this feature as it keeps data lake queries within the network boundaries their compliance requirements demand.  Both capabilities work with the integrated data lake query engine, which is available in all regions where RG provisioned and Serverless clusters are available. To learn more, see  https://docs.aws.amazon.com/redshift/latest/mgmt/spectrum-enhanced-vpc.html#spectrum-enhanced-vpc-integrated-engine in the https://docs.aws.amazon.com/redshift/.

https://aws.amazon.com/kinesis/video-streams/ now supports interface VPC endpoints powered by https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html, providing private connectivity from your Amazon Virtual Private Cloud (Amazon VPC). Traffic between your VPC and Kinesis Video Streams stays on the AWS network and is not exposed to the public internet, across the control plane and the video ingestion and playback data planes. Customers with strict security, compliance, or network-isolation requirements can now ingest, store, and play back video without internet gateways, NAT devices, or public IP addresses. For example, connected-camera or IoT video workloads in a private subnet can send media to Kinesis Video Streams and retrieve it for playback and analytics entirely over private connectivity. You create the endpoint from the Amazon VPC console, AWS CLI, or AWS SDKs and can attach a VPC endpoint policy to control access. VPC endpoints for Amazon Kinesis Video Streams are available in all AWS Regions where Amazon Kinesis Video Streams is available, including the AWS GovCloud (US) Regions and the China (Beijing) Region, operated by Beijing Sinnet Technology Co., Ltd. ("Sinnet"). To learn more, see our https://docs.aws.amazon.com/kinesisvideostreams/latest/dg/vpc-interface-endpoints.html.

Today, AWS announces system-managed materialized views for Apache Iceberg. Materialized views let you precompute an expensive query once and reuse the result across engines. Because this result is an open Iceberg table in your data lake, anyone with write access can change it, either through the catalog or by writing to the files in Amazon S3. System-managed materialized views close this gap by only allowing AWS Glue to write the materialized view's data and definition, so the result stays exactly as computed regardless of who has write access to the table or the underlying S3 files. To get started, write the SQL that defines the materialized view and, optionally, a refresh schedule. AWS Glue then computes the results, stores them as a standard Apache Iceberg table in your Amazon S3 Tables bucket, and keeps them current on your schedule. Because the result is an ordinary Iceberg table in the AWS Glue Data Catalog, any Iceberg-compatible engine can read it directly, while the service guarantees no other writer can alter it. You get a governed, always-consistent dataset that you can confidently share. You can still refresh, reschedule, or drop the view whenever you need to. System-managed Apache Iceberg materialized views are available in all regions where Apache Iceberg materialized views are supported. To learn more, see https://docs.aws.amazon.com/glue/latest/dg/materialized-views.html#materialized-views-system-managed in the https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html.

IAM Identity Center helps you connect your workforce identities to AWS once and streamline access management to AWS accounts and applications. You can now replicate IAM Identity Center to opt-in AWS Regions, and between Regions within the AWS GovCloud (US) and AWS China Regions. Previously, multi-Region support was available in the enabled-by-default commercial AWS Regions. This helps you improve the resilience of user access to AWS accounts and deploy AWS applications in the AWS Regions that best align with your business needs. When you enable multi-Region support, IAM Identity Center automatically replicates your identities, entitlements, and other information from the primary Region to additional Regions. If IAM Identity Center is affected by a disruption in the primary Region, users continue to have access to their AWS accounts using already provisioned entitlements in the additional Regions. AWS application administrators can use the standard application deployment workflow to deploy their application in an additional Region while you continue to administer IAM Identity Center in the primary Region. Multi-Region support is available for organization instances that use an external identity provider or the IAM Identity Center directory as the identity source, and requires a multi-Region customer managed KMS key (CMK). When you create a new instance, you can enable multi-Region support with a single click, which also creates the CMK. For existing instances, create a multi-Region CMK in AWS KMS, then configure it in IAM Identity Center. Standard https://aws.amazon.com/kms/pricing/ for storing and using CMKs. IAM Identity Center is provided at no additional cost. For the full list of AWS Regions where multi-Region support is available, see https://builder.aws.com/build/capabilities/explore?tab=service-feature&f=eJxtks1OwzAQhF8F7bk-kFKQKnFF4sCFHusIWck2jTCx5Z8CqvLuGKeOHTu3nW_Wu_LYV9DIsTHYvmPXi0HDHo4UrCbItCH3FDZRVUF9Y-p5NXnsRLSw5nwzmUzHBFUFNQhlzsuGiFa6tgFlOyZZLeRybEQrXdsSPZRoV6LHEj15hFY3pMUsw05cVkiSZcNIg4NRjEeQ2GgzOwFVAD6t6KdJzXJuXg5P3jGoKZqeZ4u_fnKAJUhXazbfvIYNSCUkKvP70nOD6uOEzFiF7utdKUgKewpC-XPGiWPtiu6_cO6nd28HXlvfJDx79vXF12-Wm55MP_ruYKV0oVAY6xHGP20D8yw. To learn more about multi-Region support, see https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html. To find out which AWS applications support deployment in additional Regions, visit https://docs.aws.amazon.com/singlesignon/latest/userguide/awsapps-that-work-with-identity-center.html.

Amazon DynamoDB export to Amazon S3 allows you to export your table data for analytics, data sharing, and other offline uses, as either a full export or an incremental export over a time window. Filtered export enables you to specify exactly which items and attributes to export, producing a dataset that contains only the data relevant to your use case. With filtered export, you use a key condition expression on a key attribute and a filter expression on any attribute to select which items to export, and a projection expression to choose which attributes to include. The export then returns only the items and attributes you want. You can use that subset of data to perform granular data recovery, move a slice of data between accounts, or run analytics while meeting your compliance rules. Filtered export works with both full exports and incremental exports. Filtered export is available in all AWS Regions, except the AWS GovCloud (US) Regions. To get started, see the following resources: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.HowItWorks.html in the DynamoDB developer guide https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.Filtered.html in the DynamoDB developer guide https://aws.amazon.com/blogs/database/introducing-filtered-export-from-amazon-dynamodb-to-amazon-s3/ blog post

AWS announces the preview of AWS Well-Architected Agent, a AI-powered service that is the next-gen evolution of AWS Trusted Advisor and the AWS Well-Architected Tool. The agent analyzes and optimizes AWS infrastructure across cost, security, performance, and reliability, delivering contextualized recommendations prioritized by business goals. It automatically correlates key metrics and application topology against Well-Architected best practices and analyzes Terraform, CDK templates and CloudFormation templates to deliver automation-ready fixes where applicable. With AWS Well-Architected Agent, teams can define their business goals and get prioritized recommendations prioritized by impact and effort at the resource, application, and architecture levels. For example, a team prioritizing reliability can receive recommendations to add multi-AZ failover to a critical database, complete with an SSM runbook that automates the configuration change and a cross-pillar analysis showing how this change affects cost and performance before you commit. Where applicable, recommendations are delivered with SSM runbooks, prescriptive CLI scripts, and guided console walkthroughs so teams can move quickly. The agent can also conduct automated reviews of your IaC templates that include Terraform, CloudFormation, or CDK templates, identifying gaps, and returning the IaC code changes needed to align with Well-Architected best practices. Access to the AWS Well-Architected Agent and its recommendations is available in US East (N. Virginia), US East (Ohio), and US West (Oregon). You can onboard workloads from any AWS commercial Region. AWS Well-Architected Agent is delivered by AWS Support and available to AWS customers with an AWS Support plan. Learn more about AWS Well-Architected Agent in the https://docs.aws.amazon.com/wellarchitected/latest/userguide/wa-agent.html. Get started https://us-east-1.console.aws.amazon.com/wellarchitected/home?region=us-east-1#/.

Introducing the public preview of AWS Well-Architected Agent, an AI-powered service that analyzes your AWS environment to deliver targeted, contextual recommendations for improving your applications' cost, security, performance, and resilience—with ready-to-implement fixes aligned to your business goals.

Today, AWS announces the availability of Amazon DynamoDB Accelerator (DAX) in 17 additional AWS Regions: Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Asia Pacific (New Zealand), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Taipei), Asia Pacific (Thailand), Canada West (Calgary), Europe (Milan), Europe (Zurich), Israel (Tel Aviv), Mexico (Central), AWS GovCloud (US-East), and AWS GovCloud (US-West). DAX is a fully managed, highly available, in-memory cache for Amazon DynamoDB that delivers up to 10 times performance improvement—from single-digit milliseconds to microseconds—even at millions of requests per second. This expansion brings DAX to more geographies, helping customers accelerate read-heavy DynamoDB workloads without managing their own cache infrastructure. With DAX, you can accelerate read-intensive and bursty workloads such as real-time bidding, gaming leaderboards, and retail product catalogs, while offloading read traffic from your DynamoDB tables. DAX is API-compatible with DynamoDB, so you can add microsecond-latency caching to your applications with minimal code changes. Customers in these Regions can now meet local data residency and low-latency requirements while benefiting from DAX's fully managed operations, including automated patching, failover, and scaling. To see the full list of Regions where DAX is available, see the following resources: https://builder.aws.com/build/capabilities.

Route 53 Global Resolver and DNS Firewall now provide DNS analytics and insights through native Amazon CloudWatch integration. These new capabilities enable network administrators and security teams to gain full observability into DNS query patterns, monitor DNS Firewall rule effectiveness, detect anomalous activity, and optimize DNS infrastructure performance. DNS analytics and insights is available in all AWS Regions where Amazon CloudWatch, Route 53 Global Resolver, and DNS Firewall are available. With CloudWatch Metrics and Contributor Insights, customers can search and analyze DNS query logs, create metric filters for specific patterns such as blocked queries and DNS response codes, and set automated alarms. A new Analytics tab in both the Global Resolver and DNS Firewall consoles provides streamlined access to all analytics in one place. For example, customers can create a metric filter for blocked DNS queries by VPC and set an alarm to trigger when more than 10 queries are blocked within an hour, enabling rapid response to potential security threats. Standard https://aws.amazon.com/cloudwatch/pricing/ applies to the metrics that customers opt in to. To learn more, visit the https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html.

AWS Glue Data Catalog now supports table optimization, statistics, and crawlers for Apache Iceberg Version 3 (V3) tables. With these new capabilities, you can automatically maintain V3 tables, optimize them for query performance, and discover them in Amazon S3. With table optimization, you can compact V3 tables using binpack, sort, or z-order strategies to improve query performance, and remove expired snapshots and orphan files to reduce storage costs. These optimizations support V3 data types, including variant, geospatial, and nanosecond-precision timestamps. You can also generate number of distinct values (NDV) statistics for V3 tables, which analytics engines use to plan queries efficiently. In addition, you can use Glue crawlers to discover V3 tables stored in Amazon S3 and register them in Glue Data Catalog, making them available to query with any V3-compatible engines. These capabilities are available for Iceberg V3 tables in all AWS Regions where Glue Data Catalog table optimization, statistics, and crawlers are available. To learn more, see https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html, https://docs.aws.amazon.com/glue/latest/dg/iceberg-column-statistics.html, and https://docs.aws.amazon.com/glue/latest/dg/crawler-data-stores.html in the Glue Developer Guide.

Amazon S3 Object Lock support for variable retention with event holds is now available in AWS GovCloud (US-East) and AWS GovCloud (US-West). Amazon S3 Object Lock variable retention allows you to apply write-once-read-many (WORM) protection to objects whose required retention period starts with a future event, such as a contract closing or an audit completing. You place an event hold with a retention duration on an object and S3 protects the object while the hold is in place. When you release the hold, S3 retains the object for the duration you specified. Unlike legal holds, which end protection immediately upon removal, event holds provide WORM compliance for the required retention period after the triggering event, so you can meet event-based retention requirements without retaining data longer than your policy requires. To learn more, read the https://aws.amazon.com/blogs/storage/flexibly-control-amazon-s3-object-lock-retention-based-on-real-business-events, the https://aws.amazon.com/s3/features/object-lock/, and the https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html. This capability has been https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/whitepapers/compliance/Amazon-S3-Compliance-Assessment-2026.pdf for use in environments subject to SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Regulation 1.31.

Amazon GuardDuty now supports AWS Organizations declarative policies, enabling you to centrally enable GuardDuty threat detection across every account and Region in your AWS organization. Using an organization policy, you can now apply a centrally managed GuardDuty enablement configuration. The configuration applies to existing accounts and is automatically maintained as new accounts join your organization. Enabling GuardDuty across all relevant accounts and Regions helps ensure comprehensive threat detection coverage. Previously, keeping enablement aligned across a large multi-account, multi-Region environment meant configuring GuardDuty's enablement settings separately in each Region, which could drift over time. Now you can define a central GuardDuty policy from your delegated administrator account that sets an enablement baseline across your organization (at the organization root, OUs, or individual accounts). The policy supports a default configuration that applies in every Region where GuardDuty is available, as well as per-Region overrides for Regions that require different enablement. Enablement set by a policy cannot be overridden via the GuardDuty console or API. GuardDuty declarative policy support is available in all AWS commercial Regions and the AWS GovCloud (US) Regions. To get started, make sure the delegated administrator has permission to manage GuardDuty policies. Then, sign in to the GuardDuty console and choose Organization policies, or create a policy programmatically using AWS Organizations APIs. To learn more, see https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-organization-policies.html in the Amazon GuardDuty User Guide and https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_guardduty.html in the AWS Organizations User Guide.

Amazon Redshift now makes it easier to troubleshoot and audit queries on data protected by federated permissions with fine-grained access control (FGAC). Using the new DEBUG permission, data owners can let specific identities see unredacted secure logging records across multiple Redshift data warehouses. With Amazon Redshift federated permissions, you define data permissions once, and Redshift enforces them automatically across every Redshift warehouse in your AWS account. When a query accesses FGAC-protected data, secure logging redacts sensitive values in system table records, such as rewritten query text, error messages, and object names. This protects the producer's data from consumers. At the same time, authorized auditors and administrators need visibility into these records to troubleshoot queries and meet compliance requirements, without turning off secure logging. With the new DEBUG permission, a superuser or database owner can choose which identities see these records without redaction. You grant DEBUG with the standard Redshift GRANT command, typically to an IAM user, IAM role, or IAM Identity Center user or group, so that identity can see unredacted records for its own queries. You can also grant DEBUG to the administrators of a consumer account for full log visibility during troubleshooting and audit. Records authorized for account administrators also stay unredacted when you export Redshift system table data to Amazon S3 Tables. You get precise, auditable control over who can see logs, and secure logging stays on. The feature is available in all AWS Regions where Amazon Redshift is supported. To learn more, see https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions.html,  https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT-usage-notes.html and https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html in the Amazon Redshift documentation.

AWS Secrets Manager now integrates with the https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/recommended-actions.html to surface contextual, actionable suggestions for your secrets directly in the Secrets Manager console. With this launch, you can view tailored recommendations alongside your secrets to improve your security posture and follow best practices without leaving the console. For example, you can identify secrets that need rotation configured, use a customer managed key instead of default service-provided key for encryption, and act on secrets configuration improvements, all from a single view. This feature is available in all AWS Regions in the AWS partition where AWS Secrets Manager is offered, at no additional cost. To get started, visit the https://aws%20secrets%20manager%20console/.

Amazon Quick now supports the hierarchy filter, a single control that lets readers drill through related dimensions such as Region, Country, and City. It replaces several stacked filter controls with one, cutting clutter and guiding readers to their data in fewer clicks. The filter holds up to five dimension levels, arranged broadest to most detailed. Readers open one dropdown and expand each level in turn, with every selection narrowing the next and auto-selecting its parent chain. Authors create it by adding a filter, setting its type to Hierarchy filter, and arranging the fields parent to child. For a retail sales dashboard, instead of stacking Region, Country, and City controls side by side, an author adds one hierarchy filter. A reader expands a region to see its countries, then a country to see its cities, selecting any mix along the way. The relationships are visible in the control, so readers do not need to know which country belongs to which region. The hierarchy filter is available today in all https://docs.aws.amazon.com/quick/latest/userguide/regions.html. To see how it works, read the https://aws.amazon.com/blogs/machine-learning/simplify-dashboard-drill-down-with-the-amazon-quick-sight-hierarchy-filter/. To learn more, see https://docs.aws.amazon.com/quick/latest/userguide/hierarchy-filter.html in the Amazon Quick User Guide.