AWS Parallel Computing Service (PCS), a managed service that simplifies running and scaling high performance computing (HPC) workloads on AWS using Slurm, has expanded its security and compliance coverage. Federal agencies, public sector organizations, and enterprises in regulated industries can now use PCS to run sensitive and mission-critical HPC workloads while meeting their governance, security, and compliance obligations.

PCS is now in scope for FedRAMP Class C (formerly Moderate baseline) in the US East (Ohio), US East (N. Virginia), and US West (Oregon) Regions, and FedRAMP Class D (formerly High baseline) in the AWS GovCloud (US) Regions. PCS is included in the System and Organization Controls (SOC) 1, 2, and 3 reports, which provide independent third-party assurance over the effectiveness of its controls. PCS is certified under International Organization for Standardization (ISO). PCS holds Cloud Security Alliance Security, Trust & Assurance Registry (CSA STAR) certification under CCM 4.0. PCS is included in the AWS PCI DSS and PCI 3DS attestations of compliance for workloads that handle payment card data. PCS is also HIPAA eligible.

To learn more, review the AWS services in scope by compliance program for FedRAMP, SOC, ISO , CSA STAR, PCI, and HIPAA. For more information about PCS and how to get started, visit the product page and review the documentation.

 

​AWS Parallel Computing Service (PCS), a managed service that simplifies running and scaling high performance computing (HPC) workloads on AWS using Slurm, has expanded its security and compliance coverage. Federal agencies, public sector organizations, and enterprises in regulated industries can now use PCS to run sensitive and mission-critical HPC workloads while meeting their governance, security, and compliance obligations.
PCS is now in scope for FedRAMP Class C (formerly Moderate baseline) in the US East (Ohio), US East (N. Virginia), and US West (Oregon) Regions, and FedRAMP Class D (formerly High baseline) in the AWS GovCloud (US) Regions. PCS is included in the System and Organization Controls (SOC) 1, 2, and 3 reports, which provide independent third-party assurance over the effectiveness of its controls. PCS is certified under International Organization for Standardization (ISO). PCS holds Cloud Security Alliance Security, Trust & Assurance Registry (CSA STAR) certification under CCM 4.0. PCS is included in the AWS PCI DSS and PCI 3DS attestations of compliance for workloads that handle payment card data. PCS is also HIPAA eligible.
To learn more, review the AWS services in scope by compliance program for FedRAMP, SOC, ISO , CSA STAR, PCI, and HIPAA. For more information about PCS and how to get started, visit the product page and review the documentation.  

AWS WAF now supports the Salt Security managed rule group, available through AWS Marketplace: Salt Managed Rules for AWS WAF – AI Agent & API Security. This rule group gives AWS WAF customers detection and mitigation for API-focused attacks and for traffic from AI agents and Model Context Protocol (MCP) endpoints, without writing or maintaining custom rules.

The rule group detects common and complex API attack vectors, including credential brute force, excessive GraphQL queries, server-side request forgery (SSRF), prototype pollution, and JSON Web Token (JWT) anomalies. It identifies and labels traffic from Model Context Protocol (MCP) endpoints, blocks unauthenticated MCP access, and adds observability into MCP interactions in AWS WAF. The rule group also applies rate limiting to sensitive request parameters, such as user identifiers and email addresses, to help mitigate enumeration and abuse. To support detection and downstream analysis, it labels request attributes including authorization headers, user identifiers, and GraphQL queries.

You can subscribe to the rule group and add it to a web ACL directly in the AWS WAF console through AWS Marketplace, with no additional configuration. The rule group supports versioning, and pricing is set by Salt Security through AWS Marketplace. For a full list of supported Regions, visit the AWS Regional Services page.

To get started, visit the AWS WAF console or find the Salt Security rule group in AWS Marketplace. For more information, see the AWS WAF Developer Guide.

 

