Amazon Aurora MySQL-Compatible Edition now supports MySQL 8.4, a community MySQL Long Term Support (LTS) major version. Aurora MySQL 8.4 launches with compatibility for community MySQL 8.4.7 and introduces aligned version numbering, so the version number you run on Aurora matches the community MySQL version it is compatible with. Aurora also manages the underlying patch on your behalf, simplifying day-to-day operations. Aurora MySQL now targets major versions within 12 months of community MySQL LTS releases, minor versions within 3 months of each community minor, and an Aurora LTS minor within 12 months of each major. For engine specific release objectives, see the Aurora and RDS open source release calendar announcement.

Aurora MySQL 8.4 strengthens security defaults for new clusters. TLS is enforced by default with only TLS 1.2 and 1.3 supported, new accounts use the caching_sha2_password authentication plugin, and password validation policies are customizable through DB cluster parameter groups. Automated upgrade prechecks identify compatibility issues before your cluster goes offline, giving you confidence before you upgrade. To learn more about the Aurora MySQL 8.4 customer experience, refer to the Aurora MySQL 8.4 launch announcement blog.

You can upgrade your database using Amazon RDS Blue/Green Deployments, in-place upgrade, or restore from a snapshot. Learn more about performing major version upgrades in the Amazon Aurora User Guide. You can also migrate to Aurora MySQL 8.4 from external MySQL sources using AWS Database Migration Service or Percona XtraBackup. Aurora MySQL 8.4 is available in all AWS Regions where Aurora MySQL is available.

Amazon Aurora MySQL is designed for unparalleled high performance and availability at global scale with full MySQL compatibility. It provides scale-to-zero serverless compute, Aurora Global Database for Multi-Region resilience, Aurora I/O-Optimized for improved price performance on I/O-intensive workloads, and built-in security and continuous backups. To get started with Amazon Aurora, take a look at our getting started page.

​Amazon Aurora MySQL-Compatible Edition now supports MySQL 8.4, a community MySQL Long Term Support (LTS) major version. Aurora MySQL 8.4 launches with compatibility for community MySQL 8.4.7 and introduces aligned version numbering, so the version number you run on Aurora matches the community MySQL version it is compatible with. Aurora also manages the underlying patch on your behalf, simplifying day-to-day operations. Aurora MySQL now targets major versions within 12 months of community MySQL LTS releases, minor versions within 3 months of each community minor, and an Aurora LTS minor within 12 months of each major. For engine specific release objectives, see the Aurora and RDS open source release calendar announcement. Aurora MySQL 8.4 strengthens security defaults for new clusters. TLS is enforced by default with only TLS 1.2 and 1.3 supported, new accounts use the caching_sha2_password authentication plugin, and password validation policies are customizable through DB cluster parameter groups. Automated upgrade prechecks identify compatibility issues before your cluster goes offline, giving you confidence before you upgrade. To learn more about the Aurora MySQL 8.4 customer experience, refer to the Aurora MySQL 8.4 launch announcement blog. You can upgrade your database using Amazon RDS Blue/Green Deployments, in-place upgrade, or restore from a snapshot. Learn more about performing major version upgrades in the Amazon Aurora User Guide. You can also migrate to Aurora MySQL 8.4 from external MySQL sources using AWS Database Migration Service or Percona XtraBackup. Aurora MySQL 8.4 is available in all AWS Regions where Aurora MySQL is available. Amazon Aurora MySQL is designed for unparalleled high performance and availability at global scale with full MySQL compatibility. It provides scale-to-zero serverless compute, Aurora Global Database for Multi-Region resilience, Aurora I/O-Optimized for improved price performance on I/O-intensive workloads, and built-in security and continuous backups. To get started with Amazon Aurora, take a look at our getting started page.  

Amazon Relational Database Service (Amazon RDS) Custom for SQL Server now supports the latest General Distribution Release (GDR) updates for Microsoft SQL Server. This release includes support for SQL Server 2019 CU32+GDR KB5084816 (RDS version 15.00.4465.1.v1) and SQL Server 2022 CU24+GDR KB5083252 (RDS version 16.00.4250.1.v1).

