Today, AWS Payments Cryptography announces support for hybrid post-quantum (PQ) TLS to secure API calls. With this launch, customers can future-proof transmissions of sensitive data and commands using ML-KEM post-quantum cryptography.

Enterprises operating highly regulated workloads wish to reduce post-quantum risks from “harvest now, decrypt later”. Long-lived data-in-transit can be recorded today, then decrypted in the future when a sufficiently capable quantum computer becomes available. With today’s launch, AWS Payment Cryptography joins data protection services such as AWS Key Management Service (KMS) in addressing this concern by supporting PQ-TLS.

To get started, simply ensure that your application depends on a version of AWS SDK or browser that supports PQ-TLS. For detailed guidance by language and platform, visit the PQ-TLS enablement documentation. Customers can also validate that ML-KEM was used to secure the TLS session for an API call by reviewing tlsDetails for the corresponding CloudTrail event in the console or a configured CloudTrail trail.

These capabilities are generally available in all AWS Regions at no added cost. To get started with PQ-TLS and Payment Cyptography, see our post-quantum TLS guide. For more information about PQC at AWS, please see PQC shared responsibility.

 

​Today, AWS Payments Cryptography announces support for hybrid post-quantum (PQ) TLS to secure API calls. With this launch, customers can future-proof transmissions of sensitive data and commands using ML-KEM post-quantum cryptography. Enterprises operating highly regulated workloads wish to reduce post-quantum risks from “harvest now, decrypt later”. Long-lived data-in-transit can be recorded today, then decrypted in the future when a sufficiently capable quantum computer becomes available. With today’s launch, AWS Payment Cryptography joins data protection services such as AWS Key Management Service (KMS) in addressing this concern by supporting PQ-TLS. To get started, simply ensure that your application depends on a version of AWS SDK or browser that supports PQ-TLS. For detailed guidance by language and platform, visit the PQ-TLS enablement documentation. Customers can also validate that ML-KEM was used to secure the TLS session for an API call by reviewing tlsDetails for the corresponding CloudTrail event in the console or a configured CloudTrail trail. These capabilities are generally available in all AWS Regions at no added cost. To get started with PQ-TLS and Payment Cyptography, see our post-quantum TLS guide. For more information about PQC at AWS, please see PQC shared responsibility.  

Amazon EMR 7.12 is now available featuring the new Apache Iceberg v3 table format with Apache Iceberg 1.10. This release enables you to reduce costs when deleting data, strengthen governance and compliance through better tracking for row level changes, and enhance data security with more granular data access control.

With Iceberg v3, you can delete data cost-effectively because Iceberg v3 marks deleted rows without rewriting entire files – speeding up your data pipelines while reducing storage costs. You get better governance and compliance capabilities through automatic tracking of every row’s creation and modification history, creating the audit trails needed for regulatory requirements and change data capture. You can enhance data security with table-level encryption, helping you meet privacy regulations for your most sensitive data.

With Apache Spark 3.5.6 included in this release, you can leverage these Iceberg 1.10 capabilities for building robust data lakehouse architectures on Amazon S3. This release also includes support for data governance operations across your Iceberg tables using AWS Lake Formation. In addition, this release also includes Apache Trino 476.

Amazon EMR 7.12 is available in all AWS Regions that support Amazon EMR. To learn more about Amazon EMR 7.12 release, visit the Amazon EMR 7.12 release documentation. 

 

​Amazon EMR 7.12 is now available featuring the new Apache Iceberg v3 table format with Apache Iceberg 1.10. This release enables you to reduce costs when deleting data, strengthen governance and compliance through better tracking for row level changes, and enhance data security with more granular data access control. With Iceberg v3, you can delete data cost-effectively because Iceberg v3 marks deleted rows without rewriting entire files – speeding up your data pipelines while reducing storage costs. You get better governance and compliance capabilities through automatic tracking of every row’s creation and modification history, creating the audit trails needed for regulatory requirements and change data capture. You can enhance data security with table-level encryption, helping you meet privacy regulations for your most sensitive data. With Apache Spark 3.5.6 included in this release, you can leverage these Iceberg 1.10 capabilities for building robust data lakehouse architectures on Amazon S3. This release also includes support for data governance operations across your Iceberg tables using AWS Lake Formation. In addition, this release also includes Apache Trino 476. Amazon EMR 7.12 is available in all AWS Regions that support Amazon EMR. To learn more about Amazon EMR 7.12 release, visit the Amazon EMR 7.12 release documentation.   

AWS Device Farm enables mobile and web developers to test their apps using real mobile devices and desktop browsers. Starting today, you can connect to a fully managed Appium endpoint using only a few lines of code and run interactive tests on multiple physical devices directly from your IDE or local machine. This feature also seamlessly works with third-party tools such as Appium Inspector — both hosted and local versions — for all actions including element inspection.

