Today, AWS announces that partners can associate one or more AWS Marketplace solutions and product listings from their AWS Marketplace catalog directly to co-sell opportunities in AWS Partner Central. Previously, opportunities required partners to use solutions specially created for co-selling, which meant partners managed their solutions for the AWS Marketplace catalog and solutions for co-selling separately. Partners can now associate their existing AWS Marketplace listings with opportunities to track fulfillment more effectively.
When creating or editing an opportunity in AWS Partner Central in the AWS Console, Partners can select one of the following options: (1) AWS Marketplace solutions and products, (2) AWS Marketplace solutions only, (3) AWS Marketplace products only, or (4) Other. Partners can associate up to 10 AWS Marketplace Solutions and up to 10 AWS Marketplace Products with a single opportunity. This includes AWS Marketplace listings within AWS accounts that have an established subsidiary account connection. The same capability is available programmatically through the AWS Partner Central Selling API. To progress an opportunity to the Committed or Launched stage, an AWS Marketplace Solution, AWS Marketplace Product, or Partner Solution must be associated.
Today, AWS announces that partners can associate one or more AWS Marketplace solutions and product listings from their AWS Marketplace catalog directly to co-sell opportunities in AWS Partner Central. Previously, opportunities required partners to use solutions specially created for co-selling, which meant partners managed their solutions for the AWS Marketplace catalog and solutions for co-selling separately. Partners can now associate their existing AWS Marketplace listings with opportunities to track fulfillment more effectively.
When creating or editing an opportunity in AWS Partner Central in the AWS Console, Partners can select one of the following options: (1) AWS Marketplace solutions and products, (2) AWS Marketplace solutions only, (3) AWS Marketplace products only, or (4) Other. Partners can associate up to 10 AWS Marketplace Solutions and up to 10 AWS Marketplace Products with a single opportunity. This includes AWS Marketplace listings within AWS accounts that have an established subsidiary account connection. The same capability is available programmatically through the AWS Partner Central Selling API. To progress an opportunity to the Committed or Launched stage, an AWS Marketplace Solution, AWS Marketplace Product, or Partner Solution must be associated.
This capability is generally available in AWS Partner Central in the AWS Console. To learn more, review creating an opportunity and attach AWS Marketplace listings to ACE opportunities guides, or explore how to leverage the programmatic implementation option with the AWS Partner Central Selling API.
Amazon GuardDuty Runtime Monitoring now includes three new threat detections that alert security teams when sensitive files are modified on Amazon EC2 instances and container workloads running on Amazon EKS or Amazon ECS. These findings help identify post-compromise attacker activities by monitoring critical system files, including configuration files, authentication settings, and system logs. This capability is designed for security teams, DevSecOps professionals, and cloud security architects who need comprehensive threat visibility across their AWS compute environments.
The new detections—Persistence:Runtime/SensitiveFileModified, PrivilegeEscalation:Runtime/SensitiveFileModified, and DefenseEvasion:Runtime/SensitiveFileModified—help identify attempts to maintain persistent access, escalate privileges, and evade detection after an initial system compromise. By monitoring five specific file operations (open-for-write, rename, symlink, link, and unlink) directly, these findings can detect threats even when attackers use obfuscated techniques that bypass traditional command-line monitoring. The correlation-based analysis distinguishes malicious behavior from legitimate administrative operations, helping reduce false positives while providing actionable intelligence with MITRE ATT&CK® tactics mapping and remediation recommendations.
These sensitive file modification findings are now available to all customers who have enabled GuardDuty Runtime Monitoring for their Amazon EC2, Amazon EKS, or Amazon ECS workloads. A 30-day free trial is available for new users. To learn more, see Amazon GuardDuty Findings. To receive programmatic updates on new Amazon GuardDuty features and threat detections, please subscribe to the Amazon GuardDuty SNS topic.
Amazon GuardDuty Runtime Monitoring now includes three new threat detections that alert security teams when sensitive files are modified on Amazon EC2 instances and container workloads running on Amazon EKS or Amazon ECS. These findings help identify post-compromise attacker activities by monitoring critical system files, including configuration files, authentication settings, and system logs. This capability is designed for security teams, DevSecOps professionals, and cloud security architects who need comprehensive threat visibility across their AWS compute environments. The new detections—Persistence:Runtime/SensitiveFileModified, PrivilegeEscalation:Runtime/SensitiveFileModified, and DefenseEvasion:Runtime/SensitiveFileModified—help identify attempts to maintain persistent access, escalate privileges, and evade detection after an initial system compromise. By monitoring five specific file operations (open-for-write, rename, symlink, link, and unlink) directly, these findings can detect threats even when attackers use obfuscated techniques that bypass traditional command-line monitoring. The correlation-based analysis distinguishes malicious behavior from legitimate administrative operations, helping reduce false positives while providing actionable intelligence with MITRE ATT&CK® tactics mapping and remediation recommendations. These sensitive file modification findings are now available to all customers who have enabled GuardDuty Runtime Monitoring for their Amazon EC2, Amazon EKS, or Amazon ECS workloads. A 30-day free trial is available for new users. To learn more, see Amazon GuardDuty Findings. To receive programmatic updates on new Amazon GuardDuty features and threat detections, please subscribe to the Amazon GuardDuty SNS topic.
Amazon Bedrock AgentCore is now available in four additional AWS Regions: Asia Pacific (Bangkok), Asia Pacific (Malaysia), Europe (Milan), and Europe (Spain). Amazon Bedrock AgentCore is the platform to build, connect, and optimize agents. It helps engineers ship agents fast with any framework and any model, connect them to enterprise systems and tools, and optimize them continuously, with security enforced at the infrastructure layer that agents can’t bypass.
With this expansion, customers in these regions can build and run agents closer to their end users with lower latency. AgentCore capabilities including agent runtime, identity and access control, policy management, session persistence, tool connectivity, and observability are available in these regions at launch.
Amazon Bedrock AgentCore is now available in four additional AWS Regions: Asia Pacific (Bangkok), Asia Pacific (Malaysia), Europe (Milan), and Europe (Spain). Amazon Bedrock AgentCore is the platform to build, connect, and optimize agents. It helps engineers ship agents fast with any framework and any model, connect them to enterprise systems and tools, and optimize them continuously, with security enforced at the infrastructure layer that agents can’t bypass.
With this expansion, customers in these regions can build and run agents closer to their end users with lower latency. AgentCore capabilities including agent runtime, identity and access control, policy management, session persistence, tool connectivity, and observability are available in these regions at launch.
For more information on AgentCore, visit the AgentCore product page or the AgentCore Developer Guide. To learn about pricing, visit AgentCore pricing. For region availability, visit Supported AWS Regions.
Cross-Region Automated Backup replication for Amazon RDS is now available in four additional AWS Regions. This launch allows you to setup automated backup replication between Mexico (Central) and Europe (Ireland) or US West (N. California); between Asia Pacific (Taipei) and Asia Pacific (Singapore) or Asia Pacific (Tokyo); between Asia Pacific (New Zealand) and Asia Pacific (Singapore), Asia Pacific (Sydney), or Asia Pacific (Melbourne); and between Asia Pacific (Thailand) and Asia Pacific (Singapore) or Asia Pacific (Jakarta) Regions.
Automated Backups enable recovery capability for mission-critical databases by providing you the ability to restore your database to a specific point in time within your backup retention period. With Cross-Region Automated Backup replication, RDS will replicate snapshots and transaction logs to the chosen destination AWS Region. In the event that your primary AWS Region becomes unavailable, you can restore the automated backup to a point in time in the secondary AWS Region and quickly resume operations. As transaction logs are uploaded to the target AWS Region frequently, you can achieve a Recovery Point Objective (RPO) of within the last few minutes.
You can setup Cross-Region Automated Backup replication with just a few clicks on the Amazon RDS Management Console or using the AWS SDK or CLI. Cross-Region Automated Backup replication is available on Amazon RDS for PostgreSQL, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Db2, Amazon RDS for Oracle, and Amazon RDS for Microsoft SQL Server. For more information, including instructions on getting started, read the Amazon RDS documentation.
Cross-Region Automated Backup replication for Amazon RDS is now available in four additional AWS Regions. This launch allows you to setup automated backup replication between Mexico (Central) and Europe (Ireland) or US West (N. California); between Asia Pacific (Taipei) and Asia Pacific (Singapore) or Asia Pacific (Tokyo); between Asia Pacific (New Zealand) and Asia Pacific (Singapore), Asia Pacific (Sydney), or Asia Pacific (Melbourne); and between Asia Pacific (Thailand) and Asia Pacific (Singapore) or Asia Pacific (Jakarta) Regions.
Automated Backups enable recovery capability for mission-critical databases by providing you the ability to restore your database to a specific point in time within your backup retention period. With Cross-Region Automated Backup replication, RDS will replicate snapshots and transaction logs to the chosen destination AWS Region. In the event that your primary AWS Region becomes unavailable, you can restore the automated backup to a point in time in the secondary AWS Region and quickly resume operations. As transaction logs are uploaded to the target AWS Region frequently, you can achieve a Recovery Point Objective (RPO) of within the last few minutes.
You can setup Cross-Region Automated Backup replication with just a few clicks on the Amazon RDS Management Console or using the AWS SDK or CLI. Cross-Region Automated Backup replication is available on Amazon RDS for PostgreSQL, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Db2, Amazon RDS for Oracle, and Amazon RDS for Microsoft SQL Server. For more information, including instructions on getting started, read the Amazon RDS documentation.
Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes version rollback, enabling you to revert to the previous Kubernetes minor version within 7 days if any issues arise after an upgrade. This provides an additional safety net for your upgrade workflow, allowing you to validate the new version under real production conditions and rollback if needed.
You can initiate a rollback using the Amazon EKS console, AWS CLI, or AWS SDKs. Before proceeding, Amazon EKS evaluates your cluster rollback readiness insights that include automated checks covering API compatibility, version skew, add-on compatibility, cluster health, and more. For clusters running EKS Auto Mode, EKS automatically manages the rollback of worker nodes before reverting the control plane, honoring your configured disruption controls.
Amazon EKS version rollback is available at no additional cost in all AWS Regions where Amazon EKS is available. To get started, see version rollback in the Amazon EKS User Guide.
Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes version rollback, enabling you to revert to the previous Kubernetes minor version within 7 days if any issues arise after an upgrade. This provides an additional safety net for your upgrade workflow, allowing you to validate the new version under real production conditions and rollback if needed. You can initiate a rollback using the Amazon EKS console, AWS CLI, or AWS SDKs. Before proceeding, Amazon EKS evaluates your cluster rollback readiness insights that include automated checks covering API compatibility, version skew, add-on compatibility, cluster health, and more. For clusters running EKS Auto Mode, EKS automatically manages the rollback of worker nodes before reverting the control plane, honoring your configured disruption controls. Amazon EKS version rollback is available at no additional cost in all AWS Regions where Amazon EKS is available. To get started, see version rollback in the Amazon EKS User Guide.
Amazon Managed Service for Prometheus is now FedRAMP High and Department of Defense Cloud Computing Security Requirements Guide (DoD CC SRG) Impact Level (IL) 4 and 5 authorized in the AWS GovCloud (US) Regions.
Federal agencies, public sector organizations, and other enterprises with FedRAMP High and DoD CC SRG IL-4/5 compliance requirements can now use Amazon Managed Service for Prometheus to monitor and alert on their workloads with confidence that it meets the security and compliance standards required for sensitive environments.
Amazon Managed Service for Prometheus is a fully managed, Prometheus-compatible monitoring service that makes it easy to monitor and alert on operational metrics at scale. It automatically scales ingestion and storage for high-cardinality workloads, and integrates with AWS security services for fast, secure access to data.
Amazon Managed Service for Prometheus is now FedRAMP High and Department of Defense Cloud Computing Security Requirements Guide (DoD CC SRG) Impact Level (IL) 4 and 5 authorized in the AWS GovCloud (US) Regions.
Federal agencies, public sector organizations, and other enterprises with FedRAMP High and DoD CC SRG IL-4/5 compliance requirements can now use Amazon Managed Service for Prometheus to monitor and alert on their workloads with confidence that it meets the security and compliance standards required for sensitive environments.
Amazon Managed Service for Prometheus is a fully managed, Prometheus-compatible monitoring service that makes it easy to monitor and alert on operational metrics at scale. It automatically scales ingestion and storage for high-cardinality workloads, and integrates with AWS security services for fast, secure access to data.
For more details about Amazon Managed Service for Prometheus in AWS GovCloud (US), visit the Amazon Managed Service for Prometheus GovCloud documentation or contact your AWS account team for more information. To learn more, visit the Amazon Managed Service for Prometheus product page.
Starting today, AWS Security Agent (now part of AWS Continuum) is available in three additional AWS Regions: Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo). Customers in these Regions can now access core capabilities of Security Agent to proactively secure their applications throughout the development lifecycle.
With this expansion, customers gain access to STRIDE-based threat modeling (preview) that analyzes design documents and source code to surface risks early in the development lifecycle. Full-repo and PR-level code reviews (preview) are available across GitHub, GitLab, GitHub Enterprise Server, Bitbucket, and Confluence, with managed compliance packs and custom security requirements. They can trigger threat modeling, code reviews, and remediation directly from Kiro or Claude Code through the new IDE plugins and MCP integration. On-demand penetration testing delivers validated findings with reproducible attack paths and ready-to-implement fixes, and retesting confirms that applied remediations are effective. Simulated validation remains available only in US East (N. Virginia).
AWS Security Agent scales security expertise across your applications to match development velocity while providing comprehensive security coverage. To learn more, visit the documentation or see our product page.
Starting today, AWS Security Agent (now part of AWS Continuum) is available in three additional AWS Regions: Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo). Customers in these Regions can now access core capabilities of Security Agent to proactively secure their applications throughout the development lifecycle. With this expansion, customers gain access to STRIDE-based threat modeling (preview) that analyzes design documents and source code to surface risks early in the development lifecycle. Full-repo and PR-level code reviews (preview) are available across GitHub, GitLab, GitHub Enterprise Server, Bitbucket, and Confluence, with managed compliance packs and custom security requirements. They can trigger threat modeling, code reviews, and remediation directly from Kiro or Claude Code through the new IDE plugins and MCP integration. On-demand penetration testing delivers validated findings with reproducible attack paths and ready-to-implement fixes, and retesting confirms that applied remediations are effective. Simulated validation remains available only in US East (N. Virginia). AWS Security Agent scales security expertise across your applications to match development velocity while providing comprehensive security coverage. To learn more, visit the documentation or see our product page.
Comprender el cerebro con explicaciones y experimentos impulsados por IA
Resumen
Los modelos basados en LLM pueden predecir con gran precisión las respuestas del cerebro humano al lenguaje. Pero lo que impulsa ese rendimiento es en esencia ilegible: una vasta colección de parámetros aprendidos, no teorías científicas que cualquiera pueda leer.
Las pruebas causales generativas (GCT, por sus siglas en inglés), desarrolladas en colaboración entre Microsoft Research, la Universidad de California en Berkeley, la Universidad de California en San Francisco y la Universidad de Columbia, destilan estos modelos de predicción cerebral en breves explicaciones verbales de a qué responde cada parche de la corteza: frases como «preparación de alimentos» o «nombres de lugares».
GCT entonces cierra el ciclo: un LLM escribe nuevas historias diseñadas para activar una zona cerebral objetivo, los sujetos las escuchan en el escáner y la región solo se ilumina si la explicación es correcta.
En experimentos, la GCT confirmó la selectividad conocida, desglosó regiones vecinas de procesamiento de lugares que durante mucho tiempo se consideraban intercambiables y reveló diminutas «microregiones» prefrontales ajustadas a conceptos específicos como diálogo, tiempos de reloj y mediciones.
El problema de la explicabilidad en la neurociencia del lenguaje
En la última década, los LLMs se han convertido en las herramientas más precisas que tenemos para predecir cómo responde el cerebro humano al lenguaje. Si se alimenta a un LLM la misma historia que una persona escucha en un escáner de fMRI, las representaciones internas del modelo pueden predecir la actividad de parches individuales de la corteza con una fidelidad notable. Pero este éxito tiene una condición: nadie puede leer estos modelos. Son millones de parámetros inescrutables que no pueden traducirse de manera directa en interpretaciones. Un modelo que predice la actividad cerebral nos dice que una región responde al lenguaje, pero no a lo que realmente detecta, ya sea comida, lugares, números o cualquier otra cosa distinta. A medida que los modelos de caja negra se expanden, la brecha entre la predicción y la comprensión se ha convertido en uno de los problemas centrales de la neurociencia computacional.
Convertir las cajas negras en teorías comprobables
En un nuevo artículo aceptado en Nature Neuroscience, científicos de Microsoft Research, en colaboración con científicos de la Universidad de California, Berkeley, la Universidad de California, San Francisco y la Universidad de Columbia, presentan un marco para superar esta crisis de explicabilidad: las pruebas causales generativas (GCT, por sus siglas en inglés). GCT destila los modelos de predicción cerebral en relatos breves y legibles de a qué responde cada parche de la corteza, y luego pone a prueba esas afirmaciones. Un LLM escribe nuevas historias diseñadas para activar una zona cerebral específica, los sujetos las escuchan en el escáner y, si la explicación es correcta, la región objetivo se ilumina. El resultado es un método que traduce modelos predictivos ininterpretables de nuevo en la corriente de la ciencia: hipótesis concisas que pueden confirmarse o refutarse en un experimento de seguimiento. Un LLM escribe nuevas historias diseñadas para activar una zona cerebral específica, los sujetos las escuchan en el escáner y, si la explicación es correcta, la región objetivo se ilumina. El resultado es un método que traduce modelos predictivos ininterpretables de nuevo en la corriente de la ciencia: hipótesis concisas que pueden confirmarse o refutarse en un experimento de seguimiento.
Figura 1. Los dos pasos de la prueba causal generativa (GCT). En el Paso 1, las frases que más impulsan el modelo predictivo de una región cerebral se resumen en un LLM en una breve explicación candidata, como «preparación de alimentos». En el Paso 2, un LLM escribe nuevas historias diseñadas para coincidir con esa explicación, y la respuesta de la región a estas historias de «conducción» se mide en el escáner y se compara con la línea base.
Cómo funciona la GCT
GCT tiene dos pasos: explicación y luego verificación. Para generar una explicación, el método parte de un modelo predictivo para un solo vóxel o región e identifica las frases cortas que más impulsan su respuesta predicha. Un LLM resume entonces esas palabras en una explicación verbal concisa, a menudo una sola frase como «preparación de alimentos» o «nombres de lugares».
La crucial segunda etapa cierra el ciclo. Para generar confianza en la explicación, GCT utiliza un LLM para escribir nuevas historias en las que cada párrafo está construido de manera cuidadosa, para guiar una región cerebral según su explicación. Tres sujetos volvieron al escáner para leer estas historias sintéticas. Si la actividad de una región respecto a sus párrafos «impulsivos» era mucho mayor que respecto al texto base, la explicación superaba una prueba causal genuina, no solo correlacional.
En los tres temas, el enfoque central se mantuvo: las historias sintéticas hicieron que sus regiones objetivo superaran la línea base, lo que confirma que las breves explicaciones de GCT capturan algo a lo que la corteza responde de manera genuina. Las explicaciones también eran más fiables donde los modelos subyacentes de predicción cerebral eran más sólidos (cuanto más estable era el modelo, más fiable podía confirmarse su explicación en el escáner). Con el método validado en regiones cuya selectividad ya era conocida, los investigadores aplicaron la GCT a preguntas más difíciles.
Figura 2. La respuesta cerebral se relaciona con historias de GCT para diferentes temas. Algunos mapas recuperan hallazgos bien establecidos: la explicación «Ubicaciones» produce respuestas fuertes en las áreas de lugares RSC, OPA y PPA. Otros confirman de forma independiente hipótesis más recientes: la «preparación de alimentos» activa una región en la corteza occipital ventral cerca de la zona fusiforme de la cara (FFA, por sus siglas en inglés). Algunas, como («Birthdays»), no se corresponden de manera clara con ningún resultado conocido, lo que apunta a direcciones para futuras investigaciones.
La GCT también resultó con la suficiente agudez como para disipar ambigüedades de larga data. Tres regiones vecinas implicadas en los lugares de procesamiento han sido a menudo tratadas como similares a nivel funcional: la corteza retroesplénica (CSR, por sus siglas en inglés), el área del lugar parahipocampal (PPA, por sus siglas en inglés) y el área del lugar occipital (OPA, por sus siglas en inglés). Al principio, las historias escritas para una región también activaban las otras. Pero al generar estímulos diferenciales (historias diseñadas para encender una región mientras mantienen a sus vecinas en silencio), GCT diferenció a los tres. Por ejemplo, RSC responde con mayor fuerza a nombres de ubicación propios, como Tokio o Connecticut, en lugar de ubicación general. Este es el tipo de teoría matizada y específica de región que un modelo predictivo en bruto no puede proporcionar por sí solo.
Más allá de las regiones conocidas, los autores descubrieron nuevas «microregiones» prefrontales. Al escanear una cuadrícula de ubicaciones candidatas y mantener solo las más estables, GCT sacó a la luz estas regiones no cartografiadas de manera previa, ajustadas a conceptos específicos: una selectiva para el diálogo entre personas (palabras como «dijo» o «contó»), otra para menciones de tiempos de reloj («una en punto») y otra para mediciones numéricas («50 pies»). Son distinciones que nadie había buscado; surgieron porque el método podía proponer una hipótesis y ponerla a prueba de inmediato.
Implicaciones y mirar hacia adelante
La importancia de la GCT va mucho más allá de la neurociencia. Los investigadores se enfrentan cada vez más al mismo dilema: un modelo que predice de manera hermosa pero no explica nada. GCT muestra que un modelo basado en datos no tiene por qué ser el fin de la investigación; puede destilarse en una teoría legible y comprobable a nivel experimental, y esa teoría puede compararse con la realidad a través de la generación de nuevos experimentos bajo demanda.
En neurociencia en específico, GCT apunta a una forma más rápida y rica en hipótesis de mapear la corteza—una en la que un sistema de IA propone lo que una región cerebral podría codificar y un experimento en bucle cerrado lo confirma o rechaza dentro de un solo estudio. La misma filosofía de generar y verificar podría extenderse a otros ámbitos donde los potentes modelos predictivos han superado nuestra capacidad para entenderlos. La lección más amplia es esperanzadora: el auge de los modelos de caja negra en la ciencia no significa por necesidad el retroceso de la teoría legible para humanos. Con el marco adecuado, ambos pueden avanzar juntos.
Agradecimientos
Este trabajo fue una colaboración entre Microsoft Research, UC Berkeley (Alex Huth, Bin Yu, Sihang Guo y Aliyah Hsu), la Universidad de Columbia (RJ Antonello, co-líder) y UCSF (Shailee Jain). También agradecemos a los participantes del estudio y a la comunidad más amplia de neurociencia del lenguaje cuyas herramientas y conjuntos de datos hicieron posible esta investigación.
Lean el artículo: «Pruebas causales generativas para unir modelos basados en datos y teorías científicas en neurociencia del lenguaje», aceptado en Nature Neuroscience y el código en Github.
Amazon CloudWatch Logs now enriches log events with resource tags, making it easier to filter, search, and analyze logs by the metadata that matters most to your organization, such as team ownership, environment, cost center, or application name, without requiring changes to your logging instrumentation.
With tag enrichment, Amazon CloudWatch Logs adds resource tags directly to your log events at ingestion time. You can immediately use tags in log queries, to scope your analysis without building custom pipelines or manually adding context to your application logs. For example, you can quickly filter all logs from production resources owned by a specific team, or filter by cost center during an incident investigation.
Tag enrichment for logs is available in all commercial AWS Regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). To get started, enable resource tags on telemetry in the Amazon CloudWatch Settings, or through the AWS Command Line Interface (AWS CLI), and AWS SDKs to use your existing AWS resource tags to enrich your log events. Tag enrichment is available for no additional cost. Learn more on the Amazon CloudWatch documentation page.
Amazon CloudWatch Logs now enriches log events with resource tags, making it easier to filter, search, and analyze logs by the metadata that matters most to your organization, such as team ownership, environment, cost center, or application name, without requiring changes to your logging instrumentation.
With tag enrichment, Amazon CloudWatch Logs adds resource tags directly to your log events at ingestion time. You can immediately use tags in log queries, to scope your analysis without building custom pipelines or manually adding context to your application logs. For example, you can quickly filter all logs from production resources owned by a specific team, or filter by cost center during an incident investigation.
Tag enrichment for logs is available in all commercial AWS Regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). To get started, enable resource tags on telemetry in the Amazon CloudWatch Settings, or through the AWS Command Line Interface (AWS CLI), and AWS SDKs to use your existing AWS resource tags to enrich your log events. Tag enrichment is available for no additional cost. Learn more on the Amazon CloudWatch documentation page.
AWS CloudFormation and CDK express mode reduces deployment time by up to 4x for developers and AI agents building infrastructure, based on internal benchmarks. Express mode completes stack operations when CloudFormation confirms resource configuration is applied, rather than waiting for extended stabilization checks such as traffic readiness, region propagation, and resource cleanup. This enables faster iteration cycles for developers and AI agents building infrastructure.
When iterating on infrastructure in development environments, developers and AI agents need faster iteration cycles to build infrastructure incrementally. Previously, every deployment waited for full resource stabilization regardless of whether the workflow required it. For example, creating a CloudFront distribution required waiting 5-10 minutes for propagation to all edge locations before the deployment completed, even when the developer only needed the distribution domain name to continue. With express mode, deployments complete in seconds once configuration is applied, and propagation continues in the background. CloudFormation still processes resources in dependency order and handles dependent resource failures within the same stack. Express mode disables rollback by default, enabling immediate fix-and-retry without waiting for rollback operations.
To get started, set –deployment-config ‘{«mode»: «EXPRESS»}’ when creating, updating, and deleting stacks or creating a change set through the AWS CLI, AWS SDKs, or the AWS Management Console. For AWS CDK users, activate express mode with cdk deploy –express. No template changes are required. Express mode works with all existing CloudFormation templates, and nested stacks. Visit the CloudFormation Express mode documentation to learn more.
This feature is available in all AWS Regions where CloudFormation is supported. Refer to the AWS Region table for service availability details.
AWS CloudFormation and CDK express mode reduces deployment time by up to 4x for developers and AI agents building infrastructure, based on internal benchmarks. Express mode completes stack operations when CloudFormation confirms resource configuration is applied, rather than waiting for extended stabilization checks such as traffic readiness, region propagation, and resource cleanup. This enables faster iteration cycles for developers and AI agents building infrastructure. When iterating on infrastructure in development environments, developers and AI agents need faster iteration cycles to build infrastructure incrementally. Previously, every deployment waited for full resource stabilization regardless of whether the workflow required it. For example, creating a CloudFront distribution required waiting 5-10 minutes for propagation to all edge locations before the deployment completed, even when the developer only needed the distribution domain name to continue. With express mode, deployments complete in seconds once configuration is applied, and propagation continues in the background. CloudFormation still processes resources in dependency order and handles dependent resource failures within the same stack. Express mode disables rollback by default, enabling immediate fix-and-retry without waiting for rollback operations. To get started, set –deployment-config ‘{«mode»: «EXPRESS»}’ when creating, updating, and deleting stacks or creating a change set through the AWS CLI, AWS SDKs, or the AWS Management Console. For AWS CDK users, activate express mode with cdk deploy –express. No template changes are required. Express mode works with all existing CloudFormation templates, and nested stacks. Visit the CloudFormation Express mode documentation to learn more. This feature is available in all AWS Regions where CloudFormation is supported. Refer to the AWS Region table for service availability details.
