AWS released Elastic Beanstalk Cluster Mode on September 17, 2026. It's a new mode where several Beanstalk environments can share the infrastructure running their applications. Underneath, Beanstalk operates a Kubernetes cluster through Amazon EKS, with EKS Auto Mode managing its EC2 capacity.

If you have several applications and like deploying through Beanstalk (and even if you don't like Beanstalk, like me), this is worth a look. Sharing capacity can reduce your AWS bill, and keeping deployment management in Beanstalk avoids building a Kubernetes platform.

For a small application already running well on classic Beanstalk, I don't see a reason to upgrade. If I were starting from scratch with a small, containerized web application, I'd consider ECS Express Mode first. For an application that actually needs Kubernetes tooling, I'd go with EKS Auto Mode. I still found Beanstalk Cluster mode sufficiently interesting for an article though.

Beanstalk classic lets you deploy application versions into an environment: the resources and configuration running a particular deployment. Beanstalk Cluster keeps that idea, but changes how the environment is managed. You still manage the application through Beanstalk, which handles its deployment, running copies, and health.

In classic Beanstalk, now called Standard Mode, each environment has its own EC2 Auto Scaling group. Cluster instead runs containers on shared EC2 instances, managed behind the scenes by EKS Auto Mode. A replica is one running copy of your application, a node is an EC2 instance hosting containers. Beanstalk scales the application's replicas, while EKS Auto Mode adjusts the underlying node capacity.

Suppose you deploy an API, then add an admin application. In Standard mode, each gets its own instance group. In Cluster mode, their replicas can use the same pool of nodes, while remaining separate Beanstalk environments. Environments in the same AWS account with the same subnet set share a cluster, while using a different subnet set creates a different cluster.

When both applications leave some spare capacity, pooling can let their replicas fit on fewer instances. That is the opportunity for savings: you stop reserving a separate group of instances for each application. Especially important if you're all crazy about High Availability, but your app has so little traffic that it doesn't stress a single instance, let alone several.

You can supply an existing container image or have Beanstalk build one from source using a Dockerfile or Cloud Native Buildpacks. The build path uses CodeBuild and stores the resulting image in ECR. A supplied image skips the build, of course. You still need compatible source, build configuration, and permissions, this doesn't automatically containerize every existing application (I wish!).

Note that Standard mode already supports Docker. The reason to consider Cluster mode is its shared infrastructure and operating model, rather than container support.

Cluster mode lets you manage application deployment and compute resources. Its default networking also provides HTTPS access, including certificate management for the environment's domain. You can also provide your own load balancer, though you'll need to set up the listeners and certificates.

The application still needs decisions from you that AWS cannot make from just a container image:

Your application must also work as interchangeable replicas, without keeping application state within the application's execution unit. Local storage is ephemeral, an upload saved only inside a replica disappears when that replica restarts. Files and any data that must survive beyond a few minutes needs to be stored outside of your application's execution unit. Common stuff for a scalable application, but still worth mentioning.

Sharing infrastructure has consequences beyond cost. Environments can share nodes and a control plane, so a cluster-wide failure can affect several applications. Network isolation blocks direct traffic between environments by default, but it does not create separate infrastructure. Even a dedicated node pool retains the shared control plane. If any of this is a problem for you, skip Beanstalk and just go with EKS, where you'll have more control (and more work).

Cluster mode also keeps at least one replica running at all times. Scaling cannot take an idle environment to zero. That makes Beanstalk Cluster mode a poor match if your main objective is to pay for compute resources only when you have traffic. If that's what you want, consider ECS Express Mode or Lambda instead.

Another thing to note is that if you're using Beanstalk you need to manage everything through Beanstalk. Directly changing the managed infrastructure can cause configuration drift, pausing maintenance and making environment updates fail until the change is reverted. Don't do it.

The documented deployment choices are currently limited to RollingUpdate (gradual replacement) and Recreate (taking all replicas down before starting the new version). The Cluster configuration reference lists those two, while the launch post also advertises immutable and traffic-splitting deployments, but I couldn't find more info about that at the time. I'll update this post when those are properly documented.

Another important caveat is that the Kubernetes version is fixed for the cluster's lifetime. There's no in-place version-upgrade path. For a long-lived production deployment, this isn't great. I do expect this to be solved by the time your Kubernetes version is starting to get old, but right now it's just not an option.

Most small applications currently running on Beanstalk probably have little idle capacity to reclaim and no missing capability that Cluster mode solves. Moving them means packaging, configuration, and cutover. Without a specific benefit, that's just idle work and burnt tokens. Not worth it.

Standard mode also remains relevant for Windows/.NET Framework on IIS and applications that cannot be containerized. Those would be the main reasons to use Beanstalk in Standard mode, according to AWS.

Existing behavior matters as much as runtime compatibility. Standard mode's configuration files can install packages and run commands on instances. Its Worker tier includes an SQS-reading daemon that forwards work to the application. If you depend on either, translating that behavior is part of the migration, and part of the extra work you need to do. Being able to build an image is only the beginning. Don't underestimate everything else.

EKS Auto Mode already automates node provisioning and replacement, compute scaling, networking, and load-balancing and storage integration for Kubernetes clusters. Choosing EKS doesn't necessarily mean maintaining servers yourself.

The difference between EKS and Beanstalk's Cluster mode is the interface and configuration you own. Direct EKS lets you deploy Kubernetes manifests and Helm charts, and make Kubernetes-level platform decisions. You maintain those workload definitions and their compatibility. Auto Mode also permits custom node configuration through Kubernetes resources, while reducing the overall workload of running and maintaining an EKS cluster. You can also do control-plane version upgrades. Auto Mode then updates the managed nodes, leaving application compatibility decisions with you.

Cluster mode adds Beanstalk's application interface above that infrastructure. If your developers want to deploy an application version and configure its resources through Beanstalk, that can save useful platform work. If your deployment already requires Helm or Kubernetes configuration outside Beanstalk's supported options, direct EKS gives you the interface you need.

ECS Express Mode takes a container image and IAM roles, then sets up a Fargate service with HTTPS, load balancing, scaling, and monitoring. Fargate runs the containers without requiring you to choose or provision EC2 instances. Express adds no service fee. For a containerized HTTPS application without a Kubernetes requirement, this is a close alternative to Beanstalk's Cluster mode.

For a small service starting with a ready-to-deploy image and no existing Beanstalk setup or experience, I'd consider ECS Express mode first. It provides the surrounding deployment infrastructure without introducing an EKS cluster fee, I think the interface is cleaner and easier to manage, and will let you grow out of the “easy mode” more easily.

Your build workflow can help you decide between them. If you already produce container images, ECS Express can use that output directly. If you want Beanstalk to build images from source and already manage your application versions and environments there, Beanstalk Cluster mode could save you that integration work.

An existing shared Cluster mode changes the economics a bit. Adding another environment to it doesn't introduce another cluster fee, and it makes good use of idle capacity (though remember that with with Fargate you won't have idle capacity). At that point, you should compare the additional capacity and other resources the application needs, rather than considering it as if it was an entirely new cluster.

