Amazon Bedrock Guardrails announces Identity and Access Management (IAM) policy-based enforcement capabilities to build safe, generative AI applications at scale. This new feature enables customers to apply specific guardrails to model inference calls, ensuring responsible AI policies are applied across all AI interactions. Bedrock Guardrails provides configurable safeguards to detect and filter undesirable content, topic filters to define and disallow specific topics, sensitive information filters to redact personally identifiable information (PII), word filters to block specific words, and detect model hallucinations by detecting grounding and relevance of model responses and identify, correct, and explain factual claims in model responses using Automated Reasoning checks. Guardrails can be applied across any foundation model including those hosted with Amazon Bedrock, self-hosted models, and third-party models outside Bedrock using the ApplyGuardrail API, providing a consistent user experience and standardizing safety and privacy controls.

Starting today, Bedrock Guardrails provides a new condition key bedrock:GuardrailIdentifier that can be used in IAM policies to enforce the use of specific guardrails with associated policies. This new condition key can be applied on all Bedrock Invoke and Converse APIs. If the guardrail configured in your IAM policy does not match the specified guardrail, the request will be rejected, ensuring compliance with the responsible AI policies of the organization.

IAM policy-based enforcement to comply with responsible AI policies is now available in all AWS regions where Bedrock Guardrails is supported today.

To learn more, see the technical documentation and the Bedrock Guardrails product page.

 

​Amazon Bedrock Guardrails announces Identity and Access Management (IAM) policy-based enforcement capabilities to build safe, generative AI applications at scale. This new feature enables customers to apply specific guardrails to model inference calls, ensuring responsible AI policies are applied across all AI interactions. Bedrock Guardrails provides configurable safeguards to detect and filter undesirable content, topic filters to define and disallow specific topics, sensitive information filters to redact personally identifiable information (PII), word filters to block specific words, and detect model hallucinations by detecting grounding and relevance of model responses and identify, correct, and explain factual claims in model responses using Automated Reasoning checks. Guardrails can be applied across any foundation model including those hosted with Amazon Bedrock, self-hosted models, and third-party models outside Bedrock using the ApplyGuardrail API, providing a consistent user experience and standardizing safety and privacy controls. Starting today, Bedrock Guardrails provides a new condition key bedrock:GuardrailIdentifier that can be used in IAM policies to enforce the use of specific guardrails with associated policies. This new condition key can be applied on all Bedrock Invoke and Converse APIs. If the guardrail configured in your IAM policy does not match the specified guardrail, the request will be rejected, ensuring compliance with the responsible AI policies of the organization. IAM policy-based enforcement to comply with responsible AI policies is now available in all AWS regions where Bedrock Guardrails is supported today. To learn more, see the technical documentation and the Bedrock Guardrails product page.  

Amazon CloudWatch RUM now allows customers to monitor multiple top-level domains (TLDs), and second-level domains (SLDs) using a single App Monitor unifying real user monitoring across multiple domains in CloudWatch RUM. Customers can now specify a list of domains and also use wildcards for TLDs to monitor all their front-end applications together. This enhancement is useful for web applications that need to be accessible from different domains due to various reasons such as user locations, domain migrations, or any other development needs.

This enhancement simplifies observability for applications accessed from multiple domains by displaying all real user data of the application on a single RUM dashboard. Customers can now monitor different SLDs, such as example.com and another.com, without creating separate monitors for each domain. They can also track applications deployed across multiple TLDs, such as example.com, and example.co.uk, helping monitoring performance across regions. Wildcard support for TLDs allows customers even more flexibility to monitor all variants of a domain, such as example.* or example.co.*, without manually specifying each one. Additionally, subdomain wildcards, which is already supported, continue to allow monitoring across multiple subdomains like *.example.com. These capabilities simplifies monitoring websites that operate in multiple regions, manage domain transitions during SLD migrations, and other development needs by consolidating data in a single place.

This feature is now available in all AWS commercial regions where CloudWatch RUM is available.

