This chapter covers AWS Elastic Beanstalk management and updates, a core topic for the SOA-C02 exam. Elastic Beanstalk is a PaaS service that automates application deployment and infrastructure management, allowing SysOps administrators to focus on code rather than provisioning. Approximately 10-15% of exam questions touch on Elastic Beanstalk, focusing on environment configurations, update strategies, and troubleshooting. Understanding deployment policies, environment health, and platform updates is critical for passing the exam.
Jump to a section
Imagine you're a building owner who wants to construct a new office tower. Instead of hiring individual architects, electricians, plumbers, and inspectors yourself, you hire a general contractor (Elastic Beanstalk). The contractor takes your blueprints (application code) and handles everything: they order materials (provision EC2 instances), hire subcontractors (set up load balancers, auto scaling groups, and databases), and ensure the building meets all codes (health checks, security groups). You only need to tell the contractor when to paint the walls a different color (deploy a new version). The contractor also handles routine maintenance: if a window breaks (instance failure), they replace it automatically. If you want to upgrade the elevator system (platform update), the contractor performs a rolling replacement without tenants noticing downtime. Crucially, the contractor gives you a dashboard (Beanstalk console) where you can see the construction status (environment health) and override decisions (e.g., choose to install a specific brand of HVAC system by customizing the environment configuration). You remain the owner—you have full control over the building, but you offload the operational complexity. This is exactly how Elastic Beanstalk works: you provide the code and configuration, and Beanstalk provisions and manages the underlying AWS resources, including EC2, Auto Scaling, ELB, RDS, and more. You can still SSH into instances or modify resources directly, but Beanstalk automates the lifecycle—from initial provisioning to updates and scaling.
What is AWS Elastic Beanstalk?
AWS Elastic Beanstalk is a Platform as a Service (PaaS) offering that automates the deployment, scaling, and management of applications. You upload your application code (e.g., Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker) and Elastic Beanstalk automatically handles capacity provisioning, load balancing, auto scaling, and application health monitoring. It supports multiple platforms and allows you to retain full control over the underlying AWS resources.
How Elastic Beanstalk Works
When you create an Elastic Beanstalk environment, the service provisions a set of AWS resources based on your configuration. The core components include: - Environment: A collection of AWS resources running an application version. Each environment is either a web server environment (handles HTTP requests via an ALB) or a worker environment (processes background tasks from an SQS queue). - Application Version: A specific, labeled iteration of your deployable code (e.g., a .war file, a ZIP archive, or a Docker image). - Configuration Template: A set of settings that define the environment's behavior (e.g., instance type, scaling limits, environment variables). - Platform: The combination of operating system, programming language runtime, and web server (e.g., Tomcat on Amazon Linux 2).
Internally, Elastic Beanstalk uses AWS CloudFormation to create and manage the underlying resources. When you create an environment, Beanstalk generates a CloudFormation template that defines EC2 instances, Auto Scaling groups, security groups, load balancers, and optionally RDS databases. The service then executes the template to build the infrastructure.
Environment Tiers: Web Server vs. Worker
Web Server Environment: Designed for applications that serve HTTP requests. It includes a load balancer (Application Load Balancer by default) that distributes traffic across EC2 instances in an Auto Scaling group. The load balancer terminates SSL and routes requests to the instances.
Worker Environment: Designed for background processing. It includes an SQS queue and a daemon on each EC2 instance that polls the queue. You can configure the daemon to process messages in batches (e.g., 10 messages at a time) and set a visibility timeout (default 30 seconds).
Deployment Policies
Elastic Beanstalk offers several deployment policies that control how new application versions are rolled out. Each policy has different behavior regarding downtime, speed, and resource usage.
#### All at Once Deploys the new version to all instances simultaneously. This is the fastest deployment but causes downtime because all instances are updated at the same time. If the deployment fails, the environment becomes unavailable until you roll back.
#### Rolling Deploys the new version in batches. You specify a batch size (e.g., 50% of instances). Each batch is taken out of service, updated, and returned to service before the next batch begins. During a rolling deployment, capacity is reduced during each batch, but the environment remains available (though with reduced capacity). If the deployment fails, you can roll back to the previous version by redeploying.
#### Rolling with Additional Batch Similar to Rolling, but first launches an additional batch of instances (of the specified size) to maintain full capacity during the update. This avoids reduced capacity but incurs extra cost for the temporary instances. After the deployment completes, the additional batch is terminated.
#### Immutable Launches a full set of new instances (in a new Auto Scaling group) running the new version. Once the new instances pass health checks, they are swapped into the load balancer, and the old instances are terminated. This provides the highest safety because the old environment remains intact until the new one is verified. If the deployment fails, the new instances are simply terminated. Immutable deployments take the longest because they require doubling the number of instances.
#### Blue/Green (Manual) Elastic Beanstalk does not automate blue/green deployments, but you can achieve them by creating a separate environment (green), deploying the new version there, and then swapping the CNAME (environment URL) using the Swap Environment URLs feature. This provides zero downtime and full control over testing the new version before switching traffic.
Environment Health and Monitoring
Elastic Beanstalk monitors the health of your environment using HTTP health checks (via the load balancer) and the enhanced health reporting feature. Enhanced health reporting provides detailed metrics and statuses for each instance, including: - Severity: Green (OK), Yellow (Warning), Red (Degraded), Grey (No Data). - Causes: Specific issues such as high CPU, high latency, or failed requests.
You can view the health status in the Elastic Beanstalk console or via the AWS Management Console. The health dashboard shows the overall environment color and a list of instances with their individual health statuses.
Platform Updates and Managed Updates
Elastic Beanstalk periodically releases platform updates that include security patches, bug fixes, and new features. You can configure managed updates to automatically apply these updates to your environments. Managed updates use a rolling deployment strategy (either Rolling or Immutable) to update the platform without downtime. You can set a maintenance window (e.g., every Tuesday at 2:00 AM) and choose the update level (e.g., patch or minor update).
Configuration and Customization
You can customize your environment using: - Environment Properties: Key-value pairs passed as environment variables to your application. - Configuration Files (.ebextensions): YAML or JSON files in your source bundle that configure AWS resources, install packages, or run commands. These files are processed during deployment. - Saved Configurations: Store environment settings for reuse across multiple environments. - Custom Platform: Build your own platform using Packer and the Elastic Beanstalk platform builder.
Interaction with Related Services
CloudFormation: Beanstalk uses CloudFormation under the hood. You can view the generated stack in the CloudFormation console.
Auto Scaling: Beanstalk creates an Auto Scaling group that manages instance scaling based on metrics like CPU utilization or request count.
ELB: An Application Load Balancer (or Classic Load Balancer) distributes traffic to instances.
RDS: You can optionally add an RDS database to your environment, but it's recommended to use a separate RDS instance outside Beanstalk for production workloads.
CloudWatch: Metrics and logs can be streamed to CloudWatch for monitoring.
IAM: Beanstalk creates service roles and instance profiles with permissions to manage resources.
Common CLI Commands
# Create a new environment
aws elasticbeanstalk create-environment --application-name my-app --environment-name my-env --solution-stack-name "64bit Amazon Linux 2 v5.5.0 running Tomcat 8.5" --version-label v1
# Update environment to a new version
aws elasticbeanstalk update-environment --environment-name my-env --version-label v2
# Swap environment URLs
aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-blue --destination-environment-name my-env-green
# Retrieve environment health
aws elasticbeanstalk describe-environment-health --environment-name my-env --attribute-names Status,ColorDefault Values and Timers
Health check interval: 10 seconds (default for ALB).
Unhealthy threshold: 2 consecutive failed health checks.
Connection draining: 300 seconds (default for ALB).
Cooldown period: 360 seconds (default for Auto Scaling group).
Rolling update batch size: 100% for All at Once, 50% for Rolling (configurable).
Managed updates window: Default is Sunday 09:00 UTC, but you can customize.
Trap Patterns on the Exam
Confusing Rolling with Rolling with Additional Batch: Rolling reduces capacity; Rolling with Additional Batch maintains full capacity but costs more.
Assuming Immutable is always best: Immutable is safest but slowest and most expensive; choose based on requirements.
Thinking Blue/Green is built-in: It's manual via Swap Environment URLs.
Believing you can't modify resources: You can, but Beanstalk may revert changes on update.
Step-by-Step: Deploying a New Application Version
Upload new version: Upload your source bundle to S3 or use the Beanstalk console.
Choose deployment policy: Select All at Once, Rolling, Rolling with Additional Batch, or Immutable based on your uptime and cost requirements.
Initiate deployment: The environment begins the update process. For Rolling, instances are updated in batches.
Monitor health: Check the health dashboard for any warnings or failures.
Verify deployment: Test your application endpoints to ensure the new version works.
Rollback if needed: If the deployment fails, redeploy the previous version.
Upload Application Source Bundle
Prepare your application code as a ZIP or WAR file. Upload it to the Elastic Beanstalk application or directly to an S3 bucket. Beanstalk stores the version and associates it with a version label. The source bundle must be less than 512 MB. Ensure that .ebextensions configuration files are included if needed.
Choose Deployment Policy
Select from All at Once, Rolling, Rolling with Additional Batch, or Immutable. Each policy affects downtime, speed, and cost. For example, Immutable creates a new Auto Scaling group with new instances, runs health checks, and then swaps traffic. This ensures no downtime but doubles instance count temporarily.
Initiate Deployment
Trigger the deployment via the console, CLI, or API. Beanstalk starts the update process by applying the chosen policy. For Rolling, it takes a batch of instances out of service, updates them, and returns them to service. The environment status changes to 'Updating' during this process.
Monitor Health During Deployment
Use the Elastic Beanstalk console or CLI to watch the health status. Enhanced health reporting shows instance-level details. If any instance fails health checks, the deployment may pause or roll back depending on the policy. Immutable deployments automatically roll back if new instances fail health checks.
Verify Application Functionality
After the deployment completes, test the application by accessing the environment URL. Check that all features work as expected. For critical updates, consider using blue/green deployment to test the new version in a separate environment before swapping URLs.
Rollback if Necessary
If the new version has issues, redeploy the previous version using the same deployment policy. Beanstalk does not have an automatic rollback feature except for Immutable deployments (which roll back if health checks fail). For other policies, you must manually initiate a deployment of the old version.
In a typical enterprise scenario, a company runs a Java-based web application on Elastic Beanstalk using Tomcat. The environment is configured with an Application Load Balancer, Auto Scaling group (min 2, max 10 instances), and an RDS database (separate from Beanstalk for production). The team uses immutable deployments for production updates to ensure zero downtime and automatic rollback if health checks fail. For example, when deploying a critical security patch, the team uploads the new WAR file and selects immutable deployment. Beanstalk launches 2 new instances (equal to the current instance count), attaches them to a new Auto Scaling group, and runs health checks. Once all new instances are healthy (green status for 5 minutes), Beanstalk swaps the load balancer target group to point to the new instances, then terminates the old instances. This process takes about 10-15 minutes but ensures no traffic disruption.
Another scenario involves a worker environment processing messages from an SQS queue. The team sets the batch size to 10 messages and visibility timeout to 60 seconds. During a platform update, they use rolling with additional batch to avoid message processing delays. The additional batch ensures that while 50% of instances are being updated, the remaining instances plus the new batch handle the queue backlog.
A common misconfiguration is setting the health check path to a non-existent endpoint, causing all instances to be marked unhealthy. This triggers Auto Scaling to terminate and replace instances, leading to a deployment failure. To avoid this, always test the health check URL before deployment. Also, forgetting to include .ebextensions files in the source bundle can cause missing dependencies or incorrect configurations, resulting in deployment failures.
Performance considerations: For high-traffic applications, use immutable deployments to avoid capacity reduction. For cost-sensitive dev/test environments, use rolling deployments. Always monitor CloudWatch metrics like CPUUtilization and RequestCount to adjust scaling triggers. The default cooldown period of 360 seconds can delay scaling during rapid load changes; consider reducing it to 120 seconds for bursty workloads.
The SOA-C02 exam tests Elastic Beanstalk management and updates under Domain 3: Deployment, Objective 3.1: Deploy, manage, and update applications and infrastructure. Key areas include: - Deployment policies: Understand the differences between All at Once, Rolling, Rolling with Additional Batch, and Immutable. Know which one causes downtime, which maintains full capacity, and which is safest. - Managed updates: Know how to configure managed platform updates, including the maintenance window and update level. The exam may ask about automatic vs. manual updates. - Environment health: Understand enhanced health reporting and the meaning of green, yellow, red, and grey statuses. Be able to interpret health dashboard metrics. - Swap Environment URLs: This is the manual method for blue/green deployments. Know that it swaps the CNAME between two environments. - .ebextensions: Know that configuration files in .ebextensions are processed during deployment and can be used to customize resources.
Common wrong answers: 1. Choosing Rolling with Additional Batch when asked for zero downtime: Candidates often think Rolling with Additional Batch has no downtime, but it actually has a brief period during batch swap where capacity is reduced. Immutable is the only policy with truly zero downtime. 2. Selecting All at Once for production deployments: This causes downtime; candidates may pick it for speed but ignore the outage. 3. Assuming Blue/Green is a built-in deployment policy: It is not; it's a manual process using Swap Environment URLs. 4. Confusing platform updates with application updates: Platform updates are for the underlying OS/runtime; application updates are for your code. Managed updates apply platform updates automatically.
Specific numbers to memorize:
Default health check interval: 10 seconds
Unhealthy threshold: 2
Connection draining timeout: 300 seconds
Auto Scaling cooldown: 360 seconds
Max source bundle size: 512 MB
Edge cases: If an immutable deployment fails, the old environment remains untouched and the new instances are terminated. If a rolling deployment fails, the environment may be left in a mixed state; you must manually redeploy the previous version. The exam loves to test that you cannot change the deployment policy after starting a deployment (you must cancel and start over).
To eliminate wrong answers, focus on the key requirement: does the question emphasize zero downtime, cost savings, or speed? Zero downtime → Immutable. Cost savings → Rolling. Speed → All at Once (but with downtime).
Elastic Beanstalk is a PaaS that automates deployment and infrastructure management using CloudFormation under the hood.
There are four deployment policies: All at Once (downtime), Rolling (reduced capacity), Rolling with Additional Batch (full capacity), and Immutable (zero downtime).
Immutable deployment is the safest and provides zero downtime but doubles instance count temporarily.
Swap Environment URLs is used for manual blue/green deployments; it swaps the CNAME between two environments.
Managed updates automatically apply platform updates (OS/runtime) using a rolling or immutable strategy during a maintenance window.
Enhanced health reporting provides instance-level health status and causes (green, yellow, red, grey).
Default health check interval is 10 seconds; unhealthy threshold is 2; connection draining is 300 seconds.
Source bundle size limit is 512 MB; .ebextensions files customize resources and run commands during deployment.
Manual changes to EC2 instances are not persistent; use .ebextensions for customizations.
Worker environments use SQS queues; daemon polls queue with configurable batch size and visibility timeout.
These come up on the exam all the time. Here's how to tell them apart.
Immutable Deployment
Creates a new Auto Scaling group with new instances.
Zero downtime; old instances remain until new ones are healthy.
Highest safety; automatic rollback if health checks fail.
Takes longer and costs more (double instances temporarily).
Preferred for production environments.
Rolling Deployment
Updates existing instances in batches.
Reduces capacity during each batch; may cause brief performance impact.
No automatic rollback; manual redeployment required on failure.
Faster and cheaper than Immutable.
Suitable for dev/test environments or when cost is a concern.
Mistake
Elastic Beanstalk is a serverless service that does not use EC2 instances.
Correct
Elastic Beanstalk provisions EC2 instances in an Auto Scaling group. It is a PaaS service, not serverless. You pay for the underlying EC2 instances.
Mistake
Immutable deployments cause downtime because all instances are replaced.
Correct
Immutable deployments launch new instances in a separate Auto Scaling group. Only after health checks pass are the new instances swapped in, so there is zero downtime.
Mistake
Rolling with Additional Batch is the same as Immutable but cheaper.
Correct
Rolling with Additional Batch updates instances in batches while maintaining capacity with an extra batch, but it still updates existing instances one batch at a time. Immutable creates entirely new instances and swaps them all at once.
Mistake
You can modify the underlying EC2 instances directly and Beanstalk will preserve changes.
Correct
Any manual changes to EC2 instances (e.g., installing packages via SSH) will be lost when Beanstalk performs a deployment or scaling event. Use .ebextensions to make persistent customizations.
Mistake
Swap Environment URLs is a deployment policy option in the console.
Correct
Swap Environment URLs is a manual action available in the console or CLI, not a deployment policy. It is used for blue/green deployments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Rolling updates instances in batches, reducing capacity during each batch. Rolling with Additional Batch first launches an extra batch of instances to maintain full capacity throughout the update. The extra batch is terminated after the update completes. Rolling is cheaper but reduces capacity; Rolling with Additional Batch maintains capacity but costs more for temporary instances.
Elastic Beanstalk does not have a built-in blue/green deployment policy. However, you can manually implement blue/green by creating a separate environment (green), deploying the new version there, and then using the Swap Environment URLs feature to swap the CNAME between the old (blue) and new (green) environments. This provides zero downtime and full control.
For Immutable deployments, if the new instances fail health checks, Beanstalk automatically terminates them and the environment remains on the old version. For other policies (All at Once, Rolling, Rolling with Additional Batch), you must manually redeploy the previous version by uploading it and initiating a new deployment. There is no automatic rollback for these policies.
The maximum size for a source bundle is 512 MB. If your application exceeds this, consider using Docker or custom platforms, or store large assets in S3 and download them during deployment via .ebextensions.
Yes, you can. It is recommended to create your RDS database outside of Elastic Beanstalk (i.e., not as part of the environment) for production workloads. Then, configure the environment to connect to the database using environment properties (e.g., RDS_HOSTNAME, RDS_USERNAME). This decouples the database from the environment lifecycle.
Use .ebextensions configuration files (YAML or JSON) placed in the .ebextensions folder at the root of your source bundle. These files can install packages, create files, run commands, or configure AWS resources. For example, you can install a custom RPM or set system parameters. Do not rely on manual SSH changes as they are not persistent.
The default health check interval is 10 seconds (for Application Load Balancer). The unhealthy threshold is 2 consecutive failures, meaning an instance is considered unhealthy after 20 seconds of failed checks. You can customize these settings in the load balancer configuration.
You've just covered Elastic Beanstalk Management and Updates — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?