11/13/2026, 12:00:00 AM ~ 11/16/2026, 12:00:00 AM (UTC)

Recent Announcements

Aurora PostgreSQL with express configuration now supported in CloudFormation

Aurora PostgreSQL now supports express configuration in AWS CloudFormation for infrastructure as code deployment. This launch enables you to automate the infrastructure deployment of your Aurora clusters through CloudFormation templates while benefiting from the speed of express configuration.\n Aurora PostgreSQL clusters created with express configuration allow you to create and query an Aurora serverless database in seconds. The new withExpressConfiguration createOnly property on the AWS::RDS::DBCluster resource creates both the cluster and its primary database instance from one property declaration. You don’t need to model or manage the instance separately in your CloudFormation template. This simplifies your templates and makes it easier to manage Aurora clusters with express configuration through infrastructure as code.

The CloudFormation support is available in all AWS Regions where Aurora PostgreSQL with express configuration is offered. To learn more, see the Aurora User Guide and the AWS::RDS::DBCluster resource reference in the AWS CloudFormation documentation.

Grok 4.7 now available on Kiro in AWS GovCloud (US)

A new model is now available in the Kiro IDE and CLI for the AWS GovCloud (US) Regions.\n Grok 4.7 is SpaceXSI’s most capable model for coding and knowledge work. It’s built to stay focused through hard tasks that run for hours, and it checks its work before moving on. Compared with Grok 4.6, it plans and recovers from errors more reliably in repo-scale coding work. Grok 4.7 is available with experimental support and a 500K context window. Requests up to 200K tokens use a 2.7x credit multiplier, and requests over 200K tokens are billed at 5.4x.

Kiro administrators control which models are available to their users, so organizations can align model access with their internal policies.

Ensure your IDE or CLI is updated to the latest version, then restart it to access the new model from the model selector. For more details, visit the GovCloud documentation, the monitoring and tracking guide, or contact your AWS account team. To learn more about Kiro, visit the Kiro product page.

Amazon RDS for Oracle reduces downtime for automatic minor version upgrades and scheduled maintenance

Amazon Relational Database Service (Amazon RDS) for Oracle now reduces downtime for automatic minor version upgrades, as well as minor version upgrades and operating system updates scheduled for your maintenance window. Shorter maintenance makes it easier to stay current on the latest Oracle minor versions and operating system updates with less disruption to your applications. If you turned on automatic minor version upgrade, your DB instances benefit automatically.\n To apply these upgrades and updates, RDS has to set up new resources as part of the maintenance. Previously, RDS set up these resources after the maintenance started, which made your downtime longer. Now, RDS prepares them up to 30 minutes before your maintenance window, while your DB instance keeps serving your workload. When the maintenance window opens, your DB instance is offline for less time because resources required for the maintenance are already prepared. This applies to both Enterprise Edition and Standard Edition 2 DB instances.

The preparation never blocks or delays your own operations, and your DB instance stays available while RDS prepares. If a change that you make conflicts with the preparation, RDS rolls back the staged resources, and your change goes ahead. If the preparation can’t finish, RDS still applies the maintenance in your window, without the preparation. New RDS events tell you when the preparation starts, when it finishes, and when it can’t finish. RDS for Oracle will continue to introduce improvements that further reduce maintenance downtime.

This capability is available at no additional cost in all commercial AWS Regions and the AWS GovCloud (US) Regions where Amazon RDS for Oracle is available. To learn more, see Maintenance preparation, Amazon RDS event categories and event messages, and Maintaining a DB instance in the Amazon RDS User Guide.

AWS Security Hub CSPM now supports centralized configuration with AWS Organizations declarative policies

AWS Security Hub CSPM now supports AWS Organizations declarative policies. You can use them to enable Security Hub CSPM across all accounts and Regions in your organization and to define which security standards and controls are enabled.\nPolicies can apply broadly to every account and Region, or target specific account and Region combinations. Declarative policies help keep each account’s configuration aligned with its attached policy, which helps prevent configuration drift. You can also apply them automatically to new accounts, so each account starts with a baseline configuration as soon as it’s created. Declarative policies are now the recommended way to manage Security Hub CSPM across an organization. They align with how other security services, such as Amazon GuardDuty, Amazon Inspector, and AWS Security Hub allow customers to manage configuration of the service. They also provide more flexibility, such as configuring Region-specific settings. You can continue to use central configuration until you’re ready to migrate. When you are, use the migration process in the Security Hub CSPM console. It converts your existing central configuration policies into declarative policies and applies them to the appropriate accounts and regions. Declarative policies for Security Hub CSPM are available in all commercial, AWS GovCloud (US), and China Regions. To get started, see Migrating central configuration policies. To learn more, see Declarative policies in the AWS Security Hub CSPM User Guide and Security Hub CSPM policies in the AWS Organizations User Guide. To receive notifications about new Security Hub CSPM features and controls, subscribe to the Security Hub SNS topic. You can also try Security Hub CSPM at no cost for 30 days with the AWS Free Tier offering.