The GDR updates address vulnerabilities described in CVE-2026-32167 and CVE-2026-32176. For additional information on the improvements and fixes included in these updates, see Microsoft documentation for KB5084816, KB5083252. You can upgrade your Amazon RDS Custom for SQL Server instances to apply these recommended updates using Amazon RDS Management Console, or by using the AWS SDK or CLI. To learn more about upgrading your database instances, see Amazon RDS Custom User Guide.

​Amazon Relational Database Service (Amazon RDS) Custom for SQL Server now supports the latest General Distribution Release (GDR) updates for Microsoft SQL Server. This release includes support for SQL Server 2019 CU32+GDR KB5084816 (RDS version 15.00.4465.1.v1) and SQL Server 2022 CU24+GDR KB5083252 (RDS version 16.00.4250.1.v1). The GDR updates address vulnerabilities described in CVE-2026-32167 and CVE-2026-32176. For additional information on the improvements and fixes included in these updates, see Microsoft documentation for KB5084816, KB5083252. You can upgrade your Amazon RDS Custom for SQL Server instances to apply these recommended updates using Amazon RDS Management Console, or by using the AWS SDK or CLI. To learn more about upgrading your database instances, see Amazon RDS Custom User Guide.  

Amazon Bedrock customers can now attribute model inference usage to specific teams, applications, environments, and experiments at the individual request level on the InvokeModel and InvokeModelWithResponseStream APIs. This gives customers fine-grained visibility into how their Amazon Bedrock usage is distributed across their organization, helping them
understand consumption patterns, optimize spend, and report usage back to internal stakeholders without provisioning additional resources.

This launch builds on Amazon Bedrock’s existing portfolio of usage attribution capabilities. Customers can already attribute model inference usage at the resource and identity level using application inference profiles, IAM principal-based attribution, project-level tracking on the OpenAI-compatible bedrock-mantle endpoint, and workspace-level tracking for
Anthropic Claude models. For finer-grained, per-request attribution, the Converse and ConverseStream APIs have supported request-level metadata since launch. Today’s release brings the same capability to the InvokeModel and InvokeModelWithResponseStream APIs, giving customers a consistent way to tag inference calls across the entire bedrock-runtime endpoint.

With this launch, customers can tag each Amazon Bedrock model inference call with attributes like team, project, or environment, and analyze usage by these tags in Amazon Bedrock model invocation logs. To get started, enable model invocation logging in the AWS Region where you call Amazon Bedrock, then add metadata to your inference requests. This feature is available in all AWS commercial Regions where Amazon Bedrock is available. To learn more, see Request metadata. 

​Amazon Bedrock customers can now attribute model inference usage to specific teams, applications, environments, and experiments at the individual request level on the InvokeModel and InvokeModelWithResponseStream APIs. This gives customers fine-grained visibility into how their Amazon Bedrock usage is distributed across their organization, helping them understand consumption patterns, optimize spend, and report usage back to internal stakeholders without provisioning additional resources. This launch builds on Amazon Bedrock’s existing portfolio of usage attribution capabilities. Customers can already attribute model inference usage at the resource and identity level using application inference profiles, IAM principal-based attribution, project-level tracking on the OpenAI-compatible bedrock-mantle endpoint, and workspace-level tracking for Anthropic Claude models. For finer-grained, per-request attribution, the Converse and ConverseStream APIs have supported request-level metadata since launch. Today’s release brings the same capability to the InvokeModel and InvokeModelWithResponseStream APIs, giving customers a consistent way to tag inference calls across the entire bedrock-runtime endpoint. With this launch, customers can tag each Amazon Bedrock model inference call with attributes like team, project, or environment, and analyze usage by these tags in Amazon Bedrock model invocation logs. To get started, enable model invocation logging in the AWS Region where you call Amazon Bedrock, then add metadata to your inference requests. This feature is available in all AWS commercial Regions where Amazon Bedrock is available. To learn more, see Request metadata.   

