AWS recently added Cluster Mode to Elastic Beanstalk, running applications as containers on Amazon EKS clusters the service creates and operates. It sits alongside the EC2-based environment type, now called Beanstalk Standard, and uses the same application, version, and environment concepts. The documentation adds conditions the launch messaging does not mention, covering deployments, cluster access and isolation.
Beanstalk Cluster, as the documentation calls it, is aimed at teams running a portfolio of applications on shared infrastructure. Applications arrive as source code, a Dockerfile, or a container image in Amazon ECR, and source is built into an image with Cloud Native Buildpacks on AWS CodeBuild in the customer's account. Nodes come from EKS Auto Mode, and observability is OpenTelemetry-based.
Customers do not pick the cluster. According to the developer guide, environments in the same account that use the same set of VPC subnets share a cluster, while a different subnet set gets a different one, created on first use in about ten minutes. Customers cannot choose the cluster or its Kubernetes version, and the subnets and cluster IAM roles of an existing environment cannot be changed. Correcting them means recreating the environment.
Direct access to the cluster is not part of the model either. The guide lists cluster infrastructure access as service-managed, through the Elastic Beanstalk API, the AWS CLI, or the console. Paul Pollack, a software engineering manager at AWS, addressed lock-in in his launch post:
With Cluster Mode you can take over management of your application's resources if you ever need to.
The documentation describes what happens when the cluster is changed outside Elastic Beanstalk. The service detects configuration drift, stops maintaining the cluster, places no new environments on it, and fails updates to environments already running there until the change is reverted.
Deployment options are also narrower than the launch blog suggests. It lists immutable and traffic-splitting deployments among Cluster Mode's benefits, but the architecture documentation shows a rolling update, the default, or all at once, and the What's New post lists neither. Immutable deployments remain a Beanstalk Standard feature.
On isolation, network traffic between environments on a shared cluster is blocked by default, with no option to turn the blocking off. The guide still recommends separate subnet sets, and therefore separate clusters, for environments that belong to different end customers, run code the customer does not control, or fall under a compliance regime requiring infrastructure separation:
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.
That guidance sits alongside AWS's statement that Elastic Beanstalk is HIPAA eligible and in scope for programs including PCI DSS, SOC, FedRAMP and IRAP.
The economics depend on the same sharing. Elastic Beanstalk has no platform fee and compute bills at EC2 rates, but the pricing page lists two charges Standard does not have: a flat hourly EKS fee per cluster, and an EKS Auto Mode management fee on top of the instances, which EC2 discounts such as Savings Plans or Spot do not reduce. Each load-balanced environment also gets its own Application Load Balancer, and pod-level metrics are metered per resource, which AWS says can make monitoring cost more than on Standard. The savings therefore come from shared nodes, and the guide notes that separate clusters cost more and use capacity less efficiently. AWS's own overview describes Standard as the cost-effective choice for smaller or fewer applications, and as the mode that supports Windows.
The launch also raised the question of where Cluster Mode fits. Replying to the announcement from Dan Ronald, head of product for application integration at AWS, James Eastham of Datadog, an AWS Community Builder, asked how it compares with EKS, EKS Auto Mode, ECS, ECS Express Mode, classic Beanstalk, containers on Lambda and Lambda Managed Instances, adding:
This feels like SNS vs EventBridge all over again
After Ronald replied, Eastham accepted the distinction from EKS and Lambda, but not from ECS:
ECS and Beanstalk Cluster mode seem a little close to each other when they could actually just put a bunch of effort into making one of the services great.
For teams evaluating the mode, the subnet set determines which cluster an environment joins, whether it shares infrastructure with other environments, and how much of the cost saving applies, and it cannot be changed afterward. Applications must also fit a stateless model, with interchangeable replicas and ephemeral local storage, and when subnets are omitted, environments land in the public subnets of the default VPC.
Cluster Mode is available in all commercial AWS Regions where Elastic Beanstalk operates and is not eligible for the AWS Free Tier. It can be deployed through the console, the AWS CLI, the EB CLI, CloudFormation, Terraform, a new GitHub Action, and agent skills.