Elastic Beanstalk

AWS Elastic Beanstalk is a PaaS (Platform as a Service, meaning AWS runs the servers and you just bring your code). You upload a .zip or .jar of your application, pick a platform like Node.js or Java, and Beanstalk builds the whole stack behind it: EC2 servers (virtual machines), a load balancer, an autoscaling group, and health monitoring. The big idea is that you get a running, scalable web app in minutes without writing any infrastructure code, while still keeping full access to every resource it created. It is one of the oldest “just deploy my app” services on AWS, and it is still a fast way to get started.

What Beanstalk actually provisions for you

When you create a Beanstalk environment (the running copy of your app), it spins up a coordinated set of real AWS resources on your behalf:

EC2 instances — the virtual machines that run your application code.
An ALB (Application Load Balancer — the component that spreads incoming requests across your servers).
An ASG (Auto Scaling Group — the rule set that adds or removes EC2 instances as traffic changes).
Health monitoring — Beanstalk continuously checks your instances and replaces unhealthy ones, and shows a green/yellow/red health status in the console.
A security group (a virtual firewall, e.g. sg-0a1b2c3d) and the networking wiring inside your VPC (e.g. vpc-0a1b2c3d).

The key difference from a fully managed service like App Runner is that all of these resources appear in your account. You can SSH into the EC2 instances, view the load balancer, and inspect the autoscaling group directly. Beanstalk is the orchestrator, not a black box.

Applications vs environments

Beanstalk has two layers. An application is a logical container for your project. Inside it you create environments — for example myapp-prod and myapp-staging — each of which is a full, independent stack. You deploy versions (your uploaded code bundles) into an environment.

When to use Beanstalk (and when not to)

Beanstalk is fast to start, but you can outgrow its opinionated, one-size-fits-most environment. Use the table below to decide.

Reach for Beanstalk when…	Choose App Runner instead when…	Choose ECS/Fargate instead when…
You want a traditional web app live in minutes	You have a container and just want an HTTPS URL	You need fine-grained control over networking and scaling
You’re learning AWS or building a prototype	You want the simplest possible managed path	You run many interconnected services
Your team isn’t ready to write IaC yet	You don’t want to manage any servers	You want lower per-unit cost at steady scale
You want to keep EC2 access “just in case”	Your traffic is small to moderate	You need sidecars, batch jobs, or non-HTTP workloads

Treat Beanstalk as a quick-start, not a long-term platform. For new projects in 2026, App Runner (simpler) or ECS on Fargate (more control) are usually the better long-term homes. Beanstalk shines for speed and for teams not yet ready to manage infrastructure directly.

Deploying an app

The recommended workflow uses the EB CLI (the dedicated eb command-line tool), but you can do everything from the console too.

Console steps

Open the Elastic Beanstalk console and choose Create application.
Enter an Application name like myapp.
Under Platform, pick your runtime (for example Node.js 20 or Corretto 21 for Java).
For Application code, choose Upload your code and upload your .zip (or use the provided sample to test).
Choose Configure more options to pick a single instance (cheap) or a load-balanced environment (scalable), then click Create.
Wait a few minutes. When the environment health turns green, click the URL at the top (for example http://myapp-prod.eba-abc123.us-east-1.elasticbeanstalk.com).

CLI equivalent

The EB CLI initializes a project, creates the environment, and deploys in three commands run from your project folder:

# 1. Link this folder to a new Beanstalk application
eb init myapp --platform "Node.js 20" --region us-east-1

# 2. Create a load-balanced environment (provisions EC2, ALB, ASG, health)
eb create myapp-prod --elb-type application --instance-types t3.small

# 3. Push new code later (zips the folder and rolls it out)
eb deploy myapp-prod

Output:

Creating application version archive "app-260615_143012".
Uploading myapp/app-260615_143012.zip to S3. This may take a while.
Environment details for: myapp-prod
  Application name: myapp
  Region: us-east-1
  CNAME: myapp-prod.eba-abc123.us-east-1.elasticbeanstalk.com
Printing Status:
INFO    Created Auto Scaling group: awseb-e-abc123-stack-AWSEBAutoScalingGroup
INFO    Created Application Load Balancer
INFO    Environment health has transitioned to Ok (Green)

To deploy without the EB CLI, you can also use the core aws elasticbeanstalk commands after uploading your bundle to S3:

aws elasticbeanstalk create-application-version \
  --application-name myapp \
  --version-label v2 \
  --source-bundle S3Bucket="myapp-deploys",S3Key="app-v2.zip"

aws elasticbeanstalk update-environment \
  --environment-name myapp-prod \
  --version-label v2

Configuring the environment

You tune Beanstalk through environment properties (your app’s environment variables) and .ebextensions (YAML config files committed in a .ebextensions/ folder in your project). For example, to set an environment variable and instance count:

# .ebextensions/options.config
option_settings:
  aws:elasticbeanstalk:application:environment:
    NODE_ENV: production
  aws:autoscaling:asg:
    MinSize: 2
    MaxSize: 6

This is the correct way to change Beanstalk-managed resources, because the changes flow back into the same source of truth.

The drift gotcha

Because the EC2 instances, load balancer, and autoscaling group live in your account, it is tempting to edit them directly in the EC2 console. Do not. Beanstalk treats its own configuration as the truth. If you manually change a setting it manages (for example the ASG min size, or a security group rule), Beanstalk may detect the difference as drift and revert it on the next deploy or health update. Always make changes through environment configuration or .ebextensions, never by hand.

Cost note: Beanstalk itself is free — you pay only for the resources it creates. A small single-instance environment on a t3.micro runs a few dollars a month, but a load-balanced environment adds the ALB (around $16–22/month plus data) and at least one always-on EC2 instance. To minimize cost while learning, choose single instance instead of load balanced, and run eb terminate myapp-prod to delete the whole stack when you’re done.

Best Practices

Use the EB CLI and commit .ebextensions to source control so your environment config is reproducible.
Never edit Beanstalk-managed EC2, ALB, or ASG resources by hand — change them through option_settings to avoid drift.
Keep separate environments (-staging, -prod) and promote a tested version between them rather than redeploying untested code.
Enable enhanced health reporting so you see per-request and per-instance health, not just a coarse green/red.
For real production traffic, use a load-balanced environment with MinSize: 2 so a single instance failure does not take you offline.
Plan an exit: if you hit Beanstalk’s limits, migrate to App Runner or ECS/Fargate before the workaround complexity grows.
Run eb terminate (or delete the environment in the console) to fully tear down resources and stop charges.