AWS Elastic Beanstalk Cluster Mode: qué cambia y cuándo usarlo
AWS lanzó Elastic Beanstalk Cluster Mode el 17 de septiembre de 2026. Es un nuevo modo en el que varios entornos de Beanstalk pueden compartir la infraestructura que ejecuta sus aplicaciones, usando EKS por debajo. En este artículo de explico qué cambia y cuándo usar este nuevo modo o el antiguo modo Standard.
AWS lanzó Elastic Beanstalk Cluster Mode el 17 de septiembre de 2026 . Es un nuevo modo en el que varios entornos de Beanstalk pueden compartir la infraestructura que ejecuta sus aplicaciones. Por debajo, Beanstalk opera un cluster de Kubernetes a través de Amazon EKS, mientras EKS Auto Mode administra su capacidad EC2.
Si tienes varias aplicaciones y te gusta desplegarlas con Beanstalk (e incluso si, como a mí, no te gusta Beanstalk), te conviene echarle un vistazo. Compartir capacidad puede reducir tu factura de AWS, y mantener la gestión de los despliegues en Beanstalk te evita tener que construir una plataforma de Kubernetes.
Para una aplicación pequeña que ya funciona bien en Beanstalk clásico, no veo una razón para pasarte al nuevo modo. Si estuviera empezando desde cero con una aplicación web pequeña en contenedores, primero consideraría ECS Express Mode. Para una aplicación que realmente necesita herramientas de Kubernetes, elegiría EKS Auto Mode. Aun así, el modo Cluster de Beanstalk me pareció lo suficientemente interesante como para escribir un artículo.
¿Qué cambia en Elastic Beanstalk Cluster Mode?
Beanstalk clásico te permite desplegar versiones de tu aplicación en un entorno: los recursos y la configuración que ejecutan un despliegue concreto. Beanstalk Cluster mantiene esa idea, pero cambia la forma de gestionar el entorno. Sigues administrando la aplicación a través de Beanstalk, que se encarga de su despliegue, las copias en ejecución y su estado.
En Beanstalk clásico, ahora llamado Standard Mode, cada entorno tiene su propio grupo de EC2 Auto Scaling. El modo Cluster, en cambio, ejecuta contenedores en instancias EC2 compartidas, que EKS Auto Mode administra por detrás. Una réplica es una copia de tu aplicación en ejecución; un nodo es una instancia EC2 que aloja contenedores. Beanstalk escala las réplicas de la aplicación, mientras EKS Auto Mode ajusta la capacidad de los nodos que las ejecutan.
Supongamos que despliegas una API y luego agregas una aplicación de administración. En el modo Standard, cada una obtiene su propio grupo de instancias. En el modo Cluster, sus réplicas pueden usar el mismo pool de nodos , aunque siguen siendo entornos separados de Beanstalk. Los entornos de la misma cuenta de AWS que usan el mismo conjunto de subnets comparten un cluster; si usas un conjunto diferente de subnets, se crea otro cluster.
Cuando ambas aplicaciones dejan capacidad libre, agrupar esa capacidad puede permitir que sus réplicas quepan en menos instancias. Ahí está la oportunidad de ahorro: dejas de reservar un grupo separado de instancias para cada aplicación. Esto resulta especialmente relevante si estás obsesionado con la alta disponibilidad, pero tu aplicación tiene tan poco tráfico que ni siquiera exige demasiado a una sola instancia, mucho menos a varias.
Puedes proporcionar una imagen de contenedor existente o hacer que Beanstalk construya una a partir del código fuente usando un Dockerfile o Cloud Native Buildpacks . El proceso de build usa CodeBuild y guarda la imagen resultante en ECR. Si proporcionas una imagen, ese paso se omite, por supuesto. Sigues necesitando código fuente compatible, configuración de build y permisos. Esto no convierte automáticamente cualquier aplicación existente en un contenedor (¡ojalá!).
Ten en cuenta que el modo Standard ya soporta Docker . Lo que debería llevarte a considerar el modo Cluster es su infraestructura compartida y su modelo operativo, más que el soporte de contenedores.
Qué administra AWS y qué te sigue tocando hacer
El modo Cluster te permite gestionar el despliegue de la aplicación y los recursos de cómputo. Su configuración de red predeterminada también proporciona acceso HTTPS, incluida la gestión de certificados para el dominio del entorno. También puedes proporcionar tu propio load balancer, aunque tendrás que configurar los listeners y los certificados.
Tu aplicación todavía necesita que tomes decisiones que AWS no puede resolver a partir de una imagen de contenedor:
- Recursos y estado: Deberías definir la CPU, la memoria, los límites de réplicas y los health checks adecuados. Las readiness probes le indican a la plataforma cuándo una copia puede recibir tráfico, y las liveness probes detectan cuándo necesita reiniciarse. En el modo Cluster, las probes de la aplicación permanecen deshabilitadas hasta que las configuras.
- Permisos y dependencias: Te toca mantener la aplicación y sus dependencias, y otorgarle el acceso que necesita. El modo Cluster usa roles para el cluster, los nodos y la observabilidad, además de un rol opcional para la aplicación. La consola puede ayudarte a crear los roles de infraestructura necesarios.
- Telemetría de la aplicación: Beanstalk gestiona la recopilación de datos de telemetría, pero para que la telemetría de tu aplicación sea útil necesitas instrumentarla bien. Recopilar señales de infraestructura no explica automáticamente por qué falla una operación de negocio. Deberías usar esas señales como punto de partida, sin asumir que todo va a quedar bien resuelto por arte de magia.
Tu aplicación también debe funcionar como réplicas intercambiables, sin conservar su estado dentro de la unidad que la ejecuta. El almacenamiento local es efímero: un archivo cargado y guardado únicamente dentro de una réplica desaparece cuando esa réplica se reinicia. Los archivos y cualquier dato que deba sobrevivir más de unos minutos deben almacenarse fuera de la unidad que ejecuta tu aplicación. Es lo habitual para una aplicación escalable, pero sigue siendo útil recordarlo.
Compartir infraestructura tiene consecuencias que van más allá del costo. Los entornos pueden compartir nodos y un control plane, así que una falla que afecte a todo el cluster puede impactar varias aplicaciones. El aislamiento de red bloquea por defecto el tráfico directo entre entornos, pero no crea infraestructura separada. Incluso un pool de nodos dedicado conserva el control plane compartido. Si algo de esto te resulta un problema, te conviene ir directamente con EKS, donde tendrás más control (y más trabajo).
El modo Cluster también mantiene al menos una réplica en ejecución en todo momento. El escalado no puede llevar a cero un entorno inactivo. Por eso, Beanstalk Cluster no encaja bien si tu objetivo principal es pagar por recursos de cómputo únicamente cuando tienes tráfico. Si eso es lo que buscas, deberías considerar ECS Express Mode o Lambda.
Otro punto que deberías tener presente es que, si usas Beanstalk, necesitas administrar todo a través de Beanstalk. Cambiar directamente la infraestructura administrada puede provocar configuration drift, detener el mantenimiento y hacer que las actualizaciones del entorno fallen hasta que reviertas el cambio. No lo hagas.
Las opciones de despliegue documentadas actualmente se limitan a
RollingUpdate (reemplazo gradual) y Recreate (detener todas las réplicas antes de iniciar la nueva versión). La referencia de configuración de Cluster enumera esas dos, mientras que el artículo del lanzamiento también anuncia despliegues immutable y traffic-splitting. Sin embargo, en ese momento no pude encontrar más información al respecto. Actualizaré este artículo cuando estén bien documentados.Otra limitación importante es que la versión de Kubernetes queda fija durante toda la vida del cluster. No hay una forma de actualizarla en el mismo cluster. Para un despliegue de producción que vaya a durar mucho tiempo, esto no es ideal. Espero que se resuelva para cuando tu versión de Kubernetes empiece a quedar vieja, pero por ahora esa opción no existe.
Cluster Mode frente a Standard Mode, EKS y ECS
Modo Standard
La mayoría de las aplicaciones pequeñas que hoy se ejecutan en Beanstalk probablemente tengan poca capacidad ociosa que aprovechar y ninguna funcionalidad faltante que el modo Cluster venga a resolver. Migrarlas implica trabajo de empaquetado, configuración y cambio de tráfico al nuevo entorno. Sin un beneficio concreto, eso es trabajo innecesario y tokens quemados. No vale la pena.
El modo Standard también sigue siendo relevante para Windows/.NET Framework sobre IIS y para aplicaciones que no pueden ejecutarse en contenedores. Esas serían las principales razones para usar Beanstalk en el modo Standard, según AWS .
El comportamiento actual de tu entorno importa tanto como la compatibilidad del runtime. Los archivos de configuración del modo Standard pueden instalar paquetes y ejecutar comandos en las instancias. Su Worker tier incluye un daemon que lee de SQS y envía el trabajo a la aplicación. Si dependes de cualquiera de esas capacidades, adaptar ese comportamiento forma parte de la migración y del trabajo adicional que te toca hacer. Poder construir una imagen es solo el comienzo. No deberías subestimar todo lo demás.
EKS Auto Mode
EKS Auto Mode ya automatiza el aprovisionamiento y el reemplazo de nodos, el escalado del cómputo, la red y la integración del balanceo de carga y el almacenamiento para los clusters de Kubernetes. Elegir EKS no significa necesariamente que tengas que mantener los servidores por tu cuenta.
La diferencia entre EKS y el modo Cluster de Beanstalk está en la interfaz y la configuración que quedan a tu cargo. Usar EKS directamente te permite desplegar Kubernetes manifests y Helm charts , y tomar decisiones sobre la plataforma a nivel de Kubernetes. Tú mantienes esas definiciones de las cargas de trabajo y su compatibilidad. Auto Mode también permite personalizar la configuración de los nodos mediante recursos de Kubernetes, mientras reduce el trabajo total de operar y mantener un cluster de EKS. También puedes actualizar la versión del control plane. Auto Mode actualiza después los nodos administrados y deja en tus manos las decisiones sobre compatibilidad de la aplicación.
El modo Cluster agrega la interfaz de aplicaciones de Beanstalk por encima de esa infraestructura. Si tus desarrolladores quieren desplegar una versión de la aplicación y configurar sus recursos a través de Beanstalk, eso puede ahorrarte trabajo útil de plataforma. Si tu despliegue ya requiere Helm o configuración de Kubernetes que quede fuera de las opciones soportadas por Beanstalk, usar EKS directamente te da la interfaz que necesitas.
ECS Express Mode
ECS Express Mode recibe una imagen de contenedor y roles de IAM, y configura un servicio de Fargate con HTTPS, balanceo de carga, escalado y monitoreo. Fargate ejecuta los contenedores sin que tengas que elegir ni aprovisionar instancias EC2. Express no agrega un cargo por el servicio. Para una aplicación HTTPS en contenedores que no necesita Kubernetes, es una alternativa cercana al modo Cluster de Beanstalk.
Para un servicio pequeño que empieza con una imagen lista para desplegar y sin configuración ni experiencia previa con Beanstalk, yo consideraría primero ECS Express Mode. Te proporciona la infraestructura que rodea al despliegue sin agregar el costo de un cluster de EKS. Además, creo que su interfaz es más clara y fácil de administrar, y te permitirá salir del «modo fácil» con menos esfuerzo cuando lo necesites.
Tu flujo de build puede ayudarte a decidir entre ambos. Si ya generas imágenes de contenedor, ECS Express puede usar ese resultado directamente. Si quieres que Beanstalk construya imágenes a partir del código fuente y ya gestionas allí las versiones y los entornos de tu aplicación, el modo Cluster de Beanstalk podría ahorrarte ese trabajo de integración.
Si ya tienes un cluster compartido en el modo Cluster, las cuentas cambian un poco. Agregarle otro entorno no introduce otro cargo por cluster y permite aprovechar la capacidad ociosa (aunque recuerda que con Fargate no tendrás capacidad ociosa). En ese caso, deberías comparar la capacidad adicional y los demás recursos que necesita la aplicación, en lugar de calcularlo como si fueras a crear un cluster completamente nuevo.
ECS Express también usa despliegues canary por defecto y acepta task definitions personalizadas, incluidos contenedores adicionales. Tiene algunas restricciones : por ejemplo, no puedes cambiar la estrategia de despliegue ni la configuración del load balancer del servicio. Sin embargo, para lo que ECS Express Mode no pueda hacer, puedes usar ECS directamente. Y si quieres agrupar contenedores en capacidad EC2 administrada, ECS Managed Instances ofrece ese modelo sin Kubernetes.
¿Cuándo te permite ahorrar realmente la infraestructura compartida?
Beanstalk no cobra por el servicio en sí . Sin embargo, el modo Cluster introduce cargos que el modo Standard no tiene: el cargo por el cluster de EKS y los cargos de administración de Auto Mode, además del costo de EC2.
Con la tarifa de soporte estándar de EKS de $0.10 por hora de cluster, un cluster que funciona de manera continua cuesta $73 por 730 horas (un mes), antes de sumar el cómputo de las aplicaciones. Auto Mode añade un cargo que depende del tipo de instancia. Puedes consultar los precios de EKS para ver más detalles.
El modo Cluster podría reducir tu factura de AWS cuando el ahorro por compartir capacidad y otros recursos supera los cargos adicionales. También deberías considerar las horas de trabajo que te ahorras y su valor.
Veamos estos subtotales hipotéticos de cómputo y control plane. Ambas opciones usan instancias
m5a.xlarge. Los supuestos son la región US East (N. Virginia), precios en USD, Linux/x86, On-Demand, 730 horas y soporte estándar de EKS. Los precios cuando escribí esto, en septiembre de 2026, son $0.172/hora para EC2 y $0.02064/hora para Auto Mode. Deberías comprobar si se actualizaron en las tarifas regionales de EC2 y las tarifas regionales de Auto Mode .| Capacidad supuesta | Standard: EC2 | Cluster: EC2 + Auto Mode + un cluster |
|---|---|---|
| Dos instancias dedicadas frente a dos nodos compartidos | $251.12/mes | $354.25/mes |
| Seis instancias dedicadas frente a tres nodos compartidos | $753.36/mes | $494.88/mes |
Estos valores se calculan con las siguientes fórmulas:
1
2
Standard = cantidad de instancias * $0.172 * 730
Cluster = cantidad de nodos * ($0.172 + $0.02064) * 730 + $73En comparación con un único despliegue en modo Standard, con la misma cantidad de instancias, el modo Cluster cuesta $103.13 más. Si tres nodos compartidos pueden reemplazar seis instancias dedicadas, cuesta $258.48 menos.
La segunda fila supone que puedes cumplir con los mismos requisitos de las aplicaciones usando menos capacidad. Recuerda que las necesidades reales de capacidad incluyen la sobrecarga del sistema y un margen para fallas y despliegues, y que esas restricciones pueden limitar la consolidación de infraestructura.
Para estimar tu caso, deberías empezar por tu factura actual de instancias y la demanda de CPU y memoria de cada aplicación, incluidos los períodos en los que varias aplicaciones están ocupadas al mismo tiempo. Con ese cálculo de demanda puedes dimensionar los recursos que necesitas. Ten en cuenta que EKS Auto Mode ajusta los nodos a la suma de los requests , así que, si tus requests están sobredimensionados, podrías seguir necesitando parte de esa capacidad de sobra. Deberías incluir la cantidad de réplicas, la sobrecarga del sistema y la capacidad adicional que necesitas para cumplir tus requisitos de disponibilidad y rolling deployments. Eso te da una estimación preliminar de la capacidad de los nodos y su costo, al que debes sumar los demás cargos. Si el ahorro depende de incertidumbres, como la posibilidad de agrupar las cargas en menos nodos bajo ciertas condiciones o estimaciones de tráfico de las que no estás del todo seguro, pruébalo de todos modos y haz pruebas reales, pero asegúrate muy bien antes de migrar.
Pasos para migrar de Elastic Beanstalk Standard al modo Cluster
Deberías tratar el paso del modo Standard al modo Cluster como una migración a un entorno nuevo. La API UpdateEnvironment no te permite cambiar el tier de un entorno existente al modo Cluster. Necesitas recrear los recursos y volver a desplegar.
Los pasos más importantes son:
- Preparar la aplicación: Deberías proporcionar una imagen o una configuración de build compatible y sacar los datos duraderos del almacenamiento local de las réplicas.
- Adaptar la configuración del entorno: Necesitas definir los valores de recursos, escalado, health checks, roles y subnets. El modo Cluster acepta sus propios namespaces de configuración. Lamentablemente, no puedes copiar directamente la configuración existente del modo Standard.
- Desplegar por separado y redirigir el tráfico. Deberías probar el nuevo entorno y después usar el intercambio de CNAME de Beanstalk para pasar a él. Te conviene mantener el entorno anterior disponible para hacer rollback y esperar a que se propague el DNS antes de terminarlo. Si la base de datos pertenece al entorno anterior, deberías configurar una política de retención antes de eliminarlo.
Migrar una API que ya está en contenedores y tiene todos sus datos almacenados fuera de los recursos de cómputo de la aplicación será mucho más fácil que migrar una aplicación que depende de scripts en el host, archivos cargados que se guardan de forma persistente en el almacenamiento local o el daemon de SQS del modo Standard. Antes de empezar la migración, deberías estimar cuánto trabajo te llevará y cuánto ahorrarás realmente.
Conclusión
El modo Cluster de Elastic Beanstalk te permite compartir cómputo a través del modelo de aplicaciones de Beanstalk, apoyándose en EKS para hacer el trabajo de infraestructura por ti. Eso tiene valor cuando te ahorra trabajo de despliegue que de otro modo tendrías que hacer, o capacidad que de otro modo tendrías que administrar y pagar, sobre todo capacidad ociosa. Si ya estás acostumbrado a Elastic Beanstalk, podría valer la pena pagar una factura de AWS más alta cuando eso te evita una cantidad importante de trabajo. Esto es lo que yo elegiría en cada situación:
| Tu punto de partida | Mi primera elección |
|---|---|
| Una aplicación pequeña que funciona bien en el modo Standard de Beanstalk | Seguiría en el modo Standard hasta que un beneficio concreto justifique la migración. |
| Varias aplicaciones compatibles, flujos de trabajo establecidos en Beanstalk y capacidad que vale la pena compartir | Consideraría el modo Cluster, siempre que sus controles de despliegue y su ciclo de vida se ajusten a lo que necesitas. |
| Necesitas Helm, manifests de Kubernetes o control de la plataforma a nivel de Kubernetes | Usaría EKS directamente, con Auto Mode como base administrada. |
| Un servicio HTTPS nuevo y pequeño, listo para desplegar desde una imagen, sin requisitos de Kubernetes ni una configuración existente de Beanstalk | Consideraría primero ECS Express Mode si sus controles encajan con tus necesidades. Solo elegiría el modo Cluster de Beanstalk si realmente te gusta Beanstalk. |
Por si no quedó claro, no soy fan de Elastic Beanstalk. Dicho eso, entiendo que a varias personas les gusta la experiencia de desarrollo que ofrece. Siempre me pareció que el modo Standard de Beanstalk tenía demasiadas restricciones, y les decía a los demás que deberían acostumbrarse a otra cosa. El modo Cluster hace que Elastic Beanstalk vuelva a ser útil. Así que, aunque no sea mi experiencia de desarrollo preferida, ahora me siento seguro recomendándolo si eso es lo que te gusta.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article