Elastic Beanstalk Cluster Mode: the tenancy question

Elastic Beanstalk Cluster Mode does not let you choose which cluster your application runs on. Environments in the same AWS account that use the same set of VPC subnets land on the same Amazon EKS cluster, and you cannot change an existing environment's subnets afterwards. That single rule decides your isolation boundary, most of the saving, and how far one bad cluster day spreads.

AWS released Cluster Mode on 17 September 2026, beside the EC2-based environment type now called Beanstalk Standard. The framing is modernisation without rearchitecting. The developer guide adds conditions the launch post skips, and those are the part to read before you move a legacy application.

What Elastic Beanstalk Cluster Mode actually is

A Beanstalk Cluster environment runs your application as a container image on an Amazon EKS cluster that Elastic Beanstalk creates and operates itself. You keep the same application, version, environment and configuration option concepts. Everything underneath them changes.

• Input. Source code, source plus a Dockerfile, or a prebuilt image in Amazon ECR. Source builds run Cloud Native Buildpacks or Docker on AWS CodeBuild in your own account, under a CodeBuild service role you supply.
• Nodes. Amazon EKS Auto Mode, which adds and removes nodes to fit the containers scheduled on the cluster. Node capacity is service-managed.
• Scaling. Replicas, not instances. You set min-replica and max-replica in the aws:elasticbeanstalk:eks:environment:autoscaling namespace; none of the classic aws:autoscaling:* namespaces apply.
• Observability. OpenTelemetry-based, to Amazon CloudWatch or a third-party backend.
• Requirements. Identical, interchangeable replicas, and local storage that is ephemeral and lost when a replica restarts.

That last line is the migration filter. An application that writes uploads, caches or working files to local disk and expects them after a restart is incompatible without external persistent storage. Per-instance health also disappears; health is reported at environment level.

Your subnets pick the cluster, and you cannot change them later

Elastic Beanstalk groups environments onto clusters by subnet set. Same account, same subnets, same cluster; a different set gets a different cluster. The first environment created with a given subnet set triggers a cluster build that the guide says generally takes about ten minutes, logged as a one-time CloudFormation stack creation in the environment's events. Omit subnets entirely and the environment lands in the public subnets of the default VPC.

The irreversibility is the part to plan around. You cannot change the subnets, or the cluster, node and observability roles, of an existing environment. Elastic Beanstalk rejects the update rather than moving the environment, and tells you to revert the option settings. The documented way out is a replacement environment with the settings you wanted plus a CNAME swap — a blue/green deployment you did not plan for. You also do not select the Kubernetes version, and the version a cluster starts with stays fixed for that cluster's life.

What a shared cluster does not separate

The isolation story is better than "everything shares everything" and weaker than a cluster per tenant. Elastic Beanstalk blocks network traffic between environments on a shared cluster by default, with no option that turns the blocking off. You open specific paths with three options in the aws:elasticbeanstalk:eks:environment namespace: ingress-groups for mutual traffic, and ingress-allowlist-environments or ingress-allowlist-groups for one-way permission set on the receiving environment.

Four things stay shared, and AWS lists them plainly:

• Outbound traffic is not restricted. The default blocking applies to traffic arriving at an environment. There is no configuration option that restricts where an environment's application can send traffic.
• The control plane is shared. One EKS control plane serves every environment on the cluster, at a Kubernetes version fixed for the cluster's life.
• Nodes are shared unless you set node-pool, and environments sharing a node-pool value share nodes with each other.
• Cluster-wide failure hits every environment. If the cluster drifts from the configuration Elastic Beanstalk expects, the service pauses maintenance, places no new environments on it, and fails updates to every environment already running there until the change is reverted.

AWS is unusually direct about the limit of all this:

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.

The guide recommends separate subnet sets — and therefore separate clusters — for environments belonging to different end customers, environments running code you do not control, and environments under a compliance regime that requires infrastructure separation. If each customer gets their own environment, that is your answer, and it arrives before the cost saving does. It is the same soft-versus-hard multi-tenancy split you meet when running Kubernetes directly.

The launch post and the developer guide disagree on deployments

AWS's News Blog lists Cluster Mode benefits including "All-at-once, rolling, immutable, and traffic-splitting deployments with automatic rollback on failure". The architecture documentation's comparison table gives a Beanstalk Cluster environment a rolling update, which is the default, or all at once — RollingUpdate or Recreate under the strategy option — and lists immutable deployments under Beanstalk Standard. InfoQ flagged the same gap and noted the What's New post lists neither.

We read that as the launch page describing the Elastic Beanstalk family rather than the mode. It still matters: if your release safety rests on immutable deployments, confirm the behaviour in a test environment before migrating anything. Same lesson as reading the conditions on an AWS limit increase rather than the headline.

What Cluster Mode costs, and when Standard still wins

There is no charge for Cluster Mode itself. You pay for what it provisions, and the pricing page names two charges Standard does not have:

Charge	How it behaves	Applies to
Amazon EKS cluster fee	Flat per-cluster hourly fee for the control plane. Fixed per cluster, not per application or node.	Every cluster, so every distinct subnet set
EKS Auto Mode management fee	On top of the EC2 instance cost, billed per second with a one-minute minimum, and charged independently of your purchase option.	All node capacity
Load balancing	Standard Elastic Load Balancing rates, one load balancer per load-balanced environment.	Unchanged from Standard

Read the second row twice. Reserved Instances, Savings Plans and Spot reduce the instance cost but not the Auto Mode management fee, so a heavily committed EC2 estate gains less than the headline suggests. Cluster Mode is also not Free Tier eligible.

The saving comes from bin-packing several environments onto shared nodes, so it arrives only when several environments share a subnet set. One small application on its own cluster pays a flat control-plane fee for nothing. AWS agrees: separate clusters cost more and use capacity less efficiently.

Should I move Beanstalk apps to EKS this way?

Move when the application is already stateless behind a load balancer, when you run a portfolio rather than one service, and when the environments that would share a cluster belong to one team and one trust boundary. Splitting production and development across different subnet sets is a cheap precaution even when nothing forces it.

Do not move when any of these is true: the application keeps state on local disk, each end customer has their own environment, immutable deployments are load-bearing in your release process, or a compliance regime requires infrastructure separation and you were planning to rely on the in-cluster controls. In the legacy estates we are handed, the first and last of those decide it more often than cost does.

Cluster Mode runs in all commercial AWS Regions where Elastic Beanstalk operates, and deploys from the console, the AWS CLI, CloudFormation and a new GitHub Action, so the pipeline work is small. The architecture work is not, which is why legacy application modernisation starts with the state an application keeps rather than the platform it will run on.

The next step is narrow: list your Beanstalk environments, group them by the subnet sets they would use, and check whether any group crosses a tenant or compliance boundary. That grouping is the decision you cannot take back. Our DevOps and cloud engineering work starts there, and the observability follow-on looks like a large OpenTelemetry migration: new signals, same questions about what you actually alert on.