Introducción
Equipos que administran portfolios de diez, veinte o más aplicaciones internas enfrentan un dilema recurrente en AWS: operar un clúster EKS propio por aplicación escala en costos de control plane y horas de ingeniería SRE, pero consolidar todo en un solo clúster multiplica los riesgos de aislamiento de red, conflictos de recursos y acoplamiento en los ciclos de actualización. AWS introdujo Cluster Mode en Elastic Beanstalk el 23 de septiembre de 2026 para resolver ese punto medio, ejecutando contenedores sobre clusters EKS que el propio servicio crea, configura y opera. El problema es que la documentación técnica revela condiciones que el post de lanzamiento no explicita: inmutabilidad de subredes, ausencia de despliegues inmutables, cargos por hora adicionales que las Savings Plans no amortizan y una política de aislamiento que, según la propia guía, «no hace que un cluster compartido sea equivalente a clusters separados».
Qué ocurrió
Elastic Beanstalk dividió su modelo de despliegue en dos modos. Beanstalk Standard conserva la arquitectura EC2 clásica. Beanstalk Cluster —así lo denomina la documentación— acepta la aplicación como código fuente, Dockerfile o imagen en Amazon ECR. Si el input es fuente, AWS compila la imagen con Cloud Native Buildpacks ejecutándose en AWS CodeBuild dentro de la cuenta del cliente. Los nodos de cómputo provienen de EKS Auto Mode, y toda la telemetría se instrumenta con OpenTelemetry.
El cluster no es elegible por el usuario. La asignación depende exclusivamente del conjunto de subredes VPC que se configure al crear el entorno. Entornos en la misma cuenta que comparten el mismo set de subredes aterrizan en el mismo cluster; un set distinto genera un cluster nuevo, aprovisionado en aproximadamente diez minutos en el primer uso. Una vez creado el entorno, ni las subredes ni los roles IAM del cluster admiten modificación. Corregir un error de configuración implica recrear el entorno desde cero.
Paul Pollack, software engineering manager en AWS, señaló en el post de lanzamiento que el cliente puede «tomar el control de los recursos» si lo necesita. En la práctica, la documentación describe que ante un cambio de configuración detectado fuera de Elastic Beanstalk, el servicio registra configuration drift, deja de mantener el cluster, no programa nuevos entornos sobre él y falla las actualizaciones de los entornos ya desplegados hasta que la modificación se revierte.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
La consolidación de múltiples aplicaciones en un cluster EKS compartido cambia la ecuación de riesgo operativo. El aislamiento de red entre entornos en el mismo cluster está bloqueado por defecto y no ofrece un toggle para habilitar tráfico inter-entorno. Sin embargo, la guía de AWS recomienda explícitamente usar sets de subredes separados —y por lo tanto clusters separados— para: entornos que pertenecen a distintos clientes finales, código que el cliente no controla, o cargas bajo regímenes de cumplimiento que exigen separación de infraestructura. Esta recomendación convive con la afirmación de que Elastic Beanstalk es elegible para HIPAA, PCI DSS, SOC, FedRAMP e IRAP.
Desde la perspectiva de costos, la estructura de facturación introduce dos cargos que Beanstalk Standard no contempla: una tarifa plana por hora por cluster EKS y un fee de gestión de EKS Auto Mode sobre las instancias. Los descuentos de EC2 clásicos —Savings Plans y Spot Instances— no reducen ese fee de gestión. Cada entorno balanceado obtiene su propio Application Load Balancer, y las métricas a nivel de pod se miden por recurso, lo que según AWS puede elevar el costo de monitoreo por encima del que genera Standard. El ahorro proviene exclusivamente de compartir nodos; clusters separados cuestan más y subutilizan capacidad.
Para equipos SRE que ya operan EKS propio, el modelo elimina la gestión del control plane pero elimina también la capacidad de elegir versión de Kubernetes, configurar admission controllers propios, aplicar políticas de red con NetworkPolicy a nivel de cluster o integrar herramientas de seguridad como Falco o OPA/Gatekeeper. La superficie de ataque se desplaza hacia la capa de imagen y la configuración IAM del entorno, no del cluster.
Detalles técnicos
- Componentes involucrados: Amazon EKS (control plane gestionado por AWS), EKS Auto Mode (provisión de nodos), Cloud Native Buildpacks (build de imagen), AWS CodeBuild (ejecución del build en cuenta del cliente), Amazon ECR (registro de contenedores), OpenTelemetry (observabilidad), Application Load Balancer (balanceo por entorno).
- Asignación de cluster: por set de subredes VPC. Inmutable post-creación del entorno. Tiempo de aprovisionamiento: ~10 minutos.
- Estrategias de despliegue disponibles: Rolling Update (default) y All at Once. Los despliegues inmutables y el traffic splitting con canary/blue-green permanecen exclusivos de Beanstalk Standard.
- Acceso al cluster: exclusivamente a través de la API de Elastic Beanstalk, AWS CLI o Console. No hay acceso directo a kube-apiserver ni a kubectl sobre el cluster subyacente.
- Drift detection: el servicio compara el estado real del cluster contra la configuración esperada. Ante divergencia: cesa mantenimiento, bloquea nuevos entornos, falla updates de entornos existentes.
- Aislamiento de red: bloqueo por defecto entre entornos del mismo cluster. Sin opción de habilitar tráfico inter-entorno.
- Cobertura de compliance: HIPAA eligible, PCI DSS, SOC, FedRAMP, IRAP. La guía advierte que los controles de aislamiento en cluster compartido no equivalen a clusters dedicados.
- Restricción de Kubernetes: el cliente no selecciona versión de K8s ni configura el control plane. Las actualizaciones de versión las gestiona AWS dentro del ciclo de vida de Beanstalk Cluster.
Qué deberían hacer los administradores y equipos técnicos
Antes del primer despliegue en Cluster Mode:
aws elasticbeanstalk describe-environments \
–application-name mi-app \
–query «Environments[].[EnvironmentName,PlatformArn,Resources.EC2Subnets]» \
–output table
Post-despliegue:
aws cloudtrail lookup-events \
–lookup-attributes AttributeKey=EventName,AttributeValue=UpdateClusterConfig \
–start-time $(date -d ‘7 days ago’ +%Y-%m-%dT%H:%M:%SZ) \
–query «Events[?EventSource==’eks.amazonaws.com’]» \
–output table
Conclusión
Cluster Mode reduce la fricción operativa de Kubernetes para equipos que no quieren gestionar un control plane, pero no es un reemplazo directo de EKS propio ni de ECS. La inmutabilidad de subredes, la ausencia de despliegues inmutables, los costos por capa no amortizables con descuentos EC2 y la política explícita de que el aislamiento compartido no equivale a separación dedicada son decisiones de arquitectura que se toman una sola vez y se corrigen recreando entornos. Para portfolios de aplicaciones internas con densidad alta y sin requisitos regulatorios de separación, el modelo tiene sentido. Para cargas multi-tenant o bajo compliance estricto, la propia documentación de AWS recomienda clusters dedicados, lo que en la práctica devuelve al punto de partida operativo.
Fuentes
- https://www.infoq.com/news/2026/09/elastic-beanstalk-cluster-eks/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global