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.
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.
Presentamos RAMPART y Clarity: Herramientas de código abierto para incorporar seguridad al flujo de trabajo de desarrollo de Agentes
Por: Ram Shankar Siva Kumar, Data Cowboy, AI Red Team.
Los sistemas de IA que se implementan hoy en las empresas son, de manera fundamental, diferentes de los que construíamos hace incluso dos años, porque han ido mucho más allá de responder preguntas y ahora acceden a su correo electrónico, recuperan registros de su CRM, llevan a cabo escritura y ejecución de código, y realizan acciones en su nombre a través de decenas de sistemas conectados. Ese cambio de «generar texto» a «hacer cosas en el mundo» cambia por completo la ecuación de seguridad, porque un agente que puede actuar, también puede actuar de manera potencial de formas que nadie pretendía.
Hoy, Microsoft abre el código de dos herramientas diseñadas para ayudar a los ingenieros: Microsoft RAMPART, un marco de pruebas de agentes para codificar escenarios adversariales y benignos como pruebas repetibles que pueden ejecutarse en CI, lo que facilita convertir hallazgos de equipos rojos e incidentes de IA en cobertura de regresión duradera; y Clarity, una caja de resonancia estructurada que ayuda a los equipos a determinar si construyen lo correcto antes de escribir una sola línea de código.
Hemos creado estas herramientas porque creemos que la seguridad en IA debe convertirse en una disciplina de ingeniería continua y no en un punto de control periódico, y creemos que la mejor manera de lograrlo es poner herramientas prácticas y abiertas en manos de quienes construyen la construcción.
Por qué invertimos en esto
Ayudar a los equipos a pensar en el «por qué» antes que en el «cómo» de la construcción de software: En la era de la programación de vibración, la ejecución es fácil y la pregunta más difícil es el «por qué». Los fallos de seguridad más caros que vemos casi siempre se remontan a errores de diseño que nadie cuestionó con prontitud, mucho antes de que se involucrara cualquier adversario — por ejemplo, cuando un equipo de producto decidió que su agente debía tener acceso a una herramienta, o manejar un flujo de usuario concreto, sin analizar por completo qué podría salir mal. Cuando surge el problema en un equipo rojo, el sistema ya está en gran parte construido, y abordarlo implica volver a empezar. Queríamos ofrecer a los responsables de producto e ingenieros una forma de poner a prueba sus suposiciones al inicio de un proyecto, cuando cambiar de rumbo es barato y la conversación adecuada puede ahorrar meses de retrabajo.
Ampliar las lecciones del red teaming en toda la industria. Las técnicas que descubren vulnerabilidades en un producto agente casi siempre arrojan luz sobre otro. Un ataque de inyección cruzada que funciona contra un sistema suele funcionar, con pequeñas variaciones, contra un agente de atención al cliente o un asistente de codificación. Pero esas lecciones tienden a quedarse encerradas en los informes individuales de interacción. Nuestro objetivo era construir un sistema donde las lecciones de los ejercicios de red teaming pudieran convertirse en activos de ingeniería ejecutables.
Hacer que los incidentes sean reproducibles y las mitigaciones verificables. Si algo falla en los sistemas de IA de producción, el equipo que responde debe hacer dos cosas con rapidez: replicar el incidente para entender justo qué ha pasado y verificar que la solución que envíen en verdad resiste las variantes del ataque original. Ambas tareas son más difíciles de lo que parecen con sistemas basados en LLMs probabilísticos, y la mayoría de los equipos acaban haciéndolas de manera manual de forma puntual. Queríamos herramientas diseñadas en específico para este flujo de trabajo, para que la respuesta a incidentes se convirtiera en un proceso de ingeniería repetible en lugar de un proceso de improvisación.
RAMPART: Pruebas de seguridad continuas para IA agéntica
RAMPART es un marco de trabajo de pruebas de código abierto que incorpora las técnicas de red teaming directo al flujo de trabajo de desarrollo. Está construido sobre PyRIT, el marco de automatización abierta de Microsoft para agrupar sistemas de IA generativa en red team, de modo que RAMPART aproveche las mejores pruebas adversariales de su clase, listas para usar. Mientras que PyRIT está optimizado para el descubrimiento de cajas negras por parte de los investigadores de seguridad tras la construcción del sistema, RAMPART se desarrolla para los ingenieros mientras se construye el sistema.
La experiencia de desarrollador resultará familiar para cualquiera que haya escrito pruebas de integración. Los equipos escriben pruebas pytest estándar que describen escenarios derivados de su modelo de amenazas. Cada prueba se conecta al agente a través de un adaptador delgado, orquesta una interacción y evalúa los resultados observables. Las pruebas demuestran una señal clara de aprobado o suspenso y pueden ser bloqueadas en CI igual que cualquier otra prueba de integración. Cuando se añade una nueva herramienta o fuente de datos al agente, la prueba de seguridad correspondiente puede añadirse en la misma pull request.
RAMPART se diferencia de las pruebas convencionales en los siguientes aspectos:
Diseñado para ataques de inyección rápida: la cobertura más madura de RAMPART hoy se centra en ataques de inyección cruzada, escenarios en los que un agente recupera o procesa contenido que podría estar envenenado de documentos, correos electrónicos, tickets u otras fuentes de datos que manipulan su comportamiento de forma indirecta. Se pueden añadir nuevas categorías de amenaza de manera incremental a medida que evolucionan los patrones de ataque, y los puntos de extensión del framework se definen todos como protocolos Python, por lo que la integración sigue ligera incluso para arquitecturas de agentes complejas.
Diseñado para comportamiento probabilístico: Dado que el comportamiento de los LLM es probabilístico, RAMPART soporta ensayos estadísticos. La misma prueba puede ejecutarse varias veces con políticas como «esta acción debe ser segura en al menos el 80 por ciento de las ejecuciones.» Esto refleja cómo se comportan en realidad los agentes en producción con mucha más precisión que la validación de un solo disparo.
Diseñado para reproducir tus hallazgos de equipos rojos de IA e incidentes de IA: RAMPART está diseñado para funcionar junto con equipos rojos (red teams) dedicados, y ambos se refuerzan de manera mutua. Los resultados de un compromiso con un equipo rojo pueden codificarse como pruebas RAMPART, lo que significa que el problema queda cubierto de manera permanente, se ejecuta en cada cambio y nunca retrocede de manera silenciosa. El modelo de propiedad se invierte de manera intencionada respecto al enfoque tradicional: los ingenieros escriben las pruebas, los ingenieros las ejecutan y los ingenieros tratan los fallos como cualquier otro error. El marco proporciona las estrategias de ataque, la generación adversarial de carga útil y la lógica de evaluación. El autor de la prueba se centra en expresar expectativas sobre lo que su agente debe y no debe hacer.
La seguridad del agente depende en última instancia de lo que haga el agente, lo que significa que los evaluadores deben analizar qué herramientas invoca, qué efectos secundarios ocurren y si esas acciones se mantienen dentro de los límites esperados. Los evaluadores de RAMPART están diseñados para inspeccionar todo eso. Son componibles, por lo que los equipos pueden combinarlas con lógica booleana para expresar condiciones de seguridad matizadas en lugar de depender de una sola señal binaria.
Clarity: Ayudar a comprobar las suposiciones de ingeniería de software
Mientras que la mayoría de las herramientas de IA están diseñadas para ayudar a los equipos a ejecutar más rápido, Clarity fue diseñada por Microsoft para ayudarles a determinar si ejecutan lo correcto desde el principio. Plantea el tipo de preguntas que harían arquitectos, gestores de producto e ingenieros de seguridad con experiencia, las que son fáciles de saltarse cuando un equipo está entusiasmado por construir algo nuevo.
Consideren un equipo que quiere añadir colaboración en tiempo real a un editor de documentos. En lugar de saltar directo a las opciones de implementación, Clarity preguntará qué ocurre cuando dos personas editan el mismo párrafo al mismo tiempo, y si el equipo en realidad necesita una colaboración real en tiempo real con cursores e indicadores de presencia, o si «nadie pierde su trabajo» es el verdadero requisito. Esas dos respuestas pueden dar lugar a arquitecturas muy diferentes con modos de fallo muy distintos, y aclarar esa distinción pronto puede ahorrar meses de retrabajo.
Clarity funciona como una aplicación de escritorio, una interfaz web o incrustada directo en un agente de codificación. Guía a los ingenieros a través de conversaciones estructuradas que abarcan la clarificación de problemas, la exploración de soluciones, el análisis de fallos y el seguimiento de decisiones. A medida que avanza la conversación, los resultados se escriben en un directorio .clarity-protocol/ dentro del repositorio como simples archivos markdown legibles por humanos que se confirman, revisan en pull requests y se diferencian igual que el código fuente. Recogen la declaración del problema, la justificación de la solución, el análisis de fallos y las decisiones clave tomadas a lo largo del camino.
El análisis de fallos merece un análisis más detallado, porque va mucho más allá de lo que por lo general detectaría un solo revisor. Múltiples «pensadores» de IA examinan el sistema de manera independiente desde diferentes ángulos, incluida la seguridad, factores humanos, escenarios adversariales y preocupaciones operativas. El equipo trabaja entonces los resultados junto con Clarity, para agrupar fallos relacionados, rastrear cadenas causales y planificar la gestión del edificio.
La claridad también rastrea la anticuidad en estos documentos, porque forman un grafo de dependencias. Cuando cambia una declaración de problema, Clarity sabe que la descripción de la solución y el análisis de fallos pueden necesitar ser revisados y anima al equipo a hacerlo. Las decisiones importantes se capturan con sus criterios, las opciones consideradas y la justificación detrás de cada elección, de modo que seis meses después, cualquiera del equipo pueda revisar el razonamiento completo, incluidas qué alternativas se descartaron y por qué.
El directorio .clarity-protocol/ se convierte en un artefacto compartido que todos los miembros del equipo pueden ver y aportar, y para los stakeholders que necesitan un resumen antes de una revisión, Clarity puede generar un paquete de revisión que cuenta una narrativa coherente.
RAMPART y Clarity forman parte de un movimiento más amplio hacia una seguridad en IA basada en especificaciones y nativa de la ingeniería. Complementan el trabajo de Microsoft en sistemas de política a medida: Clarity ayuda a los equipos a clarificar la intención de diseño y a capturar suposiciones; RAMPART proporciona a los equipos los bloques para escribir pruebas de seguridad de agentes concretos y mantenerlas en funcionamiento a medida que los agentes evolucionan… En conjunto, estos enfoques trasladan la seguridad de la IA de una revisión única a un conjunto de artefactos vivos que los desarrolladores pueden utilizar a lo largo de todo el ciclo de vida.
RAMPART y Clarity disponibles ahora
Tanto RAMPART como Clarity están disponibles hoy en día como proyectos de código abierto de Microsoft.
Esperamos trabajar con la comunidad. Para recibir comentarios y colaborar en su implementación en el entorno empresarial, por favor contacten con aisafetytools@microsoft.com.
Contribuciones
Microsoft RAMPART está dirigido por Bashir Partovi con contribuciones de Elliot H Omiya, Richard Lundeen, Nina Chikanov, Spencer Schoenberg y Toby Kohlenberg. Claridad es un proyecto conjunto de Yonatan Zunger, Dharmin Shah, Elliot H Omiya, Eve Kazarian, Sarah Cooley y Neil Coles. Queremos agradecer a Minsoo Thigpen, Abby Palia, Mehrnoosh Sameki, Hilary Solan, Elliot Volkman, Pete Bryan, Roman Lutz y Shiven Chawla por sus valiosos comentarios.
The post Presentamos RAMPART y Clarity: Herramientas de código abierto para incorporar seguridad al flujo de trabajo de desarrollo de Agentes appeared first on Source LATAM.
Today, AWS announces the general availability of a new AWS Local Zone in Istanbul, Türkiye, bringing AWS infrastructure closer to end users, while enabling organizations to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The AWS Local Zone in Istanbul supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
Today, AWS announces the general availability of a new AWS Local Zone in Istanbul, Türkiye, bringing AWS infrastructure closer to end users, while enabling organizations to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The AWS Local Zone in Istanbul supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
To get started, enable the AWS Local Zone in Istanbul (eu-central-1-ist-1a) from the Zones tab in the Amazon EC2 console settings or by using the ModifyAvailabilityZoneGroup API. For pricing information, visit the AWS Local Zones pricing page. To learn more, visit the AWS Local Zones overview page.
Amazon SageMaker HyperPod now supports data capture for inference workloads, enabling customers to record inference request and response payloads for model monitoring, compliance, debugging, and offline analysis. Organizations deploying generative AI and machine learning models on HyperPod need systematic visibility into the inputs flowing into their models and the outputs returned to clients to detect model drift, satisfy regulatory audit requirements, debug production issues, and build ground-truth datasets for fine-tuning. Previously, customers had to either accept limited operational visibility into their inference workloads or build expensive custom logging pipelines outside the HyperPod Inference Operator.
With data capture, you can choose to record inference traffic at the SageMaker endpoint, at the load balancer, or at the model pod, depending on the level of visibility you need, and combine these options for layered observability. Captured data is delivered asynchronously to your Amazon S3 bucket and supports configurable sampling and encryption with customer-managed AWS KMS keys, so you can balance coverage with cost while keeping sensitive data protected. Data capture is designed to never block inference, ensuring production availability is preserved. You can enable data capture by configuring it on your inference endpoint when deploying models through the HyperPod Inference Operator or with SageMaker JumpStart.
This feature is available for SageMaker HyperPod clusters using the EKS orchestrator in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see Data capture for inference on HyperPod.
Amazon SageMaker HyperPod now supports data capture for inference workloads, enabling customers to record inference request and response payloads for model monitoring, compliance, debugging, and offline analysis. Organizations deploying generative AI and machine learning models on HyperPod need systematic visibility into the inputs flowing into their models and the outputs returned to clients to detect model drift, satisfy regulatory audit requirements, debug production issues, and build ground-truth datasets for fine-tuning. Previously, customers had to either accept limited operational visibility into their inference workloads or build expensive custom logging pipelines outside the HyperPod Inference Operator. With data capture, you can choose to record inference traffic at the SageMaker endpoint, at the load balancer, or at the model pod, depending on the level of visibility you need, and combine these options for layered observability. Captured data is delivered asynchronously to your Amazon S3 bucket and supports configurable sampling and encryption with customer-managed AWS KMS keys, so you can balance coverage with cost while keeping sensitive data protected. Data capture is designed to never block inference, ensuring production availability is preserved. You can enable data capture by configuring it on your inference endpoint when deploying models through the HyperPod Inference Operator or with SageMaker JumpStart. This feature is available for SageMaker HyperPod clusters using the EKS orchestrator in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see Data capture for inference on HyperPod.
Amazon Managed Workflows for Apache Airflow (MWAA) now supports Apache Airflow version 3.2, the latest major release of the popular open-source workflow orchestration framework. Amazon MWAA is a managed service that lets you run Apache Airflow at scale without managing the underlying infrastructure. This release brings new data-aware scheduling capabilities and developer productivity improvements to teams building and operating data pipelines on AWS.
With Apache Airflow 3.2, you can now use asset partitioning to trigger downstream DAGs based on specific slices of data, such as a date-partitioned S3 path, rather than an entire asset, giving data engineering teams more precise control over pipeline execution. This release also expands Human-in-the-Loop (HITL) capabilities with a full audit history view for approvals, HITL support for the AgenticOperator, and synchronous callback support for Deadline Alerts. Additional improvements include Grid View virtualization for faster rendering of large DAGs, full XCom management from the Airflow UI, and async callable support in PythonOperator..
Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.
Amazon Managed Workflows for Apache Airflow (MWAA) now supports Apache Airflow version 3.2, the latest major release of the popular open-source workflow orchestration framework. Amazon MWAA is a managed service that lets you run Apache Airflow at scale without managing the underlying infrastructure. This release brings new data-aware scheduling capabilities and developer productivity improvements to teams building and operating data pipelines on AWS.
With Apache Airflow 3.2, you can now use asset partitioning to trigger downstream DAGs based on specific slices of data, such as a date-partitioned S3 path, rather than an entire asset, giving data engineering teams more precise control over pipeline execution. This release also expands Human-in-the-Loop (HITL) capabilities with a full audit history view for approvals, HITL support for the AgenticOperator, and synchronous callback support for Deadline Alerts. Additional improvements include Grid View virtualization for faster rendering of large DAGs, full XCom management from the Airflow UI, and async callable support in PythonOperator..
You can launch a new Apache Airflow 3.2 environment on Amazon MWAA, or upgrade from 2.11 or later, with just a few clicks in the AWS Management Console in all currently supported Amazon MWAA regions. To learn more about Apache Airflow 3.2 visit the Amazon MWAA documentation, and the Apache Airflow 3.2 change log in the Apache Airflow documentation. Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.
Amazon Elastic Container Service (Amazon ECS) now enables you to pause service deployments at critical stages during deployment progression and continue deployments when ready. You can use these pause points to introduce manual decision points and interactive controls into your deployments for scenarios such as manual approval workflows, operational checks, integration tests, or custom automation, while continuing to use native Amazon ECS deployment strategies with managed traffic shifting, bake times, fast rollbacks, CloudWatch alarms, and deployment circuit breaker.
With this launch, you can configure a new PAUSE deployment lifecycle hook as part of your Amazon ECS service deployment configuration. When a deployment reaches a configured pause point, Amazon ECS pauses deployment progression and emits Amazon EventBridge events that you can use to trigger automation workflows, approval systems, or external validation processes. You can then continue or roll back the deployment using the new ContinueServiceDeployment API. With pause hooks, you can configure timeout durations up to 14 days and timeout actions to automatically continue or roll back the deployment if no action is received.
You can configure pause hooks for rolling, blue/green, linear, and canary deployment strategies using the Amazon ECS Console, AWS CLI, AWS SDKs, AWS CloudFormation, AWS CDK, and Terraform. You can use the ContinueServiceDeployment API through the Amazon ECS Console, AWS CLI, and AWS SDKs. This feature is available in all AWS commercial and AWS GovCloud (US) Regions. To learn more, see our documentation on pause hooks for service deployments and continuing service deployments.
Amazon Elastic Container Service (Amazon ECS) now enables you to pause service deployments at critical stages during deployment progression and continue deployments when ready. You can use these pause points to introduce manual decision points and interactive controls into your deployments for scenarios such as manual approval workflows, operational checks, integration tests, or custom automation, while continuing to use native Amazon ECS deployment strategies with managed traffic shifting, bake times, fast rollbacks, CloudWatch alarms, and deployment circuit breaker.
With this launch, you can configure a new PAUSE deployment lifecycle hook as part of your Amazon ECS service deployment configuration. When a deployment reaches a configured pause point, Amazon ECS pauses deployment progression and emits Amazon EventBridge events that you can use to trigger automation workflows, approval systems, or external validation processes. You can then continue or roll back the deployment using the new ContinueServiceDeployment API. With pause hooks, you can configure timeout durations up to 14 days and timeout actions to automatically continue or roll back the deployment if no action is received.
You can configure pause hooks for rolling, blue/green, linear, and canary deployment strategies using the Amazon ECS Console, AWS CLI, AWS SDKs, AWS CloudFormation, AWS CDK, and Terraform. You can use the ContinueServiceDeployment API through the Amazon ECS Console, AWS CLI, and AWS SDKs. This feature is available in all AWS commercial and AWS GovCloud (US) Regions. To learn more, see our documentation on pause hooks for service deployments and continuing service deployments.
Amazon Managed Grafana now supports dual-stack connectivity, enabling workspaces to communicate over both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Dual-stack mode is available for workspaces running Grafana version 10.4 or later.
With dual-stack support, customers can simplify their network stack by eliminating the need to manage overlapping address spaces in their VPCs. Customers migrating to IPv6 can connect to their Grafana workspaces over IPv6 while maintaining IPv4 compatibility, and those not yet on IPv6 can continue using IPv4-only connections. This is especially beneficial as the continued growth of the internet exhausts available IPv4 addresses.
Support for dual-stack connectivity on Amazon Managed Grafana is available in all regions where the service is generally available. To get started, update your workspace configuration via the Amazon Managed Grafana console, API, or CLI. For more information, see the Amazon Managed Grafana User Guide. To learn more about best practices for configuring IPv6 in your environment, visit the whitepaper on IPv6 in AWS.
Amazon Managed Grafana now supports dual-stack connectivity, enabling workspaces to communicate over both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Dual-stack mode is available for workspaces running Grafana version 10.4 or later.
With dual-stack support, customers can simplify their network stack by eliminating the need to manage overlapping address spaces in their VPCs. Customers migrating to IPv6 can connect to their Grafana workspaces over IPv6 while maintaining IPv4 compatibility, and those not yet on IPv6 can continue using IPv4-only connections. This is especially beneficial as the continued growth of the internet exhausts available IPv4 addresses.
Support for dual-stack connectivity on Amazon Managed Grafana is available in all regions where the service is generally available. To get started, update your workspace configuration via the Amazon Managed Grafana console, API, or CLI. For more information, see the Amazon Managed Grafana User Guide. To learn more about best practices for configuring IPv6 in your environment, visit the whitepaper on IPv6 in AWS.
Today, AWS announces the availability of Amazon Inspector in the AWS Asia Pacific (Taipei) Region. Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads including Amazon EC2 instances, container images, and AWS Lambda functions for software vulnerabilities and unintended network exposure across your AWS Organization.
With this expansion, Amazon Inspector extends its security coverage to AWS Asia Pacific (Taipei) Region, designed to help customers automatically discover workloads, conduct continuous vulnerability assessments, and receive actionable security findings. The service is designed to detect newly launched Amazon EC2 instances, Lambda functions, and eligible container images pushed to Amazon Elastic Container Registry (ECR) and scan them for software vulnerabilities and unintended network exposure.
All accounts new to Amazon Inspector are eligible for a 15-day free trial to evaluate the service and estimate its cost. During the trial, all eligible Amazon EC2 instances, AWS Lambda functions, and container images pushed to Amazon ECR are continually scanned at no cost. After the trial period, you will be charged based on public pricing for Amazon Inspector. Visit the Amazon Inspector pricing page for more details.
Today, AWS announces the availability of Amazon Inspector in the AWS Asia Pacific (Taipei) Region. Amazon Inspector is an automated vulnerability management service that continually scans AWS workloads including Amazon EC2 instances, container images, and AWS Lambda functions for software vulnerabilities and unintended network exposure across your AWS Organization. With this expansion, Amazon Inspector extends its security coverage to AWS Asia Pacific (Taipei) Region, designed to help customers automatically discover workloads, conduct continuous vulnerability assessments, and receive actionable security findings. The service is designed to detect newly launched Amazon EC2 instances, Lambda functions, and eligible container images pushed to Amazon Elastic Container Registry (ECR) and scan them for software vulnerabilities and unintended network exposure. All accounts new to Amazon Inspector are eligible for a 15-day free trial to evaluate the service and estimate its cost. During the trial, all eligible Amazon EC2 instances, AWS Lambda functions, and container images pushed to Amazon ECR are continually scanned at no cost. After the trial period, you will be charged based on public pricing for Amazon Inspector. Visit the Amazon Inspector pricing page for more details. To get started with Amazon Inspector visit our documentation or begin your free trial today.
