Elastic Beanstalk
Key concepts
Platform as a Service
Deployment policies
Environment types (web/worker)
Configuration files (.ebextensions)
Blue/green deployments
Overview
AWS Elastic Beanstalk is a Platform as a Service (PaaS), which means it provisions and manages the underlying infrastructure for you so you can focus on application code. You upload a code package (for example a JAR, ZIP, or Docker image) and Beanstalk automatically handles capacity provisioning, load balancing, auto scaling, and application health monitoring. Under the hood it creates standard AWS resources such as EC2 instances, an Auto Scaling group, an Elastic Load Balancer, security groups, and optionally an RDS database, all of which remain visible and editable in your account.
On the SAA-C03 exam, Elastic Beanstalk is a low-weight topic, but it appears in "fastest path to deploy a standard web app" scenarios and in questions about controlled releases. You should recognize that it is a PaaS abstraction over familiar services, know the difference between web server and worker environments, understand the deployment policies and their trade-offs (in-place versus immutable versus blue/green), and know that .ebextensions files customize the environment.
Managed Orchestration Over Familiar Resources
Elastic Beanstalk is the fastest managed way to deploy a standard web application on AWS. It orchestrates EC2, Auto Scaling, Elastic Load Balancing, and optional RDS for you while leaving every resource open for inspection and tuning. You keep full control of the stack and pay only for the resources it creates.
Remember the deployment policy trade-offs: All at once is fastest but causes downtime, Rolling and Rolling with additional batch reduce capacity risk, and Immutable plus Blue/Green give zero-downtime with fast rollback. Worker environments process Amazon SQS messages, and .ebextensions customizes the environment. Beanstalk itself is free; you pay for the underlying resources.
Key Concepts
Platform as a Service
What PaaS Means Here
Platform as a Service (PaaS) is a model where AWS manages servers, operating system patching, and provisioning while you supply application code and configuration. Elastic Beanstalk supports managed platforms for Java, .NET, Node.js, Python, PHP, Ruby, Go, and Docker. You upload an application version (a versioned code bundle), and Beanstalk builds an environment from a platform branch. It is free to use; you pay only for the EC2, load balancer, and other resources it provisions on your behalf.
Environment Types (Web Server and Worker)
Web Server vs Worker Environments
A web server environment serves HTTP requests directly. It places EC2 instances behind an Elastic Load Balancer in an Auto Scaling group and is the right tier for websites and APIs. A worker environment handles long-running or background processing. It reads messages from an Amazon SQS (Simple Queue Service) queue and forwards each one as a local HTTP POST to your application. A daemon process on each instance pulls from the queue, so worker tiers scale on queue depth. A common pattern decouples the two: the web tier accepts a request and enqueues a job, and the worker tier processes it asynchronously.
Web Server vs Worker Environment
| Dimension | Web Server Tier | Worker Tier |
|---|---|---|
| Traffic source | HTTP requests via load balancer | Messages from an SQS queue |
| Typical use | Websites and APIs | Background and long-running jobs |
| Front-end resource | Elastic Load Balancer | SQS daemon on each instance |
| Scaling signal | Request count, CPU, latency | Queue depth |
| Configuration file | cron.yaml not used | cron.yaml schedules periodic tasks |
Deployment Policies
How New Versions Roll Out
A deployment policy controls how Beanstalk replaces running application versions inside one environment. All at once updates every instance simultaneously, which is fast but causes brief downtime and a hard rollback. Rolling updates instances in batches, so capacity drops by one batch during the deploy. Rolling with additional batch launches a temporary extra batch first, keeping full capacity throughout. Immutable launches a parallel set of brand-new instances in a fresh Auto Scaling group, then swaps them in, which gives the safest in-environment deploy and a quick rollback by terminating the new instances. Traffic splitting is a canary style policy that sends a configurable percentage of traffic to new instances before full cutover.
Deployment Policies
| Policy | Downtime | Capacity During Deploy | Rollback Speed |
|---|---|---|---|
| All at once | Yes brief | Full set replaced at once | Slow redeploy |
| Rolling | No | Reduced by one batch | Manual redeploy |
| Rolling with additional batch | No | Maintained at full | Manual redeploy |
| Immutable | No | Full plus new parallel set | Fast terminate new |
| Traffic splitting | No | Full plus new parallel set | Fast shift traffic back |
Blue/Green Deployments
Swap Two Environments
A blue/green deployment runs two separate Beanstalk environments. Blue is the current live environment; green is a new environment running the new version. You deploy and test on green, then perform a swap environment URLs action, which exchanges the CNAME (the DNS name) records so traffic moves from blue to green with no downtime. Rollback is just another swap back to blue. This pattern suits major version changes and is the safest release option because the two environments are fully isolated. If the environment uses an RDS database that Beanstalk created, decouple the database first so it is not destroyed when an old environment is terminated.
In-Place Policies vs Blue/Green
| Dimension | In-Place Deployment Policies | Blue/Green |
|---|---|---|
| Number of environments | One environment updated | Two separate environments |
| Downtime | None to brief depending on policy | None |
| Rollback | Redeploy or terminate new instances | Swap URLs back to blue |
| Best for | Routine version updates | Major changes and platform upgrades |
| DNS change | No | Yes swap CNAME records |
Configuration Files (.ebextensions)
Customizing the Environment
.ebextensions is a directory inside your source bundle that holds YAML or JSON configuration files ending in .config. Beanstalk applies them during deployment to customize the environment: set option settings, install packages, run shell commands, define environment variables, create files, and adjust the Auto Scaling group or load balancer. The files are processed in alphabetical order. For environment properties and platform options you can also use option_settings. Use .ebextensions when the console or CLI options are not enough and you need repeatable, version-controlled environment configuration.
# .ebextensions/01-options.config
option_settings:
aws:autoscaling:asg:
MinSize: "2"
MaxSize: "6"
aws:elasticbeanstalk:application:environment:
APP_ENV: "production"
packages:
yum:
htop: []
commands:
01_create_dir:
command: "mkdir -p /var/app/cache"Best Practices
1. Pick the deployment policy by risk tolerance
├── Immutable or Blue/Green for production safety
└── Rolling with additional batch to hold full capacity
2. Decouple production databases from the environment
└── Run RDS outside Beanstalk so terminating an environment keeps the data
3. Separate web and worker tiers
└── Web tier enqueues work, worker tier reads SQS and processes it
4. Version-control environment config in .ebextensions
├── Keep option settings, packages, and commands in the source bundle
└── Name files with numeric prefixes to control apply order
5. Use Blue/Green for major platform or version changes
└── Test green fully, then swap URLs, and swap back to roll backCommon Pitfalls
Pitfall 1: Losing Data When an Environment Is Terminated
Mistake: Letting Beanstalk create the RDS database inside the environment for a production workload.
Why it fails: The database lifecycle is tied to the environment, so terminating or replacing the environment can delete the data.
Correct Approach: Provision RDS separately and connect to it with environment properties, so the database survives environment changes and blue/green swaps.
Pitfall 2: Using All at Once in Production
Mistake: Choosing the All at once deployment policy for a customer-facing application.
Why it fails: Every instance updates simultaneously, causing brief downtime, and a failed deploy requires a full redeploy to recover.
Correct Approach: Use Immutable or Blue/Green for production to keep capacity and enable fast rollback; reserve All at once for development environments.
Pitfall 3: Treating Beanstalk as a Black Box
Mistake: Assuming you cannot tune the EC2 instances, Auto Scaling group, or load balancer that Beanstalk creates.
Why it fails: Hidden assumptions lead to wrong sizing and missed customization, since every resource is standard and editable.
Correct Approach: Adjust resources through .ebextensions option settings or directly, and remember the underlying EC2, ELB, and Auto Scaling resources are fully visible.
Pitfall 4: Expecting a Worker Tier to Serve Web Traffic
Mistake: Putting a public API on a worker environment.
Why it fails: Worker environments have no public load balancer; they pull from an SQS queue and POST messages locally.
Correct Approach: Use a web server environment for HTTP traffic and a worker environment for background jobs fed by SQS.
Test Your Knowledge
A team wants the fastest managed way to deploy a standard Python web application on AWS without manually configuring EC2, load balancers, or Auto Scaling, while still being able to inspect and tune those resources later. Which service fits best?
A production Elastic Beanstalk application must release a major new version with zero downtime and the ability to roll back almost instantly if the new version misbehaves. Which approach best meets this requirement?
An application accepts user uploads through a public endpoint and must process each upload with a long-running background job without blocking the request. Which Elastic Beanstalk design fits best?
Related Services
Quick Reference
Decision Summary
Quick Decisions
| If you need... | Choose |
|---|---|
| Fastest managed deploy of a standard web app | Elastic Beanstalk web server tier |
| Background processing fed by a queue | Worker tier with SQS |
| Zero downtime with instant rollback | Blue/Green swap URLs |
| Hold full capacity during a deploy | Rolling with additional batch or Immutable |
| Repeatable environment customization | .ebextensions config files |
Common CLI Commands
# Initialize an application in the current directory
eb init my-app --platform python-3.11 --region us-east-1
# Create a web server environment
eb create prod-web --instance-types t3.small --elb-type application
# Deploy the current application version
eb deploy prod-web
# Set the deployment policy to Immutable (via option setting)
aws elasticbeanstalk update-environment \
--environment-name prod-web \
--option-settings Namespace=aws:elasticbeanstalk:command,OptionName=DeploymentPolicy,Value=Immutable
# Blue/Green: swap the CNAME between two environments
aws elasticbeanstalk swap-environment-cnames \
--source-environment-name prod-blue \
--destination-environment-name prod-green