Cargando...
Cargando...
Deploy, scale, and manage applications without managing infrastructure — AWS handles the heavy lifting.
AWS Elastic Beanstalk is a Platform-as-a-Service (PaaS) that automatically handles capacity provisioning, load balancing, auto-scaling, and application health monitoring for your web applications and services. Developers upload their code and Beanstalk deploys it on managed infrastructure, while still giving you full access to the underlying AWS resources. It supports multiple platforms including Java, .NET, Node.js, Python, Ruby, PHP, Go, and Docker — making it ideal for teams that want speed without sacrificing control.
Accelerate application deployment by abstracting infrastructure provisioning while retaining full AWS resource access and control.
Use When
Avoid When
Web Server Environment Tier
Handles HTTP/HTTPS traffic via ELB + Auto Scaling + EC2. Supports all managed platforms.
Worker Environment Tier
Polls SQS queue using a built-in sqsd daemon on each instance. NOT available on .NET on Windows Server platform — critical exam trap.
Managed Platform Updates
Automatically applies platform patches during a configurable maintenance window without application downtime.
Blue/Green Deployments
Achieved via 'Swap Environment URLs' — DNS-level cutover between two full environments. Zero-downtime with easy rollback.
Rolling Deployments
Deploys to batches of instances while keeping others serving traffic. Configurable batch size (fixed number or percentage).
Rolling with Additional Batch
Launches extra instances before rolling update to maintain full capacity throughout deployment.
Immutable Deployments
Launches entirely new instances in a temporary ASG; only swaps if health checks pass. Safest deployment policy, slowest.
Traffic Splitting (Canary)
Routes a configurable percentage of traffic to new version instances for canary testing before full deployment.
All-at-Once Deployments
Fastest but causes downtime if deployment fails. Never use in production without a rollback plan.
.ebextensions Configuration Files
YAML/JSON config files in .ebextensions/ folder inside deployment package. Used to customize environment, install packages, set env vars, configure CloudWatch.
Buildfile, Procfile, Platform Hooks
AL2 and AL2023 platforms use these instead of .ebextensions for build and run commands. Buildfile = build commands, Procfile = run commands.
Enhanced Health Reporting
Provides detailed health status (OK, Warning, Degraded, Severe) with cause codes. Requires health agent on instances.
CloudWatch Integration
Streams environment metrics and logs. Custom metrics via .ebextensions. Log streaming to CloudWatch Logs configurable.
VPC Support
Deploy environments into custom VPCs with public/private subnet configuration for web and worker tiers.
RDS Integration
Can launch RDS inside or outside the environment. CRITICAL: RDS inside the environment is deleted when environment is deleted. Always use external RDS for production.
Docker Platform Support
Single container (Dockerrun.aws.json v1) and multi-container (Dockerrun.aws.json v2, uses ECS under the hood).
Dead Letter Queue (DLQ) for Worker
Configure SQS DLQ to capture messages that fail processing repeatedly. Without DLQ, poison-pill messages loop indefinitely.
Periodic Tasks (Worker cron.yaml)
Worker environments support scheduled tasks via cron.yaml file. Beanstalk daemon posts to /scheduled-tasks endpoint on schedule.
HTTPS Termination
Configure SSL on the load balancer via .ebextensions or console. Can also terminate at instance level.
Spot Instance Support
Configure mixed instance fleets with On-Demand and Spot via capacity rebalancing for cost optimization.
AWS X-Ray Integration
Enable X-Ray daemon via console toggle or .ebextensions. Automatically instruments supported runtimes.
Worker Environment with SQS Daemon Polling
high freqBeanstalk worker environments include a built-in sqsd daemon that polls an SQS queue and POST messages to a local HTTP endpoint (default: localhost/). The application processes messages synchronously. Configure SQS visibility timeout to be LONGER than maximum processing time to prevent duplicate delivery. Add a DLQ for failed messages.
Application Log Streaming and Custom Metrics
high freqConfigure log streaming to CloudWatch Logs via .ebextensions or console. Set up CloudWatch Alarms on environment health metrics. Use CloudWatch for deployment monitoring and rollback triggers. Enhanced Health integrates directly with CloudWatch.
Auto Scaling Group Management
high freqBeanstalk manages an Auto Scaling Group of EC2 instances for each environment. You can configure instance types, min/max counts, scaling triggers (CPU, network, custom CloudWatch metrics), and placement across AZs. Direct access to the underlying ASG is retained.
Application Version Storage
high freqEvery deployment artifact (ZIP/WAR/JAR) is uploaded to S3 as an application version. Beanstalk creates a dedicated S3 bucket per region. Version lifecycle policies automatically delete old versions from S3 to control costs and stay within the 1,000-version limit.
Hybrid Compute: Beanstalk for Web Tier + Lambda for Event Processing
high freqBeanstalk handles synchronous web requests while Lambda handles asynchronous event processing (image resizing, notifications, etc.). The Beanstalk app triggers Lambda via SDK calls or through SQS/SNS fan-out patterns.
Multi-Container Docker Environment
high freqBeanstalk's multi-container Docker platform uses ECS under the hood. Dockerrun.aws.json v2 defines container definitions similar to ECS task definitions. Useful for running sidecar containers (e.g., nginx + app). For complex orchestration, migrate to native ECS/EKS.
CI/CD Pipeline Integration
high freqCodePipeline deploys to Beanstalk environments as a deploy action. Supports deployment to specific environments, version creation, and environment swaps (blue/green). Combined with CodeBuild for build stage and CodeCommit/GitHub for source.
Decoupled Database Architecture
high freqBest practice: Create RDS OUTSIDE the Beanstalk environment and pass connection string via environment variables. RDS created INSIDE the environment is terminated when the environment is deleted — a critical production anti-pattern. Use Secrets Manager or Parameter Store for credentials.
Worker environment tier is NOT available on .NET on Windows Server platform. If a question asks about background job processing on .NET Windows, the answer cannot be 'use worker environment tier' — you'd need a separate EC2 solution or Lambda.
SQS visibility timeout MUST be set longer than the maximum message processing time in worker environments. If visibility timeout < processing time, SQS makes the message visible again while it's still being processed, causing duplicate processing and potentially infinite loops.
Always configure a Dead Letter Queue (DLQ) for worker environments. Without a DLQ, a 'poison-pill' message (one that always causes processing failure) will loop indefinitely, consuming SQS API calls and blocking or slowing queue processing.
Blue/Green deployment in Beanstalk is done via 'Swap Environment URLs' — this is a DNS CNAME swap, not a load balancer target group swap. DNS TTL means there can be a brief propagation delay. The two environments must be in the same region.
NEVER put RDS inside a Beanstalk environment for production. When you delete or terminate the environment, the RDS instance is also deleted. Always create RDS separately and inject the endpoint as an environment variable.
Worker environment tier is NOT supported on .NET on Windows Server platform — never select 'worker tier' as the answer for .NET Windows background job processing scenarios.
SQS visibility timeout MUST be longer than maximum message processing time in worker environments, or duplicate message delivery occurs. DLQ is mandatory to prevent poison-pill infinite loops.
RDS created INSIDE a Beanstalk environment is deleted when the environment is deleted. Always create RDS externally and inject connection details via environment variables for production workloads.
Deployment policy comparison for exams — All-at-Once: fastest, downtime risk; Rolling: no extra cost, reduced capacity during deploy; Rolling with Additional Batch: no capacity reduction, extra cost; Immutable: safest, slowest, extra cost; Traffic Splitting: canary testing with configurable percentage.
Use Application Version Lifecycle policies to automatically delete old versions when you approach the 1,000-version limit. In active CI/CD pipelines, this limit can be reached quickly. Lifecycle policies can delete by count (keep last N) or by age.
.ebextensions files are processed in alphabetical order by filename. If you have multiple config files, naming them 01-packages.config, 02-commands.config ensures predictable execution order. This matters when one config depends on another.
Elastic Beanstalk itself costs NOTHING. Exam questions about cost optimization with Beanstalk are really about the underlying resources: EC2 instance types, ELB type, RDS size, and S3 storage for versions. Switching to Beanstalk doesn't add cost.
For the DOP-C02 exam: Beanstalk supports saved configurations (configuration templates) that can be applied to new environments. This is the recommended way to ensure environment parity between dev/staging/prod — not manual console configuration.
Worker environments use the sqsd daemon for SQS polling — this is NOT SNS push. The daemon polls SQS and HTTP POSTs to the application. SNS can feed INTO SQS (fan-out pattern), but the worker tier itself always polls SQS.
Managed Platform Updates can be configured to apply minor and patch updates automatically during a maintenance window. For immutable update strategy during managed updates, Beanstalk launches new instances — this temporarily doubles instance count and incurs extra cost.
Common Mistake
Candidates assume all Elastic Beanstalk platforms support the worker environment tier, including .NET on Windows Server.
Correct
The worker environment tier is NOT supported on the .NET on Windows Server platform. Only Linux-based platforms and Windows platforms using the newer Amazon Linux 2 Docker approach support worker tiers. For .NET Windows background processing, you need an alternative like a separate EC2 fleet, Lambda, or ECS.
This is a direct exam trap. Questions will describe a .NET Windows application needing background job processing and list 'worker environment tier' as an answer choice. Selecting it is wrong. Remember: Worker tier = Linux (primarily). When you see .NET Windows + background jobs, rule out worker tier immediately.
Common Mistake
Candidates think SNS push notifications are used to deliver messages to worker environments, similar to Lambda triggers.
Correct
Worker environments use an SQS queue exclusively. The built-in sqsd daemon POLLS the SQS queue (pull model) and HTTP POSTs each message to the application's local endpoint. SNS does NOT push directly to worker environments. SNS can fan-out to SQS, which the worker then polls — but the worker tier itself only understands SQS.
This trips up candidates who know Lambda can be triggered by SNS directly. Beanstalk worker = SQS polling always. If a question mentions SNS as the direct trigger for a Beanstalk worker environment, it is wrong. The correct pattern is SNS → SQS → Beanstalk Worker.
Common Mistake
Candidates believe that not configuring a Dead Letter Queue (DLQ) for a worker environment is acceptable because failed messages will eventually be discarded.
Correct
Without a DLQ, a poison-pill message (one that always causes a processing error) will be returned to the queue after each visibility timeout and retried indefinitely. This creates an infinite loop that wastes compute resources, SQS API calls, and can starve other messages in the queue. A DLQ is essential for production worker environments.
Exam questions will describe symptoms of infinite message loops (high SQS costs, worker instances at 100% CPU, other messages not being processed) and ask for the solution. The answer is always: configure a DLQ with an appropriate maxReceiveCount. Remember: No DLQ = poison pill loops forever.
Common Mistake
Candidates think setting the SQS visibility timeout to a short value (e.g., 30 seconds) is fine for worker environments to enable fast retry on failure.
Correct
The SQS visibility timeout must be set LONGER than the maximum time your application takes to process a single message. If processing takes 5 minutes but visibility timeout is 30 seconds, SQS will make the message visible again (thinking it wasn't processed) while it's still being worked on — causing duplicate processing by another worker instance.
Duplicate processing is a serious bug in financial, inventory, or any idempotency-sensitive system. The rule: visibility timeout > max processing time. A safe formula is: visibility timeout = (average processing time × 6) or at minimum 2× the maximum processing time. This is tested directly in DVA-C02 and DOP-C02.
Common Mistake
Candidates assume that creating a web server tier environment and manually polling SQS using the AWS SDK in application code is equivalent to using the built-in worker environment tier.
Correct
The worker environment tier provides a managed sqsd daemon that handles SQS polling, message deletion on success, visibility timeout management, DLQ routing, and periodic task scheduling (cron.yaml) — all automatically. Manual SQS polling in a web tier requires you to implement all of this yourself, is more error-prone, and loses built-in Beanstalk health monitoring for queue depth. The worker tier is purpose-built for this pattern.
Exam questions may present both options and ask which is 'best practice' or 'lowest operational overhead.' The worker environment tier wins because of its managed daemon. Manual SDK polling in a web tier is an anti-pattern for Beanstalk — it negates the platform's value proposition.
Common Mistake
Candidates believe that Elastic Beanstalk costs extra on top of the underlying resource costs.
Correct
Elastic Beanstalk is completely FREE. You pay only for the AWS resources it provisions: EC2 instances, load balancers, Auto Scaling, S3 storage, RDS, etc. There is no Beanstalk service fee. This makes it cost-neutral compared to manually provisioning the same resources.
Cost optimization questions sometimes ask whether switching FROM manual EC2 management TO Beanstalk saves money. The answer is: it doesn't cost more, but it may save operational time. The underlying resource costs are identical. Beanstalk adds zero overhead to your AWS bill.
Common Mistake
Candidates think deleting a Beanstalk environment is safe when RDS was created inside that environment.
Correct
If you created an RDS instance INSIDE a Beanstalk environment (via the environment configuration), deleting the environment DELETES the RDS instance and ALL its data. This is a catastrophic production mistake. Always create RDS independently and connect via environment variables. The Beanstalk console even warns about this, but candidates forget.
This is a classic 'gotcha' in both real-world AWS and on certification exams. The correct architecture: RDS outside Beanstalk → inject endpoint as environment variable → Beanstalk environment can be safely deleted/recreated without data loss. Remember: Inside = Coupled = Dangerous.
ARTIC for deployment policies (slowest→safest to fastest→riskiest): All-at-once (risky), Rolling, Traffic-splitting, Immutable (safest-no-downtime), Canary — wait, use 'RRIAT': Rolling, Rolling-with-batch, Immutable, All-at-once, Traffic-splitting. Immutable = most isolated = safest.
Worker tier memory trick: 'Workers POLL, they don't PUSH' — the sqsd daemon always POLLS SQS. SNS PUSHES, SQS is POLLED. Worker = SQS = POLL.
DLQ reminder: 'No DLQ = Poison Pill Party' — bad messages loop forever without a Dead Letter Queue.
RDS in Beanstalk: 'Inside = Coupled = Danger' — RDS inside the environment dies with it. Always go OUTSIDE for production.
Visibility timeout rule: 'VT > PT' — Visibility Timeout must always be Greater Than Processing Time, or you get duplicates.
Beanstalk pricing: 'Beanstalk is FREE, pay for the TREE' — the service is free, you pay for the underlying resources (the infrastructure tree it grows).
CertAI Tutor · DVA-C02, SAA-C03, SAP-C02, DEA-C01, DOP-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons