This chapter covers AWS Elastic Beanstalk, a Platform-as-a-Service (PaaS) offering that automates the deployment and management of applications in the AWS cloud. For the DVA-C02 exam, Elastic Beanstalk is a major topic under Deployment Domain (Objective 3.1), appearing in roughly 10-15% of questions. You need to understand how it works, its components, deployment strategies, and how it integrates with other services like CloudFormation, CodePipeline, and RDS. This chapter provides the deep, exam-focused knowledge required to confidently answer any Elastic Beanstalk question.
Jump to a section
Imagine you want to host a dinner party. Instead of cooking, setting the table, and cleaning yourself, you go to a full-service restaurant. You tell the chef what dish you want (your application code), and the restaurant handles everything else: they source ingredients (provision resources), prepare the meal (deploy code), set the table (configure networking), serve the food (run the application), and clean up afterward (monitor and auto-scale). You don't need to know how the kitchen works or where the plates are stored—you just get a perfectly served meal. Elastic Beanstalk works the same way: you provide your application code (and optionally a configuration file), and Beanstalk automatically provisions the underlying AWS resources—EC2 instances, load balancers, auto-scaling groups, security groups, RDS databases (if configured), and more. It manages the deployment, health monitoring, and scaling, allowing you to focus on writing code rather than managing infrastructure. However, you still have full control over the environment if you need to tweak something—just like you can request a specific table or ask for a custom dish. The restaurant analogy breaks down when you need to customize the underlying infrastructure; Beanstalk lets you modify any resource via configuration files or the AWS console, giving you the flexibility of a 'DIY' approach while retaining the convenience of a managed service.
What is AWS Elastic Beanstalk?
AWS Elastic Beanstalk is a fully managed service that automates the deployment, scaling, and monitoring of web applications and services. It supports a variety of platforms including Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker. You simply upload your application code (or a Docker image), and Elastic Beanstalk handles the rest—provisioning AWS resources like EC2 instances, Auto Scaling groups, Elastic Load Balancers, and security groups. It also provides built-in health monitoring, log access, and environment management. Elastic Beanstalk is designed to give developers a quick way to deploy applications without needing deep knowledge of AWS infrastructure, while still allowing full control when needed.
How Elastic Beanstalk Works Internally
When you create an Elastic Beanstalk environment, the service uses AWS CloudFormation under the hood to provision and manage resources. The process involves the following steps:
Application Version: You upload a source bundle (e.g., a ZIP or WAR file) containing your application code. This is stored in an S3 bucket managed by Elastic Beanstalk.
Environment Configuration: You specify the platform (e.g., Python 3.8), instance type, key pair, and optional settings like environment variables or database connections.
Resource Provisioning: Elastic Beanstalk creates a CloudFormation stack that includes:
- An Auto Scaling group (default: min=1, max=4 instances) - An Elastic Load Balancer (ALB or Classic LB) - Security groups for the instances and load balancer - An Amazon RDS database (optional, not recommended for production—use separate RDS) - An S3 bucket for logs and deployment artifacts 4. Deployment: The application code is deployed to the EC2 instances. The platform runs a web server (e.g., Apache, Nginx) and application server (e.g., Tomcat, Passenger) to serve requests. 5. Health Monitoring: Elastic Beanstalk monitors the health of the environment using HTTP requests to the application. It checks for 200 OK responses and can trigger instance replacement if health checks fail. 6. Scaling: Based on CloudWatch alarms (e.g., CPU utilization > 75% for 5 minutes), the Auto Scaling group adds or removes instances.
Key Components and Defaults
Application: The top-level container for your code and environments. An application can have multiple environments (e.g., dev, test, prod).
Environment: A running instance of your application with its own set of AWS resources. Each environment has a CNAME (e.g., myapp-dev.us-east-1.elasticbeanstalk.com).
Platform: The combination of operating system, web server, and language runtime. Examples: 'Python 3.8 running on 64bit Amazon Linux 2'.
Environment Tier:
Web Server Tier: For standard HTTP applications, includes a load balancer and Auto Scaling group.
Worker Tier: For background processing tasks, includes an SQS queue and an Auto Scaling group that pulls messages from the queue.
Configuration Files (.ebextensions): YAML or JSON files placed in the .ebextensions folder of your source bundle. They allow you to customize resources, install packages, run commands, and set environment variables. They are processed by CloudFormation during deployment.
Saved Configurations: You can save environment settings as a template to reuse or share.
Deployment Policies:
All at once: Deploys to all instances simultaneously. Fast but causes downtime.
Rolling: Deploys in batches (e.g., 2 instances at a time). Reduces downtime but still some.
Rolling with additional batch: Launches new instances to maintain capacity during deployment.
Immutable: Launches a new Auto Scaling group with new instances, then swaps traffic. Zero downtime, but doubles capacity temporarily.
Blue/Green: Not a native policy—you create a separate environment and swap CNAMEs.
Health Check URL: Default is '/' but can be customized to a specific path (e.g., /health).
Environment Properties: Key-value pairs that become environment variables on the instances. Used for database URLs, secrets, etc.
Configuration and Verification Commands
You can interact with Elastic Beanstalk using the AWS Management Console, AWS CLI, or EB CLI. The EB CLI is a specialized tool for developers. Key commands:
# Initialize a project
$ eb init -p python-3.8 my-app
# Create an environment
$ eb create my-env
# Deploy a new version
$ eb deploy
# Open the application in browser
$ eb open
# View logs
$ eb logs
# SSH into an instance
$ eb ssh
# List environments
$ eb list
# Terminate an environment
$ eb terminate my-envHow Elastic Beanstalk Interacts with Related Technologies
CloudFormation: Every Elastic Beanstalk environment is backed by a CloudFormation stack. You can view the stack in CloudFormation console to see all resources.
CodePipeline: You can integrate Beanstalk with CodePipeline for CI/CD. The pipeline can automatically deploy to Beanstalk when code changes are pushed to a repository.
RDS: While Beanstalk can create an RDS database as part of the environment, this is not recommended for production because the database lifecycle is tied to the environment. Instead, use a separate RDS instance and pass the connection string via environment properties.
IAM: Beanstalk creates an instance profile role (aws-elasticbeanstalk-ec2-role) that allows EC2 instances to access S3, CloudWatch, etc. You can customize this role.
CloudWatch: Beanstalk sends metrics (CPU, latency, request count) to CloudWatch and can trigger alarms for scaling.
VPC: Beanstalk launches resources in your default VPC unless you specify a custom one. You can configure subnets, security groups, and load balancer settings.
Lifecycle and Version Management
Each application version is stored in S3. You can have up to 500 versions per application (soft limit, can be increased). Beanstalk provides a lifecycle policy to automatically delete old versions based on age or count. You can also create applications from a saved configuration or a sample application.
Deployment and Rollback
Beanstalk supports rollback to a previous version. When you deploy a new version, the old version is retained. You can roll back by deploying the old version again. However, note that rollback using 'All at once' will cause downtime. Immutable deployments are safer but slower.
Environment Types
Single Instance: For development, no load balancer. One EC2 instance.
Load Balanced: For production, includes an ALB (or Classic LB) and Auto Scaling group.
Worker: Processes tasks from an SQS queue. The environment runs a daemon that polls the queue and sends messages to the application via HTTP.
Customization via .ebextensions
.ebextensions files allow you to:
Install packages (e.g., yum packages)
Create Linux users and groups
Add commands to run during deployment (e.g., database migration)
Modify the software configuration (e.g., nginx settings)
Add CloudFormation resources (e.g., an S3 bucket)
Example .ebextensions file:
# .ebextensions/01-install-packages.config
packages:
yum:
htop: []
commands:
01_migrate:
command: "python manage.py migrate"
cwd: /var/app/current
leader_only: trueEnvironment Manifest File
You can include a env.yaml file in your source bundle to define environment settings (e.g., option settings, platform version). This is useful for reproducible deployments.
High Availability and Disaster Recovery
Beanstalk environments can be configured with Multi-AZ deployments for RDS (if using separate DB) and Auto Scaling across multiple Availability Zones. For disaster recovery, you can create a second environment in another region and use Route53 to failover.
Pricing
Elastic Beanstalk itself is free. You only pay for the underlying AWS resources (EC2, ELB, RDS, etc.).
Exam Tips
Remember that Beanstalk is a PaaS, not IaaS. It abstracts infrastructure but allows customization.
Know the deployment policies and when to use each (e.g., immutable for zero downtime, all at once for quick dev deploys).
Understand that .ebextensions are processed during deployment and can be used to run scripts.
Be aware that RDS integration is possible but not recommended for production.
Know that you can use EB CLI, AWS CLI, or console to manage environments.
Remember that Beanstalk uses CloudFormation internally.
For CI/CD, CodePipeline can deploy to Beanstalk directly.
Worker environments use SQS to decouple tasks.
The health check URL can be customized.
Environment properties are set as OS environment variables.
You can swap environment CNAMEs for blue/green deployment.
Beanstalk supports Docker, including multi-container Docker with ECS.
The default EC2 instance profile is aws-elasticbeanstalk-ec2-role.
Beanstalk automatically rotates logs to S3.
You can enable enhanced health reporting for more detailed metrics.
Environment updates can be performed with minimal downtime using rolling or immutable updates.
Beanstalk supports version labels to identify application versions.
You can use the AWS Management Console to monitor environment health and view recent events.
Prepare Application Source Bundle
First, you package your application code into a source bundle. For a Java application, this might be a WAR file. For Python, a ZIP file containing your code and a requirements.txt. The bundle must be less than 512 MB. You can include a .ebextensions folder for custom configuration. The bundle is uploaded to an S3 bucket managed by Elastic Beanstalk. This step is crucial because the bundle defines what code will run. The exam may test that you know the size limit and that the bundle must be a ZIP or WAR file.
Create Application and Environment
Using the AWS Management Console, AWS CLI, or EB CLI, you create an application (logical container) and an environment (running instance). You specify the platform (e.g., Python 3.8), environment tier (web server or worker), and configuration settings. Elastic Beanstalk then creates a CloudFormation stack that provisions resources like EC2 instances, Auto Scaling groups, and load balancers. The environment receives a CNAME like myapp.elasticbeanstalk.com. The exam often asks about the difference between application and environment.
Deploy Application Version
You upload your source bundle to Elastic Beanstalk, which deploys it to the EC2 instances. The deployment method (all at once, rolling, immutable) determines how traffic is shifted. During deployment, the platform runs scripts to set up the application (e.g., installing dependencies, running database migrations). The health check URL is pinged to ensure the application is responsive. If health checks fail, the deployment may be rolled back. The exam tests the deployment policies and their impact on downtime.
Monitor and Manage Environment
After deployment, Elastic Beanstalk continuously monitors the environment health using HTTP health checks (default: every 10 seconds). Metrics like CPU utilization, request latency, and response status are sent to CloudWatch. You can view logs, set up alarms, and configure automatic scaling based on metrics. The environment may replace unhealthy instances automatically. The exam focuses on health check configuration and CloudWatch integration.
Scale and Update Environment
As traffic increases, the Auto Scaling group adds more EC2 instances based on CloudWatch alarms (e.g., CPU > 75% for 5 minutes). You can also manually scale. When you need to update the application, you upload a new version and deploy using a chosen policy. Immutable deployment launches a new Auto Scaling group, validates health, then swaps traffic. This provides zero downtime but doubles capacity. The exam tests scaling triggers and deployment strategies.
Enterprise Scenario 1: Rapid Prototyping and Internal Tools
A startup building a SaaS product uses Elastic Beanstalk to quickly deploy a Python Flask API. The development team pushes code to GitHub, which triggers a CodePipeline build that deploys to a Beanstalk environment. The environment uses a load-balanced tier with an ALB and Auto Scaling group set to min=2, max=10 instances. The team uses immutable deployments to ensure zero downtime during updates. Environment properties store database connection strings and API keys. The health check URL is set to /api/health. The team saves configurations for staging and production environments. A common misconfiguration is not setting the health check URL correctly, causing false health failures. The team also uses .ebextensions to install system packages and run database migrations. The service handles thousands of requests per second with auto-scaling. The main challenge is managing environment variables securely; they use AWS Secrets Manager with a custom script to fetch secrets at startup.
Enterprise Scenario 2: E-commerce Platform with Worker Tier
An e-commerce company uses Elastic Beanstalk for its order processing system. The web tier handles HTTP requests, and a worker tier processes background tasks like sending confirmation emails and updating inventory. The worker tier pulls messages from an SQS queue. The company uses the worker tier's built-in cron daemon to schedule periodic tasks (e.g., daily report generation). They configure the worker environment to scale based on queue depth (number of messages). A common pitfall is that the worker tier's health check is based on the daemon's ability to poll the queue, not the application's health. The company also uses Blue/Green deployment by creating a second environment and swapping CNAMEs in Route53. They use CloudFormation to manage the Beanstalk environments as part of a larger infrastructure stack. Performance considerations include ensuring the SQS queue is in the same region and that the worker application is idempotent to handle duplicate messages.
Enterprise Scenario 3: Multi-Container Docker Application
A media company runs a web application using multiple Docker containers (frontend, backend, and a cache). They use Elastic Beanstalk's multi-container Docker platform, which runs on an ECS cluster. The Dockerrun.aws.json file defines the containers, their images, ports, and links. The environment uses an ALB to route traffic to the frontend container. The company uses immutable deployments to update the environment. They store Docker images in Amazon ECR. A common mistake is not setting the correct memory reservation for containers, causing the ECS task to fail. The company also uses .ebextensions to mount an EFS file system for shared storage across containers. The environment handles high traffic by scaling the ECS tasks. The main challenge is debugging containerized applications; they rely on CloudWatch Logs and the EB logs command.
What Goes Wrong When Misconfigured
Health Check Misconfiguration: Setting the health check URL to a path that returns a non-200 response causes the environment to become 'Severe' and may trigger instance replacement unnecessarily.
Security Group Rules: If the security group does not allow inbound traffic on the application port, the load balancer health checks fail.
Database Credentials: Hardcoding database credentials in the code is a security risk; use environment properties or Secrets Manager.
Deployment Policy: Using 'All at once' in production causes downtime; teams often forget to switch to immutable.
Incorrect Instance Profile: If the EC2 instance profile lacks permissions to access S3 or CloudWatch, deployments fail or logs are not uploaded.
DVA-C02 Exam Focus on Elastic Beanstalk
Elastic Beanstalk is tested under Domain 3: Deployment (Objective 3.1: Deploy applications using AWS Elastic Beanstalk). The exam expects you to know:
How to create and manage Beanstalk applications and environments.
Deployment policies and their impact on downtime and resource usage.
Configuration via .ebextensions and environment properties.
Integration with CodePipeline, RDS, and CloudFormation.
Health monitoring and auto-scaling configuration.
Worker tier and SQS integration.
Common Wrong Answers and Why Candidates Choose Them
'Elastic Beanstalk is an IaaS service.' Candidates often confuse PaaS with IaaS. Beanstalk abstracts infrastructure, so it is PaaS. The wrong answer is attractive because you can see EC2 instances, but you don't manage them directly.
'You must manually create an Auto Scaling group before using Beanstalk.' Beanstalk creates Auto Scaling groups automatically. Candidates who think they need to pre-create resources choose this.
'RDS should always be created as part of the Beanstalk environment.' This is a trap. The exam emphasizes that for production, you should use a separate RDS instance to avoid data loss when the environment is terminated.
'All at once deployment is best for production because it is fastest.' Candidates choose this because it is fast, but it causes downtime. Immutable is better for zero downtime.
Specific Numbers and Terms That Appear on the Exam
Default health check interval: 10 seconds.
Default health check path: '/' (root).
Default Auto Scaling: min=1, max=4.
Source bundle size limit: 512 MB.
Maximum application versions per application: 500 (soft limit).
Deployment policies: All at once, Rolling, Rolling with additional batch, Immutable.
Environment tiers: Web Server, Worker.
Platform: e.g., 'Python 3.8 running on 64bit Amazon Linux 2'.
.ebextensions folder must be in the root of the source bundle.
EB CLI commands: eb init, eb create, eb deploy, eb open, eb logs, eb ssh.
Edge Cases and Exceptions the Exam Loves to Test
Blue/Green Deployment: Beanstalk does not have a native Blue/Green policy. You must create a separate environment and swap CNAMEs (or use Route53 weighted records).
Worker Tier Cron: The worker tier can run scheduled tasks using a cron.yaml file in the source bundle. This is often tested.
Enhanced Health Reporting: Must be explicitly enabled. It provides additional metrics like request count and latency.
Docker: Beanstalk supports single-container Docker and multi-container Docker (using ECS). The multi-container option uses a Dockerrun.aws.json file.
Environment Update: Changing configuration (e.g., instance type) causes a rolling update that may cause downtime if not configured properly.
How to Eliminate Wrong Answers
If the question mentions 'zero downtime' and 'automated infrastructure', look for immutable deployment or Blue/Green (via CNAME swap).
If the question involves 'background processing' or 'task queue', the answer is likely Worker tier with SQS.
If the question asks about 'customizing the operating system', the answer is .ebextensions.
If the question mentions 'CI/CD pipeline', think CodePipeline integration.
If the question asks about 'database lifecycle tied to environment', rule out creating RDS inside Beanstalk for production.
Elastic Beanstalk is a PaaS service that automates deployment, scaling, and monitoring of web applications.
You provide a source bundle (ZIP/WAR, max 512 MB) and Beanstalk provisions EC2, ELB, Auto Scaling, and security groups.
Deployment policies: All at once (fast, downtime), Rolling (batch, some downtime), Rolling with additional batch, Immutable (zero downtime, doubles capacity).
Use .ebextensions (YAML/JSON files in .ebextensions folder) to customize resources and run commands.
For production, use a separate RDS instance, not the one integrated with Beanstalk, to avoid data loss.
Worker tier uses SQS for background processing; can also schedule tasks with cron.yaml.
Health check URL defaults to '/'; customize it for accurate health monitoring.
Enhanced health reporting provides detailed metrics but must be enabled.
Beanstalk uses CloudFormation internally; you can view the stack in CloudFormation console.
Blue/Green deployment is achieved by creating a second environment and swapping CNAMEs.
EB CLI commands: eb init, eb create, eb deploy, eb open, eb logs, eb ssh.
Beanstalk supports Docker (single and multi-container) with ECS integration.
Environment properties become OS environment variables on instances.
Auto Scaling defaults: min=1, max=4; scale based on CloudWatch alarms.
Maximum 500 application versions per application (soft limit).
These come up on the exam all the time. Here's how to tell them apart.
Elastic Beanstalk
PaaS service: you only provide code and configuration.
Automatically provisions and manages resources for you.
Supports multiple platforms (Java, Python, etc.) out of the box.
Simplifies deployment with built-in health monitoring and scaling.
Less flexible: you are limited to the supported configurations.
AWS CloudFormation
IaaS tool: you define all resources in a template (YAML/JSON).
You have full control over every resource and its configuration.
You must manually define the entire infrastructure stack.
No built-in health monitoring or scaling—you must configure those separately.
Highly flexible: you can create any AWS resource.
Mistake
Elastic Beanstalk is an IaaS service because you can see EC2 instances.
Correct
Elastic Beanstalk is a PaaS service. AWS manages the underlying infrastructure (EC2, ELB, etc.) for you. You only provide code and configuration. The fact that you can see instances does not change the service model.
Mistake
You can only deploy web applications with Beanstalk.
Correct
Beanstalk supports both Web Server tier (HTTP applications) and Worker tier (background processing). The Worker tier uses an SQS queue to decouple tasks. You can also run scheduled tasks using cron.yaml.
Mistake
RDS must be created inside the Beanstalk environment for it to work.
Correct
You can create an RDS instance as part of the Beanstalk environment, but it is not recommended for production because the database is deleted when the environment is terminated. Best practice is to use a separate RDS instance and pass the connection string via environment properties.
Mistake
All at once deployment is the best choice for production because it is fastest.
Correct
All at once deployment causes downtime because all instances are updated simultaneously. For production, immutable deployment is preferred because it provides zero downtime by launching a new Auto Scaling group and swapping traffic.
Mistake
You cannot customize the EC2 instances in a Beanstalk environment.
Correct
You can customize instances using .ebextensions configuration files. These allow you to install packages, run commands, modify software settings, and even add CloudFormation resources. You can also SSH into instances using the EB CLI or key pairs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Elastic Beanstalk is a PaaS service that automatically provisions and manages AWS resources for your application. You provide code and configuration, and Beanstalk handles the rest. CloudFormation is an IaaS tool that allows you to define your entire infrastructure as code using templates. With CloudFormation, you have full control over every resource, but you must configure everything manually. Beanstalk uses CloudFormation internally to create resources. For the exam, remember that Beanstalk is higher-level and easier for developers, while CloudFormation is more flexible and powerful for infrastructure teams.
Use immutable deployment. This policy launches a new Auto Scaling group with the new version, performs health checks, and then swaps traffic to the new group. The old group is terminated only after the new group is healthy. This ensures zero downtime. Alternatively, you can use Blue/Green deployment by creating a separate environment and swapping the CNAME. Immutable is the native way and is recommended. Avoid 'All at once' for production as it causes downtime.
Yes, but for production, it is recommended to use a separate RDS instance outside of Beanstalk. Beanstalk can create an RDS database as part of the environment, but the database is tied to the environment's lifecycle—if you terminate the environment, the database is deleted. Instead, create a standalone RDS instance and pass its endpoint and credentials via environment properties. This decouples the database from the application environment, allowing you to update or replace the environment without data loss.
The worker tier is an environment type designed for background processing tasks. It includes an SQS queue and an Auto Scaling group of EC2 instances that poll the queue for messages. When a message is received, the worker application processes it. The worker tier also supports scheduled tasks using a cron.yaml file. This is ideal for tasks like sending emails, processing images, or generating reports. The exam tests that you know the worker tier uses SQS and that it can run cron jobs.
Use .ebextensions configuration files. Place YAML or JSON files in a folder named '.ebextensions' at the root of your source bundle. These files are processed during deployment and can install packages, run commands, create Linux users, modify configuration files, and even add AWS resources. For example, you can install nginx or run a database migration script. The exam tests that .ebextensions files are used for customization and that they are processed by CloudFormation.
First, check the health check URL configured in the environment settings. Ensure it returns a 200 OK response. Common issues: the application is not running on the expected port, security groups do not allow traffic on that port, or the path is incorrect. Use 'eb logs' to view application logs. You can also SSH into an instance using 'eb ssh' and check the application manually. The exam may ask about customizing the health check URL or that the default path is '/'.
Yes, Elastic Beanstalk supports Docker. For single-container Docker, you provide a Dockerfile or a Docker image in Amazon ECR. For multi-container Docker, you need a 'Dockerrun.aws.json' file that defines the containers, their images, and ports. The multi-container platform runs on an ECS cluster. Beanstalk handles the deployment and scaling of the containers. The exam may test that multi-container Docker uses ECS and requires a specific JSON file.
You've just covered AWS Elastic Beanstalk — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?