Elastic Beanstalk（重點概覽）

AWS Elastic Beanstalk is the classic managed-deployment service for web applications on AWS: you upload code, and AWS Elastic Beanstalk provisions the Amazon EC2 instances, Elastic Load Balancer, Auto Scaling group, and Amazon CloudWatch alarms required to run it. For the DVA-C02 exam this topic remains in scope, but the V2.1 exam guide has noticeably de-emphasized AWS Elastic Beanstalk compared with earlier versions — expect a small number of questions covering deployment policies, worker vs web server environments, configuration hooks, and the well-known RDS coupling gotcha, rather than deep operational scenarios. Treat this guide as a focused primer: enough depth to answer AWS Elastic Beanstalk questions correctly, without over-investing in a de-prioritized topic.

What Is AWS Elastic Beanstalk?

AWS Elastic Beanstalk is a managed deployment service that takes application code (Java, .NET, PHP, Node.js, Python, Ruby, Go, or Docker) and deploys it into a fully managed environment of AWS resources. You keep full ownership of those AWS resources — the EC2 instances, load balancer, Auto Scaling group, and Amazon CloudWatch metrics all appear in your AWS account and can be inspected and modified — but AWS Elastic Beanstalk handles the wiring, health monitoring, and deployment orchestration for you. That makes AWS Elastic Beanstalk one of the earliest PaaS-like offerings on AWS, predating AWS App Runner, Amazon ECS, Amazon EKS, and AWS Fargate.

At the DVA-C02 level the things that matter about AWS Elastic Beanstalk are:

1. Platform abstraction — AWS Elastic Beanstalk supports a curated list of runtime platforms, each versioned and patched by AWS.
2. Environment types — AWS Elastic Beanstalk provides two distinct environment shapes: web server environments and worker environments.
3. Deployment policies — AWS Elastic Beanstalk offers five built-in deployment strategies that map almost one-to-one onto DVA-C02 exam scenarios.
4. Configuration surfaces — .ebextensions, .platform hooks, environment variables, and saved configurations.
5. Common gotchas — in particular, the RDS coupling trap and the application version lifecycle.
6. Migration paths — where AWS Elastic Beanstalk workloads typically go next (Amazon ECS, Amazon EKS, AWS App Runner).

白話文解釋 AWS Elastic Beanstalk

要把 AWS Elastic Beanstalk 的定位一次講清楚，用三個白話類比會比讀完 Developer Guide 第一章更快。

類比一：租一間「全配套房」的房屋仲介（房屋仲介類比） AWS Elastic Beanstalk 就像一間提供全配套房的房屋仲介。你只要帶著行李（應用程式碼）入住，房子裡的床、冰箱、冷氣、Wi-Fi（也就是 Amazon EC2、Elastic Load Balancer、Auto Scaling、Amazon CloudWatch）早就幫你裝好。你仍然是租客，可以自己換床單、加購家電，但主結構、水電、瓦斯線路都歸房東管。對比之下，自己從 Amazon EC2 蓋起來就像自己買地蓋房子——什麼都要想。AWS Elastic Beanstalk 的五種 deployment policies，就像五種不同的搬家方式：一次全部搬進去、分批搬、多借一間周轉、整棟新蓋再搬、兩邊同時住一陣子。

類比二：餐廳的內外場（廚房類比） AWS Elastic Beanstalk 有兩種環境：web server environment 是「外場」，直接面對客人（HTTP 請求），由 Elastic Load Balancer 分桌帶位；worker environment 是「內場」，不直接服務客人，而是從 Amazon SQS 佇列拿到「訂單紙條」後慢慢處理，做完再把盤子端出去。外場講求反應速度，內場講求吞吐量與錯誤重試。DVA-C02 常問「哪種環境適合非同步後台處理？」——答案是 worker environment。

