AWS B2B Data Interchange now supports custom validation rules for X12 EDI documents, enabling you to expand and alter the validation logic of the X12 ANSI standard to align with custom agreements with your trading partners.

AWS B2B Data Interchange automates validation, transformation, and generation of Electronic Data Interchange (EDI) documents such as ANSI X12 documents to and from JSON and XML data formats. With this launch, you can expand and alter the validation logic of the X12 ANSI standard. You can choose if certain elements need to be present and what length and values of elements are allowed for documents to pass the validation. AWS B2B Data Interchange will automatically validate X12 EDI documents against a combination of the X12 standard and your custom rules. Validation status will be communicated in a generated functional acknowledgment X12 EDI document (997/999) and in an emitted EventBridge event. In case of validation failure, AWS B2B Data Interchange will also generate a human-readable plain language explanation of validation errors and store it alongside your output files. You can use these events and data to trigger and streamline your validation remediation workflow, reducing the time and costs to process your X12 documents.

Support for custom validation rules for X12 EDI documents is available in all AWS Regions where the AWS B2B Data Interchange service is available. To get started with building event-driven EDI workloads on AWS B2B Data Interchange, take the self-paced workshop or refer to the AWS B2B Data Interchange user guide.

 

​AWS B2B Data Interchange now supports custom validation rules for X12 EDI documents, enabling you to expand and alter the validation logic of the X12 ANSI standard to align with custom agreements with your trading partners. AWS B2B Data Interchange automates validation, transformation, and generation of Electronic Data Interchange (EDI) documents such as ANSI X12 documents to and from JSON and XML data formats. With this launch, you can expand and alter the validation logic of the X12 ANSI standard. You can choose if certain elements need to be present and what length and values of elements are allowed for documents to pass the validation. AWS B2B Data Interchange will automatically validate X12 EDI documents against a combination of the X12 standard and your custom rules. Validation status will be communicated in a generated functional acknowledgment X12 EDI document (997/999) and in an emitted EventBridge event. In case of validation failure, AWS B2B Data Interchange will also generate a human-readable plain language explanation of validation errors and store it alongside your output files. You can use these events and data to trigger and streamline your validation remediation workflow, reducing the time and costs to process your X12 documents. Support for custom validation rules for X12 EDI documents is available in all AWS Regions where the AWS B2B Data Interchange service is available. To get started with building event-driven EDI workloads on AWS B2B Data Interchange, take the self-paced workshop or refer to the AWS B2B Data Interchange user guide.  

Amazon Bedrock Data Automation (BDA) is now generally available in the AWS GovCloud (US-West) Region.

BDA is a feature of Amazon Bedrock that enables developers to automate the generation of valuable insights from unstructured multimodal content such as documents, images, video, and audio to build GenAI-based applications. By leveraging BDA, developers can reduce development time and effort, making it easier to build intelligent document processing, media analysis, and other multimodal data-centric automation solutions. BDA can be used as a standalone feature or as a parser in Amazon Knowledge Bases RAG workflows.

With this launch, BDA is now available in a total of 8 AWS Regions: Europe (Frankfurt), Europe (London), Europe (Ireland), Asia Pacific (Mumbai) and Asia Pacific (Sydney), US West (Oregon), US East (N. Virginia) and AWS GovCloud (US-West) Regions. To learn more, visit the Bedrock Data Automation product page and the Amazon Bedrock Pricing page.

 

​Amazon Bedrock Data Automation (BDA) is now generally available in the AWS GovCloud (US-West) Region. BDA is a feature of Amazon Bedrock that enables developers to automate the generation of valuable insights from unstructured multimodal content such as documents, images, video, and audio to build GenAI-based applications. By leveraging BDA, developers can reduce development time and effort, making it easier to build intelligent document processing, media analysis, and other multimodal data-centric automation solutions. BDA can be used as a standalone feature or as a parser in Amazon Knowledge Bases RAG workflows. With this launch, BDA is now available in a total of 8 AWS Regions: Europe (Frankfurt), Europe (London), Europe (Ireland), Asia Pacific (Mumbai) and Asia Pacific (Sydney), US West (Oregon), US East (N. Virginia) and AWS GovCloud (US-West) Regions. To learn more, visit the Bedrock Data Automation product page and the Amazon Bedrock Pricing page.  