Support for live video and log streaming enables you to get faster test feedback within your local workflow. It complements our existing server-side execution which gives you the scale and control to run secure enterprise-grade workloads. Taken together, Device Farm now offers you the ability to author, inspect, debug, test, and release mobile apps faster, whether from your IDE, AWS Console, or other environments.

To learn more, see Appium Testing in AWS Device Farm Developer Guide.

 

​AWS Device Farm enables mobile and web developers to test their apps using real mobile devices and desktop browsers. Starting today, you can connect to a fully managed Appium endpoint using only a few lines of code and run interactive tests on multiple physical devices directly from your IDE or local machine. This feature also seamlessly works with third-party tools such as Appium Inspector — both hosted and local versions — for all actions including element inspection.
Support for live video and log streaming enables you to get faster test feedback within your local workflow. It complements our existing server-side execution which gives you the scale and control to run secure enterprise-grade workloads. Taken together, Device Farm now offers you the ability to author, inspect, debug, test, and release mobile apps faster, whether from your IDE, AWS Console, or other environments.
To learn more, see Appium Testing in AWS Device Farm Developer Guide.  

Today, we’re excited to announce the addition of Web Bot Auth (WBA) support in AWS WAF, providing a secure and standardized way to authenticate legitimate AI agents and automated tools accessing web applications. This new capability helps distinguish trusted bot traffic from potentially harmful automated access attempts.

Web Bot Auth is an authentication method that leverages cryptographic signatures in HTTP messages to verifythat a request comes from an automated bot. Web Bot Auth is used as a verification method for verified bots and signed agents. It relies on two active IETF drafts: a directory draft allowing the crawler to share their public keys, and a protocol draft defining how these keys should be used to attach crawler’s identity to HTTP requests.

AWS WAF now automatically allows verified AI agent traffic Verified WBA bots will now be automatically allowed by default, previously Category AI blocked unverified bots, this behavior is now refined to respect WBA verification.

To learn more, please review the documentation.

 

​Today, we’re excited to announce the addition of Web Bot Auth (WBA) support in AWS WAF, providing a secure and standardized way to authenticate legitimate AI agents and automated tools accessing web applications. This new capability helps distinguish trusted bot traffic from potentially harmful automated access attempts.
Web Bot Auth is an authentication method that leverages cryptographic signatures in HTTP messages to verifythat a request comes from an automated bot. Web Bot Auth is used as a verification method for verified bots and signed agents. It relies on two active IETF drafts: a directory draft allowing the crawler to share their public keys, and a protocol draft defining how these keys should be used to attach crawler’s identity to HTTP requests.
AWS WAF now automatically allows verified AI agent traffic Verified WBA bots will now be automatically allowed by default, previously Category AI blocked unverified bots, this behavior is now refined to respect WBA verification.
To learn more, please review the documentation.  

Amazon Aurora DSQL now supports a maximum storage limit of 256 TiB, doubling the previous limit of 128 TiB. Now, customers can store and manage larger datasets within a single database cluster, simplifying data management for large-scale applications. With Aurora DSQL, customers only pay for the storage they use and storage automatically scales with usage, ensuring that customers do not need to provision storage upfront.

All Aurora DSQL clusters by default have a storage limit of 10 TiB. Customers that desire clusters with higher storage limits can request a limit increase using either the Service Quotas console or AWS CLI. Visit the Service Quotas documentation for a step-by-step guide to requesting a quote increase.

The increased storage limits are available in all Regions where Aurora DSQL is available. Get started with Aurora DSQL for free with the AWS Free Tier. To learn more about Aurora DSQL, visit the webpage and documentation.

 

​Amazon Aurora DSQL now supports a maximum storage limit of 256 TiB, doubling the previous limit of 128 TiB. Now, customers can store and manage larger datasets within a single database cluster, simplifying data management for large-scale applications. With Aurora DSQL, customers only pay for the storage they use and storage automatically scales with usage, ensuring that customers do not need to provision storage upfront. All Aurora DSQL clusters by default have a storage limit of 10 TiB. Customers that desire clusters with higher storage limits can request a limit increase using either the Service Quotas console or AWS CLI. Visit the Service Quotas documentation for a step-by-step guide to requesting a quote increase. The increased storage limits are available in all Regions where Aurora DSQL is available. Get started with Aurora DSQL for free with the AWS Free Tier. To learn more about Aurora DSQL, visit the webpage and documentation.  

Today we are announcing the release of Aurora DSQL Connectors for Python, Node.js, and JDBC that simplify IAM authorization for customers using standard PostgreSQL drivers to connect to Aurora DSQL clusters. These connectors act as transparent authentication layers that automatically handle IAM token generation, eliminating the need to write token generation code or manually supply IAM tokens. The connectors work seamlessly with popular PostgreSQL drivers including psycopg and psycopg2 for Python, node-postgres and Postgres.js for Node.js, and the standard PostgreSQL JDBC driver, while supporting existing workflows, connection pooling libraries (including HikariCP for JDBC and built-in pooling for Node.js and Python), and frameworks like Spring Boot.

