10/24/2025, 12:00:00 AM ~ 10/27/2025, 12:00:00 AM (UTC)

Recent Announcements

Amazon EC2 Auto Scaling now supports predictive scaling in six more regions

Customers can now enable predictive scaling for their Auto Scaling groups (ASGs) in six more regions: Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Israel (Tel Aviv), Canada West (Calgary), Europe (Spain), and Europe (Zurich). Predictive Scaling can proactively scale out your ASGs to be ready for upcoming demand. This allows you to avoid the need to over-provision capacity, resulting in lower EC2 cost, while ensuring your application’s responsiveness. To see the list of all supported AWS public regions and AWS GovCloud (US) regions, click here.\n Predictive Scaling is appropriate for applications that experience recurring patterns of steep demand changes, such as early morning spikes when business resumes. It learns from the past patterns and launches instances in advance of predicted demand, giving instances time to warm up. Predictive scaling enhances existing Auto Scaling policies, such as Target Tracking or Simple Scaling, so that your applications scale based on both real-time metrics and historic patterns. You can preview how Predictive Scaling works with your ASG by using the “Forecast Only” mode. Predictive Scaling is available as a scaling policy type through AWS Command Line Interface (CLI), EC2 Auto Scaling Management Console, AWS CloudFormation and AWS SDKs. To learn more, visit the Predictive Scaling page in the EC2 Auto Scaling documentation.

Amazon VPC Reachability Analyzer and Amazon VPC Network Access Analyzer are now available in AWS GovCloud (US) Regions

With this launch, Amazon VPC Reachability Analyzer and Amazon VPC Network Access Analyzer are now available in both AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions.\n VPC Reachability Analyzer allows you to diagnose network reachability between a source resource and a destination resource in your virtual private clouds (VPCs) by analyzing your network configurations. For example, Reachability Analyzer can help you identify a missing route table entry in your VPC route table that could be blocking network reachability between an EC2 instance in Account A that is not able to connect to another EC2 instance in Account B in your AWS Organization. VPC Network Access Analyzer allows you to identify unintended network access to your AWS resources, helping you meet your security and compliance guidelines. For example, you can create a scope to verify that all paths from your web-applications to the internet, traverse the firewall, and detect any paths that bypass the firewall. For more information, visit documentation for VPC Reachability Analyzer and VPC Network Access Analyzer. For pricing, refer to the Network Analysis tab on the Amazon VPC Pricing Page.

Aurora DSQL now supports resource-based policies

Amazon Aurora DSQL now supports resource-based policies, enabling you to simplify access control for your Aurora DSQL resources. With resource-based policies, you can specify Identity and Access Management (IAM) principals and the specific IAM actions they can perform against your Aurora DSQL resources. Resource-based policies also enable you to implement Block Public Access (BPA), which helps to further restrict access to your Aurora DSQL public or VPC endpoints.\n Aurora DSQL support for resource-based policies is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Osaka), Asia Pacific (Tokyo), Asia Pacific (Seoul), Europe (Ireland), Europe (London), Europe (Paris), and Europe (Frankfurt). To get started, visit the Aurora DSQL resource-based policies documentation.

AWS Transfer Family now supports changing identity provider type on a server

AWS Transfer Family now enables you to change your server’s identity provider (IdP) type without service interruption. This enhancement gives you more control and flexibility over authentication management in your file transfer workflows, enabling you to adapt quickly to changing business requirements.\n AWS Transfer Family provides fully managed file transfers over SFTP, FTP, FTPS, AS2, and web-browser based interfaces. With this launch, you can now dynamically switch between service managed authentication, Active Directory, and custom IdP configurations for SFTP, FTPS, and FTP servers. This enables you to implement zero-downtime authentication migration and meet evolving compliance requirements.  Changing IDP type is available in all AWS Regions where the service is available. To learn more, visit the Transfer Family User Guide.

New Amazon CloudWatch metrics to monitor EC2 instances exceeding I/O performance