Today, we are announcing the support of Bring Your Own Knowledge Graph (BYOKG) for Retrieval-Augmented Generation (RAG) using the open-source GraphRAG Toolkit. This new capability allows customers to connect their existing knowledge graphs to large language models (LLMs), enabling Generative AI applications that deliver more accurate, context-rich, and explainable responses grounded in trusted, structured data.

Previously, customers who wanted to use their own curated graphs for RAG had to build custom pipelines and retrieval logic to integrate graph queries into generative AI workflows. With BYOKG support, developers can now directly leverage their domain-specific graphs, such as those stored in Amazon Neptune Database or Neptune Analytics, through the GraphRAG Toolkit. This makes it easier to operationalize graph-aware RAG, reducing hallucinations and improving reasoning over multi-hop and temporal relationships. For example, a fraud investigation assistant can query a financial services company’s knowledge graph to surface suspicious transaction patterns and provide analysts with contextual explanations. Similarly, a telecom operations chatbot can detect that a series of linked cell towers are consistently failing, trace the dependency paths to affected network switches, and then guide technicians using SOP documents on how to resolve the issue. Developers simply configure the GraphRAG Toolkit with their existing graph data source, and it will orchestrate retrieval strategies that use graph queries alongside vector search to enhance generative AI outputs.

To learn more and get started, visit the GraphRAG Toolkit User Guide.

 

​Today, we are announcing the support of Bring Your Own Knowledge Graph (BYOKG) for Retrieval-Augmented Generation (RAG) using the open-source GraphRAG Toolkit. This new capability allows customers to connect their existing knowledge graphs to large language models (LLMs), enabling Generative AI applications that deliver more accurate, context-rich, and explainable responses grounded in trusted, structured data. Previously, customers who wanted to use their own curated graphs for RAG had to build custom pipelines and retrieval logic to integrate graph queries into generative AI workflows. With BYOKG support, developers can now directly leverage their domain-specific graphs, such as those stored in Amazon Neptune Database or Neptune Analytics, through the GraphRAG Toolkit. This makes it easier to operationalize graph-aware RAG, reducing hallucinations and improving reasoning over multi-hop and temporal relationships. For example, a fraud investigation assistant can query a financial services company’s knowledge graph to surface suspicious transaction patterns and provide analysts with contextual explanations. Similarly, a telecom operations chatbot can detect that a series of linked cell towers are consistently failing, trace the dependency paths to affected network switches, and then guide technicians using SOP documents on how to resolve the issue. Developers simply configure the GraphRAG Toolkit with their existing graph data source, and it will orchestrate retrieval strategies that use graph queries alongside vector search to enhance generative AI outputs. To learn more and get started, visit the GraphRAG Toolkit User Guide.  

Etiquetas:

• Seguridad
• Tecnología

The post Resiliencia poscuántica: construir bases seguras appeared first on Source LATAM.

 

​The post Resiliencia poscuántica: construir bases seguras appeared first on Source LATAM.  

Today, AWS announced the release of a model context protocol (MCP) server for Billing and Cost Management, now available in the AWS Labs GitHub repository. The Billing and Cost Management MCP server allows customers to analyze their historical spending, find cost optimization opportunities, and estimate the costs of new workloads using the AI agent or assistant of their choice.

Artificial intelligence is transforming the way that customers manage FinOps practices. While customers can access AI-powered cost analysis and optimization capabilities in Amazon Q Developer in the console, the Billing and Cost Management MCP server brings these capabilities to any MCP-compatible AI assistant or agent that customers may be using, such as Q Developer CLI tool, the Kiro IDE, Visual Studio Code, or Claude Desktop. This MCP server gives these clients rich capabilities to analyze historical and forecasted cost and usage data, identify cost optimization opportunities, understand AWS service pricing, find cost anomalies, and more. The MCP server not only provides access to AWS service APIs; it also provides a dedicated SQL-based calculation engine allowing AI assistants to perform reliable, reproducible calculations — ranging from period-over-period changes to unit cost metrics — and easily handle large volumes of cost and usage data.

You can download and integrate the open-source server with your preferred MCP-compatible AI assistant. The server connects securely to the AWS Billing and Cost Management services using standard AWS credentials with minimal configuration required. To get started, visit the AWS Labs GitHub repository.

 

