ECS con EBS nativo ya está en GovCloud (2026)
La integración de ECS con EBS en regiones GovCloud ya es oficial desde el 18 de mayo de 2026: Amazon ECS aprovisiona automáticamente un volumen EBS por tarea, lo monta en el contenedor y lo elimina al terminar la ejecución, sin que tengas que gestionar nada manualmente. Una brecha importante en entornos de gobierno federal de AWS finalmente cerrada.
En 30 segundos
- AWS anunció el 18 de mayo de 2026 soporte nativo de EBS en ECS para las regiones GovCloud (us-gov-west-1 y us-gov-east-1).
- ECS crea un volumen EBS nuevo por cada tarea, lo adjunta automáticamente y lo destruye al terminar, sin intervención manual.
- Soporta EC2, Fargate y ECS Managed Instances con configuración directa en la definición de tareas.
- Los volúmenes se pueden cifrar con KMS, tienen snapshots opcionales y se integran con Data Lifecycle Manager para retención.
- Ideal para cargas de trabajo ETL de gran volumen, transcodificación de medios e inferencia de ML donde EFS quedaba corto en rendimiento.
Qué es la integración nativa de ECS con Amazon EBS
La integración nativa de ECS con Amazon EBS es la capacidad de Amazon Elastic Container Service de aprovisionar, adjuntar y desmontar volúmenes de Amazon Elastic Block Store directamente desde la definición de tarea, sin que el operador tenga que gestionar el ciclo de vida del volumen por separado.
Antes de esto, si querías almacenamiento persistente de alto rendimiento en ECS, las opciones eran dos: gestionabas los volúmenes EBS vos mismo (con la complejidad operacional que eso implica) o usabas EFS, que es más simple de configurar pero tiene un perfil de rendimiento distinto. La integración nativa elimina esa carga operacional y lleva la experiencia a algo mucho más parecido a cómo funciona el almacenamiento en Kubernetes con PersistentVolumeClaims.
Según el anuncio oficial de AWS del 18 de mayo de 2026, esta capacidad ya estaba disponible en regiones comerciales y ahora llega a GovCloud, que tiene sus propias restricciones de compliance que hacen que cada funcionalidad tarde más en aparecer.
Por qué es importante en AWS GovCloud
GovCloud no es simplemente “AWS pero en otro centro de datos”. Las regiones us-gov-west-1 y us-gov-east-1 están diseñadas para cumplir con FedRAMP High, ITAR, DoD CC SRG y otros estándares federales de EE.UU. Eso significa que toda nueva funcionalidad pasa por un proceso de certificación adicional antes de estar disponible, y que hay capacidades que en regiones comerciales llegaron hace meses o años y en GovCloud todavía no están.
El almacenamiento de bloques de alto rendimiento era una de esas brechas. Las agencias que corrían cargas de trabajo de procesamiento intensivo en ECS dentro de GovCloud tenían que elegir entre EFS (que compartís entre tareas pero con menor throughput pico) o gestionar EBS manualmente, lo cual en un entorno de compliance estricto agrega complejidad de auditoría y más superficie de error operacional. En como explicamos en nuestra guía de CI/CD profundizamos sobre esto.
Ahora con la integración nativa, el volumen EBS queda bajo el control de ECS, con etiquetado automático y ciclo de vida auditado. Eso es exactamente lo que necesitás cuando el auditor te pregunta quién creó ese volumen, cuándo y para qué.
Características técnicas: configuración de volúmenes EBS
La configuración se hace directamente en la definición de tareas ECS. Podés especificar tipo de volumen (gp3, io2), IOPS, throughput, y si el volumen debe cifrarse con una clave KMS propia o la clave administrada por AWS.
Según la documentación oficial de Amazon ECS, los entornos soportados son EC2, Fargate y ECS Managed Instances. Ojo, hay diferencias entre ellos que importan (más sobre esto abajo).
Los volúmenes se pueden integrar con snapshots de EBS para backup y con Data Lifecycle Manager para definir políticas de retención automática. Para entornos GovCloud donde la retención de datos tiene requisitos regulatorios específicos, esto es clave.
Ciclo de vida de volúmenes: creación y eliminación automática
Acá viene lo importante: ECS crea un volumen EBS nuevo por cada tarea. No reutiliza volúmenes existentes de corridas anteriores.
El comportamiento por defecto es eliminación automática cuando la tarea termina. Si necesitás retener los datos, tenés que cambiar ese comportamiento explícitamente en la configuración. ¿Por qué esto importa? Porque si corrés una tarea ETL que procesa datos sensibles, querés asegurarte de que el volumen desaparece al terminar. Si en cambio necesitás los resultados, tenés que indicarlo o perder el trabajo. Cubrimos ese tema en detalle en especialmente en despliegues multi-región.
La lógica es razonable para cargas de trabajo stateless-por-diseño, pero puede generar sorpresas si arrancás sin leer la documentación (spoiler: pasa más seguido de lo que debería).
Casos de uso prácticos: ETL, transcodificación y ML
ETL con datasets grandes
Ponele que tenés un pipeline que descarga un dump de base de datos de 200GB, lo transforma y carga el resultado en S3. Con EFS, el throughput de lectura/escritura puede ser el cuello de botella. Con un volumen gp3 configurado a 3000 IOPS y 125 MB/s de throughput (o io2 si necesitás más), el procesamiento local dentro del contenedor va a ser consistente y predecible.
Transcodificación de medios
En agencias de defensa o comunicaciones que manejan archivos de video o audio, la transcodificación en contenedores necesita I/O de bloque de alta velocidad. EBS te da latencia de un solo dígito en milisegundos, que EFS no puede garantizar de la misma forma por su naturaleza de sistema de archivos distribuido.
Inferencia de machine learning
Los modelos grandes necesitan cargarse rápido al arrancar el contenedor. Si el modelo pesa varios GB y lo tenés en EFS, el tiempo de arranque puede ser un problema. Con EBS adjunto al contenedor, la carga es local y mucho más veloz. Para cargas de trabajo de inferencia en batch dentro de GovCloud, esto hace diferencia real.
EBS vs EFS en GovCloud: cuándo usar cada uno
| Característica | Amazon EBS (con ECS nativo) | Amazon EFS |
|---|---|---|
| Tipo de almacenamiento | Bloques (block storage) | Sistema de archivos (NFS) |
| Compartición entre tareas | No (un volumen por tarea) | Sí (múltiples tareas simultáneas) |
| Latencia | Un solo dígito en ms | Latencia variable (decenas de ms) |
| IOPS máximas | Hasta 256,000 (io2 Block Express) | Variable según modo de throughput |
| Gestión del ciclo de vida | Automática con ECS (nueva) | Automática, disponible hace más tiempo |
| Persistencia entre ejecuciones | Configurable (por defecto se borra) | Persistente por diseño |
| Disponibilidad en Fargate | Soportado (con limitaciones) | Soportado |
| Caso de uso ideal | I/O intensivo por tarea individual | Datos compartidos entre múltiples tareas |
La regla práctica: si cada tarea necesita su propio espacio de trabajo con alto rendimiento, EBS. Si varias tareas leen o escriben los mismos datos simultáneamente, EFS. No son opciones mutuamente excluyentes en una arquitectura, podés usar EBS para el procesamiento y EFS para los datos de entrada compartidos. Sobre eso hablamos en cuando necesitás ejecutar cargas localmente.
Sobre Fargate con EBS: soportado, pero con algunas limitaciones respecto a EC2 en cuanto a tipos de volumen disponibles. La documentación de ECS tiene los detalles específicos de qué soporta cada launch type.
Seguridad, compliance y consideraciones operacionales
ECS etiqueta automáticamente los volúmenes con AmazonECSCreated y AmazonECSManaged. Eso puede parecer un detalle menor, pero en GovCloud donde tenés que auditar el origen de cada recurso, tener ese etiquetado automático simplifica enormemente los informes de compliance.
El cifrado con KMS funciona con claves propias (CMK), lo que te permite cumplir con requisitos de gestión de claves de FedRAMP y similares. Los snapshots opcionales te dan capacidad de backup antes de la eliminación automática del volumen si el workload lo requiere.
Data Lifecycle Manager (DLM) se integra para gestionar la retención de snapshots con políticas automatizadas. Si tenés un requisito de retener evidencia de procesamiento durante 7 años (como en algunos contextos de auditoría federal), DLM es lo que te permite implementarlo sin procesos manuales.
Errores comunes al configurar EBS nativo en ECS
Asumir que el volumen persiste entre ejecuciones
El error más frecuente: arrancar con la suposición de que ECS va a reutilizar el volumen de la corrida anterior. No lo hace. Cada tarea nueva, volumen nuevo. Si necesitás persistencia entre ejecuciones, la solución correcta es escribir los resultados a S3 o RDS antes de que la tarea termine, o cambiar el comportamiento de eliminación y gestionar el ciclo de vida vos mismo.
Configurar gp2 en vez de gp3
gp2 es el tipo legacy. gp3 tiene mejor precio y rendimiento configurable de forma independiente (IOPS y throughput por separado). A menos que tengas alguna razón específica para gp2, usá gp3 por defecto. En GovCloud aplica exactamente igual que en regiones comerciales. Relacionado: en contextos con requisitos de conformidad.
Olvidar los permisos IAM para el ciclo de vida EBS
La integración nativa necesita que el rol de tarea tenga permisos para crear, adjuntar y eliminar volúmenes EBS. Si la tarea falla silenciosamente o el contenedor no puede arrancar, revisá los permisos IAM antes de cualquier otra cosa. El error en CloudWatch suele ser críptico y no siempre apunta directo a la causa.
Preguntas Frecuentes
¿Qué es la integración nativa de ECS con Amazon EBS?
Es la capacidad de Amazon ECS de aprovisionar y gestionar automáticamente volúmenes EBS para cada tarea, sin intervención manual del operador. ECS crea el volumen, lo monta en el contenedor al arrancar la tarea y lo elimina al terminar, con soporte para cifrado KMS, snapshots y configuración de IOPS y throughput directamente en la definición de tareas.
¿Cómo configurar volúmenes EBS en tareas de ECS?
La configuración se hace en la sección volumes de la definición de tarea ECS, especificando el tipo de volumen (gp3, io2), IOPS, throughput y opciones de cifrado. Además, el rol de ejecución de ECS necesita los permisos IAM correspondientes para gestionar el ciclo de vida del volumen. La documentación oficial de ECS tiene los ejemplos de JSON de definición de tarea completos.
¿Cuál es la diferencia entre EBS y EFS en GovCloud para contenedores?
EBS da un volumen de bloques de alto rendimiento exclusivo para una tarea (latencia de un solo dígito en ms, hasta 256,000 IOPS con io2), pero no se comparte entre tareas simultáneas. EFS es un sistema de archivos compartido que múltiples tareas pueden montar al mismo tiempo, útil cuando necesitás que varios contenedores lean o escriban el mismo conjunto de datos, aunque con mayor latencia y throughput variable.
¿Se pueden usar volúmenes EBS persistentes en Fargate?
Sí, Fargate soporta la integración nativa de EBS. Eso sí, hay limitaciones en los tipos de volumen disponibles respecto a EC2. El comportamiento de eliminación automática aplica igual: el volumen se destruye al terminar la tarea salvo que se configure lo contrario. Si necesitás persistencia entre ejecuciones en Fargate, la recomendación es exfiltrar los datos a S3 o a una base de datos antes de que la tarea finalice.
¿Para qué casos de uso necesito EBS en contenedores y no alcanza con EFS?
EBS es la opción correcta cuando la tarea necesita I/O intensivo y predecible: procesamiento ETL de datasets grandes, transcodificación de medios, carga de modelos de ML para inferencia, o cualquier carga de trabajo donde la latencia de disco sea crítica y el acceso sea exclusivo de esa tarea. Si en cambio varias tareas necesitan leer los mismos archivos de configuración o compartir un dataset de referencia, EFS sigue siendo la opción natural.
Conclusión
La llegada de la integración nativa de ECS con EBS a GovCloud cierra una brecha que venía limitando las cargas de trabajo de I/O intensivo en entornos de gobierno federal. Hasta ahora, quien necesitaba ese nivel de rendimiento en GovCloud tenía que gestionar el ciclo de vida de EBS por fuera de ECS, con todo lo que eso implica en complejidad operacional y auditoría.
Ahora el flujo es limpio: definís el volumen en la tarea, ECS lo aprovisiona, lo monta, y al terminar lo destruye. Si trabajás con cargas de trabajo ETL, ML o transcodificación dentro de GovCloud, esta es la funcionalidad que te cambia la operación real. El etiquetado automático y la integración con KMS y DLM además simplifican la parte de compliance, que en entornos federales suele ser tan importante como la funcionalidad técnica.
Si armás infraestructura en donweb.com y después necesitás migrar cargas a AWS GovCloud, esta integración es un punto de planificación que vale tener en el radar desde el diseño inicial.