See documentation to know more about the feature, or see the one observability workshop to learn how to get started with CloudWatch RUM.
 

 

​Amazon CloudWatch RUM now allows customers to monitor multiple top-level domains (TLDs), and second-level domains (SLDs) using a single App Monitor unifying real user monitoring across multiple domains in CloudWatch RUM. Customers can now specify a list of domains and also use wildcards for TLDs to monitor all their front-end applications together. This enhancement is useful for web applications that need to be accessible from different domains due to various reasons such as user locations, domain migrations, or any other development needs. This enhancement simplifies observability for applications accessed from multiple domains by displaying all real user data of the application on a single RUM dashboard. Customers can now monitor different SLDs, such as example.com and another.com, without creating separate monitors for each domain. They can also track applications deployed across multiple TLDs, such as example.com, and example.co.uk, helping monitoring performance across regions. Wildcard support for TLDs allows customers even more flexibility to monitor all variants of a domain, such as example.* or example.co.*, without manually specifying each one. Additionally, subdomain wildcards, which is already supported, continue to allow monitoring across multiple subdomains like *.example.com. These capabilities simplifies monitoring websites that operate in multiple regions, manage domain transitions during SLD migrations, and other development needs by consolidating data in a single place. This feature is now available in all AWS commercial regions where CloudWatch RUM is available. See documentation to know more about the feature, or see the one observability workshop to learn how to get started with CloudWatch RUM.    

Amazon CloudWatch RUM, which helps developers monitor real user interactions and diagnose front-end performance issues in web applications, now supports JavaScript source maps, enabling developers to convert minified JavaScript errors in the stack trace into readable formats for faster error resolution. With this feature, front-end developers and DevOps teams can now view searchable, human-readable JS errors and quickly identify the exact location of errors in their original source code.

JavaScript errors can be difficult to debug when they are minified in the stack trace, making it hard to pinpoint the source of an issue. Now, if an error occurs in a production environment, RUM leverages customer uploaded source maps to trace it back to the original code. The added ability to search unminified stack traces in RUM events helps developers analyze trends and correlate issues across multiple sessions, enabling faster detection and prioritization of recurring errors. To unminify errors in JavaScript stack traces, customers need to enable it in the App Monitor configuration and provide the S3 URI of the bucket or folder that holds the source maps via the console or RUM APIs.

These enhancements are available in all regions where CloudWatch RUM is available. Customer pay cost of storage of their source maps to Amazon S3 and for the API calls to upload and retrieve source maps as per AWS public pricing found here.

See documentation to know more about the feature, or see user guide to learn how to get started with CloudWatch RUM.
 

 

​Amazon CloudWatch RUM, which helps developers monitor real user interactions and diagnose front-end performance issues in web applications, now supports JavaScript source maps, enabling developers to convert minified JavaScript errors in the stack trace into readable formats for faster error resolution. With this feature, front-end developers and DevOps teams can now view searchable, human-readable JS errors and quickly identify the exact location of errors in their original source code. JavaScript errors can be difficult to debug when they are minified in the stack trace, making it hard to pinpoint the source of an issue. Now, if an error occurs in a production environment, RUM leverages customer uploaded source maps to trace it back to the original code. The added ability to search unminified stack traces in RUM events helps developers analyze trends and correlate issues across multiple sessions, enabling faster detection and prioritization of recurring errors. To unminify errors in JavaScript stack traces, customers need to enable it in the App Monitor configuration and provide the S3 URI of the bucket or folder that holds the source maps via the console or RUM APIs. These enhancements are available in all regions where CloudWatch RUM is available. Customer pay cost of storage of their source maps to Amazon S3 and for the API calls to upload and retrieve source maps as per AWS public pricing found here. See documentation to know more about the feature, or see user guide to learn how to get started with CloudWatch RUM.    

AWS announces the next generation of Amazon Connect, where powerful AI turns every customer touchpoint into a deeper relationship and better outcome. This comprehensive approach spans self-service, agent assistance, analytics, post-contact evaluation, and automated follow-up boosts sales and delights customers, while learning from every touchpoint. The next generation of Amazon Connect can be enabled with a single click, and includes unlimited use of AI capabilities, so you can focus on making customer experience improvements, not cost-driven compromises.