Today, Amazon announced two new Amazon CloudWatch metrics that provide insight into when your application exceeds the I/O performance limits for your EC2 instance with attached EBS volumes. These two metrics, Instance EBS IOPS Exceeded Check and Instance EBS Throughput Exceeded Check, monitor if the driven IOPS or throughput is exceeding the maximum EBS IOPS or throughput that your instance can support.\n With these two new metrics at the instance level, you can quickly identify and respond to application performance issues stemming from exceeding the EBS-Optimized limits of your instance. These metrics will return a value of 0 (performance not exceeded) or a 1 (performance exceeded) when your workload is exceeding the EBS-Optimized IOPS or throughput limit of the EC2 instance. With Amazon CloudWatch, you can use these new metrics to create customized dashboards and set alarms that notify you or automatically perform actions based on these metrics, such as moving to a larger instance size or a different instance type that supports higher EBS-Optimized limits. The Instance EBS IOPS Exceeded Check and Instance EBS Throughput Exceeded Check metrics are available by default at a 1-minute frequency at no additional charges, for all Nitro-based Amazon EC2 instances with EBS volumes attached. You can access these metrics via the EC2 console, CLI, or CloudWatch API in all Commercial AWS Regions, including the AWS GovCloud (US) Regions and China Regions. To learn more about these CloudWatch metrics, please visit the EC2 CloudWatch Metrics documentation.

AWS Lambda increases maximum payload size from 256 KB to 1 MB for asynchronous invocations

AWS Lambda increases asynchronous invocations maximum payload size from 256 KB to 1 MB, allowing customers to ingest richer, complex payloads for their event-driven workloads without the need to split, compress, or externalize data. Customers invoke their Lambda functions asynchronously using either Lambda API directly, or by receiving push-based events from various AWS services like Amazon S3, Amazon CloudWatch, Amazon SNS, Amazon EventBridge, AWS Step Functions.\n Modern cloud applications increasingly rely on AWS Lambda’s asynchronous invocations and its integration with various AWS serverless services to build scalable, event-driven architectures. These applications often need to process rich contextual data, including large-language model prompts, telemetry signals, and complex JSON structures for machine learning outputs. With increase in maximum payload size to 1MB for asynchronous invocations, developers can streamline their architectures by including comprehensive data, from detailed user profiles to complete transaction histories, in a single event, eliminating the need for complex data chunking or external storage solutions. This feature is generally available in all AWS Commercial and AWS GovCloud (US) Regions. Customers can start sending asynchronous invocation payloads up to 1 MB using Lambda’s invoke API. Customers are charged for 1 request per each asynchronous invocation for first 256 KB. Individual payload size beyond 256 KB is charged 1 additional request for each 64 KB of chunk up to 1 MB. To learn more, read Lambda asynchronous invocation documentation and AWS Lambda pricing.

Amazon SageMaker Unified Studio supports Amazon Athena workgroups

Data engineers and data analysts using Amazon SageMaker Unified Studio can now connect to and run queries with pre-existing Amazon Athena workgroups. This feature enables data teams to run SQL queries in SageMaker Unified Studio with the default settings and properties from existing Athena workgroups. Since Athena workgroups are used to manage query access and control costs, data engineers and data analysts can save time by reusing Athena workgroups as their SQL analytics compute while maintaining data usage limits and tracking query usage by team or project. \n When choosing a compute for SQL analytics within SageMaker Unified Studio, customers can create a new Athena compute connection or choose to connect to an existing Athena workgroup. To get started, navigate to SageMaker Unified Studio, select “Add compute” and choose “Connect to existing compute resources”. Then create a connection to your pre-existing Athena workgroups and save. This new compute is now available within the SageMaker Unified Studio query editor to run SQL queries. Connecting to Athena workgroups within SageMaker Unified Studio is available in all regions where SageMaker Unified Studio is supported. To learn more, refer to the SageMaker Unified Studio Guide and Athena Workgroups Guide.

AWS Blogs

AWS Japan Blog (Japanese)

AWS Japan Startup Blog (Japanese)

AWS Big Data Blog

AWS Compute Blog

AWS DevOps & Developer Productivity Blog

AWS for Industries

Artificial Intelligence

Open Source Project

AWS CLI

AWS CDK

Amplify for Android

Amplify UI

Karpenter