Elastic Beanstalk estrena Cluster Mode: tus aplicaciones corren en clusters EKS compartidos
AWS añade un segundo tipo de entorno a Elastic Beanstalk que despliega las aplicaciones como contenedores sobre EKS, con el cluster gestionado por el servicio y compartido entre entornos.
AWS ha añadido Cluster Mode a Elastic Beanstalk. En este modo, las aplicaciones se ejecutan como contenedores en clusters de Amazon EKS que el propio servicio crea y opera, sin que el cliente toque Kubernetes. Convive con el tipo de entorno basado en EC2, que ahora se llama Beanstalk Standard, y mantiene los mismos conceptos de aplicación, versión y entorno.
El código llega como fuente, Dockerfile o imagen en Amazon ECR. Si es fuente, se construye con Cloud Native Buildpacks sobre AWS CodeBuild en la cuenta del cliente. Los nodos salen de EKS Auto Mode y la observabilidad va por OpenTelemetry.
El cluster lo elige AWS, no tú
Aquí está la parte que la documentación cuenta y el anuncio no. Los entornos de una misma cuenta que usan el mismo conjunto de subredes de VPC comparten cluster; un conjunto distinto genera otro, creado al primer uso en unos diez minutos. No se puede escoger cluster ni versión de Kubernetes, y las subredes y los roles IAM del cluster de un entorno ya existente no se modifican: si están mal, toca recrear el entorno.
El acceso directo al cluster tampoco forma parte del modelo. La documentación de Beanstalk Cluster describe la infraestructura como gestionada por el servicio, con la API de Beanstalk, la CLI de AWS o la consola como vías. Si alguien cambia el cluster por fuera, el servicio detecta la deriva, deja de mantenerlo, no coloca nuevos entornos en él y falla las actualizaciones de los que ya corren hasta que se revierta el cambio. Paul Pollack, responsable de ingeniería de software en AWS, responde al miedo al lock-in en el anuncio: "With Cluster Mode you can take over management of your application's resources if you ever need to."
Menos opciones de despliegue y aislamiento con matices
Las opciones de despliegue son más estrechas de lo que sugiere el blog de lanzamiento. Este menciona despliegues inmutables y con reparto de tráfico, pero la documentación de arquitectura solo recoge actualización progresiva, la opción por defecto, o todo a la vez. Los inmutables siguen siendo cosa de Standard.
En aislamiento, el tráfico entre entornos de un cluster compartido está bloqueado por defecto y no hay forma de desactivar ese bloqueo. La guía recomienda conjuntos de subredes separados, y por tanto clusters separados, para entornos de distintos clientes finales, código que el cliente no controla o regímenes de cumplimiento que exijan separar infraestructura. Lo dice sin rodeos: "The controls described in the rest of this topic separate environments on a shared cluster, but they do not make a shared cluster equivalent to separate clusters." Eso convive con que AWS declare Beanstalk elegible para HIPAA y dentro del alcance de PCI DSS, SOC, FedRAMP e IRAP.
La economía depende de ese mismo reparto. No hay tarifa de plataforma y el cómputo se factura a precios de EC2, pero aparecen dos cargos que Standard no tiene: una tarifa horaria fija de EKS por cluster y una tarifa de gestión de EKS Auto Mode sobre las instancias, que los descuentos de EC2 como Savings Plans o Spot no reducen. Cada entorno con balanceo lleva su propio Application Load Balancer, y las métricas a nivel de pod se facturan por recurso, lo que según AWS puede encarecer el monitoreo respecto a Standard. El ahorro, si llega, viene de compartir nodos.
El lanzamiento también abrió el debate de dónde encaja esto. James Eastham, de Datadog y AWS Community Builder, preguntó por su relación con EKS, EKS Auto Mode, ECS, ECS Express Mode, Beanstalk clásico, contenedores en Lambda y Lambda Managed Instances, y lo resumió con un "This feels like SNS vs EventBridge all over again". Tras la respuesta de Dan Ronald, responsable de producto de integración de aplicaciones en AWS, aceptó la diferencia frente a EKS y Lambda, pero no frente a ECS.
Para quien evalúe el modo: las aplicaciones tienen que ser stateless, con réplicas intercambiables y almacenamiento local efímero, y si se omiten las subredes el entorno acaba en las subredes públicas de la VPC por defecto. Está en todas las regiones comerciales donde opera Beanstalk, no entra en el Free Tier y se despliega desde consola, CLI de AWS, EB CLI, CloudFormation, Terraform, una GitHub Action nueva y agent skills. La decisión real no es si usar Cluster Mode, sino si el conjunto de subredes que elijas hoy sigue teniendo sentido dentro de dos años, porque cambiarlo significa empezar de cero.