This next generation of Amazon Connect is available in US East (N. Virginia), US West (Oregon), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), and Europe (London). To learn more see our launch blog, documentation, and our pricing page.

 

​AWS announces the next generation of Amazon Connect, where powerful AI turns every customer touchpoint into a deeper relationship and better outcome. This comprehensive approach spans self-service, agent assistance, analytics, post-contact evaluation, and automated follow-up boosts sales and delights customers, while learning from every touchpoint. The next generation of Amazon Connect can be enabled with a single click, and includes unlimited use of AI capabilities, so you can focus on making customer experience improvements, not cost-driven compromises. This next generation of Amazon Connect is available in US East (N. Virginia), US West (Oregon), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), and Europe (London). To learn more see our launch blog, documentation, and our pricing page.  

Today, AWS announces increased quotas for AWS Client VPN, expanding routes per target network association to 100 and authorization rules per endpoint to 200.

AWS Client VPN allows you to securely manage network routing and access control for your VPN connections. Previously, you were given default quota of 10 routes per association and 50 authorization rules per endpoint. With this quota increase, you can now configure up to 100 routes per association and 200 rules per endpoint. For example, enterprises with distributed architectures can define specific routing paths for multiple subnets across development, staging, and production environments, providing greater flexibility and granular control over network traffic flows.

These new quotas are default configurations and can be adjusted to a higher limit as well. These default quotas are automatically applied to all new and existing Client VPN endpoints. This enhancement is available at no additional cost in all AWS Regions where AWS Client VPN is generally available.

To learn more about Client VPN:

• Read the AWS Client VPN quotas page
• Visit the AWS Client VPN product page
• Read the AWS Client VPN documentation

 

​Today, AWS announces increased quotas for AWS Client VPN, expanding routes per target network association to 100 and authorization rules per endpoint to 200. AWS Client VPN allows you to securely manage network routing and access control for your VPN connections. Previously, you were given default quota of 10 routes per association and 50 authorization rules per endpoint. With this quota increase, you can now configure up to 100 routes per association and 200 rules per endpoint. For example, enterprises with distributed architectures can define specific routing paths for multiple subnets across development, staging, and production environments, providing greater flexibility and granular control over network traffic flows. These new quotas are default configurations and can be adjusted to a higher limit as well. These default quotas are automatically applied to all new and existing Client VPN endpoints. This enhancement is available at no additional cost in all AWS Regions where AWS Client VPN is generally available. To learn more about Client VPN:

Read the AWS Client VPN quotas page
Visit the AWS Client VPN product page
Read the AWS Client VPN documentation  

The Amazon DAX SDK for JavaScript, version 3 (v3) is now available. You can use this new DAX SDK to build JavaScript applications that benefit from accelerated access to DynamoDB with minimal configuration changes. The AWS SDK for JavaScript v3 offers a modular architecture and features that improve developer productivity.

DAX is a fully managed, highly available, in-memory cache for DynamoDB that can boost read performance by up to 10 times, even at millions of requests per second. It is API compatible with DynamoDB, so you do not need to change your application logic. Simply provision a DAX cluster, update your client to use the new DAX SDK for JavaScript v3, and direct your existing DynamoDB calls to the DAX endpoint.

For information about DAX Regional availability, see the “Service endpoints” section in Amazon DynamoDB endpoints and quotas. To get started with the DAX SDK for JavaScript v3, see Node.js and DAX.

 

​The Amazon DAX SDK for JavaScript, version 3 (v3) is now available. You can use this new DAX SDK to build JavaScript applications that benefit from accelerated access to DynamoDB with minimal configuration changes. The AWS SDK for JavaScript v3 offers a modular architecture and features that improve developer productivity. DAX is a fully managed, highly available, in-memory cache for DynamoDB that can boost read performance by up to 10 times, even at millions of requests per second. It is API compatible with DynamoDB, so you do not need to change your application logic. Simply provision a DAX cluster, update your client to use the new DAX SDK for JavaScript v3, and direct your existing DynamoDB calls to the DAX endpoint. For information about DAX Regional availability, see the “Service endpoints” section in Amazon DynamoDB endpoints and quotas. To get started with the DAX SDK for JavaScript v3, see Node.js and DAX.  

