AWS Copilot CLI desplegando contenedores sin pelear con ECS

ECS es poderoso pero configurarlo desde la consola o con CloudFormation directo es tedioso. Copilot CLI es la capa de abstracción que siempre debió existir.

Instalación

brew install aws/tap/copilot-cli
copilot --version

El modelo mental

Copilot organiza las cosas en tres niveles:

1. Application: el proyecto completo.
2. Environment: staging, production, etc.
3. Service: cada servicio desplegable.

Arrancar un proyecto

Si ya tienes un Dockerfile:

copilot init

Te va a preguntar qué tipo de servicio quieres:

• Request-Driven Web Service (App Runner).
• Load Balanced Web Service (ALB + Fargate).
• Backend Service (Fargate sin ALB).
• Worker Service (Fargate consumiendo SQS).
• Scheduled Job (tareas cron).

Lo que pasa por debajo

Copilot genera un manifest.yml por servicio:

name: api
type: Load Balanced Web Service

image:
  build: Dockerfile
  port: 3000

http:
  path: '/'
  healthcheck: '/health'

cpu: 256
memory: 512
count: 2

Y cuando haces copilot deploy, traduce ese manifest a CloudFormation y lo aplica. Puedes ver el CloudFormation generado con copilot svc package.

Múltiples ambientes

copilot env init --name staging
copilot env init --name production
copilot deploy --env production

Cada env es una VPC distinta, con sus propios recursos. Puedes compartir recursos entre ambientes si quieres, pero por defecto están aislados.

Cuándo no usar Copilot

Si tu infraestructura tiene mucho más que contenedores (Lambdas, EventBridge, Step Functions, etc.), mejor usa CDK. Copilot brilla cuando el 80% de tu workload son servicios containerizados.

Cierre

Copilot te ahorra escribir cientos de líneas de CloudFormation para algo que al final siempre es lo mismo: un contenedor en Fargate detrás de un ALB con autoscaling.