AWS announced on September 17, 2026, the general availability of Cluster Mode in the AWS Elastic Beanstalk service. The new mode allows teams to provide source code, a Docker file, or a container image, while Elastic Beanstalk creates and manages the runtime environment, including deployment, scaling, debugging, monitoring, and upgrades throughout the application’s operation.
Cluster Mode targets teams managing a collection of applications rather than running each application in a fully separate environment. The new architecture is based on Amazon Elastic Kubernetes Service (Amazon EKS), with a single operational baseline managed by Elastic Beanstalk. According to AWS, applications can share resources, which may reduce the cost per application as the portfolio grows without adding a comparable operational burden.
What does the new mode provide?
Applications written in Java, .NET, Python, Node.js, PHP, Ruby, and Go can be deployed directly from source code. Elastic Beanstalk uses Cloud Native Buildpacks to create containers when needed, without requiring the team to write a Dockerfile or reengineer the application. The mode also supports ready-made container images, and deployments can be managed through the console, AWS CLI, EB CLI, or AWS SDKs.
- Deployment strategies including all at once, rolling, immutable, and traffic splitting with automatic rollback on failure.
- Event-based automatic scaling and integration with AWS Secrets Manager for secret management.
- OpenTelemetry-based monitoring, with the ability to integrate with monitoring tools, including Amazon CloudWatch.
- AI-powered analysis of environment health issues, with service-side log collection and recommendations for resolving failures.
- HTTPS support by default through AWS Certificate Manager, with a compliance posture that includes HIPAA eligibility, PCI DSS compliance, and alignment with SOC 1/2/3, according to AWS.
What changes in practice for teams?
Cluster Mode shortens the distance between deploying a traditional application and managing it within a shared container environment. When the first environment is created for a specific subnet group, the service creates an EKS cluster, and the process may take approximately ten minutes. Subsequent deployments benefit from the existing cluster, according to AWS. Multiple microservices can run within the same application, with settings for resources such as the number of replicas, CPU units, memory, port, and health-check path for each service.
Most importantly, teams are not forced to move from the current mode. Elastic Beanstalk Standard environments, backed by Amazon EC2, continue to operate, and Standard and Cluster Mode environments can run side by side within the same Elastic Beanstalk application. The service also performs compatibility checks before changes, enabling gradual migration.
When is Cluster Mode not the best option?
AWS says Standard Mode remains suitable for single applications or single environments, Windows/.NET Framework workloads running on IIS, and applications that cannot be containerized. It may also be more suitable for workloads spending less than $500 per month, because EKS control plane charges and the surcharge associated with EKS Auto Mode may add costs that resource sharing in a single application does not offset.
Availability and cost
Cluster Mode is generally available in all AWS Regions where Elastic Beanstalk is available. AWS does not charge an additional fee for Cluster Mode itself, but the customer pays for the underlying resources consumed by the applications, including EKS control plane charges, EKS Auto Mode compute, Amazon ECR, and Amazon CloudWatch. The service is not eligible for the AWS Free Tier.
certi.news analysis: The actual change is not merely a new deployment option, but the transfer of responsibility for operating a group of containerized applications to the Elastic Beanstalk layer while using EKS behind the scenes. This may benefit teams that want to standardize operations and reduce manual work, but the decision is not determined by the absence of an additional service fee; EKS costs and supporting resources, along with the application’s compatibility with containers, remain decisive factors. The source also provides no performance figures or actual cost comparison between the two modes, so workload and cost should be tested before migrating a large production portfolio.