​AWS WAF now supports the Salt Security managed rule group, available through AWS Marketplace: Salt Managed Rules for AWS WAF – AI Agent & API Security. This rule group gives AWS WAF customers detection and mitigation for API-focused attacks and for traffic from AI agents and Model Context Protocol (MCP) endpoints, without writing or maintaining custom rules. The rule group detects common and complex API attack vectors, including credential brute force, excessive GraphQL queries, server-side request forgery (SSRF), prototype pollution, and JSON Web Token (JWT) anomalies. It identifies and labels traffic from Model Context Protocol (MCP) endpoints, blocks unauthenticated MCP access, and adds observability into MCP interactions in AWS WAF. The rule group also applies rate limiting to sensitive request parameters, such as user identifiers and email addresses, to help mitigate enumeration and abuse. To support detection and downstream analysis, it labels request attributes including authorization headers, user identifiers, and GraphQL queries. You can subscribe to the rule group and add it to a web ACL directly in the AWS WAF console through AWS Marketplace, with no additional configuration. The rule group supports versioning, and pricing is set by Salt Security through AWS Marketplace. For a full list of supported Regions, visit the AWS Regional Services page. To get started, visit the AWS WAF console or find the Salt Security rule group in AWS Marketplace. For more information, see the AWS WAF Developer Guide.  

AWS Lambda console now extends its console-to-IDE integration to support Kiro and Cursor IDEs. This expansion builds on the existing console-to-IDE transition for Visual Studio Code (VS Code), providing a seamless transition between cloud and local development environments for serverless developers using these popular IDEs.

With the expanded console-to-IDE integration, developers can start from the Lambda console and follow a guided setup to begin local development in Kiro or Cursor while preserving their existing code and configurations. This capability also enables developers to easily convert their applications to an AWS Serverless Application Model (AWS SAM) template using Kiro and Cursor, simplifying their Infrastructure as Code (IaC) practices and CI/CD pipeline integration.

This feature is available in all commercial AWS Regions where Lambda is available, at no additional cost.

To get started, click the «Open in Kiro» or «Open in Cursor» button in the Lambda console’s Code tab or in the Getting Started popup when creating a new function. This will automatically open your function in the selected IDE on your local device. To learn more about this experience, visit the Lambda developer guide.

 

​AWS Lambda console now extends its console-to-IDE integration to support Kiro and Cursor IDEs. This expansion builds on the existing console-to-IDE transition for Visual Studio Code (VS Code), providing a seamless transition between cloud and local development environments for serverless developers using these popular IDEs.
With the expanded console-to-IDE integration, developers can start from the Lambda console and follow a guided setup to begin local development in Kiro or Cursor while preserving their existing code and configurations. This capability also enables developers to easily convert their applications to an AWS Serverless Application Model (AWS SAM) template using Kiro and Cursor, simplifying their Infrastructure as Code (IaC) practices and CI/CD pipeline integration.
This feature is available in all commercial AWS Regions where Lambda is available, at no additional cost.
To get started, click the «Open in Kiro» or «Open in Cursor» button in the Lambda console’s Code tab or in the Getting Started popup when creating a new function. This will automatically open your function in the selected IDE on your local device. To learn more about this experience, visit the Lambda developer guide.  

Today, AWS announces runtime instances, a new feature in Amazon Bedrock AgentCore that lets you run agents on your own Amazon EC2 instances without managing infrastructure. AgentCore runtime provides purpose-built infrastructure to deploy and operate AI agents securely at scale. Runtime instances complement the existing microVM-based option in AgentCore runtime and give teams running sustained, resource-intensive, or specialized-hardware agents access to the breadth of EC2 instance types, while AgentCore handles provisioning, patching, scaling, and lifecycle management.

Using the AWS Management Console, CLI, SDKs, or APIs, you create a capacity provider that specifies the EC2 instance types your agents need, including GPU-accelerated, memory-optimized, and compute-optimized families, and attach your agents to it. Runtime instances support long-running agent sessions of up to 14 days, while the default serverless, microVM-based runtime is designed for sessions of up to 8 hours that need fast startup . You can choose the right compute for each agent, or run a mix, without changing how you deploy or invoke your agents.