The Aurora DSQL Connectors streamline authentication and eliminate security risks associated with traditional user-generated passwords. By automatically generating IAM tokens for each connection using valid AWS credentials and the AWS SDK, the connectors ensure valid tokens are always used while maintaining full compatibility with existing PostgreSQL driver features.

The above connectors are available in all Regions where Aurora DSQL is available. To get started, visit the Connectors for Aurora DSQL documentation page. For code examples, visit our Github page for node-postgres, Postgres.js, psycopg and psycopg2, and JDBC. Get started with Aurora DSQL for free with the AWS Free Tier. To learn more about Aurora DSQL, visit the webpage.

 

​Today we are announcing the release of Aurora DSQL Connectors for Python, Node.js, and JDBC that simplify IAM authorization for customers using standard PostgreSQL drivers to connect to Aurora DSQL clusters. These connectors act as transparent authentication layers that automatically handle IAM token generation, eliminating the need to write token generation code or manually supply IAM tokens. The connectors work seamlessly with popular PostgreSQL drivers including psycopg and psycopg2 for Python, node-postgres and Postgres.js for Node.js, and the standard PostgreSQL JDBC driver, while supporting existing workflows, connection pooling libraries (including HikariCP for JDBC and built-in pooling for Node.js and Python), and frameworks like Spring Boot. The Aurora DSQL Connectors streamline authentication and eliminate security risks associated with traditional user-generated passwords. By automatically generating IAM tokens for each connection using valid AWS credentials and the AWS SDK, the connectors ensure valid tokens are always used while maintaining full compatibility with existing PostgreSQL driver features. The above connectors are available in all Regions where Aurora DSQL is available. To get started, visit the Connectors for Aurora DSQL documentation page. For code examples, visit our Github page for node-postgres, Postgres.js, psycopg and psycopg2, and JDBC. Get started with Aurora DSQL for free with the AWS Free Tier. To learn more about Aurora DSQL, visit the webpage.  

Amazon EC2 Image Builder now supports automatic versioning for recipes and automatic build version incrementing for components, reducing the overhead of managing versions manually. This enables you to increment versions automatically and dynamically reference the latest compatible versions in your pipelines without manual updates.

With automatic versioning, you no longer need to manually track and increment version numbers when creating new versions of your recipes. You can simply place a single ‘x’ placeholder in any position of the version number, and Image Builder detects the latest existing version and automatically increments that position. For components, Image Builder automatically increments the build version when you create a component with the same name and semantic version. When referencing resources in your configurations, wildcard patterns automatically resolve to the highest available version matching the specified pattern, ensuring your pipelines always use the latest versions.

Auto-versioning is available in all AWS regions including AWS China (Beijing) Region, operated by Sinnet, AWS China (Ningxia) Region, operated by NWCD, and AWS GovCloud (US) Regions. You can get started from the EC2 Image Builder Console, CLI, API, CloudFormation, or CDK. Refer to documentation to learn more about recipes, components and semantic versioning.

 

​Amazon EC2 Image Builder now supports automatic versioning for recipes and automatic build version incrementing for components, reducing the overhead of managing versions manually. This enables you to increment versions automatically and dynamically reference the latest compatible versions in your pipelines without manual updates. With automatic versioning, you no longer need to manually track and increment version numbers when creating new versions of your recipes. You can simply place a single ‘x’ placeholder in any position of the version number, and Image Builder detects the latest existing version and automatically increments that position. For components, Image Builder automatically increments the build version when you create a component with the same name and semantic version. When referencing resources in your configurations, wildcard patterns automatically resolve to the highest available version matching the specified pattern, ensuring your pipelines always use the latest versions. Auto-versioning is available in all AWS regions including AWS China (Beijing) Region, operated by Sinnet, AWS China (Ningxia) Region, operated by NWCD, and AWS GovCloud (US) Regions. You can get started from the EC2 Image Builder Console, CLI, API, CloudFormation, or CDK. Refer to documentation to learn more about recipes, components and semantic versioning.  

AWS announces the launch of natural language test Q&A generation for Automated Reasoning checks in Amazon Bedrock Guardrails. Automated Reasoning checks uses formal verification techniques to validate the accuracy and policy compliance of outputs from generative AI models. Automated Reasoning checks deliver up to 99% accuracy at detecting correct responses from LLMs, giving you provable assurance in detecting AI hallucinations while also assisting with ambiguity detection in model responses.

