Elastic Beanstalk Adds Cluster Mode, Running Applications on Shared EKS Clusters

AWS has added Cluster Mode to Elastic Beanstalk, enabling applications to run as containers on shared Amazon EKS clusters. This new feature operates alongside the EC2-based environment type, known as Beanstalk Standard, and maintains the same application, version, and environment concepts. The documentation outlines specific conditions, including deployments, cluster access, and isolation.

To use Elastic Beanstalk Cluster Mode, applications can be submitted as source code, a Dockerfile, or a container image in Amazon ECR. The source code is then built into an image using Cloud Native Buildpacks within the customer's AWS account. Nodes for the cluster come from EKS Auto Mode, and observability is provided via OpenTelemetry.

Customers do not have control over the cluster's creation, Kubernetes version, or the subnets and IAM roles associated with the cluster. The cluster is managed by the service, and customers cannot modify these settings after creation. Direct access to the cluster is also not part of the model, with all access managed through the Elastic Beanstalk API, AWS CLI, or console.

Paul Pollack, a software engineering manager at AWS, addressed potential lock-in concerns in his launch post, stating that Cluster Mode allows customers to take over management of their application resources if needed. The service detects configuration drift, stops maintaining the cluster, and prevents new environments from being deployed until the change is reverted.

Deployment options vary from the initial launch announcement, with immutable and traffic-splitting deployments emphasized. However, the architecture documentation shows that rolling updates are the default method, and all-at-once deployment options are also available. AWS's launch post did not mention these details.

Isolation between environments on a shared cluster is achieved by default through network traffic blocking. The documentation recommends separate subnet sets for environments belonging to different end customers, running controlled code, or subject to specific compliance requirements. AWS also states that Elastic Beanstalk is HIPAA eligible and in scope for various programs, including PCI DSS, SOC, FedRAMP, and IRAP.

Pricing for Elastic Beanstalk Cluster Mode includes no platform fee and compute bills at EC2 rates, but two additional charges are present: a flat hourly EKS fee per cluster and an EKS Auto Mode management fee on top of instances. These charges may make monitoring more expensive than in the EC2 Standard environment due to pod-level metrics being metered per resource. Shared nodes and less efficient capacity utilization contribute to cost savings, as noted in the documentation.

Elastic Beanstalk Standard is positioned as the cost-effective choice for smaller applications, supporting Windows environments, while Cluster Mode caters to larger portfolios and shared infrastructure requirements. The subnet set determines cluster assignment and shared infrastructure usage, with changes requiring environment recreation.

Applications must adhere to a stateless model with interchangeable replicas and ephemeral local storage. In cases where subnets are omitted, environments are deployed in the public subnets of the default VPC.