Cloud Parts

AWS Elastic Beanstalk

Upload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.

What it is
Platform as a service (PaaS)
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
12 October 2026
Website

What it is

You create an application, upload a version of your code as a source bundle, and launch it into an environment. For a web server environment in Standard mode, Elastic Beanstalk creates an Application Load Balancer by default, an Auto Scaling group of EC2 instances, security groups, CloudWatch alarms that drive scaling, and an S3 bucket for code and logs. It launches all of this through a CloudFormation stack whose template you can open, and gives the environment a URL such as myapp.us-west-2.elasticbeanstalk.com. A host manager on each instance deploys the code, rotates logs and reports health. A worker environment instead runs a daemon that pulls messages from an SQS queue and POSTs each one to your app on localhost.

A platform is an operating system, language runtime, web server and Elastic Beanstalk components, packaged as an AMI. Current platforms cover Docker, Go, Java SE, Tomcat, .NET Core on Linux, .NET on Windows Server, Node.js, PHP, Python and Ruby; the Linux ones run Amazon Linux 2023. New versions roll out with all-at-once, rolling, rolling with an extra batch, immutable or traffic-splitting deployments, or blue/green by swapping two environments’ URLs. Elastic Beanstalk itself is free: you pay for the EC2 instances, load balancers and other resources it creates.

Since September 17, 2026 there is also Cluster mode. Instead of dedicated instances per environment, Elastic Beanstalk runs your app as a container image on an EKS cluster that it creates and shares between your environments, with nodes supplied by EKS Auto Mode and replicas scaled between a minimum and maximum. You pay for the EKS cluster and Auto Mode charges on top of the EC2 capacity.

Why teams pick it

  • No charge for the service itself; compute is billed at EC2 rates, so Reserved Instances, Savings Plans and Spot all apply
  • Nothing is hidden: you can pick instance types, SSH into instances, and add any CloudFormation resource to the environment’s template from .ebextensions files
  • Five deployment policies plus blue/green CNAME swaps cover most release styles without extra tooling
  • Worker environments come with a managed SQS queue, a daemon that delivers messages over HTTP, and cron-style periodic tasks

Watch out for

  • In Standard mode every environment has its own instances and load balancer, and Auto Scaling always keeps at least one instance running, so many small apps add up
  • Platform versions are retired when their components reach end of life, and moving to an incompatible platform version requires a blue/green deployment
  • The default all-at-once deployment updates instances in place, so the app can be briefly unavailable unless you choose another policy
  • Cluster mode uses its own configuration namespaces and none of the classic compute ones apply, so an existing environment’s settings have to be rewritten to move to it

Alternatives

What all platform as a service (paas) have in common →
Azure App ServiceAzureAzure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.DokkuOpen sourceA Heroku-like PaaS on one server of your own: `git push` to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.Fly.ioCommercialFly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.Google App EngineGoogle CloudGoogle’s original platform as a service: describe your app in an `app.yaml`, run one deploy command, and Google runs and scales the instances.HerokuCommercialThe platform that defined PaaS: `git push` your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.

How it fits with other technologies

Create an environment with the EB CLI, deploy, then swap blue/green · bash

eb init shop-api --region eu-west-1 \
  --platform "Python 3.13 running on 64bit Amazon Linux 2023"
eb create shop-blue --instance_type t3.small \
  --min-instances 2 --max-instances 6
eb deploy shop-blue

# Release a risky change to a second environment, then swap URLs
eb create shop-green
eb swap shop-blue --destination_name shop-green

See it in a real stack

No architecture uses AWS Elastic Beanstalk yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2011–2026

By 2011, developers who didn’t want to manage servers could use platforms such as Heroku for Ruby on Rails, several of which ran on AWS. They were simple but hid the stack underneath. Amazon announced AWS Elastic Beanstalk in public beta on January 19, 2011, as a way to get the same convenience without giving up control: upload your app and it provisions capacity, load balancing, auto-scaling and health monitoring, while every resource stays visible in your account.

Jeff Barr’s launch post explained that the beanstalk was “built using a number of existing AWS services, not from magic beans”: EC2 instances, an Elastic Load Balancer and an Auto Scaling group. The beta supported only Java web apps packaged as WAR files and run on Tomcat. In a post of the same day, Werner Vogels said AWS wanted to let many development platforms bloom rather than build one, and that Elastic Beanstalk targeted both app developers and platform builders who wanted control of the stack.

Other languages followed: PHP with Git-based deploys in March 2012, then Node.js, Python, Ruby and .NET, and Docker in April 2014. In September 2026 AWS added Cluster mode, which packs many applications onto a shared EKS cluster instead of giving each one its own instances.

Why it’s built this way

Built from ordinary AWS resources in your account
Vogels wrote that Elastic Beanstalk “stays true to the AWS principles by not locking customers into a black box”: the instances, load balancer and scaling group it creates are normal resources you can inspect and tune.
Gradual control instead of a fixed platform
Barr described letting developers start with no configuration and then take over pieces as needed: choose the instance type, log in to instances, or build a custom AMI from the default one.
No charge beyond the resources
AWS charged nothing for Elastic Beanstalk itself, only for the EC2 and other resources it created, so a small app could run within the AWS Free Usage Tier.

Timeline

  1. 2011

    Public beta on January 19, for Java apps on Tomcat

  2. 2012

    PHP support and Git-based deployment

  3. 2014

    Docker support, joining Node.js, PHP, Python, .NET, Java and Ruby

  4. 2026

    Cluster mode runs many applications on a shared EKS cluster

Sources13 · facts checked 12 October 2026

Improve this page on GitHub