​Today, AWS announced the release of a model context protocol (MCP) server for Billing and Cost Management, now available in the AWS Labs GitHub repository. The Billing and Cost Management MCP server allows customers to analyze their historical spending, find cost optimization opportunities, and estimate the costs of new workloads using the AI agent or assistant of their choice. Artificial intelligence is transforming the way that customers manage FinOps practices. While customers can access AI-powered cost analysis and optimization capabilities in Amazon Q Developer in the console, the Billing and Cost Management MCP server brings these capabilities to any MCP-compatible AI assistant or agent that customers may be using, such as Q Developer CLI tool, the Kiro IDE, Visual Studio Code, or Claude Desktop. This MCP server gives these clients rich capabilities to analyze historical and forecasted cost and usage data, identify cost optimization opportunities, understand AWS service pricing, find cost anomalies, and more. The MCP server not only provides access to AWS service APIs; it also provides a dedicated SQL-based calculation engine allowing AI assistants to perform reliable, reproducible calculations — ranging from period-over-period changes to unit cost metrics — and easily handle large volumes of cost and usage data. You can download and integrate the open-source server with your preferred MCP-compatible AI assistant. The server connects securely to the AWS Billing and Cost Management services using standard AWS credentials with minimal configuration required. To get started, visit the AWS Labs GitHub repository.  

Amazon Relational Database Service (RDS) for DB2 now supports read replicas. Customers can add up to three read replicas for their database instance, and use the replicas to support read-only applications without overloading the primary database instance.

Customers can setup replicas in the same region or in a different region from the primary database instance. When a read replica is setup, RDS replicates changes asynchronously to the read replicas. Customers can run their read-only queries against the read replica without impacting performance of the primary database instance. Customers can also use read replicas for disaster recovery procedures by promoting a read replica to support both read and write operations.

Read replicas require IBM Db2 licenses for all vCPUs on replica instances. Customers can obtain On-Demand Db2 licenses from the AWS Marketplace, or use Bring Your Own License (BYOL). To learn more, refer to Amazon RDS for Db2 documentation and pricing pages.

 

​Amazon Relational Database Service (RDS) for DB2 now supports read replicas. Customers can add up to three read replicas for their database instance, and use the replicas to support read-only applications without overloading the primary database instance. Customers can setup replicas in the same region or in a different region from the primary database instance. When a read replica is setup, RDS replicates changes asynchronously to the read replicas. Customers can run their read-only queries against the read replica without impacting performance of the primary database instance. Customers can also use read replicas for disaster recovery procedures by promoting a read replica to support both read and write operations. Read replicas require IBM Db2 licenses for all vCPUs on replica instances. Customers can obtain On-Demand Db2 licenses from the AWS Marketplace, or use Bring Your Own License (BYOL). To learn more, refer to Amazon RDS for Db2 documentation and pricing pages.  

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R7g instances are available in the AWS Africa (Cape Town) region. These instances are powered by AWS Graviton3 processors that provide up to 25% better compute performance compared to AWS Graviton2 processors, and built on top of the the AWS Nitro System, a collection of AWS designed innovations that deliver efficient, flexible, and secure cloud services with isolated multi-tenancy, private networking, and fast local storage.

Amazon EC2 Graviton3 instances also use up to 60% less energy to reduce your cloud carbon footprint for the same performance than comparable EC2 instances. For increased scalability, these instances are available in 9 different instance sizes, including bare metal, and offer up to 30 Gbps networking bandwidth and up to 20 Gbps of bandwidth to the Amazon Elastic Block Store (EBS).

To learn more, see Amazon EC2 R7g. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R7g instances are available in the AWS Africa (Cape Town) region. These instances are powered by AWS Graviton3 processors that provide up to 25% better compute performance compared to AWS Graviton2 processors, and built on top of the the AWS Nitro System, a collection of AWS designed innovations that deliver efficient, flexible, and secure cloud services with isolated multi-tenancy, private networking, and fast local storage. Amazon EC2 Graviton3 instances also use up to 60% less energy to reduce your cloud carbon footprint for the same performance than comparable EC2 instances. For increased scalability, these instances are available in 9 different instance sizes, including bare metal, and offer up to 30 Gbps networking bandwidth and up to 20 Gbps of bandwidth to the Amazon Elastic Block Store (EBS). To learn more, see Amazon EC2 R7g. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.  

