Amazon CloudWatch Application Signals now supports Custom Metrics, empowering developers and operators to pinpoint the root cause of application issues faster and with greater precision. CloudWatch Application Signals already helps you monitor the health of your applications through standard metrics like fault rates, errors, and latency. Now, you can add your own custom metrics that provide deeper context about your application’s behavior and correlate them with standard metrics in a unified view.
With Custom Metrics in Application Signals, you can define and visualize application-specific metrics that provide critical context for your services, correlate custom metrics with standard metrics in the new ‘Related Metrics’ tab, identify patterns and dependencies between metrics to narrow down issue root causes, and analyze specific data points through interactive visualization and correlation analysis. You have the flexibility of using either OpenTelemetry Metrics, where you create and export metrics directly from your application code using the OpenTelemetry Metrics SDK or Span Metrics, where you can add custom span attributes using the OpenTelemetry Traces SDK and create metrics from them using Metrics Filters. In the Application Signals console you can select and graph multiple metrics together to visualize correlations, filter metrics by name, type, and other attributes, select data points to view correlated spans, top contributors, and related logs and navigate directly from Service Operations or Dependencies to Related Metrics through correlation analysis.
Custom Metrics support is available in all regions Application Signals is available in. For more information about custom metrics, refer to the documentation. For pricing details, see Amazon CloudWatch pricing.
Amazon CloudWatch Application Signals now supports Custom Metrics, empowering developers and operators to pinpoint the root cause of application issues faster and with greater precision. CloudWatch Application Signals already helps you monitor the health of your applications through standard metrics like fault rates, errors, and latency. Now, you can add your own custom metrics that provide deeper context about your application’s behavior and correlate them with standard metrics in a unified view. With Custom Metrics in Application Signals, you can define and visualize application-specific metrics that provide critical context for your services, correlate custom metrics with standard metrics in the new ‘Related Metrics’ tab, identify patterns and dependencies between metrics to narrow down issue root causes, and analyze specific data points through interactive visualization and correlation analysis. You have the flexibility of using either OpenTelemetry Metrics, where you create and export metrics directly from your application code using the OpenTelemetry Metrics SDK or Span Metrics, where you can add custom span attributes using the OpenTelemetry Traces SDK and create metrics from them using Metrics Filters. In the Application Signals console you can select and graph multiple metrics together to visualize correlations, filter metrics by name, type, and other attributes, select data points to view correlated spans, top contributors, and related logs and navigate directly from Service Operations or Dependencies to Related Metrics through correlation analysis.
Custom Metrics support is available in all regions Application Signals is available in. For more information about custom metrics, refer to the documentation. For pricing details, see Amazon CloudWatch pricing.
AWS App Runner now supports IPv6-based inbound and outbound traffic on both public and private App Runner service endpoints. This helps customers meet IPv6 compliance requirements, and removes the need for handling address translation between IPv4 and IPv6.
App Runner is a fully-managed service that makes it easier for developers to quickly deploy containerized web applications and APIs to the cloud, at scale, and without managing infrastructure. Previously, IPv6 was only supported on incoming traffic through public endpoints. You can configure IPv6 by selecting the dual-stack option in your networking configuration on new or existing services.
AWS App Runner now supports IPv6-based inbound and outbound traffic on both public and private App Runner service endpoints. This helps customers meet IPv6 compliance requirements, and removes the need for handling address translation between IPv4 and IPv6. App Runner is a fully-managed service that makes it easier for developers to quickly deploy containerized web applications and APIs to the cloud, at scale, and without managing infrastructure. Previously, IPv6 was only supported on incoming traffic through public endpoints. You can configure IPv6 by selecting the dual-stack option in your networking configuration on new or existing services. AWS App Runner support for IPv6 is available in all AWS Regions where AWS App Runner is available. For more information about how to manage dual-stack support for your App Runner service, see Networking with App Runner in the AWS App Runner Developer Guide.
Una misión para traer el futuro de la energía limpia
Juntos, abordamos uno de los mayores desafíos en el despliegue de tecnología nuclear, que es navegar por procesos de permisos complejos, lentos y costosos.
– Mark Tipping, director global de energía offshore a X, Lloyd’s Register
Acerca de la IA generativa para permisos
Los permisos son el mayor cuello de botella para implementar energía limpia con la suficiente rapidez como para evitar un cambio climático descontrolado. En algunos casos, se necesita más de una década y cientos de millones de dólares para obtener una licencia para una sola planta nuclear, antes de que genere un solo vatio de energía. Eso no solo es ineficiente, es existencial.
Entonces, un equipo de proyecto de 53 piratas informáticos de todo Microsoft se propuso cambiar eso. ¿Su misión? Utilizar la IA generativa para romper el atasco de los permisos y acelerar la transición energética global. Lo que comenzó como un proyecto de Hackathon 2024 llamado Project GreenLight es ahora un flujo de trabajo comercial con clientes reales, ingresos reales e impacto en el mundo real.
Dar el paso
Antes del hackathon, antes del código, antes de la IA, hubo natación.
El 21 de junio de 2022, el Consorcio Repowering Coal se reunió en las oficinas de Microsoft en Dublín. Eran los primeros días. No hay agenda formal. Solo una sala repleta de 50 personas de toda la industria nuclear avanzada, reunidas por Terra Praxis y Microsoft. La pregunta sobre la mesa: ¿Cómo pasamos de un reactor nuclear que se construye por década en el mundo occidental a los 2.500 necesarios para reemplazar el carbón a nivel mundial?
Las conversaciones fueron crudas, abiertas y urgentes. Surgieron cuellos de botella. Fabricación. Despliegue. Pero uno se destacó: permitir.
Y luego vino la natación.
Esa noche, el grupo caminó hasta los acantilados de Vico, al sur de Dublín. Saltaron juntos al mar: ejecutivos, ingenieros, innovadores. Sin trajes. Sin silos. Solo propósito compartido.
«Solo desbloqueó a todos. Se convirtió en un grupo de empresas no competitivas, que colaboraban en un espíritu de amistad».
Ese momento de vulnerabilidad y conexión marcó la pauta para todo lo que siguió. No se trataba solo de resolver un problema técnico. Se trataba de desbloquear un movimiento.
El punto débil de los permisos
La idea nació de años de trabajo con la industria nuclear a través del Consorcio de Repotenciación del Carbón. El equipo no dejaba de escuchar lo mismo: «Los permisos acaban con nosotros. Es el mayor cuello de botella que se interpone entre nosotros y la descarbonización de la energía del carbón a nivel mundial». Esa idea se convirtió en la chispa.
Centrado en un inicio en los permisos nucleares, el proyecto se expandió con rapidez para cubrir las energías renovables, la minería y otros sectores de energía limpia. La ambición del equipo creció con cada iteración, al igual que su impacto.
Este es un equipo que sabe lo que se necesita.
La tercera vez es aún más encantadora
Hackathon 2024 fue el tercer Hackathon del equipo. Vinieron preparados. Con meses de anticipación, trazaron roles, reclutaron talento y construyeron un plan para comenzar a trabajar el lunes por la mañana.
Abordaron tres desafíos principales:
Creación automatizada de documentos: Uso de IA generativa para redactar documentos de permisos a partir de datos históricos y específicos del proyecto.
Copiloto para ingenieros de permisos: Un copiloto con todo el conjunto de datos regulatorios de la empresa que admite consultas ad-hoc por parte del equipo de permisos. De manera fundamental, esto se ejecuta por completo en el propio inquilino de Azure de la empresa, lo que evita que los datos se filtren a través de las consultas de los empleados a sistemas externos de IA generativa que se ejecutan a través de Internet.
Revisión previa a la presentación para reguladores: IA que marca la información faltante antes de la presentación formal, lo que reduce las costosas demoras.
El equipo no solo construyó prototipos, sino que los envió. «Hemos logrado cuatro victorias en el diseño de IA e impulsamos a bastantes empresas en la industria energética y más allá. Esto no es algo abstracto», compartió Kelly.
El efecto hackathon
Este no fue solo un proyecto paralelo, fue un campo de pruebas. El Hackathon de The Garage le dio al equipo el espacio, el apoyo y la energía para convertir una idea audaz en una realidad comercial.
«Es increíble ver que lo que comenzó como un proyecto paralelo llevó a Microsoft a la energía nuclear», dijo entusiasmado Ed Essey, director senior de Business Value y entrenador del equipo. «Ahora, da forma a la faz del planeta y cómo crea energía de una manera que protege nuestro planeta para las generaciones venideras».
El entorno del Hackathon permitió al equipo moverse rápido, experimentar con libertad e iterar sin las limitaciones del desarrollo de productos tradicionales. El coaching agudizó su mensaje. Community amplificó su alcance. Y el espíritu hacker los mantuvo enfocados en el impacto.
Lo que comenzó como un prototipo se convirtió en un modelo de cómo Microsoft puede liderar la transición a la energía limpia, no solo a través de la tecnología, sino también a través de la innovación impulsada por un propósito. The Garage no solo apoyó el proyecto. Le dio forma.
No todo fue fácil
Antes de que la IA generativa se convirtiera en la corriente principal, incluso antes de que se lanzara la asociación Azure OpenAI, el equipo intentó abordar los permisos con enfoques de software tradicionales. No funcionó.
«Comenzamos a intentarlo sin IA generativa… solo programación de software normal. Era un problema intratable».
El avance se produjo cuando el equipo se dio cuenta de que la IA generativa podía hacer lo que los sistemas deterministas no podían: extraer de manera dinámica conjuntos de datos masivos y variados y generar contenido en los formatos flexibles requeridos por diferentes documentos de licencia. Ese cambio desbloqueó una aplicabilidad mucho más amplia, no solo para los permisos nucleares, sino también en sectores de energía limpia como la eólica y la minería.
Luego vino el segundo avance. Por casualidad, el equipo se conectó con un miembro del equipo de Semantic Kernel, que se unió al esfuerzo del Hackathon. Juntos, construyeron un sistema que podía identificar de manera inteligente qué fuentes de datos usar para cada sección de un documento de permisos y estructurar el resultado en consecuencia. Lo que solía llevar meses o años, crear el primer borrador, ahora tomaba cinco minutos.
Y no se detuvo ahí. Al integrar Azure OpenAI y Kernel Memory, el equipo agregó una característica que podría revisar las solicitudes de permisos con respecto a las regulaciones relevantes antes de su presentación, lo que evitó meses o años de idas y venidas con los reguladores. La reciente incorporación de flujos de trabajo de IA agéntica aceleró esta capacidad, lo que permitió que varios agentes redactaran, revisaran y refinaran documentos en tiempo real.
«Este proyecto se trataba de lograr una aplicabilidad mucho más amplia, no solo este documento específico de permisos nucleares, sino en todo el campo de los permisos nucleares y en los permisos de energía eólica y otras energías renovables».
¿El resultado? Un sistema escalable e inteligente que ya ha comenzado a aumentar la productividad en toda la industria energética, y todo comenzó con el Hackathon.
Grupo de descarbonización del evento de la Industria Nuclear Avanzada de Dublín y Repotenciación del Carbón, junio de 2023
Construido para importar
Lo que comenzó como una idea de Hackathon ahora da forma a la política, para acelerar el despliegue e influir en la estrategia energética global.
Los números hablan por sí solos: 25-75% de aumento de la productividad en los flujos de trabajo de permisos.
Esto catalizó un grupo de trabajo de Microsoft sobre IA para permisos, con el apoyo de Melanie Nakagawa, directora de sostenibilidad; Darryl Willis, vicepresidente ejecutivo de la industria de energía y recursos; y Brad Smith, presidente y vicepresidente. El flujo de trabajo colabora con entidades gubernamentales y reguladoras de todo el mundo, además de las industrias energética y minera.
Próxima parada: estar en todas partes
El proyecto es ahora un flujo de trabajo comercial completo bajo MCAPS Energy & Resources. Se ha comenzado a expandir a nuevos «escenarios héroes» como la minería y la energía eólica marina, con una arquitectura modular que permite a los clientes agregar nuevos conjuntos de datos y casos de uso.
El equipo ha creado una capa central de permisos de IA generativa y también ha creado escenarios de héroes para diferentes industrias.
El equipo también trabaja con los reguladores para mejorar su productividad, lo que asegura que los permisos más rápidos en el lado de la industria no abrumen al sector público.
Y recién han comenzado.
La innovación del equipo amplía el legado de Repowering Coal, miembro del Muro de la Fama del Garaje.
Today, Amazon Braket introduced a local device emulator that enables developers to test verbatim circuits with device-specific characteristics before running on quantum hardware. This feature accelerates development by providing early feedback on circuit compatibility and expected behavior under realistic noise conditions, helping customers validate their quantum programs and develop noise-aware algorithms without incurring hardware costs.
The local device emulator offers several key capabilities:
Validates circuit compatibility with target quantum devices, including qubit connectivity, native gate sets, and device topology constraints
Simulates quantum circuits with depolarizing channels applied to one-qubit and two-qubit gates based on device calibration data
Provides realistic predictions of program behavior on noisy hardware using local density matrix simulation
Supports both real-time and historical calibration data for device emulation
Braket users can instantiate device emulators directly from AWS quantum devices or from custom device properties using the Amazon Braket SDK. The emulator seamlessly integrates with existing workflows, allowing developers to catch compatibility issues early and efficiently iterate on their quantum algorithms before running them on actual quantum hardware.
Today, Amazon Braket introduced a local device emulator that enables developers to test verbatim circuits with device-specific characteristics before running on quantum hardware. This feature accelerates development by providing early feedback on circuit compatibility and expected behavior under realistic noise conditions, helping customers validate their quantum programs and develop noise-aware algorithms without incurring hardware costs. The local device emulator offers several key capabilities:
Validates circuit compatibility with target quantum devices, including qubit connectivity, native gate sets, and device topology constraints
Simulates quantum circuits with depolarizing channels applied to one-qubit and two-qubit gates based on device calibration data
Provides realistic predictions of program behavior on noisy hardware using local density matrix simulation
Supports both real-time and historical calibration data for device emulation
Braket users can instantiate device emulators directly from AWS quantum devices or from custom device properties using the Amazon Braket SDK. The emulator seamlessly integrates with existing workflows, allowing developers to catch compatibility issues early and efficiently iterate on their quantum algorithms before running them on actual quantum hardware. For more information, visit the Amazon Braket developer guide, read the launch blog post, and explore our example notebook demonstrating the local device emulator.
Starting today, Amazon GameLift Streams offers enhanced flexibility for managing default applications in stream groups. You can now create new stream groups without specifying a default application and modify or remove the default application in the existing stream group.
The key improvements include:
Ability to create a stream group without a default application
Ability to select and modify the default application in an existing stream group
Ability to unlink a default application without having to delete the entire stream group
Automatic selection of a new default application when no default exists, before streaming an application, ensuring the stream group always has a default when available
Each stream group can have one application set as default, which is pre-cached to help reduce the stream startup time. You can now switch the default status between any linked applications to optimize the performance without recreating stream groups.
To take advantage of these improvements, you can use the updated Amazon GameLift Streams APIs or the service console to manage your default application configurations. The UpdateStreamGroup API includes a new optional field for the default application identifier. The AssociateApplications and DisassociateApplications APIs have also been updated to handle default application changes. For more information about default applications, see Multi-application stream groups in the Developer Guide.
These enhancements provide a better experience as you build and scale your cloud gaming infrastructure.
Starting today, Amazon GameLift Streams offers enhanced flexibility for managing default applications in stream groups. You can now create new stream groups without specifying a default application and modify or remove the default application in the existing stream group.
The key improvements include:
Ability to create a stream group without a default application
Ability to select and modify the default application in an existing stream group
Ability to unlink a default application without having to delete the entire stream group
Automatic selection of a new default application when no default exists, before streaming an application, ensuring the stream group always has a default when available
Each stream group can have one application set as default, which is pre-cached to help reduce the stream startup time. You can now switch the default status between any linked applications to optimize the performance without recreating stream groups.
To take advantage of these improvements, you can use the updated Amazon GameLift Streams APIs or the service console to manage your default application configurations. The UpdateStreamGroup API includes a new optional field for the default application identifier. The AssociateApplications and DisassociateApplications APIs have also been updated to handle default application changes. For more information about default applications, see Multi-application stream groups in the Developer Guide.
These enhancements provide a better experience as you build and scale your cloud gaming infrastructure.
You can now downgrade to minor Apache Airflow versions on Amazon Managed Workflows for Apache Airflow (MWAA).
Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier to set up and operate end-to-end data pipelines in the cloud. This in-place minor Apache Airflow version option allows you to downgrade your MWAA Apache Airflow version to any other supported minor version.
Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundationin the United States and/or other countries.
You can now downgrade to minor Apache Airflow versions on Amazon Managed Workflows for Apache Airflow (MWAA). Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier to set up and operate end-to-end data pipelines in the cloud. This in-place minor Apache Airflow version option allows you to downgrade your MWAA Apache Airflow version to any other supported minor version. You can launch a new Apache Airflow environment on Amazon MWAA with just a few clicks in the AWS Management Console in all currently supported Amazon MWAA regions. To learn more about Apache Airflow minor version downgrade visit the Amazon MWAA documentation. Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundationin the United States and/or other countries.
Amazon RDS now supports Redo Transport Compression, a feature that compresses redo data before it is transmitted to a standby database. By reducing the amount of data sent over the network, it improves redo transport performance. Because of faster redo log transport, customers can achieve a lower Recovery Point Objective (RPO), which is the amount of data loss that may occur when promoting a replica in situations where the primary instance becomes unavailable.
Compression and decompression of redo data consumes CPU resources on both the primary and standby databases. Customers should ensure that sufficient CPU capacity is available to handle this increased workload, and use Redo Transport Compression in situations where reduced network traffic and improved RPO outweigh the CPU overhead of compression. To enable the feature, set redo_compression parameter in the Parameter Group for your database instance. Redo Log Compression is available for both mounted and read replicas, and requires Oracle Enterprise Edition with Oracle Advanced Compression Licensing.
Redo Transport Compression is available in all AWS Regions where Amazon RDS for Oracle is available. To learn more about using Redo Transport Compression, visit the Amazon RDS User Guide.
Amazon RDS now supports Redo Transport Compression, a feature that compresses redo data before it is transmitted to a standby database. By reducing the amount of data sent over the network, it improves redo transport performance. Because of faster redo log transport, customers can achieve a lower Recovery Point Objective (RPO), which is the amount of data loss that may occur when promoting a replica in situations where the primary instance becomes unavailable. Compression and decompression of redo data consumes CPU resources on both the primary and standby databases. Customers should ensure that sufficient CPU capacity is available to handle this increased workload, and use Redo Transport Compression in situations where reduced network traffic and improved RPO outweigh the CPU overhead of compression. To enable the feature, set redo_compression parameter in the Parameter Group for your database instance. Redo Log Compression is available for both mounted and read replicas, and requires Oracle Enterprise Edition with Oracle Advanced Compression Licensing. Redo Transport Compression is available in all AWS Regions where Amazon RDS for Oracle is available. To learn more about using Redo Transport Compression, visit the Amazon RDS User Guide.
Today, AWS Client VPN announces support for remote access to IPv6 workloads, allowing customers to establish secure VPN connections to their IPv6-enabled VPC resources. This new capability enables customers to meet their compliance and IPv6 network adoption goals. Now organizations can support IPv4, IPv6, and dual-stack resource connectivity through their Client VPN endpoints.
Previously, Client VPN only supported remote access to IPv4-enabled AWS workloads. With this feature, administrators can now support IPv6-enabled resources using IPv6-only or dual-stack Client VPN endpoints. Organizations can now directly connect their remote users to IPv6 resources and maintain end-to-end IPv6-only connectivity. For example, organizations can now use IPv6-enabled devices to remotely access IPv6-enabled resources in VPC via Client VPN, preserving end-to-end IPv6 connectivity. This feature simplifies network architecture for organizations using IPv6 while preserving native protocol preferences.
This feature is available in all regions where AWS Client VPN is generally available, except the Middle East (Bahrain) Region, and comes with no additional cost. Customers can use IPv6 and dual-stack endpoints at the current endpoint per-hour price.
Today, AWS Client VPN announces support for remote access to IPv6 workloads, allowing customers to establish secure VPN connections to their IPv6-enabled VPC resources. This new capability enables customers to meet their compliance and IPv6 network adoption goals. Now organizations can support IPv4, IPv6, and dual-stack resource connectivity through their Client VPN endpoints. Previously, Client VPN only supported remote access to IPv4-enabled AWS workloads. With this feature, administrators can now support IPv6-enabled resources using IPv6-only or dual-stack Client VPN endpoints. Organizations can now directly connect their remote users to IPv6 resources and maintain end-to-end IPv6-only connectivity. For example, organizations can now use IPv6-enabled devices to remotely access IPv6-enabled resources in VPC via Client VPN, preserving end-to-end IPv6 connectivity. This feature simplifies network architecture for organizations using IPv6 while preserving native protocol preferences. This feature is available in all regions where AWS Client VPN is generally available, except the Middle East (Bahrain) Region, and comes with no additional cost. Customers can use IPv6 and dual-stack endpoints at the current endpoint per-hour price. To learn more about Client VPN:
Visit the AWS Client VPN product page
Read the AWS Client VPN documentation
Read the AWS Client VPN user guide
Amazon Relational Database Service (Amazon RDS) for Oracle now supports ECC384 Certificate Authority with two new ECDSA cipher suites for Oracle Secure Socket Layer (SSL) and Oracle Enterprise Manager (OEM) Agent options in Oracle Database versions 19c and 21c. The ECC384 Certificate Authority and ECDSA cipher suites provide comparable security to the RSA certificate authorities while using shorter keys, and deliver faster encryption with lower CPU usage.
The new ECDSA cipher suites supported with this option are TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384. To use these cipher suites, select ECC384 (rds-ca-ecc384-g1) as the Certificate Authority for your Amazon RDS for Oracle database instances.
Amazon Relational Database Service (Amazon RDS) for Oracle now supports ECC384 Certificate Authority with two new ECDSA cipher suites for Oracle Secure Socket Layer (SSL) and Oracle Enterprise Manager (OEM) Agent options in Oracle Database versions 19c and 21c. The ECC384 Certificate Authority and ECDSA cipher suites provide comparable security to the RSA certificate authorities while using shorter keys, and deliver faster encryption with lower CPU usage. The new ECDSA cipher suites supported with this option are TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384. To use these cipher suites, select ECC384 (rds-ca-ecc384-g1) as the Certificate Authority for your Amazon RDS for Oracle database instances. To learn more about adding SSL with ECDSA cipher suites, see Adding SSL option documentation. To learn more about modifying the OEM Agent to select ECDSA cipher suites, see Modifying OEM Agent Database settings documentation. To learn more about modifying a database instance to select rds-ca-ecc384-g1 Certificate Authority, see Modifying an Amazon RDS DB instance documentation.
Amazon Aurora DSQL now supports application resiliency testing with AWS Fault Injection Service (FIS), a fully managed service for running controlled fault injection experiments to improve application performance, observability, and resilience. With this launch, customers can simulate real-world scenarios that disrupt connections to Aurora DSQL clusters, such as during regional failures, enabling them to observe how their applications respond to these disruptions and validate their resilience mechanisms.
Aurora DSQL is the fastest serverless, distributed SQL database with active-active high availability and multi-Region strong consistency. The new FIS action creates scenarios where applications need to handle connection disruptions or complete inaccessibility to an Aurora DSQL cluster in an AWS Region, enabling customers to test application resilience and recovery capabilities. This lets customers test and build confidence that their applications respond as intended when experiencing connection issues, whether they operate within a single Region or across multiple Regions. Customers can create experiment templates in FIS to integrate experiments with continuous integration and release testing. Customers can also generate detailed reports of their FIS experiments and store them in Amazon S3, enabling them to audit and demonstrate compliance with both organizational and regulatory resilience testing requirements.
Aurora DSQL support for FIS is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Europe (Ireland), Europe (London), and Europe (Paris). To get started, visit the Aurora DSQL FIS actions documentation.
Amazon Aurora DSQL now supports application resiliency testing with AWS Fault Injection Service (FIS), a fully managed service for running controlled fault injection experiments to improve application performance, observability, and resilience. With this launch, customers can simulate real-world scenarios that disrupt connections to Aurora DSQL clusters, such as during regional failures, enabling them to observe how their applications respond to these disruptions and validate their resilience mechanisms. Aurora DSQL is the fastest serverless, distributed SQL database with active-active high availability and multi-Region strong consistency. The new FIS action creates scenarios where applications need to handle connection disruptions or complete inaccessibility to an Aurora DSQL cluster in an AWS Region, enabling customers to test application resilience and recovery capabilities. This lets customers test and build confidence that their applications respond as intended when experiencing connection issues, whether they operate within a single Region or across multiple Regions. Customers can create experiment templates in FIS to integrate experiments with continuous integration and release testing. Customers can also generate detailed reports of their FIS experiments and store them in Amazon S3, enabling them to audit and demonstrate compliance with both organizational and regulatory resilience testing requirements. Aurora DSQL support for FIS is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Europe (Ireland), Europe (London), and Europe (Paris). To get started, visit the Aurora DSQL FIS actions documentation.