You can use runtime instances in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). You are charged for the management of the compute provisioned, in addition to your Amazon EC2 costs. To get started, visit AWS News Blog or AgentCore documentation. To learn about pricing, visit AgentCore pricing.

 

​Today, AWS announces runtime instances, a new feature in Amazon Bedrock AgentCore that lets you run agents on your own Amazon EC2 instances without managing infrastructure. AgentCore runtime provides purpose-built infrastructure to deploy and operate AI agents securely at scale. Runtime instances complement the existing microVM-based option in AgentCore runtime and give teams running sustained, resource-intensive, or specialized-hardware agents access to the breadth of EC2 instance types, while AgentCore handles provisioning, patching, scaling, and lifecycle management.
Using the AWS Management Console, CLI, SDKs, or APIs, you create a capacity provider that specifies the EC2 instance types your agents need, including GPU-accelerated, memory-optimized, and compute-optimized families, and attach your agents to it. Runtime instances support long-running agent sessions of up to 14 days, while the default serverless, microVM-based runtime is designed for sessions of up to 8 hours that need fast startup . You can choose the right compute for each agent, or run a mix, without changing how you deploy or invoke your agents.
You can use runtime instances in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). You are charged for the management of the compute provisioned, in addition to your Amazon EC2 costs. To get started, visit AWS News Blog or AgentCore documentation. To learn about pricing, visit AgentCore pricing.  

Amazon Elastic Container Service (Amazon ECS) now supports fractional GPU scheduling with Amazon EC2 G6f instances, enabling you to run your workloads on GPU partitions as small as one-eighth of an NVIDIA L4 Tensor Core GPU with 3 GB of GPU memory. Fractional GPUs give you the flexibility to right-size your containers for small-model AI inference, model experimentation, graphics rendering, and other workloads that do not require a full GPU, helping reduce infrastructure costs compared to provisioning a full GPU instance.

You can request a fractional GPU by setting GPU=0.125, GPU=0.25, or GPU=0.5 in the container definition of your Amazon ECS task definition. Amazon ECS then places the task on a G6f instance that satisfies the request. Fractional GPU configuration is supported on both Amazon ECS Managed Instances and Amazon ECS on EC2. With ECS Managed Instances, you get a fully managed experience where ECS automatically handles instance provisioning, scaling, patching, and lifecycle management, so you can focus on your GPU workloads rather than infrastructure operations. ECS Managed Instances also include capabilities built specifically for accelerated workloads, such as GPU metrics through Amazon CloudWatch Container Insights, and automatic health monitoring that detects GPU hardware failures and replaces unhealthy instances to minimize workload disruption.

This capability is available in all AWS Regions where Amazon EC2 G6f instances are available. To get started, use the AWS Management Console, AWS CLI, AWS SDKs, AWS CloudFormation, or other infrastructure-as-code tools to configure a capacity provider with G6f instances and specify a fractional GPU value in the container definition of your ECS task definition. To learn more, visit the Amazon ECS fractional GPU documentation and the Amazon EC2 G6 instance page.

 

