Today, AWS announced enhanced API key restrictions for Amazon Location Service, enabling developers to secure their location-based applications more effectively. This new capability helps organizations that need to restrict API access to specific mobile applications, providing improved security controls for location services across their application portfolio.

Developers can now create granular security policies by restricting API keys to specific Android applications using package names and SHA-1 certificate fingerprints, or to iOS applications using Bundle IDs. For example, enterprises can ensure their API keys only work with their approved mobile applications, while development teams can create separate keys for testing and production environments.

Amazon Location Service API key restrictions are available in the following AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain), and South America (São Paulo). To implement these restrictions, you’ll need to update your API key configurations using the Amazon Location Service console or APIs. To learn more, please visit the Developer Guide.

 

​Today, AWS announced enhanced API key restrictions for Amazon Location Service, enabling developers to secure their location-based applications more effectively. This new capability helps organizations that need to restrict API access to specific mobile applications, providing improved security controls for location services across their application portfolio. Developers can now create granular security policies by restricting API keys to specific Android applications using package names and SHA-1 certificate fingerprints, or to iOS applications using Bundle IDs. For example, enterprises can ensure their API keys only work with their approved mobile applications, while development teams can create separate keys for testing and production environments. Amazon Location Service API key restrictions are available in the following AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain), and South America (São Paulo). To implement these restrictions, you’ll need to update your API key configurations using the Amazon Location Service console or APIs. To learn more, please visit the Developer Guide.  

Amazon Elastic Container Service (Amazon ECS) Managed Instances is now available in all commercial AWS Regions. ECS Managed Instances is a fully managed compute option designed to eliminate infrastructure management overhead while giving you access to the full capabilities of Amazon EC2. By offloading infrastructure operations to AWS, you get the application performance you want and the simplicity you need while reducing your total cost of ownership.

Managed Instances dynamically scales EC2 instances to match your workload requirements and continuously optimizes task placement to reduce infrastructure costs. It also enhances your security posture through regular security patching initiated every 14 days. You can simply define your task requirements such as the number of vCPUs, memory size, and CPU architecture, and Amazon ECS automatically provisions, configures and operates most optimal EC2 instances within your AWS account using AWS-controlled access. You can also specify desired instance types in Managed Instances Capacity Provider configuration, including GPU-accelerated, network-optimized, and burstable performance, to run your workloads on the instance families you prefer.

To get started with ECS Managed Instances, use the AWS Console, Amazon ECS MCP Server, or your favorite infrastructure-as-code tooling to enable it in a new or existing Amazon ECS cluster. You will be charged for the management of compute provisioned, in addition to your regular Amazon EC2 costs. To learn more about ECS Managed Instances, visit the feature page, documentation, and AWS News launch blog.

 

​Amazon Elastic Container Service (Amazon ECS) Managed Instances is now available in all commercial AWS Regions. ECS Managed Instances is a fully managed compute option designed to eliminate infrastructure management overhead while giving you access to the full capabilities of Amazon EC2. By offloading infrastructure operations to AWS, you get the application performance you want and the simplicity you need while reducing your total cost of ownership. Managed Instances dynamically scales EC2 instances to match your workload requirements and continuously optimizes task placement to reduce infrastructure costs. It also enhances your security posture through regular security patching initiated every 14 days. You can simply define your task requirements such as the number of vCPUs, memory size, and CPU architecture, and Amazon ECS automatically provisions, configures and operates most optimal EC2 instances within your AWS account using AWS-controlled access. You can also specify desired instance types in Managed Instances Capacity Provider configuration, including GPU-accelerated, network-optimized, and burstable performance, to run your workloads on the instance families you prefer. To get started with ECS Managed Instances, use the AWS Console, Amazon ECS MCP Server, or your favorite infrastructure-as-code tooling to enable it in a new or existing Amazon ECS cluster. You will be charged for the management of compute provisioned, in addition to your regular Amazon EC2 costs. To learn more about ECS Managed Instances, visit the feature page, documentation, and AWS News launch blog.  

AWS Payment Cryptography has expanded its global presence with availability in three new regions – Canada(Montreal), Africa (Cape Town) and Europe (London). This expansion enables customers with latency-sensitive payment applications to build, deploy or migrate into additional AWS Regions without depending on cross-region support. For customers processing payment workloads in Europe, availability in London offers additional options for multi-Region high availability.