AWS WAF now supports URI fragment field matching, enabling customers to match against the URI fragment and along with the already supported URI path. With this feature, customers can create rules that inspect and match against the content of the URI fragment within the URI path.

Customers previously could use WAF match conditions to inspect requests and compare their origin against provided criteria. As customers strive to enhance security, they have requested the ability to match against the URI fragment – the part of the URL often after the «#» symbol. URI fragment is often used to identify specific sections or anchors within a web page and is not typically sent to the server during the initial request. For example, if you have a login page with a dynamic fragment like «foo://login.aspx#myFragment», you can create a rule that only allows requests with the «myFragment» fragment and denies all others. This enables targeted security controls, such as blocking access to sensitive areas, detecting unauthorized access attempts, and implementing enhanced bot detection by analyzing fragment patterns used by malicious actors.

There is no additional cost, but standard WAF charges still apply. For more information about pricing, visit the AWS WAF Pricing page. The feature is available in all AWS Regions where WAF is available for all supported origins. For more information about URI field for matching, visit the Developer Guide.
 

 

​AWS WAF now supports URI fragment field matching, enabling customers to match against the URI fragment and along with the already supported URI path. With this feature, customers can create rules that inspect and match against the content of the URI fragment within the URI path. Customers previously could use WAF match conditions to inspect requests and compare their origin against provided criteria. As customers strive to enhance security, they have requested the ability to match against the URI fragment – the part of the URL often after the «#» symbol. URI fragment is often used to identify specific sections or anchors within a web page and is not typically sent to the server during the initial request. For example, if you have a login page with a dynamic fragment like «foo://login.aspx#myFragment», you can create a rule that only allows requests with the «myFragment» fragment and denies all others. This enables targeted security controls, such as blocking access to sensitive areas, detecting unauthorized access attempts, and implementing enhanced bot detection by analyzing fragment patterns used by malicious actors. There is no additional cost, but standard WAF charges still apply. For more information about pricing, visit the AWS WAF Pricing page. The feature is available in all AWS Regions where WAF is available for all supported origins. For more information about URI field for matching, visit the Developer Guide.    

The Amazon DAX SDK for Go, version 2 (v2) is now available and is compatible with the AWS SDK for Go v2. The Amazon DAX SDK for Go v2 offers a modular architecture and features that improve developer productivity.

DAX is a fully managed, highly available, in-memory cache for DynamoDB that can boost read performance by up to 10 times, even at millions of requests per second. It is API compatible with DynamoDB, so you do not need to change your application logic. Simply create a DAX cluster, switch to the DAX SDK for Go v2, and point your existing DynamoDB calls to the DAX endpoint.

For information about DAX Regional availability, see the “Service endpoints” section in Amazon DynamoDB endpoints and quotas. To get started with the DAX SDK for Go v2, see DAX SDK for Go.

 

​The Amazon DAX SDK for Go, version 2 (v2) is now available and is compatible with the AWS SDK for Go v2. The Amazon DAX SDK for Go v2 offers a modular architecture and features that improve developer productivity. DAX is a fully managed, highly available, in-memory cache for DynamoDB that can boost read performance by up to 10 times, even at millions of requests per second. It is API compatible with DynamoDB, so you do not need to change your application logic. Simply create a DAX cluster, switch to the DAX SDK for Go v2, and point your existing DynamoDB calls to the DAX endpoint. For information about DAX Regional availability, see the “Service endpoints” section in Amazon DynamoDB endpoints and quotas. To get started with the DAX SDK for Go v2, see DAX SDK for Go.  