​Amazon Elastic Container Service (Amazon ECS) now supports fractional GPU scheduling with Amazon EC2 G6f instances, enabling you to run your workloads on GPU partitions as small as one-eighth of an NVIDIA L4 Tensor Core GPU with 3 GB of GPU memory. Fractional GPUs give you the flexibility to right-size your containers for small-model AI inference, model experimentation, graphics rendering, and other workloads that do not require a full GPU, helping reduce infrastructure costs compared to provisioning a full GPU instance.
You can request a fractional GPU by setting GPU=0.125, GPU=0.25, or GPU=0.5 in the container definition of your Amazon ECS task definition. Amazon ECS then places the task on a G6f instance that satisfies the request. Fractional GPU configuration is supported on both Amazon ECS Managed Instances and Amazon ECS on EC2. With ECS Managed Instances, you get a fully managed experience where ECS automatically handles instance provisioning, scaling, patching, and lifecycle management, so you can focus on your GPU workloads rather than infrastructure operations. ECS Managed Instances also include capabilities built specifically for accelerated workloads, such as GPU metrics through Amazon CloudWatch Container Insights, and automatic health monitoring that detects GPU hardware failures and replaces unhealthy instances to minimize workload disruption.
This capability is available in all AWS Regions where Amazon EC2 G6f instances are available. To get started, use the AWS Management Console, AWS CLI, AWS SDKs, AWS CloudFormation, or other infrastructure-as-code tools to configure a capacity provider with G6f instances and specify a fractional GPU value in the container definition of your ECS task definition. To learn more, visit the Amazon ECS fractional GPU documentation and the Amazon EC2 G6 instance page.  

Amazon Elastic Compute Cloud (Amazon EC2) G7 instances powered by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs are now available in Europe (Spain) Region. G7 instances deliver up to 4.6x AI inference performance and up to 2.1 graphics performance compared to G6 instances. G7 instances also deliver faster performance for GPU-accelerated data analytics workloads.

Customers can use G7 instances for deploying AI models for language translation, video and image analysis, and speech recognition. They also accelerate graphics workloads such as creating and rendering real-time, cinematic-quality graphics and game streaming. Additionally, G7 instances support video transcoding, spatial computing, and data analytics workloads such as recommender systems, Retrieval Augmented Generation (RAG) inference, and real-time data pipelines. G7 instances feature up to 8 NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs with 32 GB of memory per GPU and custom Intel Xeon 6 processors. They support up to 192 virtual CPUs (vCPUs) and up to 700 Gbps of Elastic Fabric Adapter (EFA) networking bandwidth. They also support up to 768 GiB of system memory, and up to 7.6 TB of local NVMe SSD storage.

You can start using Amazon EC2 G7 instances today in four AWS Regions: US East (N. Virginia and Ohio), US West (Oregon), and Europe (Spain). You can purchase G7 instances as On-Demand Instances, Spot Instances, or as part of Savings Plans.

To get started, visit the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs. To learn more, visit the G7 instance page.

 

​Amazon Elastic Compute Cloud (Amazon EC2) G7 instances powered by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs are now available in Europe (Spain) Region. G7 instances deliver up to 4.6x AI inference performance and up to 2.1 graphics performance compared to G6 instances. G7 instances also deliver faster performance for GPU-accelerated data analytics workloads.
Customers can use G7 instances for deploying AI models for language translation, video and image analysis, and speech recognition. They also accelerate graphics workloads such as creating and rendering real-time, cinematic-quality graphics and game streaming. Additionally, G7 instances support video transcoding, spatial computing, and data analytics workloads such as recommender systems, Retrieval Augmented Generation (RAG) inference, and real-time data pipelines. G7 instances feature up to 8 NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs with 32 GB of memory per GPU and custom Intel Xeon 6 processors. They support up to 192 virtual CPUs (vCPUs) and up to 700 Gbps of Elastic Fabric Adapter (EFA) networking bandwidth. They also support up to 768 GiB of system memory, and up to 7.6 TB of local NVMe SSD storage.
You can start using Amazon EC2 G7 instances today in four AWS Regions: US East (N. Virginia and Ohio), US West (Oregon), and Europe (Spain). You can purchase G7 instances as On-Demand Instances, Spot Instances, or as part of Savings Plans.
To get started, visit the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs. To learn more, visit the G7 instance page.  

Amazon ElastiCache now supports Graviton4-based M8g, R8g, and C8gn node families for Valkey and Memcached. Graviton4-based nodes provide up to 47% higher throughput, up to 43% lower P99 latency, and up to 31% better price-performance for on-demand pricing over Graviton3-based nodes of equivalent sizes on Amazon ElastiCache for Valkey, depending on node family, size, and workload configuration.