Amazon RDS for PostgreSQL now supports delayed read replicas, allowing you to specify a minimum time period that a replica database lags behind a source database. This feature creates a time buffer that helps protect against data loss from human errors such as accidental table drops or unintended data modifications.

In disaster recovery scenarios, you can pause replication before problematic changes are applied, resume replication up to a specific log position, and promote the replica as your new primary database. This approach enables faster recovery compared to traditional point-in-time restore operations, which can take hours for large databases.

This feature is available in all AWS Regions where RDS for PostgreSQL is offered, including the AWS GovCloud (US) Regions, at no additional cost beyond standard RDS pricing. To learn more, visit the Amazon RDS for PostgreSQL documentation. 

 

​Amazon RDS for PostgreSQL now supports delayed read replicas, allowing you to specify a minimum time period that a replica database lags behind a source database. This feature creates a time buffer that helps protect against data loss from human errors such as accidental table drops or unintended data modifications. In disaster recovery scenarios, you can pause replication before problematic changes are applied, resume replication up to a specific log position, and promote the replica as your new primary database. This approach enables faster recovery compared to traditional point-in-time restore operations, which can take hours for large databases. This feature is available in all AWS Regions where RDS for PostgreSQL is offered, including the AWS GovCloud (US) Regions, at no additional cost beyond standard RDS pricing. To learn more, visit the Amazon RDS for PostgreSQL documentation.   

The Count Tokens API is now available in Amazon Bedrock, enabling you to determine the token count for a given prompt or input being sent to a specific model ID prior to performing any inference.

By surfacing a prompt’s token count, the Count Tokens API allows you to more accurately project your costs, and provides you with greater transparency and control over your AI model usage. It allows you to proactively manage your token limits on Amazon Bedrock, helping to optimize your usage and avoid unexpected throttling. It also helps ensure your workloads fit within a model’s context length limit, allowing for more efficient prompt optimization.

At launch, the Count Tokens API will support Claude models, with the functionality available in all regions where these models are supported. For more information about this new feature, including supported models and use cases, visit the Count Tokens API documentation.

 

​The Count Tokens API is now available in Amazon Bedrock, enabling you to determine the token count for a given prompt or input being sent to a specific model ID prior to performing any inference.
By surfacing a prompt’s token count, the Count Tokens API allows you to more accurately project your costs, and provides you with greater transparency and control over your AI model usage. It allows you to proactively manage your token limits on Amazon Bedrock, helping to optimize your usage and avoid unexpected throttling. It also helps ensure your workloads fit within a model’s context length limit, allowing for more efficient prompt optimization.
At launch, the Count Tokens API will support Claude models, with the functionality available in all regions where these models are supported. For more information about this new feature, including supported models and use cases, visit the Count Tokens API documentation.  

Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes namespace configuration for AWS and Community add-ons, providing you greater control over how add-ons are organized within your Kubernetes cluster.

With namespace configuration, you can now specify a custom namespace during add-on installation, enabling better organization and isolation of add-on objects within your EKS cluster. This flexibility helps you align add-ons with your operational needs and existing namespace strategy. Once an add-on is installed in a specific namespace, you must remove and recreate the add-on to change its namespace.

This feature is available through the AWS Management Console, Amazon EKS APIs, AWS Command Line Interface (CLI), and infrastructure as code tools like AWS CloudFormation. Namespace configuration for AWS and Community add-ons is now available in all commercial AWS Regions. To learn more, visit the Amazon EKS documentation.

 

​Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes namespace configuration for AWS and Community add-ons, providing you greater control over how add-ons are organized within your Kubernetes cluster. With namespace configuration, you can now specify a custom namespace during add-on installation, enabling better organization and isolation of add-on objects within your EKS cluster. This flexibility helps you align add-ons with your operational needs and existing namespace strategy. Once an add-on is installed in a specific namespace, you must remove and recreate the add-on to change its namespace. This feature is available through the AWS Management Console, Amazon EKS APIs, AWS Command Line Interface (CLI), and infrastructure as code tools like AWS CloudFormation. Namespace configuration for AWS and Community add-ons is now available in all commercial AWS Regions. To learn more, visit the Amazon EKS documentation.