Elastic Beanstalk
What Problem It Solves
Standing up a production web app means wiring together an EC2 fleet, a load balancer, an Auto Scaling group, health checks, logging, deploy tooling, and rolling-update logic — every time. AWS Elastic Beanstalk does that wiring for you: you upload a code bundle (Java, .NET, Node, Python, Go, Ruby, PHP, Docker), pick an environment type, and Beanstalk provisions and manages the ALB + ASG + EC2 + CloudWatch stack, handles deployments and version rollback, and lets you tune capacity and settings through one console — a PaaS layer over your own AWS account, not a black box.
Global | Regional | AZ Scope
- An environment is Regional; its load balanced type spreads the Auto Scaling group across multiple AZs you choose for high availability. A single-instance environment (dev/test) lives in one AZ.
- Application versions (uploaded bundles) are stored in S3 in that Region; you promote the same version from a staging environment to a production environment.
- The underlying CloudFormation stack, EC2 instances, and ALB are all visible and editable in your account — Beanstalk just owns their lifecycle.
graph TD
DEV["Upload code bundle (.zip / Dockerfile)"] --> EB["Elastic Beanstalk Environment"]
EB -->|"provisions + manages"| STACK
subgraph STACK["Managed environment (multi-AZ)"]
ALB["Application Load Balancer"]
subgraph ASG["Auto Scaling Group"]
I1["EC2 (AZ-a)"]
I2["EC2 (AZ-b)"]
end
ALB --> I1
ALB --> I2
end
EB -.->|"health, logs, metrics"| CW(("CloudWatch"))
classDef eb fill:#f3ecfb,stroke:#8b3de0,stroke-width:2px,color:#3a1a5c
classDef inst fill:#e8f0fe,stroke:#3b82f6,stroke-width:2px,color:#173a70
class EB eb
class I1,I2 inst
Cost
Elastic Beanstalk adds no charge of its own. You pay the normal price of the resources it creates — EC2 instances, the ALB, EBS volumes, data transfer, and any RDS database if you let Beanstalk create one. Cost control is the same as running the stack by hand: right-size instances, set sensible Auto Scaling min/max, and use a single-instance environment for non-production.
Exam Tips
- Deployment policies: All at once (fastest, brief downtime), Rolling (batches, reduced capacity during deploy), Rolling with additional batch (keeps full capacity), Immutable (new ASG, safest rollback), Traffic splitting / blue-green (canary then swap CNAMEs).
- Blue-green on Beanstalk = deploy to a second environment, test, then swap environment URLs — near-zero downtime and instant rollback.
- Customize the platform with a
.ebextensions/folder (.configfiles) in the bundle for packages, files, and option settings; useDockerrun.aws.jsonfor container environments. - Let Beanstalk create the RDS instance only for dev/test — for production, create the database separately so it survives environment teardown.
- Trigger phrases: “deploy a standard web app with minimal ops,” “don’t want to manage the infrastructure but need access to it,” “automatic capacity, load balancing, and health monitoring.”
- Beanstalk vs App Runner vs ECS/EKS vs Lambda: Beanstalk when you want a managed EC2-based web tier you can still tune; App Runner for fully hands-off containers; ECS/EKS for full container orchestration control; Lambda for event-driven, no servers.