AWS Firewall Manager is now available in the AWS Asia Pacific (Thailand) and AWS Mexico (Central) regions, bringing AWS Firewall Manager to a total of 34 AWS commercial regions, 2 GovCloud regions, and all Amazon CloudFront edge locations.

AWS Firewall Manager is a security management service that enables customers to centrally configure and manage firewall rules across their accounts and resources. Using AWS Firewall Manager, customers can manage AWS WAF rules, AWS Shield Advanced protections, AWS Network Firewall, R53 resolver DNS Firewall and VPC security groups across their entire AWS Organizations. AWS Firewall Manager makes it easier for customers to ensure that all firewall rules are consistently enforced and compliant, even as new accounts and resources are created.

To get started, see the AWS Firewall Manager documentation for more details and the AWS Region Table for the list of regions where AWS Firewall Manager is currently available. To learn more about AWS Firewall Manager, its features, and its pricing, visit the AWS Firewall Manager website.

 

​AWS Firewall Manager is now available in the AWS Asia Pacific (Thailand) and AWS Mexico (Central) regions, bringing AWS Firewall Manager to a total of 34 AWS commercial regions, 2 GovCloud regions, and all Amazon CloudFront edge locations. AWS Firewall Manager is a security management service that enables customers to centrally configure and manage firewall rules across their accounts and resources. Using AWS Firewall Manager, customers can manage AWS WAF rules, AWS Shield Advanced protections, AWS Network Firewall, R53 resolver DNS Firewall and VPC security groups across their entire AWS Organizations. AWS Firewall Manager makes it easier for customers to ensure that all firewall rules are consistently enforced and compliant, even as new accounts and resources are created. To get started, see the AWS Firewall Manager documentation for more details and the AWS Region Table for the list of regions where AWS Firewall Manager is currently available. To learn more about AWS Firewall Manager, its features, and its pricing, visit the AWS Firewall Manager website.  

Customers can now set exclusion time windows to avoid affecting a service’s reliability score during planned downtime. This feature works with service-level objectives (SLOs) that are created and tracked using CloudWatch Application Signals. SLOs help track longer term performance of services against pre-defined thresholds. Customers can now gain control for pausing/resuming their SLOs during planned outages on CloudWatch Application Signals, an application performance monitoring (APM) tool that simplifies health and performance monitoring for applications hosted on AWS.

Customers occasionally need to omit specific timeframes from their SLO status and budget calculations due to scheduled maintenance, such as a periodical database maintenance window. This could be a single event, like a one time testing window, or a repeating event, such as off-hours. Using the Application Signals console or the SLO CloudFormation template, they can configure a start date and time, plus a duration or end time, to pause SLO measurements during a specific window. The new feature allows for configuring exclusion windows for multiple SLOs at a time, including existing SLOs.

All regions with Application Signals also support SLO time window exclusion. See documentation to learn more about SLOs. Customers may now sign up for the new bundled pricing plan for Application Signals. To learn more, see Amazon CloudWatch pricing.
 

 

​Customers can now set exclusion time windows to avoid affecting a service’s reliability score during planned downtime. This feature works with service-level objectives (SLOs) that are created and tracked using CloudWatch Application Signals. SLOs help track longer term performance of services against pre-defined thresholds. Customers can now gain control for pausing/resuming their SLOs during planned outages on CloudWatch Application Signals, an application performance monitoring (APM) tool that simplifies health and performance monitoring for applications hosted on AWS. Customers occasionally need to omit specific timeframes from their SLO status and budget calculations due to scheduled maintenance, such as a periodical database maintenance window. This could be a single event, like a one time testing window, or a repeating event, such as off-hours. Using the Application Signals console or the SLO CloudFormation template, they can configure a start date and time, plus a duration or end time, to pause SLO measurements during a specific window. The new feature allows for configuring exclusion windows for multiple SLOs at a time, including existing SLOs. All regions with Application Signals also support SLO time window exclusion. See documentation to learn more about SLOs. Customers may now sign up for the new bundled pricing plan for Application Signals. To learn more, see Amazon CloudWatch pricing.