Contenedores a escala: escalado, híbridos y multiclúster

Correr un servicio en contenedores ya lo sabes hacer. El problema llega con la primera campaña: el tráfico se multiplica y alguien tiene que decidir cuántas copias corren y en cuántos servidores caben. Más adelante llegan otras preguntas: correr lo mismo en la planta de producción, o tener un segundo clúster listo en otra región.

Dos capas de escalado

Criterio	Amazon ECS	Amazon EKS
Más copias de la app	Service Auto Scaling (Application Auto Scaling) cambia el número deseado de tareas	Horizontal Pod Autoscaler (HPA) cambia el número de réplicas
Más servidores	Capacity provider con un grupo de Auto Scaling y managed scaling	Cluster Autoscaler o Karpenter
Que AWS maneje los servidores	Fargate o ECS Managed Instances	Fargate o EKS Auto Mode

Con Fargate, la segunda capa desaparece: cada tarea o pod recibe su propia capacidad. Con EC2, necesitas las dos capas conectadas. La base de todo esto está en contenedores y en Auto Scaling.

ECS: escalar el servicio y la capacidad

Service Auto Scaling usa Application Auto Scaling, el mismo motor que escala tablas de DynamoDB o réplicas de Aurora. Admite las mismas políticas que ya conoces: target tracking (por ejemplo, CPU promedio del servicio en 60 % o peticiones por destino del ALB), por pasos, programada y predictiva. Para trabajadores que leen de una cola, escala con una métrica propia de mensajes pendientes por tarea.

Los capacity providers deciden dónde se ubican las tareas. Hay tres tipos, y una estrategia solo puede mezclar proveedores del mismo tipo:

• 

  FARGATE y FARGATE_SPOT

  Sin servidores. Fargate Spot usa capacidad sobrante con descuento y puede interrumpir la tarea con dos minutos de aviso (una señal SIGTERM).
• 

  Grupo de Auto Scaling

  Con managed scaling, ECS crea una política de target tracking sobre la métrica CapacityProviderReservation y agrega o quita instancias según lo que piden las tareas.
• 

  ECS Managed Instances

  Instancias EC2 que AWS elige, parcha y reemplaza por ti. Sirve cuando necesitas GPU o un tipo de instancia específico sin operar el grupo.

La estrategia reparte las tareas con dos números: base (cuántas van primero a un proveedor) y weight (la proporción del resto). Este ejemplo deja dos tareas fijas en Fargate y reparte las demás tres a uno hacia Fargate Spot:

"capacityProviderStrategy": [
  { "capacityProvider": "FARGATE",      "base": 2, "weight": 1 },
  { "capacityProvider": "FARGATE_SPOT", "base": 0, "weight": 3 }
]

EKS: pods, nodos y quién los maneja

1. 1

   Horizontal Pod Autoscaler

   Mira la CPU, la memoria o una métrica propia y sube o baja las réplicas de un Deployment. Solo crea pods; no crea servidores.
2. 2

   Pods en Pending

   Si los pods nuevos no caben en ningún nodo, Kubernetes los deja en espera. Esa es la señal para la segunda capa.
3. 3

   Cluster Autoscaler

   Ajusta la capacidad deseada de grupos de Auto Scaling (los managed node groups). Cada grupo tiene tipos de instancia fijos.
4. 4

   Karpenter

   Lee qué necesitan los pods pendientes y lanza directo la instancia EC2 del tamaño justo, en menos de un minuto. También consolida: mueve pods y apaga nodos que sobran. Es código abierto y lo operas tú.
5. 5

   EKS Auto Mode

   AWS opera Karpenter por ti, junto con los balanceadores, el almacenamiento en bloque y la red de los pods. Los nodos son inmutables y se reemplazan como máximo a los 21 días.

Contenedores fuera de la región

Hay cargas que no pueden irse a la nube: latencia con máquinas de planta, datos que la ley obliga a dejar en el país, o hardware que ya pagaste. Las opciones se distinguen por dónde vive el plano de control y qué pasa si se cae el enlace.

• 

  Amazon ECS Anywhere

  Las grúas de AWS manejando contenedores en tu propia bodega.
• 

  Amazon EKS Anywhere

  Tu propio puerto, con el mismo manual de operación que usa AWS.
• 

  AWS Outposts

  AWS instala un pedazo del puerto dentro de tu bodega. Más en otras opciones de cómputo.

Varios clústeres para alta disponibilidad y DR

Un clúster de EKS o ECS ya reparte nodos en varias zonas de disponibilidad. Para sobrevivir a la falla de una región, o a un error que rompa el clúster entero, necesitas un segundo clúster. El patrón más común:

1. 1

   Dos regiones, dos clústeres

   Uno activo y otro pasivo con capacidad mínima (pilot light o warm standby), o ambos activos detrás de Route 53 o Global Accelerator.
2. 2

   El mismo estado deseado en los dos

   Con GitOps (Argo CD o Flux), el repositorio es la verdad y cada clúster se sincroniza solo. Nadie aplica cambios a mano en uno y olvida el otro.
3. 3

   Imágenes en las dos regiones

   La replicación de ECR copia cada imagen nueva a otra región o cuenta. Solo replica lo que se sube después de configurarla, y no copia las lifecycle policies.
4. 4

   Los datos, por separado

   Los contenedores son fáciles de recrear; los datos no. Aurora Global Database, DynamoDB global tables o la replicación de S3 definen tu RPO real. Detalle en replicación y consistencia.
5. 5

   El cambio de región, ensayado

   Un runbook y un simulacro. Sin eso, el clúster pasivo es una suposición. Ver failover y failback.

ECR también cuida la cadena de suministro: el escaneo básico revisa vulnerabilidades al subir la imagen y el escaneo mejorado, con Amazon Inspector, sigue revisando de forma continua. Las lifecycle policies borran imágenes viejas por antigüedad o por cantidad para que el registro no crezca sin control.

Ver qué pasa: Container Insights

CloudWatch Container Insights recoge métricas y logs de ECS, EKS (también sobre Fargate) y Kubernetes en EC2. La versión con enhanced observability baja hasta el nivel de cada contenedor. En ECS es la que AWS recomienda y se activa con la configuración de cuenta o de clúster containerInsights=enhanced. En EKS se instala con el complemento Amazon CloudWatch Observability, y también hay una variante basada en OpenTelemetry. Así ves qué servicio consume, qué pod se reinicia y en qué nodo. Para una vista de varias cuentas, sigue con observabilidad a escala.