Amazon SageMaker Unified Studio now supports automatic creation of connections for Glue job retries across subnets to improve data pipeline resilience. This helps organizations running business-critical data pipelines reduce unplanned downtime and meet their SLAs — without requiring engineers to manually configure backup connectors or intervene during subnet failures.

With this launch, SageMaker Unified Studio automates the provisioning of Glue connectors across subnets defined in the domain VPC configuration. Administrators can define their domain VPC with multiple private subnets across availability zones, and the system provisions the connectors needed for all new projects so that failed jobs can be retried on an alternate subnet automatically. If a Glue job fails because the primary subnet is unavailable due to IP address exhaustion or availability zone degradation, the job can be retried on a connector in a different subnet. No user action is needed beyond the initial VPC configuration on the domain.

This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the Amazon SageMaker Unified Studio documentation. 

​Amazon SageMaker Unified Studio now supports automatic creation of connections for Glue job retries across subnets to improve data pipeline resilience. This helps organizations running business-critical data pipelines reduce unplanned downtime and meet their SLAs — without requiring engineers to manually configure backup connectors or intervene during subnet failures.
With this launch, SageMaker Unified Studio automates the provisioning of Glue connectors across subnets defined in the domain VPC configuration. Administrators can define their domain VPC with multiple private subnets across availability zones, and the system provisions the connectors needed for all new projects so that failed jobs can be retried on an alternate subnet automatically. If a Glue job fails because the primary subnet is unavailable due to IP address exhaustion or availability zone degradation, the job can be retried on a connector in a different subnet. No user action is needed beyond the initial VPC configuration on the domain.
This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the Amazon SageMaker Unified Studio documentation.   

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i-flex, M7i-flex and M7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in Asia Pacific (Hyderabad) region. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers.

C7i-flex and M7i-flex instances are the easiest way for you to get price-performance benefits for a majority of general-purpose workloads. They deliver up to 19% better price-performance compared to C6i and M6i  instances respectively. These instances offer the most common sizes, from large to 16xlarge, and are a great first choice for applications that don’t fully utilize all compute resources such as web and application servers, virtual-desktops, batch-processing, and microservices. 

M7i deliver up to 15% better price-performance compared to M6i. M7i instances are a great choice for workloads that need the largest instance sizes or continuous high CPU usage, such as gaming servers, CPU-based machine learning (ML), and video-streaming. M7i offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads.

To learn more, visit the EC2  C7i-flex and M7i/M7i-flex instances pages.

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i-flex, M7i-flex and M7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in Asia Pacific (Hyderabad) region. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers. C7i-flex and M7i-flex instances are the easiest way for you to get price-performance benefits for a majority of general-purpose workloads. They deliver up to 19% better price-performance compared to C6i and M6i  instances respectively. These instances offer the most common sizes, from large to 16xlarge, and are a great first choice for applications that don’t fully utilize all compute resources such as web and application servers, virtual-desktops, batch-processing, and microservices. 
 
M7i deliver up to 15% better price-performance compared to M6i. M7i instances are a great choice for workloads that need the largest instance sizes or continuous high CPU usage, such as gaming servers, CPU-based machine learning (ML), and video-streaming. M7i offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads. To learn more, visit the EC2  C7i-flex and M7i/M7i-flex instances pages.  

Amazon SageMaker Inference now supports OpenAI-compatible APIs, so you can use the tools and frameworks you already know, like the OpenAI SDK, LangChain, and Strands Agents, to connect directly to your SageMaker endpoints. Switching requires nothing more than changing an endpoint URL — no custom integration code, no SDK wrappers, no rewrites.

With this launch, you no longer need to adopt a different API format or change your authentication approach. Simply change your endpoint URL, and your existing SDK calls, streaming logic, and framework integrations continue to work as-is. You immediately gain the ability to choose your own GPU instances, keep data in your own VPC, run any open source or fine-tuned model, and scale with auto-scaling policies tuned to your workload. Authentication uses existing AWS credentials with automatic token refresh, so there is nothing extra to manage in production.

This capability is available today in US East (N. Virginia), US West (Oregon), US East (Ohio), Asia Pacific (Mumbai), Asia Pacific (Jakarta), Europe (Ireland), Europe (Frankfurt), South America (São Paulo), Asia Pacific (Tokyo), Asia Pacific (Seoul), Europe (London), Asia Pacific (Singapore), Asia Pacific (Sydney), and Canada (Central). To learn more and get started, read the launch blog or visit the SageMaker Inference documentation.

​Amazon SageMaker Inference now supports OpenAI-compatible APIs, so you can use the tools and frameworks you already know, like the OpenAI SDK, LangChain, and Strands Agents, to connect directly to your SageMaker endpoints. Switching requires nothing more than changing an endpoint URL — no custom integration code, no SDK wrappers, no rewrites. With this launch, you no longer need to adopt a different API format or change your authentication approach. Simply change your endpoint URL, and your existing SDK calls, streaming logic, and framework integrations continue to work as-is. You immediately gain the ability to choose your own GPU instances, keep data in your own VPC, run any open source or fine-tuned model, and scale with auto-scaling policies tuned to your workload. Authentication uses existing AWS credentials with automatic token refresh, so there is nothing extra to manage in production. This capability is available today in US East (N. Virginia), US West (Oregon), US East (Ohio), Asia Pacific (Mumbai), Asia Pacific (Jakarta), Europe (Ireland), Europe (Frankfurt), South America (São Paulo), Asia Pacific (Tokyo), Asia Pacific (Seoul), Europe (London), Asia Pacific (Singapore), Asia Pacific (Sydney), and Canada (Central). To learn more and get started, read the launch blog or visit the SageMaker Inference documentation.  

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

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

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

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

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

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

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

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

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

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

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

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

• Categoría: Noticias de Microsoft

mayo 21, 2026

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

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

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

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

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

El usuario ha cambiado—y eso lo cambia todo

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

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

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

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

El software se rediseña para agentes en tres capas

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

Qué significa esto para el software que ya poseen

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

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

Qué significa esto para su organización

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

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

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

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

Etiquetas:

• IA
• Vida y Trabajo

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

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

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

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

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

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

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

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

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

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

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

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