• Categoría: Noticias de Microsoft

mayo 21, 2026

IA en el trabajo: Cuando los mayores usuarios del software no son humanos

Los agentes ya operan dentro de su stack, para cambiar lo que el software debe ser y en qué deben invertir los líderes.

Por: Jared Spataro, CMO de IA en el Trabajo de Microsoft.

Cada software con el que funciona su organización—su CRM, su ERP, su plataforma de gestión de proyectos, su suite de productividad—se construyó bajo una única suposición: que el usuario principal era un ser humano. Esa suposición ya no se cumple.

Los agentes ya trabajan dentro de su pila de software—a velocidad de máquina, sin necesidad de menús ni formación, para gestionar el trabajo en segundos o minutos que antes llevaban horas o días a los humanos. Ahora la pregunta es qué cambia eso —y para quién.

El usuario ha cambiado—y eso lo cambia todo

Durante 30 años, cada software empresarial se construyó en torno a una única limitación: el humano en el otro extremo. Cada característica tenía que ser descubrible. Cada flujo de trabajo tenía que ser aprendible. El límite de lo que el software podía hacer estaba limitado a lo que una persona podía navegar. Cuando los agentes hacen el trabajo, ese techo desaparece. El software ya no tiene que reflejar la elección entre lo potente y lo utilizable.

La evidencia de ese cambio ya está aquí. Un responsable financiero de uno de nuestros equipos de finanzas comerciales describió de manera reciente sentarse con un conjunto de datos desordenado, un cuaderno en blanco y un único objetivo: llegar a la historia del negocio más rápido. Pidieron a Copilot que construyera un pivote a nivel de producto a partir de una extracción de datos en bruto. Cuando la primera revisión volvió como vista anual, escribieron en inglés claro que necesitaban trimestres fiscales—y Copilot volvió a la fuente, añadió una columna que mapeaba cada fila al trimestre correcto y reconstruyó el pivote. El gerente insistió más, pidió una descomposición Volumen-Tasa-Total, además de un puente de contribución año tras año. Y al final, para poner a prueba el resultado, rompieron de manera deliberada varias fórmulas y pidieron a Copilot que auditara todo el cuaderno. Recorría todas las pestañas, marcaba cada inconsistencia con un nivel de gravedad y reescribía cada fórmula rota—todo mientras el encargado respondía correos y llamadas en una segunda pantalla. Su reflexión refleja el cambio: «Aunque funciona de manera discreta en segundo plano, podemos centrar nuestro enfoque en las ideas, la toma de decisiones y conversaciones significativas entre socios de negocio.» El gerente no navegaba por Excel. La IA lo hacía.

Eso de «estar en segundo plano en silencio» importa. Muchos de los agentes más importantes ni siquiera aparecen en una ventana de chat. Funcionarán sin cabeza—activados por un cambio de política, una actualización de datos, la apertura de un ticket, un envío retrasado—para ejecutar trabajo dentro de los sistemas a velocidad de máquina, y luego solo aparecen resultados cuando una persona necesite revisar, aprobar o intervenir.

Nuestro nuevo Copilot Cowork es un sistema agéntico que se integra en el software empresarial que su organización ya ejecuta y ejecuta el trabajo en su nombre: el humano establece el objetivo, el agente realiza el trabajo. Además, resulta ser un producto que fue escrito casi en su totalidad por agentes, por un puñado de ingenieros, en cuestión de semanas. En ambos casos, el cambio es el mismo: los agentes se convierten en los principales operadores del software empresarial.

El software se rediseña para agentes en tres capas

Los agentes ya trabajan dentro de sus herramientas. Las plataformas que avanzan se transformarán desde los datos hacia arriba.

Qué significa esto para el software que ya poseen

La mayor parte de la conversación sobre IA y software empresarial se centra en la superficie: la interfaz, las funciones, la velocidad. Y todo eso es importante, pero se han comenzado a producir cambios aún más importantes bajo el capó.