AWS Payment Cryptography is a fully managed service that simplifies payment-specific cryptographic operations and key management for cloud-hosted payment applications. The service scales elastically with your business needs and is assessed as compliant with PCI PIN and PCI P2PE requirements, eliminating the need to maintain dedicated payment HSM instances. Organizations performing payment functions – including acquirers, payment facilitators, networks, switches, processors, and banks can now position their payment cryptographic operations closer to their applications while reducing dependencies on auxiliary data centers with dedicated payment HSMs.

AWS Payment Cryptography is available in the following AWS Regions: Canada(Montreal), US East (Ohio, N. Virginia), US West (Oregon), Europe (Ireland, Frankfurt, London), Africa(Cape Town) and Asia Pacific (Singapore, Tokyo, Osaka, Mumbai).

To start using the service, please download the latest AWS CLI/SDK and see the AWS Payment Cryptography user guide for more information.

 

​AWS Payment Cryptography has expanded its global presence with availability in three new regions – Canada(Montreal), Africa (Cape Town) and Europe (London). This expansion enables customers with latency-sensitive payment applications to build, deploy or migrate into additional AWS Regions without depending on cross-region support. For customers processing payment workloads in Europe, availability in London offers additional options for multi-Region high availability. AWS Payment Cryptography is a fully managed service that simplifies payment-specific cryptographic operations and key management for cloud-hosted payment applications. The service scales elastically with your business needs and is assessed as compliant with PCI PIN and PCI P2PE requirements, eliminating the need to maintain dedicated payment HSM instances. Organizations performing payment functions – including acquirers, payment facilitators, networks, switches, processors, and banks can now position their payment cryptographic operations closer to their applications while reducing dependencies on auxiliary data centers with dedicated payment HSMs. AWS Payment Cryptography is available in the following AWS Regions: Canada(Montreal), US East (Ohio, N. Virginia), US West (Oregon), Europe (Ireland, Frankfurt, London), Africa(Cape Town) and Asia Pacific (Singapore, Tokyo, Osaka, Mumbai). To start using the service, please download the latest AWS CLI/SDK and see the AWS Payment Cryptography user guide for more information.  

Amazon Cognito now enables app clients to specify resource indicators during access token requests as part of its OAuth 2.0 authorization code grant and implicit grant flows. The resource indicator identifies the protected resource, such as a user’s bank account record or a specific file in a file server that the user needs to access. After authenticating the client, Cognito then issues an access token for that specific resource. This ensures that access tokens can be limited from broad service level access down to accessing specific individual resources.

This capability makes it simpler to protect resources that a user needs to access. For example, agents (an example of app clients) on behalf of users can request access tokens for specific protected resources, such as a user’s banking records. After validation, Cognito issues an access token with the audience claim set to the specific resource. Previously, clients had to use non-standard claims or scopes for Cognito to infer and issue resource-specific access tokens. Now, customers can specify the target resource in a simple and consistent way using standards-based resource parameter.

This capability is available to Amazon Cognito Managed Login customers using Essentials or Plus tiers in AWS Regions where Cognito is available, including the AWS GovCloud (US) Regions. To learn more, refer to the developer guide, and pricing for Cognito Essentials and Plus tier.

 

​Amazon Cognito now enables app clients to specify resource indicators during access token requests as part of its OAuth 2.0 authorization code grant and implicit grant flows. The resource indicator identifies the protected resource, such as a user’s bank account record or a specific file in a file server that the user needs to access. After authenticating the client, Cognito then issues an access token for that specific resource. This ensures that access tokens can be limited from broad service level access down to accessing specific individual resources. This capability makes it simpler to protect resources that a user needs to access. For example, agents (an example of app clients) on behalf of users can request access tokens for specific protected resources, such as a user’s banking records. After validation, Cognito issues an access token with the audience claim set to the specific resource. Previously, clients had to use non-standard claims or scopes for Cognito to infer and issue resource-specific access tokens. Now, customers can specify the target resource in a simple and consistent way using standards-based resource parameter. This capability is available to Amazon Cognito Managed Login customers using Essentials or Plus tiers in AWS Regions where Cognito is available, including the AWS GovCloud (US) Regions. To learn more, refer to the developer guide, and pricing for Cognito Essentials and Plus tier.  

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.

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. 

 

​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. 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.   

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.

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. 

 

​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. 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.   

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.

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.

 

​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. 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.  

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.

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.

 

​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. 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.  

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.

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.

 

​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. 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.  

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.

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.

 

​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. 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.