AWS Elastic Beanstalk is a gift to the DVA-C02 exam writers. It bundles EC2, Auto Scaling, load balancing, and health monitoring behind a single “just give me your code” abstraction — and then exposes a set of deployment policies and configuration files with just enough sharp edges to make good exam questions. If you can explain the difference between Rolling and Rolling with additional batch, and you know where a database migration command belongs in .ebextensions, you’ll pick up easy points that many candidates leave on the table.
This guide takes a practitioner’s view of Beanstalk for the AWS Certified Developer Associate (DVA-C02) exam: the object model, all five deployment policies side by side, the .ebextensions mechanics the exam loves, worker environments, and the blue/green pattern that Beanstalk does not implement the way you’d expect.
What Elastic Beanstalk Actually Is
Elastic Beanstalk is a Platform as a Service (PaaS). You upload an application bundle; Beanstalk provisions and manages the underlying AWS resources — EC2 instances, an Auto Scaling group, an Elastic Load Balancer, security groups, and CloudWatch alarms — and handles capacity, health, and updates. You keep full control of those resources (you can SSH to the instances, tweak the ASG, add resources), and Beanstalk itself is free — you pay only for the AWS resources it spins up.
Supported platforms include Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker (single-container and multi-container). For the exam, remember the positioning: Beanstalk is for developers who want their app deployed with production-grade infrastructure without hand-writing CloudFormation. It sits above raw EC2 and below fully-managed serverless like the SAM/Lambda stack.
The Object Model
Four terms show up constantly. Get them straight:
| Term | What it is |
|---|---|
| Application | The top-level container — holds versions, environments, and saved configs |
| Application version | A specific, labeled, deployable build of your code (stored as a bundle in Amazon S3) |
| Environment | An application version deployed onto a set of AWS resources (e.g. myapp-prod) |
| Environment tier | Either a Web Server tier (serves HTTP) or a Worker tier (processes background jobs) |
An application can run many environments — for example dev, staging, and prod — each running a possibly different application version. This separation is what makes the blue/green swap (below) possible.
Web Server tier vs Worker tier
- Web Server environment — handles HTTP requests. Backed by an ELB, an Auto Scaling group, and EC2 instances. This is the default.
- Worker environment — processes long-running or scheduled background tasks. A daemon called
sqsdon each instance pulls messages from an Amazon SQS queue and POSTs them to your application onlocalhost. For periodic jobs, add acron.yamlfile to schedule tasks. Decoupling web and worker tiers is a classic exam pattern: the web tier writes a job to SQS, the worker tier drains it.
Single-instance vs load-balanced
- Single instance — one EC2 instance with an Elastic IP, no load balancer. Cheap; good for dev.
- Load balanced / Auto Scaling — an ELB in front of an ASG. Production default, and required for most of the interesting deployment policies.
Deployment Policies: the Core Exam Topic
When you deploy a new application version to an existing environment, Beanstalk offers several deployment policies. This table is the single highest-yield thing to memorize:
| Policy | How it works | Capacity during deploy | Extra cost | Rollback | Downtime |
|---|---|---|---|---|---|
| All at once | Deploys to every instance simultaneously | Drops to zero briefly | None | Re-deploy old version | Yes (brief outage) |
| Rolling | Deploys in batches; each batch is taken out, updated, returned | Reduced (running fewer instances) | None | Re-deploy, or another rolling pass | No, but reduced capacity |
| Rolling with additional batch | Launches one extra batch first, then rolls through | Full throughout | Small (extra batch runs temporarily) | Another rolling pass | No |
| Immutable | Launches a whole new set of instances in a temporary ASG, deploys there, then swaps them in | Full (old set stays until new is healthy) | Higher (double instances temporarily) | Terminate the new instances | No |
| Traffic splitting | Like immutable, but shifts a percentage of live traffic to the new instances for evaluation (canary) | Full | Higher (double instances) | Shift traffic back, terminate new | No |
How to reason about the trade-offs the exam asks about:
- Fastest, cheapest, but risky → All at once. If the deploy fails, the whole environment is down.
- No extra cost but tolerate reduced capacity → Rolling.
- Maintain full capacity at low extra cost → Rolling with additional batch. The “additional batch” exists precisely to keep you at 100% capacity while a batch is being replaced.
- Safest, easiest rollback, willing to pay for double instances → Immutable. A failed deploy leaves the old instances untouched; you just terminate the new ASG.
- Canary / gradual validation with real traffic → Traffic splitting.
A detail worth remembering: single-instance environments only support All at once and Immutable (there’s no batch to roll through when you have one instance). Rolling policies require a load-balanced environment.
If a failed All at once or Rolling deploy leaves instances in a mixed or unhealthy state, you generally recover by deploying a known-good version again — the reduced-risk policies (immutable, traffic splitting) are what you choose when clean rollback matters. This connects directly to the deployment-strategy concepts in the DVA-C02 CI/CD guide.
Blue/Green on Beanstalk: Swap Environment URLs
Here’s the trap: Blue/Green is not one of the deployment policies above. Beanstalk implements blue/green with a separate technique — you run two environments and swap their URLs.
- Blue is your current production environment.
- Clone it (or create a fresh environment) as Green, and deploy the new version there.
- Test Green on its own environment URL.
- Swap Environment URLs — Beanstalk swaps the CNAME records so production traffic now points at Green.
- If something’s wrong, swap back.
Because the swap is a DNS CNAME change, it gives near-zero downtime and instant rollback, and it’s the right answer whenever a question mentions “deploy to a separate environment and cut over” or “test the new version in production-like conditions before sending traffic.” The CLI command is eb swap. Note the DNS caveat: clients holding a cached DNS record may take a little time to move — a normal consequence of CNAME-based cutover.
Configuration with .ebextensions
To customize the environment beyond the console defaults, add a folder named .ebextensions/ at the root of your source bundle, containing one or more files ending in .config (YAML or JSON). These are the keys the exam expects you to recognize:
# .ebextensions/01-setup.config
option_settings:
aws:elasticbeanstalk:application:environment:
APP_ENV: production
aws:autoscaling:asg:
MinSize: 2
MaxSize: 6
packages:
yum:
git: []
files:
"/etc/myapp/app.conf":
mode: "000644"
owner: root
content: |
log_level = info
commands:
01_make_dir:
command: "mkdir -p /var/app/data"
container_commands:
01_migrate:
command: "python manage.py migrate"
leader_only: truecommands vs container_commands — the classic question
This distinction is worth its own callout:
commandsrun early, on the instance OS, before your application source is extracted and set up. Use them for OS-level prep.container_commandsrun after the application has been extracted to a staging directory but before it is deployed to its final location. This is where database migrations and app-aware setup belong.leader_only: true(valid oncontainer_commands) makes the command run on only one instance in the environment. That’s exactly what you want for a DB migration — you don’t want every instance in the ASG runningmigrateagainst the same database simultaneously.
If an exam question asks “where do you put a database migration that must run once per deploy across a fleet?” the answer is a container_command with leader_only: true.
Adding AWS resources
.ebextensions can also declare extra CloudFormation resources under a Resources: key (an SQS queue, a DynamoDB table, an alarm), and set any environment option via option_settings. This is how you extend a Beanstalk environment without leaving the platform.
Configuration Precedence
When the same setting is defined in more than one place, Beanstalk applies this order (highest wins):
- Settings applied directly to the running environment (console, CLI
eb setenv, or API). - Saved configurations (reusable templates you save from an environment).
.ebextensionsfiles in the source bundle.- Default values.
The takeaway: a value set directly on the environment overrides the same option in .ebextensions. Candidates get tripped up when a .config file “isn’t taking effect” — often because a direct setting is winning.
RDS: Coupled vs Decoupled
Beanstalk can launch an RDS instance inside your environment, but for production this is usually the wrong call: the database’s lifecycle is then tied to the environment, so terminating the environment deletes the database. The recommended pattern is to create RDS separately (decoupled) and connect the Beanstalk instances to it via environment variables for the endpoint/credentials and a security group rule allowing access. Decoupling also lets you rebuild or blue/green-swap environments without touching data.
The EB CLI You Should Recognize
You won’t be asked to memorize every flag, but these commands appear in scenario wording:
| Command | Purpose |
|---|---|
eb init | Configure the app/platform/region for a project directory |
eb create | Create a new environment |
eb deploy | Deploy the current source to the environment |
eb status / eb health | Show environment and instance health |
eb logs | Pull instance logs |
eb setenv KEY=value | Set environment variables (applied directly — highest precedence) |
eb swap | Swap two environments’ CNAMEs (blue/green cutover) |
eb open | Open the environment URL in a browser |
Enhanced Health Reporting
Beanstalk offers basic and enhanced health reporting. Enhanced health installs a health agent on each instance and gives you a richer status model — Green / Yellow / Red / Grey — plus per-instance metrics pushed to CloudWatch. It requires the appropriate instance profile and service role. When a question mentions detailed, real-time environment health with color-coded status and CloudWatch integration, that’s enhanced health. For the broader monitoring toolset, see the DVA-C02 monitoring & troubleshooting guide.
Common Exam Traps
- Blue/green is a URL swap, not a deployment policy. Don’t pick “blue/green” from a list of deployment policies — it isn’t there.
- Rolling with additional batch is the one that keeps you at full capacity during a rolling deploy. Plain rolling runs at reduced capacity.
- Immutable deploys to a new set of instances and is the safest for rollback; it costs more because instances temporarily double.
- Database migrations →
container_commandswithleader_only: true, notcommands. - Direct environment settings override
.ebextensions. Precedence matters. - Beanstalk is free; you pay for the underlying EC2/ELB/RDS resources.
- Worker tier uses SQS +
sqsd, withcron.yamlfor scheduled tasks.
Practice Beanstalk Before Exam Day
Beanstalk questions reward precision — the exam distinguishes people who can recite “rolling with additional batch = full capacity” from people who guess. The AWS Certified Developer Associate (DVA-C02) Mock Exam Bundle includes deployment-policy scenarios, .ebextensions placement questions, and blue/green cutover cases with explanations that reinforce why each option is right or wrong. Pair it with the DVA-C02 Study Plan to sequence Beanstalk alongside the rest of the deployment domain, and review the exam topics breakdown so you know how much weight deployment carries.
Frequently Asked Questions
Which Elastic Beanstalk deployment policy maintains full capacity at the lowest extra cost?
Rolling with additional batch. It launches one extra batch of instances so the environment stays at 100% capacity throughout the deploy, at only the cost of that temporary extra batch — cheaper than Immutable, which doubles the fleet.
Is Blue/Green a deployment policy in Elastic Beanstalk?
No. Blue/green is done by deploying to a separate environment and using Swap Environment URLs (eb swap) to cut over via a CNAME change. The named deployment policies are All at once, Rolling, Rolling with additional batch, Immutable, and Traffic splitting.
Where do I put a database migration in Elastic Beanstalk?
In a container_command inside .ebextensions, with leader_only: true so it runs on a single instance rather than every instance in the Auto Scaling group. container_commands run after the app is set up but before it’s deployed; commands run too early, before your source is extracted.
What’s the difference between the Web Server and Worker environment tiers?
The Web Server tier serves HTTP traffic behind a load balancer. The Worker tier runs a daemon (sqsd) that pulls messages from an SQS queue and delivers them to your app for background processing, with cron.yaml for scheduled tasks.
Does Elastic Beanstalk cost extra?
No. There’s no additional charge for Beanstalk itself — you pay only for the underlying resources it provisions (EC2, ELB, RDS, S3 storage for versions, etc.).
Why isn’t my .ebextensions setting taking effect?
Most often because a setting applied directly to the environment (via the console, API, or eb setenv) has higher precedence and is overriding it. The order is: direct settings > saved configurations > .ebextensions > defaults.
Should I let Beanstalk create my RDS database?
Not for production. An RDS instance created inside the environment is deleted when the environment is terminated. Create RDS separately and connect via environment variables and security groups so your data survives environment rebuilds and blue/green swaps.