Ya sabes crear imágenes de Docker (subcapítulo 17.1). Ahora surge una pregunta práctica: una vez construida tu imagen, ¿dónde la guardas para que tus servidores o servicios de AWS puedan usarla? La respuesta es un registro de imágenes, y el de AWS se llama ECR (Elastic Container Registry).

Construyes una imagen en tu ordenador. Pero para desplegarla en AWS (en ECS o EKS, que veremos a continuación), esos servicios necesitan descargarla de algún lugar accesible. No puedes ejecutar una imagen que solo está en tu portátil; tiene que estar en un sitio central del que todos puedan tirar.

Ese «sitio central» es un registro de imágenes.

Un registro de contenedores (container registry) es un almacén de imágenes de Docker. Subes (push) tus imágenes a él, y luego cualquier máquina o servicio autorizado las descarga (pull) para ejecutarlas.

Seguramente conozcas Docker Hub, el registro público más famoso. ECR es el equivalente de AWS, pensado para tus imágenes privadas.

Analogía: un registro de imágenes es como un almacén o biblioteca de plantillas. Guardas allí tus «moldes» (imágenes, recuerda la analogía del subcapítulo 17.1), etiquetados y ordenados, y cualquiera con permiso puede ir a coger el molde que necesita para producir sus galletas (contenedores).

ECR (Elastic Container Registry) es el registro de imágenes privado y gestionado de AWS. Sus características clave:

Tus imágenes son privadas por defecto: solo quien tú autorices (mediante IAM, Capítulo 7) puede subirlas o descargarlas. Esto es importante porque tus imágenes contienen tu código y tu propiedad intelectual; no quieres que estén expuestas al mundo.

El control de acceso usa IAM (Capítulo 7), igual que el resto de AWS. Defines con políticas quién puede hacer push (subir) y quién pull (descargar). Aplica el mínimo privilegio (subcapítulo 7.2): por ejemplo, que el sistema de CI/CD pueda subir imágenes y que ECS solo pueda descargarlas.

ECR se conecta de forma natural con los servicios que ejecutan contenedores en AWS (ECS y EKS, siguientes subcapítulos). Cuando despliegas una aplicación, esos servicios descargan la imagen directamente de ECR, sin configuración complicada y dentro de la red de AWS (rápido y seguro).

Como otros servicios gestionados que hemos visto, AWS se encarga de la infraestructura: disponibilidad, escalado del almacenamiento, etc. Tú solo subes y descargas imágenes.

El ciclo típico, que conecta el desarrollo con el despliegue:

Ejemplo del mundo real: un equipo desarrolla una API. Su sistema de CI/CD (Capítulo 22), cada vez que se aprueba un cambio, construye una imagen nueva de la API y la sube a ECR con una etiqueta de versión (ej. api:v2.3). Después, ECS descarga esa versión de ECR y la despliega. ECR es el «puente» entre el código que se construye y los contenedores que se ejecutan.

Dentro de ECR, organizas las imágenes en repositorios (uno por aplicación, normalmente) y cada imagen lleva una etiqueta (tag) que suele indicar la versión:

Las etiquetas te permiten tener varias versiones de la misma aplicación y elegir cuál desplegar. Esto es clave para poder volver a una versión anterior rápidamente si una nueva da problemas (rollback).

Apunte de costes: ECR cobra por el almacenamiento de las imágenes. Las imágenes viejas que ya no usas se acumulan, así que conviene configurar políticas de ciclo de vida (parecidas a las de S3, subcapítulo 5.3) que borren automáticamente las versiones antiguas y mantengan el coste bajo control.

• Una imagen construida hay que guardarla en un registro para que los servicios de AWS puedan descargarla y ejecutarla; no basta con tenerla en tu portátil.
• ECR (Elastic Container Registry) es el registro de imágenes privado y gestionado de AWS (el equivalente privado de Docker Hub).
• Es privado y seguro (control de acceso con IAM, mínimo privilegio) e integrado de forma natural con ECS y EKS, que descargan las imágenes de ahí.
• Flujo: construyes la imagen → la subes (push) a ECR → ECS/EKS la descarga (pull) y la ejecuta. Es el «puente» entre el desarrollo y el despliegue.
• Organizas las imágenes en repositorios con etiquetas (tags) de versión, lo que permite desplegar versiones concretas y hacer rollback. Usa políticas de ciclo de vida para borrar imágenes viejas y controlar costes.

En el siguiente subcapítulo veremos el servicio que ejecuta tus contenedores: ECS, con sus task definitions, services y la diferencia entre Fargate y EC2.