Graviton4-based nodes also offer more memory per node compared to equivalent Graviton3-based nodes. As an example, an m8g.8xlarge provides 124.65 GiB versus 103.68 GiB on m7g.8xlarge, up to 20% more memory at the same node size. C8gn nodes offer up to 200 Gbps of network bandwidth, enabling you to scale performance and throughput while optimizing the cost of running network-intensive workloads.

M8g, R8g, and C8gn nodes are available in sizes from large to 16xlarge in over 30 AWS Regions, including the AWS GovCloud (US) Regions and the China Regions. For complete information on pricing and regional availability, please refer to the Amazon ElastiCache pricing page. To get started, create a new cluster or modify an existing cluster using the AWS Management Console, AWS SDK, or AWS CLI. To work with ElastiCache using AI coding agents, see Agent tools for ElastiCache. To learn more, see Supported node types in the Amazon ElastiCache User Guide.

 

​Amazon ElastiCache now supports Graviton4-based M8g, R8g, and C8gn node families for Valkey and Memcached. Graviton4-based nodes provide up to 47% higher throughput, up to 43% lower P99 latency, and up to 31% better price-performance for on-demand pricing over Graviton3-based nodes of equivalent sizes on Amazon ElastiCache for Valkey, depending on node family, size, and workload configuration.
Graviton4-based nodes also offer more memory per node compared to equivalent Graviton3-based nodes. As an example, an m8g.8xlarge provides 124.65 GiB versus 103.68 GiB on m7g.8xlarge, up to 20% more memory at the same node size. C8gn nodes offer up to 200 Gbps of network bandwidth, enabling you to scale performance and throughput while optimizing the cost of running network-intensive workloads.
M8g, R8g, and C8gn nodes are available in sizes from large to 16xlarge in over 30 AWS Regions, including the AWS GovCloud (US) Regions and the China Regions. For complete information on pricing and regional availability, please refer to the Amazon ElastiCache pricing page. To get started, create a new cluster or modify an existing cluster using the AWS Management Console, AWS SDK, or AWS CLI. To work with ElastiCache using AI coding agents, see Agent tools for ElastiCache. To learn more, see Supported node types in the Amazon ElastiCache User Guide.  

You can now use the AWS Glue Schema Registry, a serverless and free feature of AWS Glue, in the Asia Pacific (New Zealand), Asia Pacific (Thailand), Asia Pacific (Hyderabad), Asia Pacific (Osaka), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Mexico (Central), Israel (Tel Aviv), Asia Pacific (Taipei), Canada West (Calgary) regions to validate and control the evolution of streaming data using registered Apache Avro, JSON, and Protobuf schema formats.

The Schema Registry acts as a centralized repository for managing data format and structure between decoupled applications in data streaming systems. By using it, you can eliminate data validation logic and cross-team coordination, improve streaming data quality, and reduce downstream application failures. Through Apache-licensed serializers and deserializers, the Schema Registry integrates with C# and Java applications developed for Apache Kafka/Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Data Streams, Apache Flink/Amazon Managed Service for Apache Flink, and AWS Lambda.

To get started, visit the AWS Glue Schema Registry documentation. For a full list of AWS Regions where AWS Glue Schema Registry is available, see the AWS Regional Services List.

 

​You can now use the AWS Glue Schema Registry, a serverless and free feature of AWS Glue, in the Asia Pacific (New Zealand), Asia Pacific (Thailand), Asia Pacific (Hyderabad), Asia Pacific (Osaka), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Mexico (Central), Israel (Tel Aviv), Asia Pacific (Taipei), Canada West (Calgary) regions to validate and control the evolution of streaming data using registered Apache Avro, JSON, and Protobuf schema formats. The Schema Registry acts as a centralized repository for managing data format and structure between decoupled applications in data streaming systems. By using it, you can eliminate data validation logic and cross-team coordination, improve streaming data quality, and reduce downstream application failures. Through Apache-licensed serializers and deserializers, the Schema Registry integrates with C# and Java applications developed for Apache Kafka/Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Data Streams, Apache Flink/Amazon Managed Service for Apache Flink, and AWS Lambda. To get started, visit the AWS Glue Schema Registry documentation. For a full list of AWS Regions where AWS Glue Schema Registry is available, see the AWS Regional Services List.  

