Cloud computing offers different levels of control vs. convenience. At the lowest level, Infrastructure as a Service (IaaS) gives you raw servers — you install the OS, configure networking, deploy your app. At the highest level, Software as a Service (SaaS) gives you a finished product — Gmail, Slack. In between sits Platform as a Service (PaaS).

PaaS takes care of the platform layer: operating system, runtime, middleware, and scaling infrastructure. You focus only on your application code. You don't patch servers, configure load balancers, or set up monitoring — the platform does it for you.

Imagine you want to deploy a simple Node.js web app on AWS. Without Beanstalk, you would need to:

Beanstalk exists because most developers want to deploy code, not configure infrastructure. It bridges the gap between "I have a ZIP file" and "I have a production-grade, load-balanced, auto-scaling deployment."

The three most common AWS compute options for applications — each with a different tradeoff between control and convenience:

Think of deploying your app like arriving at a hotel:

When you create a Beanstalk environment, here is what happens behind the scenes:

Under the hood, Beanstalk generates a CloudFormation template that describes all these resources. When you update your code or change configuration, Beanstalk updates the CloudFormation stack. This is why Beanstalk is not magic — it's automation on top of services you already know.

Elastic Beanstalk — Underlying AWS Services

Elastic Beanstalk Environment

Beanstalk

Orchestrator

→

CloudFormation

Infra Templates

→

EC2

App Servers

Auto Scaling

Scale In/Out

ELB

Load Balancer

CloudWatch

Monitoring

S3

Version Storage

SNS

Notifications

You provide code → Beanstalk generates CloudFormation → CloudFormation provisions EC2, ASG, ELB, CloudWatch, S3, SNS

Elastic Beanstalk organizes everything into a clear hierarchy. Understanding these five building blocks is essential before you deploy anything:

Beanstalk offers two environment types, each designed for a different workload pattern:

Beanstalk provides managed platforms — pre-configured AMIs with the OS, runtime, and web server already installed. You don't need to install Node.js or configure Nginx — the platform handles it.

Environment Types — How Traffic Flows

🌐 Web Server Environment

USERS → HTTPS

ELB

↓

EC2

App

EC2

App

Auto Scaling Group

⚙️ Worker Environment

SQS MESSAGES

SQS Queue

↓

EC2

Worker

EC2

Worker

No Load Balancer · Scales on queue depth

Web Server = internet-facing (ELB + ASG) · Worker = queue-driven (SQS + ASG, no ELB)

When you push a new version of your application, how should Beanstalk update the running instances? Replace all at once? Replace them gradually? Spin up brand new ones? The choice affects downtime, risk, speed, and cost.

Beanstalk provides five deployment policies. Each makes a different tradeoff — there is no "best" option, only the right one for your situation.

Immutable Deploy — New ASG alongside Old ASG

Old ASG (v1)

EC2

v1 ✓

EC2

v1 ✓

Serving traffic

→

SWAP

New ASG (v2)

EC2

v2 ✓

EC2

v2 ✓

Health checks pass → take over

ELB

Routes to new ASG after health check

Old ASG serves traffic while new ASG launches · Once v2 healthy → ELB switches · Old ASG terminates

Elastic Beanstalk is not a separate compute engine. It is an orchestration layer that creates, configures, and manages real AWS services on your behalf. When you create a Beanstalk environment, it generates a CloudFormation stack that provisions the following resources:

Beyond the core resources, Beanstalk can optionally create or integrate with additional services:

Every Beanstalk environment is backed by a CloudFormation stack. When you create or update an environment, Beanstalk:

This means: everything Beanstalk does, you could do manually with CloudFormation. Beanstalk is a convenience layer that generates and manages CloudFormation stacks. Understanding this helps demystify what happens when something goes wrong — you can always inspect the CloudFormation events for detailed error logs.

Beanstalk Environment — All Managed Components

Elastic Beanstalk Environment

ELB

ALB / NLB / CLB

→

Auto Scaling Group

EC2

Platform + App

EC2

Platform + App

+N

Scales

CloudWatch

Logs + Alarms

S3

App Versions

SNS

Notifications

CloudFormation

Stack Mgmt

RDS

Optional DB

SQS

Worker Queues

ElastiCache

Session Store

Route 53

Custom Domain

Solid = created by Beanstalk · Dashed = optional / external integration

Every load-balanced Beanstalk environment includes an Auto Scaling Group (ASG). The ASG manages the fleet of EC2 instances and automatically adjusts the count based on demand. You configure three key parameters:

Beanstalk uses CloudWatch metrics to decide when to scale. You can configure scaling policies based on several triggers:

Beanstalk uses health checks to determine if instances are working correctly. There are two levels:

Enhanced Health requires the service role aws-elasticbeanstalk-service-role with the AWSElasticBeanstalkEnhancedHealth managed policy attached. Beanstalk creates this automatically when you launch an environment with enhanced health enabled via the console or EB CLI.

To achieve true high availability with Beanstalk, your environment should survive the failure of an entire Availability Zone:

Beanstalk Auto Scaling — Services Involved

CloudWatch

Metrics + Alarms

→

Auto Scaling

Scaling Policies

→

EC2

Launch / Terminate

→

ELB

Register / Deregister

Scaling Flow

📊

1. CloudWatch

Detects CPU > 70%

🔔

2. Alarm Fires

Triggers policy

🚀

3. ASG Launches

New EC2 instance

✅

4. ELB Registers

Receives traffic

CloudWatch monitors → Alarm triggers scaling policy → ASG launches/terminates EC2 → ELB registers/deregisters targets

