Starting today, Amazon Elastic Compute Cloud (Amazon EC2) Flex (C7i-flex, M7i-flex) instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in Asia Pacific (Thailand) and Mexico (Central) regions. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers.

Flex instances are the easiest way for you to get price-performance benefits for a majority of general-purpose and compute intensive workloads. C7i-flex and M7i-flex instances deliver up to 19% better price-performance compared to C6i and M6i instances respectively. These instances offer the most common sizes, from large to 16xlarge, and are a great first choice for applications that don’t fully utilize all compute resources such as web and application servers, virtual desktops, batch-processing, microservices, databases, caches, and more. For workloads that need larger instance sizes (up to 192 vCPUs and 768 GiB memory) or continuous high CPU usage, you can leverage C7i and M7i instances.

C7i-flex instances are available in the following AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), Canada (Central), Asia Pacific (Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand, Tokyo), Mexico (Central), South America (São Paulo), and AWS GovCloud (US-West).

M7i-flex instances are available in the following AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), Canada (Central), Asia Pacific (Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand, Tokyo), Mexico (Central), South America (São Paulo), and the AWS GovCloud (US-East, US-West).
 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) Flex (C7i-flex, M7i-flex) instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in Asia Pacific (Thailand) and Mexico (Central) regions. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers. Flex instances are the easiest way for you to get price-performance benefits for a majority of general-purpose and compute intensive workloads. C7i-flex and M7i-flex instances deliver up to 19% better price-performance compared to C6i and M6i instances respectively. These instances offer the most common sizes, from large to 16xlarge, and are a great first choice for applications that don’t fully utilize all compute resources such as web and application servers, virtual desktops, batch-processing, microservices, databases, caches, and more. For workloads that need larger instance sizes (up to 192 vCPUs and 768 GiB memory) or continuous high CPU usage, you can leverage C7i and M7i instances. C7i-flex instances are available in the following AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), Canada (Central), Asia Pacific (Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand, Tokyo), Mexico (Central), South America (São Paulo), and AWS GovCloud (US-West). M7i-flex instances are available in the following AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Europe (Frankfurt, Ireland, London, Paris, Spain, Stockholm), Canada (Central), Asia Pacific (Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand, Tokyo), Mexico (Central), South America (São Paulo), and the AWS GovCloud (US-East, US-West).    

Today, AWS announces the general availability of PySpark in AWS Clean Rooms, enabling companies and their partners to run sophisticated analytics across large datasets using PySpark, the Python API for Apache Spark. With this launch, you and your partners can bring PySpark code and libraries to an AWS Clean Rooms collaboration and run advanced analyses without having to share underlying data or proprietary analysis methods. For example, an advertising measurement provider can use PySpark in AWS Clean Rooms to run their custom algorithms across multiple publisher datasets simultaneously to measure ad effectiveness. Similarly, a pharmaceutical company can run their proprietary algorithms and libraries across multiple healthcare provider datasets with appropriate patient consent to evaluate drug adherence across clinical trials, without sharing their proprietary data.

AWS Clean Rooms helps companies and their partners to easily analyze and collaborate on their collective datasets without revealing or copying one another’s underlying data. Companies can deploy their own clean rooms without having to build, manage, or maintain their own solutions or move data outside of their AWS environment. PySpark in AWS Clean Rooms is generally available in these AWS Regions. To learn more, visit AWS Clean Rooms.

​Today, AWS announces the general availability of PySpark in AWS Clean Rooms, enabling companies and their partners to run sophisticated analytics across large datasets using PySpark, the Python API for Apache Spark. With this launch, you and your partners can bring PySpark code and libraries to an AWS Clean Rooms collaboration and run advanced analyses without having to share underlying data or proprietary analysis methods. For example, an advertising measurement provider can use PySpark in AWS Clean Rooms to run their custom algorithms across multiple publisher datasets simultaneously to measure ad effectiveness. Similarly, a pharmaceutical company can run their proprietary algorithms and libraries across multiple healthcare provider datasets with appropriate patient consent to evaluate drug adherence across clinical trials, without sharing their proprietary data. AWS Clean Rooms helps companies and their partners to easily analyze and collaborate on their collective datasets without revealing or copying one another’s underlying data. Companies can deploy their own clean rooms without having to build, manage, or maintain their own solutions or move data outside of their AWS environment. PySpark in AWS Clean Rooms is generally available in these AWS Regions. To learn more, visit AWS Clean Rooms.  

The post Microsoft Ability Summit 2025: Accesibilidad en la era de la IA appeared first on Source LATAM.

​The post Microsoft Ability Summit 2025: Accesibilidad en la era de la IA appeared first on Source LATAM.  

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.