AWS Transform now automates the configuration and execution of post-launch actions through the migration workflow. Define actions at the account level and apply them automatically to each source server across your target accounts, including multi-account migrations. Automating these actions removes the slow, error-prone work of configuring them server by server, so your team moves more servers with less hands-on effort.

Post-launch actions run through AWS Systems Manager (SSM) immediately after test or cutover launch. You can use predefined actions or bring your own SSM document. For source server bulk configurations, the migration inventory file now includes a new structure for post-launch actions, making it easier to review and modify actions per source server.

The AWS Transform for migrations agent automates your migration configuration end to end, including replication templates, EC2 launch templates, EC2 right-sizing, and post-launch actions, with the flexibility to create and edit any of these at the source server level. 

This new capability is available in all AWS Regions where AWS Transform is offered.

To learn more, please visit the AWS Transform User Guide.

 

​AWS Transform now automates the configuration and execution of post-launch actions through the migration workflow. Define actions at the account level and apply them automatically to each source server across your target accounts, including multi-account migrations. Automating these actions removes the slow, error-prone work of configuring them server by server, so your team moves more servers with less hands-on effort.
Post-launch actions run through AWS Systems Manager (SSM) immediately after test or cutover launch. You can use predefined actions or bring your own SSM document. For source server bulk configurations, the migration inventory file now includes a new structure for post-launch actions, making it easier to review and modify actions per source server.
The AWS Transform for migrations agent automates your migration configuration end to end, including replication templates, EC2 launch templates, EC2 right-sizing, and post-launch actions, with the flexibility to create and edit any of these at the source server level. 
This new capability is available in all AWS Regions where AWS Transform is offered.
To learn more, please visit the AWS Transform User Guide.  

AWS Security Agent (now part of AWS Continuum) now enables penetration testing of applications that use email-based multi-factor authentication (MFA) as part of their login flow. Previously, applications requiring one-time codes or verification links sent by email were out of scope for automated pentesting because the agent had no mechanism to intercept those messages. This launch expands coverage for penetration testing customers whose target applications rely on email-based authentication.

To use this feature, AWS Security Agent generates a unique forwarding address per credential, allowing you to route your application’s MFA emails directly to the agent using a forwarding rule in your existing email provider. During a pentest, the agent automatically reads the forwarded message and submits the code or link to complete authentication — no email account credentials are stored, preserving a strong privacy posture. This capability complements existing TOTP support, giving customers a unified solution for testing applications across multiple MFA methods.

This feature is available in all AWS Regions where AWS Security Agent is supported.

To learn more, visit the AWS Security Agent product page and the AWS Security Agent User Guide. 

 

​AWS Security Agent (now part of AWS Continuum) now enables penetration testing of applications that use email-based multi-factor authentication (MFA) as part of their login flow. Previously, applications requiring one-time codes or verification links sent by email were out of scope for automated pentesting because the agent had no mechanism to intercept those messages. This launch expands coverage for penetration testing customers whose target applications rely on email-based authentication.
To use this feature, AWS Security Agent generates a unique forwarding address per credential, allowing you to route your application’s MFA emails directly to the agent using a forwarding rule in your existing email provider. During a pentest, the agent automatically reads the forwarded message and submits the code or link to complete authentication — no email account credentials are stored, preserving a strong privacy posture. This capability complements existing TOTP support, giving customers a unified solution for testing applications across multiple MFA methods.
This feature is available in all AWS Regions where AWS Security Agent is supported.
To learn more, visit the AWS Security Agent product page and the AWS Security Agent User Guide.