• Experiencia de usuario. Existe una opinión que ha comenzado a ganar fuerza, de que las interfaces desaparecerán por completo a medida que los agentes tomen el control, pero la tecnología no se difunde así. La adopción ocurre cuando te encuentras con los usuarios donde están: en las herramientas que conocen y en los lienzos donde vive el trabajo. Las interfaces se convierten en el punto de encuentro: donde el trabajo se revisa, comparte y se entrega. Ahora hay dos clases de usuario: humano y agente, y el software tiene que servir a ambos.
• Lógica de negocio. La capa que codifica cómo opera una empresa: cómo cierras los libros, cómo se aprueba un informe y a quién se escala el caso. Ahora mismo, esa lógica está integrada en flujos de trabajo diseñados para humanos. A medida que los agentes asumen más de esa ejecución, debe estar integrada en el sistema como habilidades que un agente pueda invocar de manera directa. De ahí vendrán las mayores ganancias de eficiencia.
• Datos preparados. Cada aplicación empresarial almacena datos como base para su trabajo, pero los agentes se benefician de que estén optimizados para su uso. Los agentes pueden averiguar la estructura y el significado de un conjunto de datos por sí mismos, pero si tienen que hacerlo cada vez que alguien hace una pregunta, la IA tiene que reinventar la rueda una y otra vez. La solución es preparar los datos a medida que entran en el sistema para que los agentes puedan responder de manera directa a la pregunta en lugar de averiguar qué ven ustedes. Piénsenlo como la diferencia entre entregarle a alguien un montón enorme de papeles y un informe bien organizado. Misma información, punto de partida muy diferente.

Qué significa esto para su organización

Si los agentes gestionan más la ejecución y las barreras para crear software son más bajas que nunca, surge una pregunta razonable: ¿por qué no construir el suyo propio? Porque, aunque construir su propio CRM ahora pueda ser posible gracias a la IA, cada hora dedicada a construir y mantener software que una solución lista ya podría manejar, es una hora que no se dedica al trabajo que define su ventaja competitiva. La era de la IA va a obligar a hacer un ajuste de cuentas sobre dónde las organizaciones destinan su tiempo y recursos. Las empresas que avancen no serán las que más hagan; serán las que sean más disciplinadas en lo que solo ellas pueden hacer. Las Frontier Firms (Empresas Frontera) que vemos, no externalizan más, sino que se concentran más.

Esto también se aplica a las herramientas que su organización ya posee o a las que está suscrita la organización. La mayoría de las organizaciones pagan por software con funciones avanzadas que pocos o ningún empleado utiliza. Los agentes encontrarán y usarán esas funciones. Y de manera eventual, incluso podrían empezar a solicitar capacidades que ningún usuario humano habría imaginado. El software se desarrollará más rápido que cualquier individuo que pueda seguir, y eso hace que la capa humana sea más relevante, no menos.

A medida que el trabajo humano se traslada aguas arriba—menos tiempo práctico en el software, más tiempo para decidir qué debe producir—las organizaciones que avancen serán las que desarrollen de manera deliberada la capacidad de sus empleados para marcar dirección, evaluar resultados y mantener la responsabilidad de cómo funciona el sistema. Eso es una inversión de talento y cultura, no tecnológica. Y el momento de empezar a invertir es ahora.

Para más información sobre la IA y el futuro del trabajo, suscríbanse a este boletín.

Etiquetas:

• IA
• Vida y Trabajo

The post IA en el trabajo: Cuando los mayores usuarios del software no son humanos appeared first on Source LATAM.

​The post IA en el trabajo: Cuando los mayores usuarios del software no son humanos appeared first on Source LATAM.  

Amazon SageMaker Unified Studio now supports data quality rule authoring and evaluation, powered by AWS Glue Data Quality. Data engineers, analysts, and data scientists can define data quality rules, run ruleset evaluations, and view results directly within SageMaker Unified Studio for both data at rest in catalog tables and data in transit within Visual ETL jobs. This helps you catch data quality issues before bad data enters your data lakes or affects downstream analytics and machine learning workloads.