類比三：考試「開書 + 夾小抄」的 .ebextensions（開書考試類比） 設定 AWS Elastic Beanstalk 的常見武器是 .ebextensions 資料夾，裡面放 YAML 檔告訴 AWS Elastic Beanstalk「在環境內再裝什麼套件、開什麼設定」。它就像開書考試時事先夾在書裡的小抄：題目（deploy）一出現，Beanstalk 翻到小抄自動把套件裝上。Amazon Linux 2 與 Amazon Linux 2023 platform 又多了 .platform/hooks/，讓你在 deploy 的前後、config 變更的前後塞進自己的 shell script，粒度更細。考試問到「我想在 Beanstalk 環境安裝自訂套件或設定檔」——答案就是 .ebextensions 或 .platform hooks。

類比四：快遞的「冷鏈」與「一般件」（快遞類比，補強記憶） 把 deployment policies 想像成快遞選項：All-at-Once 是整車直送、最快但只要一台車出事整批貨沒了；Rolling 是分車送；Rolling with Additional Batch 是多叫一台車當週轉；Immutable 是換整隊新車再切換；Traffic Splitting 是兩隊車並行、用 A/B 流量分流。考試看到「零停機」「快速回滾」「Canary」「A/B」這些字眼，就能一眼對到某個 policy。

把這四個類比疊在一起：AWS Elastic Beanstalk = 管家型房屋仲介，外場 / 內場兩種房型，用小抄（.ebextensions）自訂裝潢，五種搬家方式對應 deployment policies。DVA-C02 的 AWS Elastic Beanstalk 題目八成都落在這四條線上。

AWS Elastic Beanstalk Platforms and the Managed Environment

An AWS Elastic Beanstalk platform is a curated combination of operating system, language runtime, web server, and AWS Elastic Beanstalk agent. AWS Elastic Beanstalk maintains platforms for Java (Corretto), .NET on Windows Server, Node.js, PHP, Python, Ruby, Go, Docker, and preconfigured Docker images. Each platform has a platform version with a lifecycle managed by AWS — new minor versions patch the OS and runtime; major versions bring breaking changes.

When you create an AWS Elastic Beanstalk environment, AWS Elastic Beanstalk provisions the following managed resources:

• An Amazon EC2 Auto Scaling group to host your application.
• Amazon EC2 instances running the selected platform and your uploaded application bundle.
• An Elastic Load Balancer (Application Load Balancer by default) for web server environments.
• Amazon CloudWatch alarms driving Auto Scaling decisions.
• An Amazon S3 bucket storing application versions, logs, and configuration snapshots.
• IAM Roles: a service role for AWS Elastic Beanstalk itself and an instance profile granting your application the permissions it needs.
• A security group that restricts inbound traffic to ports your application requires.

You are billed only for these underlying resources; AWS Elastic Beanstalk itself has no markup.

Environment URL and CNAME

Every AWS Elastic Beanstalk environment gets a unique URL in the form environment-name.region.elasticbeanstalk.com. This CNAME is the handle you use for blue/green deployments — swapping the CNAME between two environments is how AWS Elastic Beanstalk performs zero-downtime cutovers. The CNAME is also what Amazon Route 53 records should point at (usually via an alias or CNAME record) for production traffic.

Web Server Environment vs Worker Environment

AWS Elastic Beanstalk offers two environment tiers that shape how your application receives work.

Web Server Environment

A web server environment runs an HTTP-serving application behind an Elastic Load Balancer. HTTP clients (browsers, mobile apps, other services) hit the load balancer URL, which dispatches requests to EC2 instances in the Auto Scaling group. This is the default tier and matches the classic "three-tier web app" pattern.

Key web server environment characteristics:

• Inbound protocol: HTTP / HTTPS, optionally WebSockets.
• Load balancer: Application Load Balancer (default), Classic Load Balancer, or Network Load Balancer.
• Scaling trigger: CPU utilization, latency, request count, or a custom Amazon CloudWatch metric.
• Health: AWS Elastic Beanstalk monitors HTTP responses and reports green / yellow / red.

Worker Environment