To get started with Automated Reasoning checks, customers create and test Automated Reasoning policies using natural language documents and sample Q&As. Automated Reasoning checks generates up to N test Q&As for each policy using content from the input document, reducing the work required to go from initial policy generation to production-ready, refined policy.

Test generation for Automated Reasoning checks is now available in the US (N. Virginia), US (Ohio), US (Oregon), Europe (Frankfurt), Europe (Ireland), and Europe (Paris) Regions. Customers can access the service through the Amazon Bedrock console, as well as the Amazon Bedrock Python SDK.

To learn more about Automated Reasoning checks and how you can integrate it into your generative AI workflows, please read the Amazon Bedrock documentation, review the tutorials on the AWS AI blog, and visit the Bedrock Guardrails webpage.

 

​AWS announces the launch of natural language test Q&A generation for Automated Reasoning checks in Amazon Bedrock Guardrails. Automated Reasoning checks uses formal verification techniques to validate the accuracy and policy compliance of outputs from generative AI models. Automated Reasoning checks deliver up to 99% accuracy at detecting correct responses from LLMs, giving you provable assurance in detecting AI hallucinations while also assisting with ambiguity detection in model responses. To get started with Automated Reasoning checks, customers create and test Automated Reasoning policies using natural language documents and sample Q&As. Automated Reasoning checks generates up to N test Q&As for each policy using content from the input document, reducing the work required to go from initial policy generation to production-ready, refined policy. Test generation for Automated Reasoning checks is now available in the US (N. Virginia), US (Ohio), US (Oregon), Europe (Frankfurt), Europe (Ireland), and Europe (Paris) Regions. Customers can access the service through the Amazon Bedrock console, as well as the Amazon Bedrock Python SDK. To learn more about Automated Reasoning checks and how you can integrate it into your generative AI workflows, please read the Amazon Bedrock documentation, review the tutorials on the AWS AI blog, and visit the Bedrock Guardrails webpage.  

AWS IoT Core now supports a SET clause in IoT rules-SQL, which lets you set and reuse variables across SQL statements. This new feature provides a simpler SQL experience and ensures consistent content when variables are used multiple times. Additionally, a new get_or_default() function provides improved failure handling by returning default values while encountering data encoding or external dependency issues, ensuring IoT rules continue execution successfully.

AWS IoT Core is a fully managed service that securely connects millions of IoT devices to the AWS cloud. Rules for AWS IoT is a component of AWS IoT Core which enables you to filter, process, and decode IoT device data using SQL-like statements, and route the data to 20+ AWS and third-party services. As you define an IoT rule, these new capabilities help you eliminate complicated SQL statements and make it easy for you to manage IoT rules-SQL failures.

These new features are available in all AWS Regions where AWS IoT Core is available, including AWS GovCloud (US) and Amazon China Regions. For more information and getting started experience, visit the developer guides on SET clause and get_or_default() function.

 

​AWS IoT Core now supports a SET clause in IoT rules-SQL, which lets you set and reuse variables across SQL statements. This new feature provides a simpler SQL experience and ensures consistent content when variables are used multiple times. Additionally, a new get_or_default() function provides improved failure handling by returning default values while encountering data encoding or external dependency issues, ensuring IoT rules continue execution successfully. AWS IoT Core is a fully managed service that securely connects millions of IoT devices to the AWS cloud. Rules for AWS IoT is a component of AWS IoT Core which enables you to filter, process, and decode IoT device data using SQL-like statements, and route the data to 20+ AWS and third-party services. As you define an IoT rule, these new capabilities help you eliminate complicated SQL statements and make it easy for you to manage IoT rules-SQL failures.
These new features are available in all AWS Regions where AWS IoT Core is available, including AWS GovCloud (US) and Amazon China Regions. For more information and getting started experience, visit the developer guides on SET clause and get_or_default() function.  

Amazon Connect now provides you with the ability to monitor which contacts are queued for callback. This feature enables you to search for contacts queued for callback and view additional details such as the customer’s phone number and duration of being queued within the Connect UI and APIs. You can now pro-actively route contacts to agents that are at risk of exceeding the callback timelines communicated to customers. Businesses can also identify customers that have already successfully connected with agents, and clear them from the callback queue to remove duplicative work.

This feature is available in all regions where Amazon Connect is offered. To learn more, please visit our documentation and our webpage. 

 

​Amazon Connect now provides you with the ability to monitor which contacts are queued for callback. This feature enables you to search for contacts queued for callback and view additional details such as the customer’s phone number and duration of being queued within the Connect UI and APIs. You can now pro-actively route contacts to agents that are at risk of exceeding the callback timelines communicated to customers. Businesses can also identify customers that have already successfully connected with agents, and clear them from the callback queue to remove duplicative work. This feature is available in all regions where Amazon Connect is offered. To learn more, please visit our documentation and our webpage.