Beanstalk applies configuration from multiple sources. When settings conflict, higher-priority sources override lower ones. Understanding this order prevents "why isn't my setting applied?" confusion:

Environment variables are the simplest and most common way to configure your application in Beanstalk. They inject runtime configuration without changing your code — database URLs, API keys, feature flags.

The .ebextensions directory is the most powerful customization tool in Beanstalk. It contains YAML or JSON config files that execute during deployment. You place this directory in the root of your source bundle:

my-app/
├── .ebextensions/
│   ├── 01-env-vars.config
│   ├── 02-packages.config
│   ├── 03-nginx.config
│   └── 04-custom-logs.config
├── app.js
├── package.json
└── ...

Example — 01-env-vars.config:

option_settings:
  aws:elasticbeanstalk:application:environment:
    NODE_ENV: production
    LOG_LEVEL: info

  aws:autoscaling:asg:
    MinSize: 2
    MaxSize: 6

  aws:autoscaling:launchconfiguration:
    InstanceType: t3.medium

  aws:elasticbeanstalk:environment:
    LoadBalancerType: application

Example — 02-packages.config:

packages:
  yum:
    ImageMagick: []
    git: []

commands:
  01_setup_timezone:
    command: "ln -sf /usr/share/zoneinfo/UTC /etc/localtime"

container_commands:
  01_run_migrations:
    command: "npm run migrate"
    leader_only: true          # Only runs on ONE instance
  02_seed_data:
    command: "npm run seed"
    leader_only: true          # Only runs on ONE instance
  03_clear_cache:
    command: "npm run cache:clear"
    leader_only: false         # Runs on EVERY instance

Platform hooks are the newer, recommended way to run scripts during the deployment lifecycle. They replace the older commands and container_commands in .ebextensions with a clearer, lifecycle-based structure:

.platform/
├── hooks/
│   ├── prebuild/    ← Before build
│   ├── predeploy/   ← Before app starts
│   └── postdeploy/  ← After app starts
├── confighooks/
│   ├── prebuild/
│   ├── predeploy/
│   └── postdeploy/
└── nginx/
    └── conf.d/
        └── custom.conf

If your .ebextensions or platform hooks install many packages or take a long time, you can bake a custom AMI — an image with everything pre-installed. This dramatically reduces deployment time because instances boot with all dependencies already present.

Beanstalk platforms (Amazon Linux 2+) use Nginx as the reverse proxy in front of your application. You can customize Nginx by placing config files in your source bundle:

# .platform/nginx/conf.d/proxy.conf
client_max_body_size 50M;
proxy_read_timeout 300s;

# Custom headers
add_header X-Frame-Options "DENY";
add_header X-Content-Type "nosniff";

# .platform/nginx/nginx.conf
# Complete replacement — use with care
# Must include all required directives

# Useful for:
# - Custom routing
# - WebSocket support
# - Gzip configuration
# - Static file serving

Where Configuration Applies in the Stack

⚙️ Application Config

Environment Variables

DB_HOST, API_KEY, NODE_ENV

Secrets Manager

Encrypted secrets at runtime

🏗️ Platform Config

.platform/hooks/

Lifecycle scripts

.platform/nginx/

Proxy customization

Custom AMI

Pre-baked dependencies

☁️ Infrastructure Config

.ebextensions/

Instance type, ASG, ELB

Resources (CFN)

Extra RDS, SQS, DynamoDB

Saved Configs

Reusable templates

EC2

Env vars + hooks

ELB

.ebextensions

ASG

.ebextensions

CloudWatch

Auto-configured

CloudFormation

Resources key

Application config → your code reads env vars · Platform config → hooks + nginx · Infrastructure config → .ebextensions + CFN

The most common Beanstalk pattern: a single-tier web application with all components managed by one Beanstalk environment. Suitable for most small to medium applications.

For applications with both user-facing traffic and heavy background processing. Separate the two concerns into two Beanstalk environments connected by SQS.

For teams that need zero-downtime deployments with instant rollback capability. Combine Beanstalk's URL swap with a CI/CD pipeline for fully automated releases.

When your application runs in Docker containers but you don't need the complexity of ECS or EKS, Beanstalk's Docker platform is the simplest path. Just provide a Dockerfile or docker-compose.yml.

Automated Blue/Green Deployment Pipeline

👨‍💻

Developer

git push

→

CodePipeline

Orchestrate

→

Build & Test

CodeBuild

→

EB Green

Deploy v2

→

🔄

Swap URLs

CNAME Swap

🔵 Blue (current prod)

ELB

→

v1

v1

🟢 Green (new version)

ELB

→

v2

v2

git push → CodePipeline → Build → Deploy to Green → Smoke test → Swap URLs → Green is prod · Blue = rollback target

my-app/
├── .ebextensions/                 ← Infrastructure config (YAML)
│   ├── 01-env-vars.config         ← Environment variables + scaling
│   ├── 02-packages.config         ← yum packages + commands
│   └── 03-resources.config        ← Extra CloudFormation resources
├── .platform/                     ← Platform customization (AL2023)
│   ├── hooks/
│   │   ├── prebuild/              ← Before build (install deps)
│   │   ├── predeploy/             ← Before app starts (migrations)
│   │   └── postdeploy/            ← After app running (warmup)
│   ├── confighooks/               ← Same stages, config changes only
│   └── nginx/
│       └── conf.d/
│           └── proxy.conf         ← Custom Nginx settings
├── app.js                         ← Your application code
├── package.json                   ← Dependencies
└── Procfile                       ← (Optional) custom start command
    web: node app.js --port $PORT