DEV Community

Cover image for AWS Elastic Beanstalk Cluster Mode: EKS Without Writing YAML
Ajeet yadav
Ajeet yadav

Posted on Originally published at codingprotocols.com

AWS Elastic Beanstalk Cluster Mode: EKS Without Writing YAML

AWS Elastic Beanstalk Cluster Mode: The Important Part AWS Doesn't Emphasize

AWS recently introduced Cluster Mode for Elastic Beanstalk.

The basic idea is simple: instead of giving every environment its own EC2 Auto Scaling group, Elastic Beanstalk can run your application as containers on an AWS-managed EKS cluster.

That gives you:

  • Container-based deployments
  • Shared infrastructure across environments
  • EKS Auto Mode for underlying capacity
  • Rolling deployments
  • No Kubernetes YAML to maintain
  • Less infrastructure to operate

But there's an important trade-off.

The decisions you make at creation time matter

Cluster Mode uses your VPC subnet set to determine the EKS cluster your environment belongs to.

If multiple environments use the same subnet set, they can share the same cluster.

The Kubernetes version is also selected when the cluster is created and remains fixed for that cluster's lifetime.

There are similar constraints around cluster-level IAM configuration.

So Cluster Mode isn't simply:

"Elastic Beanstalk, but running on EKS."

It's closer to:

"Elastic Beanstalk manages the EKS complexity for you — but you give up some of the control that comes with managing EKS yourself."

The operational trade-off

With Standard Mode, you're thinking about:

EC2
Auto Scaling
Instance Types
SSH
Host-level configuration
Enter fullscreen mode Exit fullscreen mode

With Cluster Mode, the model becomes:

Containers
Replicas
CPU / Memory
EKS
Application-level observability
Enter fullscreen mode Exit fullscreen mode

You don't manage the underlying node fleet in the same way, and host-level troubleshooting changes significantly.

That's a good thing if your goal is to avoid operating Kubernetes.

It's less attractive if your application depends on deep infrastructure customization or host-level access.

When should you use it?

Cluster Mode is particularly interesting for teams running multiple containerized applications that don't want to operate their own EKS clusters.

Standard Mode can still make more sense for:

  • Simple or low-spend applications
  • Workloads requiring host-level access
  • Applications that aren't container-friendly
  • Workloads needing deeper infrastructure control

The biggest thing to remember is:

Managed doesn't mean unconstrained.

Cluster Mode removes a lot of operational work, but it also removes some infrastructure-level decisions.

Top comments (0)