A worker environment does not serve HTTP directly. Instead, AWS Elastic Beanstalk provisions an Amazon SQS queue and a small daemon on each EC2 instance (the SQS daemon) that polls the queue and POSTs each message to a local HTTP endpoint in your application (by default http://localhost/). The application processes the message and returns an HTTP 2xx status to acknowledge. A non-2xx response signals a failure; AWS Elastic Beanstalk returns the message to the queue and eventually routes repeatedly failed messages to a dead-letter queue.

Key worker environment characteristics:

• Inbound protocol: Amazon SQS messages, not HTTP from the internet.
• Scaling trigger: SQS queue depth.
• Use cases: asynchronous background jobs, image processing, report generation, scheduled tasks (via periodic cron.yaml configuration), email dispatch, ETL.
• Interaction: cron.yaml at the root of the application bundle defines scheduled jobs that AWS Elastic Beanstalk invokes on one leader instance per environment.

AWS Elastic Beanstalk Deployment Policies

Deployment policies are the heart of DVA-C02 AWS Elastic Beanstalk questions. AWS Elastic Beanstalk offers five built-in policies for deploying a new application version to an existing environment. You pick the policy based on trade-offs between deployment speed, cost, downtime, and rollback behavior.

All-at-Once

With the All-at-Once AWS Elastic Beanstalk deployment policy, AWS Elastic Beanstalk deploys the new application version to every EC2 instance in the environment simultaneously.

• Speed: fastest.
• Downtime: yes — all instances restart at the same time, so the service is briefly unavailable.
• Cost: lowest — no extra instances provisioned.
• Rollback: manual redeploy of the previous version.
• When to choose: dev and test environments where a short outage is acceptable.

Rolling

With the Rolling AWS Elastic Beanstalk deployment policy, AWS Elastic Beanstalk updates instances in batches — for example, 25% at a time. As each batch finishes updating, the next batch begins.

• Speed: moderate.
• Downtime: none (as long as the load balancer always has healthy instances).
• Capacity during deploy: reduced — while a batch updates, total capacity drops.
• Cost: no extra instances.
• Rollback: rolls back by redeploying the previous version in the same batched manner.
• When to choose: production environments where you can tolerate temporarily reduced capacity.

Rolling with Additional Batch

Rolling with Additional Batch adds one extra batch of fresh instances before the deployment starts, so the environment always has full capacity during the rollout.

• Speed: moderate (slightly slower than plain Rolling).
• Downtime: none.
• Capacity during deploy: full — the additional batch preserves total capacity.
• Cost: small — you pay for the extra batch for the duration of the deployment.
• Rollback: rolls back using the same pattern.
• When to choose: production where reduced capacity during deploy is not acceptable.

Immutable

The Immutable AWS Elastic Beanstalk deployment policy provisions a brand new Auto Scaling group with fresh EC2 instances running the new application version. Only after the new ASG reports healthy does AWS Elastic Beanstalk attach those instances to the load balancer and terminate the old ASG.

• Speed: slowest of the in-place policies.
• Downtime: none.
• Capacity during deploy: doubled.
• Cost: highest among in-place policies — you pay for two full fleets briefly.
• Rollback: very fast — the old ASG is still around until the new one is fully healthy, so reverting is just terminating the new ASG.
• When to choose: production where safety and fast rollback trump cost.

Traffic Splitting (Canary)

Traffic Splitting is the newest AWS Elastic Beanstalk deployment policy. Like Immutable, it launches a parallel set of instances with the new version, but it then splits traffic at the load balancer — for example, 90% to the old version and 10% to the new — so you can validate the new version against real traffic before a full cutover. After the evaluation window, AWS Elastic Beanstalk shifts 100% of traffic to the new version or rolls back on CloudWatch alarm triggers.

• Speed: slow — includes an evaluation window.
• Downtime: none.
• Cost: similar to Immutable during deploy.
• Rollback: automatic based on alarms.
• When to choose: canary releases and A/B validation of new versions before full promotion.

Blue/Green Deployments via CNAME Swap

The five built-in deployment policies above are in-place — they deploy into the existing AWS Elastic Beanstalk environment. For true blue/green deployment on AWS Elastic Beanstalk, the pattern is:

1. Keep the current production environment running (call it blue) on its CNAME myapp.elasticbeanstalk.com.
2. Clone the blue environment to create a separate green environment with a different CNAME, then deploy the new application version to green.
3. Run smoke tests against green.
4. Use the AWS Elastic Beanstalk Swap Environment URLs action to swap CNAMEs. The public DNS name that users hit now resolves to the green environment; the old blue environment becomes the rollback target.
5. If anything breaks, swap CNAMEs back — rollback is near instant.
6. Once green is stable, terminate the old blue environment to release resources.

Blue/green via CNAME swap is the AWS Elastic Beanstalk answer to DVA-C02 questions phrased as "zero downtime, new environment, quick rollback by DNS change." Watch for the important details: the swap is CNAME-level, so clients that cached the old DNS record may continue hitting blue until their TTL expires; keep DNS TTLs short when planning swaps.

Configuration: .ebextensions and .platform Hooks

AWS Elastic Beanstalk gives you two customization surfaces inside your application bundle. Understanding both is important for DVA-C02.

.ebextensions

The .ebextensions/ directory at the root of your source bundle holds YAML or JSON configuration files (.config) that AWS Elastic Beanstalk applies when provisioning or updating the environment. Supported sections include:

• packages — install OS packages via yum, rpm, apt, or language-specific package managers.
• files — write files onto the instance filesystem with specified ownership and permissions.
• commands — run commands before the application is set up.
• container_commands — run commands after the application is extracted but before it is deployed.
• services — start, stop, enable, or disable sysvinit or systemd services.
• option_settings — override AWS Elastic Beanstalk configuration options (scaling, load balancer, environment variables, and so on) or set AWS resource properties.
• Resources — extend the underlying AWS CloudFormation stack with additional AWS resources, because AWS Elastic Beanstalk uses AWS CloudFormation under the hood.

.platform Hooks (Amazon Linux 2 and Amazon Linux 2023)

On the Amazon Linux 2 and Amazon Linux 2023 AWS Elastic Beanstalk platforms, the newer .platform/hooks/ directory lets you drop executable shell scripts into lifecycle phases:

• prebuild/ — runs after source code is extracted, before build tools run.
• predeploy/ — runs after build but before the application is deployed.
• postdeploy/ — runs after the application is deployed.
• confighooks/prebuild/, confighooks/predeploy/, confighooks/postdeploy/ — analogous hooks that run on configuration changes (not code deploys).

.platform hooks replace many of the classic .ebextensions patterns on newer platform versions and should be preferred for anything that is an imperative script rather than declarative AWS resource configuration.

Environment Variables and Environment Properties

AWS Elastic Beanstalk exposes key-value environment properties (sometimes called environment variables) to the running application process. Set them via:

• The AWS Elastic Beanstalk console (Configuration → Software).
• The AWS CLI: aws elasticbeanstalk update-environment --option-settings Namespace=aws:elasticbeanstalk:application:environment,OptionName=KEY,Value=VALUE.
• .ebextensions option_settings in the aws:elasticbeanstalk:application:environment namespace.

Environment properties are the standard way to pass non-secret configuration (feature flags, endpoint URLs, log levels) and are exposed to the application as OS environment variables. For secrets, prefer AWS Systems Manager Parameter Store or AWS Secrets Manager — fetch secrets at boot via .platform hooks rather than baking them into environment properties, so they do not appear in AWS Elastic Beanstalk configuration snapshots.

Saved Configurations

A saved configuration is a named snapshot of an AWS Elastic Beanstalk environment's configuration options (instance type, scaling settings, environment variables, load balancer type, VPC wiring). Saved configurations are stored in the AWS Elastic Beanstalk Amazon S3 bucket and can be reapplied when creating new environments or reset onto existing ones.

Saved configurations are the correct AWS Elastic Beanstalk answer when DVA-C02 asks how to replicate a known-good configuration across multiple environments, or how to capture configuration for version control alongside application code.

The RDS Coupling Gotcha — Decouple in Production

One of the most frequently asked AWS Elastic Beanstalk traps on DVA-C02 is the RDS coupling problem. When you create an AWS Elastic Beanstalk environment, you can optionally have AWS Elastic Beanstalk provision an Amazon RDS database as part of the environment. This is convenient for development, but dangerous for production:

• The Amazon RDS instance is owned by the AWS Elastic Beanstalk environment's AWS CloudFormation stack.
• If the environment is terminated, the Amazon RDS database is terminated with it. Your data goes away.
• Cloning environments or doing blue/green swaps becomes risky because the database is tied to one specific environment.

The production pattern is to decouple Amazon RDS from AWS Elastic Beanstalk:

1. Create the Amazon RDS database outside AWS Elastic Beanstalk (via AWS CloudFormation, AWS CDK, or the Amazon RDS console directly).
2. Pass the database endpoint, username, and password into the AWS Elastic Beanstalk environment via environment properties (with secrets pulled from AWS Secrets Manager at runtime).
3. Configure the environment's security group to allow traffic to the RDS security group on the database port.
4. Now the database lifecycle is independent of the AWS Elastic Beanstalk environment lifecycle — you can clone, blue/green, or terminate environments without losing data.

Application Version Lifecycle

An AWS Elastic Beanstalk application version is an uploaded source bundle (typically a ZIP) stored in Amazon S3 and tracked with a label. Each deployment references a version label. Over time, unused versions accumulate and can hit the 1000-version-per-application soft limit.

The application version lifecycle policy cleans this up automatically. You can configure it to:

• Delete by count — retain the most recent N versions (for example 200) and delete older ones.
• Delete by age — retain versions younger than N days and delete older ones.
• Optionally keep the source bundle in Amazon S3 when deleting the AWS Elastic Beanstalk version record, so you can restore later.
• Optionally protect the version that is currently deployed to any environment from deletion.

For DVA-C02, know that AWS Elastic Beanstalk will not clean up application versions automatically unless you set a lifecycle policy, and that hitting the version limit is a common operational issue.

Migration Paths: Amazon ECS, Amazon EKS, AWS App Runner

AWS Elastic Beanstalk has been de-emphasized in DVA-C02 V2.1 because newer services cover the same use cases with modern defaults. Know the migration paths when the exam asks "which service replaces AWS Elastic Beanstalk for a team adopting containers?"

• Amazon ECS on AWS Fargate — the direct replacement for AWS Elastic Beanstalk Docker platforms when you want serverless containers with full AWS-native integration. Best when you want control over task definitions, service discovery, and Amazon ECS autoscaling.
• Amazon EKS on AWS Fargate — when the team has standardized on Kubernetes and wants portability across clouds or existing on-premises clusters.
• AWS App Runner — the closest PaaS-style successor to AWS Elastic Beanstalk for web apps. You hand AWS App Runner a container image or a source repository and it handles the load balancer, TLS, autoscaling, and deploys automatically. No Auto Scaling groups or Amazon EC2 instances to manage.
• AWS Lambda + Amazon API Gateway — when the workload is event-driven, bursty, or naturally fits a function-per-endpoint model.

Monitoring and Health in AWS Elastic Beanstalk

AWS Elastic Beanstalk provides two health-reporting modes:

• Basic health reporting — uses Amazon EC2 and Elastic Load Balancer health checks to classify the environment as green, yellow, red, or grey.
• Enhanced health reporting — an AWS Elastic Beanstalk agent on each instance collects detailed request metrics (p50/p90/p99 latency, request counts, HTTP status codes) and publishes to Amazon CloudWatch. Enhanced mode is required for many of the more useful AWS Elastic Beanstalk alarms.

Enhanced health reporting is usually the right choice for production. It surfaces percentile latency and error-rate information that Basic mode cannot.

Scaling and Auto Scaling

AWS Elastic Beanstalk wraps an Amazon EC2 Auto Scaling group. You configure:

• Minimum and maximum instance counts.
• A scaling trigger (Amazon CloudWatch metric, threshold, statistic, period).
• Scale-up and scale-down increments and cooldowns.

For web server environments, CPU utilization and request count are common triggers. For worker environments, SQS queue depth is the natural signal — AWS Elastic Beanstalk exposes ApproximateNumberOfMessagesVisible as a scaling metric.

Packaging and Deploying an Application Bundle

You deploy to AWS Elastic Beanstalk by uploading a source bundle — typically a ZIP of your application at the repo root containing .ebextensions/, .platform/ hooks, platform-specific manifests (Procfile, buildfile, Dockerrun.aws.json), and application code.

Common deploy paths:

• AWS Elastic Beanstalk CLI (eb CLI) — a local CLI that runs eb init, eb create, eb deploy, eb open, and eb logs.
• AWS Management Console — upload ZIP through the browser.
• AWS CodePipeline + AWS CodeBuild — CI/CD pipeline that calls the AWS Elastic Beanstalk API with a new application version.
• AWS CloudFormation — define AWS::ElasticBeanstalk::Application, AWS::ElasticBeanstalk::ApplicationVersion, and AWS::ElasticBeanstalk::Environment resources.

vs Similar Services: AWS Elastic Beanstalk vs AWS App Runner vs AWS CodeDeploy

• AWS Elastic Beanstalk — managed environment (EC2 + ELB + ASG) for web apps; five deployment policies; .ebextensions customization; mature but de-emphasized.
• AWS App Runner — newer PaaS for containerized and source-based web apps; no EC2 visible; simpler mental model; no deployment-policy selection exposed.
• AWS CodeDeploy — deployment orchestration service that works with Amazon EC2, AWS Lambda, and Amazon ECS; offers in-place and blue/green strategies defined in appspec.yml. Often the better answer on DVA-C02 when the question is about deployment strategy outside the AWS Elastic Beanstalk envelope.

If a DVA-C02 question describes uploading a web app ZIP with a platform runtime, AWS Elastic Beanstalk is a fit. If it describes a container image and wants zero EC2 management, AWS App Runner is a fit. If it describes orchestrating a blue/green deploy across Amazon ECS or AWS Lambda, AWS CodeDeploy is a fit.

Key Numbers and Must-Memorize Facts

• 5 deployment policies: All-at-Once, Rolling, Rolling with Additional Batch, Immutable, Traffic Splitting.
• 2 environment tiers: web server, worker.
• 8 supported platform families (excluding Docker): Java, .NET, PHP, Node.js, Python, Ruby, Go, plus Docker as its own family.
• 1000 — soft limit on application versions per application (manage via lifecycle policy).
• $0 — AWS Elastic Beanstalk service fee; you pay for underlying resources only.
• 2 customization surfaces: .ebextensions/ and .platform/hooks/.
• 1 blue/green mechanism: Swap Environment URLs (CNAME swap between two environments).

Common Exam Traps — Pitfalls to Memorize

Trap 1: "Immutable is the same as blue/green"

False. Immutable replaces the Auto Scaling group inside one AWS Elastic Beanstalk environment and reuses the same CNAME. Blue/green is two AWS Elastic Beanstalk environments swapped via CNAME.

Trap 2: "All-at-Once is safe for production"

False. All-at-Once causes downtime. It is for dev/test. Pick Rolling, Rolling with Additional Batch, Immutable, or Traffic Splitting for production.

Trap 3: "AWS Elastic Beanstalk auto-scales based on queue depth for web server environments"

False. Queue-depth scaling applies to worker environments. Web server environments scale on HTTP-oriented metrics (CPU, request count, latency).

Trap 4: ".ebextensions only sets environment variables"

False. .ebextensions can install packages, write files, run commands, start services, override AWS Elastic Beanstalk options, and even add AWS CloudFormation resources.

Trap 5: "Provisioning RDS inside AWS Elastic Beanstalk is the best practice"

False. That pattern couples the database lifecycle to the environment. Production best practice is to create Amazon RDS separately and inject its endpoint as an environment property.

Trap 6: "AWS Elastic Beanstalk and AWS CodeDeploy are the same thing"

False. AWS Elastic Beanstalk is an environment abstraction that includes deployment; AWS CodeDeploy is a standalone deployment service for Amazon EC2, AWS Lambda, or Amazon ECS. DVA-C02 often tests the distinction.

Trap 7: "Traffic Splitting shifts traffic gradually like a linear AWS Lambda alias"

Partially. Traffic Splitting does shift a configurable percentage and can evaluate CloudWatch alarms, but the trigger model and rollback semantics are AWS Elastic Beanstalk–specific and not identical to AWS Lambda alias routing used by AWS CodeDeploy.

FAQ — AWS Elastic Beanstalk Top DVA-C02 Questions

Q1: What is AWS Elastic Beanstalk in one sentence for DVA-C02? A: AWS Elastic Beanstalk is a managed deployment service that takes your web application code and runs it on a fully provisioned AWS environment — EC2, ELB, Auto Scaling, CloudWatch — without charging anything beyond those underlying resources. You keep ownership of the resources; AWS Elastic Beanstalk orchestrates the lifecycle.

Q2: Which AWS Elastic Beanstalk deployment policy should I pick for zero downtime and the fastest rollback? A: Immutable. It provisions a new Auto Scaling group in parallel, only cuts over once the new ASG is healthy, and keeps the old ASG available for rapid rollback by termination. If the exam also requires canary testing against real traffic, pick Traffic Splitting instead.

Q3: How do I do a blue/green deployment on AWS Elastic Beanstalk? A: Create a second environment (green) alongside the current one (blue), deploy the new version to green, smoke-test, then use Swap Environment URLs to swap CNAMEs. Rollback is another CNAME swap. Remember this is environment-level, not a deployment policy.

Q4: What is the difference between a web server environment and a worker environment? A: A web server environment receives HTTP requests through an Elastic Load Balancer. A worker environment receives Amazon SQS messages through an on-instance daemon and is designed for asynchronous background processing. Worker environments scale on queue depth; web server environments scale on HTTP-oriented metrics.

Q5: Why should I avoid creating Amazon RDS inside my AWS Elastic Beanstalk environment in production? A: Because terminating the AWS Elastic Beanstalk environment terminates the RDS instance with it, losing data. Best practice is to create Amazon RDS separately and pass its endpoint to AWS Elastic Beanstalk as an environment property, so the database lifecycle is independent of the environment lifecycle.

Q6: What is the difference between .ebextensions and .platform hooks? A: .ebextensions is the original declarative configuration mechanism (packages, files, commands, services, option_settings, Resources) and works on all platforms. .platform/hooks/ is the newer Amazon Linux 2 / 2023 mechanism that runs executable shell scripts at prebuild, predeploy, and postdeploy phases. Prefer .platform hooks for imperative scripts; prefer .ebextensions for declarative AWS resource configuration.

Q7: If my team is moving off AWS Elastic Beanstalk, what should we migrate to? A: For containerized web apps with minimal operations, AWS App Runner is the closest PaaS-style successor. For more control, Amazon ECS on AWS Fargate. For Kubernetes standardization, Amazon EKS on AWS Fargate. For event-driven or low-throughput endpoints, AWS Lambda plus Amazon API Gateway.

Q8: Does AWS Elastic Beanstalk cost extra on top of EC2 and ELB? A: No. AWS Elastic Beanstalk itself is free. You pay only for the Amazon EC2, Elastic Load Balancer, Amazon EBS, Amazon CloudWatch, and Amazon S3 resources it provisions on your behalf.

Further Reading — Official AWS Documentation

• AWS Elastic Beanstalk Developer Guide: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html
• Elastic Beanstalk concepts: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html
• Web server environment: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-webserver.html
• Worker environment: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html
• Deployment policies: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html
• Blue/green CNAME swap: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
• .ebextensions: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html
• .platform hooks: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html
• Environment properties: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-softwaresettings.html
• Saved configurations: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-configuration-savedconfig.html
• Adding a database: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.db.html
• Application version lifecycle: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/applications-lifecycle.html
• AWS App Runner Developer Guide: https://docs.aws.amazon.com/apprunner/latest/dg/what-is-apprunner.html

AWS Elastic Beanstalk is the classic "upload code, AWS handles the environment" deployment service on AWS, and while DVA-C02 V2.1 has narrowed its footprint, the core ideas remain testable: understand the two environment tiers, the five deployment policies, CNAME-swap blue/green, the two configuration surfaces (.ebextensions and .platform hooks), environment variables, saved configurations, the RDS coupling gotcha, the application version lifecycle, and the migration path toward Amazon ECS, Amazon EKS, or AWS App Runner. Answer AWS Elastic Beanstalk questions by mapping the scenario to one of these concepts and you will capture the modest but consistent DVA-C02 point budget it carries.