With this launch, you can author rules using the same Data Quality Definition Language (DQDL) used in AWS Glue Data Quality and run evaluations directly in SageMaker Unified Studio across two workflows. For data at rest, a dedicated Data Quality tab on catalog assets provides rule authoring, on-demand or scheduled evaluations, and detailed per-rule pass/fail results. For data in transit, you can add an Evaluate Data Quality transform to any Visual ETL job, and review data quality results as part of the run details. You can create rulesets that check for completeness, uniqueness, freshness, accuracy, and other data quality dimensions.

This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available, in both AWS IAM Identity Center-based and IAM-based domains. To learn more, visit the Amazon SageMaker Unified Studio documentation.

​Amazon SageMaker Unified Studio now supports data quality rule authoring and evaluation, powered by AWS Glue Data Quality. Data engineers, analysts, and data scientists can define data quality rules, run ruleset evaluations, and view results directly within SageMaker Unified Studio for both data at rest in catalog tables and data in transit within Visual ETL jobs. This helps you catch data quality issues before bad data enters your data lakes or affects downstream analytics and machine learning workloads. With this launch, you can author rules using the same Data Quality Definition Language (DQDL) used in AWS Glue Data Quality and run evaluations directly in SageMaker Unified Studio across two workflows. For data at rest, a dedicated Data Quality tab on catalog assets provides rule authoring, on-demand or scheduled evaluations, and detailed per-rule pass/fail results. For data in transit, you can add an Evaluate Data Quality transform to any Visual ETL job, and review data quality results as part of the run details. You can create rulesets that check for completeness, uniqueness, freshness, accuracy, and other data quality dimensions. This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available, in both AWS IAM Identity Center-based and IAM-based domains. To learn more, visit the Amazon SageMaker Unified Studio documentation.  

Today, AWS Security Hub brings identity risk into the same unified console where central security teams already manage threats, exposures, and posture findings. Security Hub now detects unused IAM permissions, roles, and credentials across your AWS organization, helping central security teams identify and reduce identity risk at scale. Until now, managing identity risk across hundreds of accounts required toggling between multiple tools, with no unified view connecting unused permissions to actual resource exposure. Security Hub now surfaces these identity risks alongside threats, exposures, and posture findings in a unified console, enabling teams to prioritize remediation based on actual organizational risk.

When you enable Security Hub for your organization, a service-linked IAM Access Analyzer is automatically created in each member account with no additional configuration required. Security Hub evaluates IAM principals against 90 days of actual access activity, detects unused access, and correlates identity findings with exposure context so teams can focus on the risks that matter most. Security Hub also provides on-demand generation of recommended least-privilege policies based on actual usage patterns, helping teams refine IAM permissions and reduce their attack surface. These capabilities represent a foundational step toward broader cloud infrastructure entitlement management in Security Hub, delivered with consistent workflows, automation rules, and downstream integrations. These capabilities are included with Security Hub Essentials at no additional cost.

To learn more, see Understanding unused access findings in Security Hub in the AWS Security Hub User Guide and the AWS Security Hub product page. For the full list of AWS Regions where Security Hub is available, see the AWS Regional Services List.

​Today, AWS Security Hub brings identity risk into the same unified console where central security teams already manage threats, exposures, and posture findings. Security Hub now detects unused IAM permissions, roles, and credentials across your AWS organization, helping central security teams identify and reduce identity risk at scale. Until now, managing identity risk across hundreds of accounts required toggling between multiple tools, with no unified view connecting unused permissions to actual resource exposure. Security Hub now surfaces these identity risks alongside threats, exposures, and posture findings in a unified console, enabling teams to prioritize remediation based on actual organizational risk. When you enable Security Hub for your organization, a service-linked IAM Access Analyzer is automatically created in each member account with no additional configuration required. Security Hub evaluates IAM principals against 90 days of actual access activity, detects unused access, and correlates identity findings with exposure context so teams can focus on the risks that matter most. Security Hub also provides on-demand generation of recommended least-privilege policies based on actual usage patterns, helping teams refine IAM permissions and reduce their attack surface. These capabilities represent a foundational step toward broader cloud infrastructure entitlement management in Security Hub, delivered with consistent workflows, automation rules, and downstream integrations. These capabilities are included with Security Hub Essentials at no additional cost. To learn more, see Understanding unused access findings in Security Hub in the AWS Security Hub User Guide and the AWS Security Hub product page. For the full list of AWS Regions where Security Hub is available, see the AWS Regional Services List.  