Amazon Bedrock AgentCore Identity now supports OAuth 2.0 discovery URLs

Amazon Bedrock AgentCore Identity now supports OAuth 2.0 authorization server discovery URLs for both inbound JWT authorization and outbound OAuth credential providers. This update enables developers to configure AgentCore with OAuth 2.0 authorization servers that do not use OpenID Connect (OIDC).\n Previously, AgentCore Identity accepted only OIDC discovery URLs. Authorization servers that implement OAuth 2.0 without OIDC publish their metadata at a different well-known path and could not be used with AgentCore. With this launch, you can use either OIDC or OAuth 2.0 authorization server discovery URLs when you configure a JWT authorizer or a custom OAuth credential provider on AgentCore.

This feature is available in all AWS Regions where Amazon Bedrock AgentCore is available, at no additional cost. To learn more, see Configure inbound JWT authorizer and Add OAuth client using custom provider in the Amazon Bedrock AgentCore Developer Guide.

AWS Batch on Amazon EKS adds Linux capabilities, seccomp, and pod-level settings

AWS Batch now supports additional Kubernetes security context settings in Amazon EKS job definitions, including Linux capabilities, seccomp profiles, and pod-level settings. For EKS clusters that enforce the Kubernetes Pod Security Standards restricted profile, you can now run AWS Batch jobs with only the privileges and system calls they require.\n To get started, use the RegisterJobDefinition API to set capabilities and seccompProfile in a container’s securityContext, or set securityContext in podProperties to define pod-wide settings such as fsGroup. Container-level settings override pod-level defaults. You can configure these settings through the AWS Management Console, AWS CLI, AWS SDKs, or AWS CloudFormation.

The additional security context settings for AWS Batch on Amazon EKS are now supported in all AWS Regions where AWS Batch is available. For more information, see the Amazon EKS properties section in the AWS Batch User Guide.

AWS Secrets Manager now supports cross-account replication

AWS Secrets Manager now supports cross-account replication, enabling you to maintain a synchronized copy of a primary secret in a secondary AWS account for cross-account access, backup, and disaster recovery. Cross-account replication extends the existing multi-Region replication capability across account boundaries.\n With cross-account replication, platform or security teams can own and rotate a secret centrally, and each consuming account gets a local, always-current copy without any shared KMS keys or cross-account secret policies. The replica secret is a full, independent resource, encrypted with a customer managed KMS key owned by the replica account. Secrets Manager updates it automatically whenever the primary secret’s value changes, including rotations.

You can keep a live copy of critical secrets in a dedicated recovery or failover account, isolated from ransomware or a compromised primary account. If needed, the replica can be promoted to a standalone secret.

Cross-account replication is available in all AWS Regions where Secrets Manager is available. For a list of regions where Secrets Manager is available, see the AWS Region table.

To learn more, see Replicate secrets across AWS accounts in the Secrets Manager User Guide and the AssociateCrossAccountReplica API reference. For pricing details, see AWS Secrets Manager pricing.

Amazon SageMaker Unified Studio now supports layout customization for designations

Amazon SageMaker Unified Studio now supports layout customization, a new capability that gives domain administrators control over which tools and left navigation items project members see based on their designation. Organizations with data engineering, analytics, and machine learning teams on a single platform can configure a layout within each designation definition, and that layout applies across every project in the domain without per-project configuration.\nPreviously, all project members saw the same interface regardless of their role, creating confusion and potential governance issues. With layout customization, administrators define a layout as part of a designation that specifies which left navigation items are visible for project members assigned to that designation. When a project member opens a project, SageMaker Unified Studio resolves the member’s designation and renders only the tools included in their designation’s layout. For example, a SQL analyst designation can be configured to show only the Query Editor, while an ML engineer designation shows notebooks, training jobs, and model endpoints. Navigation items are configurable across categories including Data Analytics, artificial intelligence and machine learning (AI/ML), Generative AI, and IDEs. If a project member navigates directly to a hidden page, they see an access-denied page. For members with multiple designations, visible tools are the union of all their designations’ layouts. New navigation items added to SageMaker Unified Studio remain hidden for designations with a configured layout until an administrator adds them. This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the Designations documentation at https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/designations.html

AWS Blogs

AWS Japan Blog (Japanese)

AWS Architecture Blog

AWS Cloud Operations Blog

AWS Big Data Blog

AWS Database Blog

AWS DevOps & Developer Productivity Blog

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

AWS Security Blog

AWS Storage Blog

Open Source Project

AWS CLI

AWS CDK

Amplify for iOS

Bottlerocket OS

AWS Load Balancer Controller