ECS Express also defaults to canary deployments and accepts custom task definitions, including additional containers. There are a few restrictions, for example you can't change the deployment strategy or the service's load-balancer configuration. However, for anything that ECS Express mode can't do, you can just use plain ECS. And if you want containers packed onto managed EC2 capacity, ECS Managed Instances offers that model without Kubernetes.

Beanstalk itself adds no service charge. Cluster mode nevertheless introduces charges that Standard mode does not have: an EKS cluster fee and Auto Mode management fees on top of EC2.

At EKS's standard-support rate of $0.10 per cluster-hour, one continuously running cluster costs $73 over 730 hours (a month), before any application compute. Auto Mode adds an instance-specific charge. Check EKS pricing for more details.

Cluster mode may lower your AWS bill when the savings from shared capacity and other resources exceed its added fees. And you should also consider the hours saved and their value.

Consider these hypothetical compute and control-plane subtotals. Both options use m5a.xlarge instances. The assumptions are US East (N. Virginia), USD, Linux/x86, On-Demand, 730 hours, and EKS standard support. The prices when I wrote this (September 2026) are $0.172/hour for EC2 and $0.02064/hour for Auto Mode. Check for updates at EC2 regional rates and Auto Mode regional rates.

This is calculated using these formulas:
Standard = instance count * $0.172 * 730
Cluster = node count * ($0.172 + $0.02064) * 730 + $73

Compared to a single deployment on Standard mode, with the same number of instances, Cluster mode costs $103.13 more. If three shared nodes can replace six dedicated instances, it costs $258.48 less.

That second row assumes the smaller footprint can meet the same application requirements. Remember that real capacity needs include system overhead and room for failures and deployments, and infrastructure consolidation can be limited by those constraints.

To estimate your own case, start with your current instance bill and each application's CPU and memory demand, including periods when applications are busy at the same time. Use that demand calculation to size your resource needs. Keep in mind that EKS Auto Mode fits nodes to the aggregate requests, so oversized requests can mean you still need some of that spare capacity. Include the replica count, system overhead, and extra capacity your availability and rolling-deployment requirements need. That gives you a preliminary estimate on your node capacity and their cost, and you need to add to that the other charges. If the savings depend on uncertainties such as conditional node packing or traffic estimates you're not entirely sure about, try it anyways and run real tests, but make triple sure before migrating.

Standard-to-Cluster mode should be considered a migration to a new environment. The UpdateEnvironment API does not let you change an existing environment's tier into Cluster mode, you need to recreate things and redeploy.

The most important steps are:

An API that's already containerized and has all of its data stored outside the application's compute resources will be much easier to migrate than an application relying on host scripts, persistent local uploads, or Standard mode's SQS daemon. Estimate how much work this will be and how much you'll actually save before you get on the migraiton.

Elastic Beanstalk Cluster mode makes shared compute available through Beanstalk's application model, relying on EKS to do the infrastructure work for you. That is valuable when it removes deployment work you would otherwise have to do, or capacity you would otherwise have to manage and pay for (especially idle capacity). It can be worth a higher AWS bill when it avoids significant work, if you're already used to Elastic Beanstalk. Here's what I'd choose in each situation:

In case you couldn't tell, I'm not a fan of Elastic Beanstalk. That said, I understand several people like the developer experience it provides. I've always found Beanstalk Standard mode too restricted, and told people they should just get used to something else. Cluster mode makes Elastic Beanstalk useful again. So even if it's not my preferred developer experience, now I feel safe recommending it if that's what you like.