Amazon Elastic Container Service (ECS) now supports mounting Amazon Elastic Block Store (EBS) volumes to containers in the AWS GovCloud Regions. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media transcoding, and ML inference workloads using serverless containers.
With EBS task attachment, customers can allow ECS to provision, manage and de-provision EBS Volumes with each new ECS Task launch. EBS task attachment will automatically wire these volumes to their containerized workloads. Customers can have ECS format an empty volume on their behalf or bring an EBS snapshot for ECS to use to create new volumes.
EBS task attachment is now available in the AWS GovCloud Regions for EC2, Fargate, and Managed Instances launch types. To learn more, see Use Amazon EBS volumes with Amazon ECS in the Amazon ECS Developer Guide.

​Amazon Elastic Container Service (ECS) now supports mounting Amazon Elastic Block Store (EBS) volumes to containers in the AWS GovCloud Regions. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media transcoding, and ML inference workloads using serverless containers. With EBS task attachment, customers can allow ECS to provision, manage and de-provision EBS Volumes with each new ECS Task launch. EBS task attachment will automatically wire these volumes to their containerized workloads. Customers can have ECS format an empty volume on their behalf or bring an EBS snapshot for ECS to use to create new volumes. EBS task attachment is now available in the AWS GovCloud Regions for EC2, Fargate, and Managed Instances launch types. To learn more, see Use Amazon EBS volumes with Amazon ECS in the Amazon ECS Developer Guide.  

AWS Security Hub Extended plan now includes 21 curated partner solutions across 9 security categories, adding SentinelOne (endpoint), CyberArk (identity), Sublime (email), Varonis (data security), LayerX (browser), Native Security (cloud), and Zenity (AI security). With these additions, you have more flexibility to select the solutions that best fit your enterprise security requirements. All solutions have published pay-as-you-go pricing, a single AWS bill, automatic Enterprise Discount Program (EDP) eligibility, unified Level 1 support for AWS Enterprise Support customers, and no long-term commitments.

Security Hub Extended is a plan of Security Hub that helps simplify how you procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. With today’s expansion, you now have more choice within each category, selecting between established leaders and fast-growing innovators across your security domains. Security findings from all participating solutions are emitted in the Open Cybersecurity Schema Framework (OCSF) schema and automatically aggregated in AWS Security Hub. With the Extended plan, you can combine AWS and curated partner solutions to quickly identify and respond to risks that span boundaries.

We will continue to expand the Extended plan based on customer feedback. The seven new curated partner solutions are available today in all AWS commercial Regions where Security Hub is available. For a list of supported Regions, see the AWS Region table. For more information about pricing, visit the AWS Security Hub pricing page. To get started, visit the AWS Security Hub console or product page.

​AWS Security Hub Extended plan now includes 21 curated partner solutions across 9 security categories, adding SentinelOne (endpoint), CyberArk (identity), Sublime (email), Varonis (data security), LayerX (browser), Native Security (cloud), and Zenity (AI security). With these additions, you have more flexibility to select the solutions that best fit your enterprise security requirements. All solutions have published pay-as-you-go pricing, a single AWS bill, automatic Enterprise Discount Program (EDP) eligibility, unified Level 1 support for AWS Enterprise Support customers, and no long-term commitments.
Security Hub Extended is a plan of Security Hub that helps simplify how you procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. With today’s expansion, you now have more choice within each category, selecting between established leaders and fast-growing innovators across your security domains. Security findings from all participating solutions are emitted in the Open Cybersecurity Schema Framework (OCSF) schema and automatically aggregated in AWS Security Hub. With the Extended plan, you can combine AWS and curated partner solutions to quickly identify and respond to risks that span boundaries.
 
