AWS announces the AWS Serverless Application Model (SAM) Kiro power, bringing serverless application development expertise to agentic AI development in Kiro. With this power, you can build, deploy, and manage serverless applications with AI agent-assisted development directly in your local environment.
SAM is an open-source framework that simplifies building serverless applications on AWS. SAM Kiro power dynamically loads relevant guidance and development expertise the AI agent needs to build serverless applications. This includes initializing SAM projects, building and deploying applications to AWS, and locally testing Lambda functions. The power supports event-driven patterns with Amazon EventBridge, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon DynamoDB Streams, and Amazon Simple Queue Service (SQS), while covering security best practices for IAM policies. Built-in guidance enforces use of SAM resources and Powertools for AWS Lambda for observability and structured logging by default, ensuring best practices from the start. This guidance accelerates your journey from concept to production, whether building static websites with API backends, event-driven microservices, or full-stack applications.
The SAM Kiro Power is available today with one-click installation from the Kiro IDE and the Kiro Powers page. Explore the power on Github or visit the developer guide to learn more about SAM.
AWS announces the AWS Serverless Application Model (SAM) Kiro power, bringing serverless application development expertise to agentic AI development in Kiro. With this power, you can build, deploy, and manage serverless applications with AI agent-assisted development directly in your local environment.
SAM is an open-source framework that simplifies building serverless applications on AWS. SAM Kiro power dynamically loads relevant guidance and development expertise the AI agent needs to build serverless applications. This includes initializing SAM projects, building and deploying applications to AWS, and locally testing Lambda functions. The power supports event-driven patterns with Amazon EventBridge, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon DynamoDB Streams, and Amazon Simple Queue Service (SQS), while covering security best practices for IAM policies. Built-in guidance enforces use of SAM resources and Powertools for AWS Lambda for observability and structured logging by default, ensuring best practices from the start. This guidance accelerates your journey from concept to production, whether building static websites with API backends, event-driven microservices, or full-stack applications.
The SAM Kiro Power is available today with one-click installation from the Kiro IDE and the Kiro Powers page. Explore the power on Github or visit the developer guide to learn more about SAM.
Graviton M7g instances for Standard brokers deliver up to 24% compute cost savings and up to 29% higher write and read throughput over comparable MSK clusters running on M5 instances. To get started, create a new cluster with M7g brokers or upgrade your M5 cluster to M7g through the Amazon MSK console or the Amazon CLI and read our Amazon MSK Developer Guide for more information.
You can now create provisioned Amazon Managed Streaming for Apache Kafka (Amazon MSK) clusters with Standard brokers running on AWS Graviton3-based M7g instances in Africa (Cape Town) region.
Graviton M7g instances for Standard brokers deliver up to 24% compute cost savings and up to 29% higher write and read throughput over comparable MSK clusters running on M5 instances. To get started, create a new cluster with M7g brokers or upgrade your M5 cluster to M7g through the Amazon MSK console or the Amazon CLI and read our Amazon MSK Developer Guide for more information.
AWS Lambda Managed Instances now supports Rust, enabling developers to run high-performance Rust-based functions on Lambda-managed Amazon EC2 instances while maintaining Lambda’s operational simplicity. This combination makes it easier than ever to run performance-critical applications without the complexity of managing servers.
Lambda Managed Instances gives Lambda developers access to specialized compute configurations, including the latest-generation processors and high-bandwidth networking. Lambda Managed Instances are fully managed EC2 instances, with built-in routing, load-balancing and auto-scaling, with no operational overhead. They combine Lambda’s serverless experience with EC2 pricing advantages including Compute Savings Plans and Reserved Instances. Rust support for Lambda Managed Instances combines these benefits with the performance and efficiency of Rust, including parallel request processing within each execution environment. Together, using Lambda Managed Instances with Rust maximizes utilization and price-performance.
Rust support for Lambda Managed Instances is available today in all AWS Regions where Lambda Managed Instances is available.
To get started with Rust on Lambda Managed Instances, see the Lambda documentation. To learn more about more about this release, see the release notes.
AWS Lambda Managed Instances now supports Rust, enabling developers to run high-performance Rust-based functions on Lambda-managed Amazon EC2 instances while maintaining Lambda’s operational simplicity. This combination makes it easier than ever to run performance-critical applications without the complexity of managing servers. Lambda Managed Instances gives Lambda developers access to specialized compute configurations, including the latest-generation processors and high-bandwidth networking. Lambda Managed Instances are fully managed EC2 instances, with built-in routing, load-balancing and auto-scaling, with no operational overhead. They combine Lambda’s serverless experience with EC2 pricing advantages including Compute Savings Plans and Reserved Instances. Rust support for Lambda Managed Instances combines these benefits with the performance and efficiency of Rust, including parallel request processing within each execution environment. Together, using Lambda Managed Instances with Rust maximizes utilization and price-performance. Rust support for Lambda Managed Instances is available today in all AWS Regions where Lambda Managed Instances is available. To get started with Rust on Lambda Managed Instances, see the Lambda documentation. To learn more about more about this release, see the release notes.
Starting today, AWS Network Firewall is available in the AWS European Sovereign Cloud. With this launch, European customers, particularly those in highly regulated industries, government agencies, and organizations with strict data sovereignty requirements, can deploy AWS Network Firewall to protect their most sensitive workloads while maintaining full compliance with European Union (EU) data protection regulations.
Through this expansion, customers using the AWS European Sovereign Cloud can leverage the same AWS Network Firewall capabilities available in other AWS Regions, while ensuring that all data and operations remain entirely within EU borders and under EU-based control. AWS Network Firewall is a managed firewall service that provides essential network protections for your Amazon Virtual Private Clouds (VPCs). The service automatically scales with network traffic volume to provide high-availability protections without the need to set up or maintain the underlying infrastructure.
To learn more about AWS Network Firewall availability, visit the AWS Region Table. For more information, please see the AWS Network Firewall product page and the service documentation.
Starting today, AWS Network Firewall is available in the AWS European Sovereign Cloud. With this launch, European customers, particularly those in highly regulated industries, government agencies, and organizations with strict data sovereignty requirements, can deploy AWS Network Firewall to protect their most sensitive workloads while maintaining full compliance with European Union (EU) data protection regulations. Through this expansion, customers using the AWS European Sovereign Cloud can leverage the same AWS Network Firewall capabilities available in other AWS Regions, while ensuring that all data and operations remain entirely within EU borders and under EU-based control. AWS Network Firewall is a managed firewall service that provides essential network protections for your Amazon Virtual Private Clouds (VPCs). The service automatically scales with network traffic volume to provide high-availability protections without the need to set up or maintain the underlying infrastructure. To learn more about AWS Network Firewall availability, visit the AWS Region Table. For more information, please see the AWS Network Firewall product page and the service documentation.
IA en el trabajo: Desde «mejores respuestas» hasta resultados empresariales reales
Las organizaciones están inundadas de experimentación con IA, pero la creación de valor se retrasa. El cuello de botella rara vez es la capacidad de la tecnología, sino cómo se coordina el trabajo.
Por: Jared Spataro, Director Médico de la IA en el Trabajo de Microsoft
Durante el último mes, hemos visto cómo las herramientas de codificación con IA empiezan a asumir tareas de desarrollo en varios pasos de principio a fin. GitHub Copilot ahora puede diseñar funcionalidades, sugerir correcciones, ejecutar pruebas e iterar sobre el código dentro del flujo de trabajo de los desarrolladores. Claude Code de Anthropic ha demostrado una ejecución similar en varios pasos—planificar cambios, escribir y revisar código, y validar resultados—mientras los humanos supervisan o incluso duermen. Y OpenAI describió su nuevo Codex GPT-5.3 como «fundamental para crearse a sí mismo.»
Mientras tanto, la mayoría de las empresas utilizan modelos como herramientas para responder preguntas. Esa brecha—entre lo que los modelos son capaces de hacer ahora y cómo se utilizan en verdad en el trabajo—crece con rapidez.
La siguiente fase de la IA es un cambio de modelos independientes a sistemas de trabajo agénticos. En 2026, la IA planificará, actuará, verificará, revisará y cumplirá cada vez más. Hasta ahora, el mayor reto para llevar la IA al trabajo ha sido tan solo conseguir que la gente la utilice. De cara al futuro, se convierte en una cuestión operativa: cómo estructurar, coordinar y gobernar el trabajo cuando las tareas y procesos completos de extremo a extremo se ejecutan de manera autónoma por agentes. La calidad del modelo va a importar, pero lo que más importará es asegurar que esos modelos existan dentro de un sistema diseñado para ofrecer resultados de alta calidad de manera consistente, segura y a gran escala.
Ya hemos comenzado a incorporar estas capacidades a Microsoft Copilot—ampliándola de la asistencia en tareas a la ejecución coordinada dentro de las herramientas que la gente utiliza a diario.
Los planificadores y los trabajadores hacen el trabajo
Un sistema de trabajo agéntico es una serie de agentes, apoyados por herramientas, configurados para colaborar y completar tareas. A un nivel básico, estos sistemas tienen dos roles: planificadores y trabajadores. Un bucle externo de agentes planificadores toma un objetivo, lo divide en pasos y asigna esos pasos a agentes de trabajo o herramientas deterministas—como una base de datos o una calculadora—para completar una tarea. Un bucle interno de agentes trabajadores ejecuta esos pasos—escribir código, analizar datos, tomar acciones—a través de herramientas donde la precisión y la repetibilidad importan. Los agentes planificadores luego revisan el progreso y deciden qué ocurre después.
Esta estructura es más o menos sencilla, pero crucial porque permite a los sistemas de IA mantenerse orientados a lo largo del tiempo para planificar, ejecutar, revisar su trabajo y recuperarse cuando algo falla. Pueden ver elementos de esto hoy en GitHub Copilot. Un desarrollador puede describir un cambio, hacer que Copilot genere la implementación, ejecutar pruebas, responder a fallos e iterar, todo dentro del entorno de desarrollo. Estas herramientas son todavía guiadas por humanos, pero muestran cómo la ejecución en varios pasos se integra de manera directa en los flujos de trabajo. Claude Code ha demostrado una ejecución similar en varios pasos fuera del IDE, lo que deja en claro hacia dónde se dirige esto.
Los sistemas de trabajo en verdad agénticos permitirán que funciones enteras pasen de la asistencia tarea por tarea a la ejecución de extremo a extremo, desde marketing y finanzas hasta operaciones y atención al cliente.
Desde asistentes hasta sistemas de trabajo agénticos
Los agentes planificadores y trabajadores coordinan para pasar del objetivo al resultado—a través de ejecutar tareas de extremo a extremo sin que los humanos orquesten cada paso.
De la experiencia a la ejecución
El verdadero desbloqueo de un sistema de trabajo agéntico es la capacidad de pasar de un objetivo a otro sin que los humanos coordinen cada paso. Eso es lo que eleva la IA de asistente a capa operativa.
Este cambio deja claro el problema que la mayoría de las organizaciones han encontrado. La IA no se estanca porque los modelos no puedan hacer más. Está estancado porque el trabajo sigue diseñado en torno a que los humanos tomen todas las decisiones. Como resultado, los líderes ven mucha actividad—borradores, pilotos, experimentos—pero muy poco progreso que se acumule.
Hasta que cambien los flujos de trabajo, el progreso se mantendrá incremental, sin importar lo capaz que se vuelva la tecnología.
En la práctica, un sistema de trabajo se comporta menos como una sola herramienta y más como un equipo bien gestionado: un objetivo entra en el sistema. Una capa coordinadora lo traduce en pasos, enruta cada paso al agente correspondiente, evalúa los resultados según criterios definidos y determina qué debe ocurrir a continuación. Si algo falla, el sistema intenta, escala o solicita la intervención humana. Cuando algo funciona, el sistema captura lo aprendido—enfoques exitosos, señales útiles, casos límite resueltos—y utiliza ese contexto para informar la siguiente ejecución.
Esta es la dirección hacia la que Copilot evoluciona: desde la asistencia en tareas aisladas hasta la ejecución coordinada entre flujos de trabajo.
Lo que todo esto significa para los líderes
Pasamos de modelos quesaben a sistemas que ejecutan—una categoría de cambio diferente. Es una nueva configuración de cómo se realiza el trabajo.
La mayoría de los líderes no empiezan con un mapa claro de sus flujos de trabajo. Eso es normal. El trabajo se ha acumulado a lo largo de los años entre equipos, herramientas y entregas que nadie posee por completo. El punto de partida práctico no es rediseñarlo todo, sino empezar con un resultado recurrente y rastrear cómo se hace en verdad. Ya sea al lanzar una campaña, cerrar un ticket o lanzar una función, hagan preguntas:
¿Dónde se retrasa el trabajo?
¿Dónde intervienen los humanos solo para hacer avanzar las cosas?
¿Dónde se estanca el progreso porque la coordinación del flujo de trabajo vive en la cabeza de las personas?
Los sistemas de trabajo agénticos importan porque hacen visibles esos puntos débiles para su rediseño. Ofrecen a los líderes una forma de pasar de experimentos de IA aislados a mecanismos operativos que pueden llevar el trabajo hacia adelante. Así es como este cambio se vuelve accionable: un flujo de trabajo a la vez.
Para más información sobre la IA y el futuro del trabajo, suscríbanse a este boletín.
The Landing Zone Accelerator on AWS (LZA) Model Context Protocol (MCP) Server is now open source, enabling organizations to manage LZA deployments through natural language conversations with AI assistants.
Using the new LZA MCP Server, you can streamline configuration tasks that previously required time-intenstive manual work. The LZA MCP Server provides 20 specialized tools that help you search documentation across multiple LZA versions, manage configurations, monitor pipelines, and surface actionable insights when deployment failures occur.
The server operates as a containerized MCP endpoint compatible with IDEs including Kiro, Amazon Q Developer, and Claude Code, using temporary credentials following AWS security best practices.
The LZA MCP Server is open source and available now. Visit the AWS Labs GitHub repository to view the source, download, and get started. The LZA MCP Server is available in all commercial AWS Regions and AWS GovCloud (US) Regions where Landing Zone Accelerator is supported.
The Landing Zone Accelerator on AWS (LZA) Model Context Protocol (MCP) Server is now open source, enabling organizations to manage LZA deployments through natural language conversations with AI assistants. Using the new LZA MCP Server, you can streamline configuration tasks that previously required time-intenstive manual work. The LZA MCP Server provides 20 specialized tools that help you search documentation across multiple LZA versions, manage configurations, monitor pipelines, and surface actionable insights when deployment failures occur. The server operates as a containerized MCP endpoint compatible with IDEs including Kiro, Amazon Q Developer, and Claude Code, using temporary credentials following AWS security best practices. The LZA MCP Server is open source and available now. Visit the AWS Labs GitHub repository to view the source, download, and get started. The LZA MCP Server is available in all commercial AWS Regions and AWS GovCloud (US) Regions where Landing Zone Accelerator is supported.
Amazon OpenSearch Service now supports cross-account data access, enabling users to access OpenSearch domains hosted in different AWS accounts from within a single OpenSearch UI application. With this feature, you can query or build dashboard with data from OpenSearch domains across different accounts in the same region – without switching to a new endpoint or replicating data. Cross-account data access is available for OpenSearch domains hosted in both public and Virtual Private Cloud (VPC) configurations.
With cross-account data access, teams no longer need to consolidate data into a single account or maintain costly data pipelines to enable unified analysis across organizational boundaries. This makes it easier to build centralized observability, search, and security analytics workflows that span multiple AWS accounts while keeping data in place and maintaining each account’s access controls. Cross-account data access supports both IAM (including SAML via IAM federation) and IAM Identity Center (IdC) for end user authentication.
Cross-account data access to OpenSearch domains is available in all AWS Regions where OpenSearch UI is available. To learn more, see Cross-account data access to OpenSearch domains in the Amazon OpenSearch Service Developer Guide.
Amazon OpenSearch Service now supports cross-account data access, enabling users to access OpenSearch domains hosted in different AWS accounts from within a single OpenSearch UI application. With this feature, you can query or build dashboard with data from OpenSearch domains across different accounts in the same region – without switching to a new endpoint or replicating data. Cross-account data access is available for OpenSearch domains hosted in both public and Virtual Private Cloud (VPC) configurations. With cross-account data access, teams no longer need to consolidate data into a single account or maintain costly data pipelines to enable unified analysis across organizational boundaries. This makes it easier to build centralized observability, search, and security analytics workflows that span multiple AWS accounts while keeping data in place and maintaining each account’s access controls. Cross-account data access supports both IAM (including SAML via IAM federation) and IAM Identity Center (IdC) for end user authentication. Cross-account data access to OpenSearch domains is available in all AWS Regions where OpenSearch UI is available. To learn more, see Cross-account data access to OpenSearch domains in the Amazon OpenSearch Service Developer Guide.
AWS announces the general availability of CDK Mixins, a new feature of the AWS Cloud Development Kit (CDK) that lets you add composable, reusable abstractions to any AWS construct, whether L1, L2, or custom, without rebuilding your existing infrastructure code. CDK Mixins are available through the aws-cdk-lib package and work across all construct types, giving you flexibility to apply the right abstractions where and when you need them.
Previously, teams had to choose between immediate access to new AWS features using L1 constructs or the convenience of higher-level abstractions with L2 constructs, often requiring significant rework to meet security, compliance, or operational requirements. CDK Mixins simplify the maintenance of custom construct libraries. CDK Mixins let you apply features like auto-delete, bucket encryption, versioning, and block public access directly to constructs using a simple .with() syntax, combine multiple Mixins into custom L2 constructs, and apply compliance policies across an entire scope. Developers can use Mixins.of() for advanced resource type or path-pattern filtering. Enterprise teams can now enforce reusable security and compliance policies across their infrastructure while maintaining day-one access to new AWS features.
CDK Mixins are available in all AWS regions where AWS CloudFormation is supported.
AWS announces the general availability of CDK Mixins, a new feature of the AWS Cloud Development Kit (CDK) that lets you add composable, reusable abstractions to any AWS construct, whether L1, L2, or custom, without rebuilding your existing infrastructure code. CDK Mixins are available through the aws-cdk-lib package and work across all construct types, giving you flexibility to apply the right abstractions where and when you need them. Previously, teams had to choose between immediate access to new AWS features using L1 constructs or the convenience of higher-level abstractions with L2 constructs, often requiring significant rework to meet security, compliance, or operational requirements. CDK Mixins simplify the maintenance of custom construct libraries. CDK Mixins let you apply features like auto-delete, bucket encryption, versioning, and block public access directly to constructs using a simple .with() syntax, combine multiple Mixins into custom L2 constructs, and apply compliance policies across an entire scope. Developers can use Mixins.of() for advanced resource type or path-pattern filtering. Enterprise teams can now enforce reusable security and compliance policies across their infrastructure while maintaining day-one access to new AWS features. CDK Mixins are available in all AWS regions where AWS CloudFormation is supported.
To get started with CDK Mixins, visit the AWS documentation.
Amazon Bedrock AgentCore Memory now supports streaming notifications for long-term memory, eliminating the need to poll for changes. Long-term memory extracts insights from agent interactions to deliver personalized experiences in future interactions. Developers now receive push notifications whenever memory records are created or modified.
Updates stream directly to Amazon Kinesis each time a memory record is created or modified. This enables developers to trigger downstream workflows, refresh application state, and audit memory updates automatically without writing polling logic or managing refresh intervals.
This feature is available in 15 AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul), Canada (Central), and South America (São Paulo).
To learn more about implementing streaming notifications in AgentCore Memory, visit the documentation.
Amazon Bedrock AgentCore Memory now supports streaming notifications for long-term memory, eliminating the need to poll for changes. Long-term memory extracts insights from agent interactions to deliver personalized experiences in future interactions. Developers now receive push notifications whenever memory records are created or modified. Updates stream directly to Amazon Kinesis each time a memory record is created or modified. This enables developers to trigger downstream workflows, refresh application state, and audit memory updates automatically without writing polling logic or managing refresh intervals.
This feature is available in 15 AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul), Canada (Central), and South America (São Paulo).
To learn more about implementing streaming notifications in AgentCore Memory, visit the documentation.
You can now create Amazon S3 general purpose buckets in your own reserved namespace, eliminating the need to find globally unique bucket names and making it easier to build workloads that utilize a bucket per customer, team, or dataset. With account regional namespaces, you can create predictable bucket names across multiple AWS Regions with assurance that the names you want will always be available for you to use.
Account regional namespaces help simplify bucket creation and management as your data storage needs grow in size and scope. To get started, add the new bucket namespace request header when creating buckets through the CreateBucket API or by updating your AWS CloudFormation templates to include your unique account regional suffix in the requested name. Additionally, cloud security teams can use service control policies (SCP) and IAM policies to enforce that users only create buckets in their account regional namespace, helping teams enforce consistent bucket naming practices across their enterprise.
Account regional namespaces for S3 general purpose buckets are now available in 37 AWS Regions including the AWS China and AWS GovCloud (US) Regions at no additional cost through the AWS Management Console, S3 REST API, AWS CLI, AWS SDK, and AWS CloudFormation. To learn more, read the AWS News Blog or visit the S3 user guide.
You can now create Amazon S3 general purpose buckets in your own reserved namespace, eliminating the need to find globally unique bucket names and making it easier to build workloads that utilize a bucket per customer, team, or dataset. With account regional namespaces, you can create predictable bucket names across multiple AWS Regions with assurance that the names you want will always be available for you to use. Account regional namespaces help simplify bucket creation and management as your data storage needs grow in size and scope. To get started, add the new bucket namespace request header when creating buckets through the CreateBucket API or by updating your AWS CloudFormation templates to include your unique account regional suffix in the requested name. Additionally, cloud security teams can use service control policies (SCP) and IAM policies to enforce that users only create buckets in their account regional namespace, helping teams enforce consistent bucket naming practices across their enterprise. Account regional namespaces for S3 general purpose buckets are now available in 37 AWS Regions including the AWS China and AWS GovCloud (US) Regions at no additional cost through the AWS Management Console, S3 REST API, AWS CLI, AWS SDK, and AWS CloudFormation. To learn more, read the AWS News Blog or visit the S3 user guide.