We will continue to expand the Extended plan based on customer feedback. The seven new curated partner solutions are available today in all AWS commercial Regions where Security Hub is available. For a list of supported Regions, see the AWS Region table. For more information about pricing, visit the AWS Security Hub pricing page. To get started, visit the AWS Security Hub console or product page.  

Today, Amazon Web Services (AWS) announced version 0.1 of ExtendDB, an open source project that implements the Amazon DynamoDB API with pluggable storage backends. Amazon DynamoDB is a serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. ExtendDB enables application developers, platform teams, and enterprise architects to use the DynamoDB programming model in environments where the DynamoDB managed service is not available, including developer laptops, on-premises data centers, and disconnected edge sites, without rewriting application code.

ExtendDB implements the DynamoDB control plane and data plane APIs, including operations on tables, items, and streams. The reference storage backend at launch is PostgreSQL, and the pluggable architecture allows the community to add new storage backends without modifying the core adapter. Developers can use ExtendDB for high-fidelity local development and continuous integration testing, and operate DynamoDB-shaped workloads in on-premises data centers backed by a supported database.

ExtendDB is maintained by AWS, released under the Apache 2.0 license, and developed in the open on GitHub. We invite the community to contribute backend implementations, submit feedback, and participate in the project’s evolution. To learn more, see the ExtendDB project page and the AWS database blog post. To get started or contribute, visit the GitHub repository.

​Today, Amazon Web Services (AWS) announced version 0.1 of ExtendDB, an open source project that implements the Amazon DynamoDB API with pluggable storage backends. Amazon DynamoDB is a serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. ExtendDB enables application developers, platform teams, and enterprise architects to use the DynamoDB programming model in environments where the DynamoDB managed service is not available, including developer laptops, on-premises data centers, and disconnected edge sites, without rewriting application code. ExtendDB implements the DynamoDB control plane and data plane APIs, including operations on tables, items, and streams. The reference storage backend at launch is PostgreSQL, and the pluggable architecture allows the community to add new storage backends without modifying the core adapter. Developers can use ExtendDB for high-fidelity local development and continuous integration testing, and operate DynamoDB-shaped workloads in on-premises data centers backed by a supported database. ExtendDB is maintained by AWS, released under the Apache 2.0 license, and developed in the open on GitHub. We invite the community to contribute backend implementations, submit feedback, and participate in the project’s evolution. To learn more, see the ExtendDB project page and the AWS database blog post. To get started or contribute, visit the GitHub repository.  

​AWS Billing Conductor Console now enables you to see which accounts have received or accepted billing transfer invites but still lack access to pro forma billing data.
 
This page helps customers detect and close gaps in their account’s billing visibility. When an account accepts a billing transfer invitation, billing data is transferred to the inviting account. By configuring a billing group via AWS Billing Conductor, accounts can access pro forma cost data across Billing and Cost Management tools. This page provides visibility into what accounts currently lack access to pro forma billing data, making it easier to complete this configuration step. Customers can also sign up for daily notifications via AWS User Notifications and Amazon EventBridge to receive a summary of accepted billing transfers that lack a corresponding billing group. Notifications are available via email, Amazon Q Developer in chat applications (Slack, Microsoft Teams, and Amazon Chime), AWS Console Mobile Application push notifications, and the Console Notifications Center. 

These features are available in the US East (N. Virginia) region. To get started, visit the AWS Billing Conductor console. To learn more about setting up EventBridge integration, see the EventBridge documentation. For instructions on configuring User Notifications, see the User Notifications documentation. To learn more about Billing Transfer and AWS Billing Conductor visit the Billing Transfer product page, AWS Billing documentation and the AWS Cost Management documentation.