Skip to content

Elastic Beanstalk

1. Why This Service Exists (The Real Problem)

The Problem: You wrote your code (Python/Node/Java). Now you need to deploy it. - Infrastructure Sprawl: You manually create an EC2, install Nginx, install Python, set up a Load Balancer, create a Security Group, configure Auto Scaling... - Maintenance Burden: Who patches the OS? Who rotates the logs? Who updates the Load Balancer certificate?

The Solution: You upload your code (ZIP file/Git repo), and AWS builds the entire infrastructure for you automatically.

2. Mental Model (Antigravity View)

The Analogy: The Private Chef. - EC2: Cooking yourself (Buying ingredients, chopping, cooking, cleaning). - Elastic Beanstalk: You provide the Menu (Code) and the Preferences (Config), and the Chef (AWS) cooks, serves, and cleans up. - Under the Hood: It's just CloudFormation templates that provision standard AWS resources (EC2, ALB, ASG, RDS) for you.

One-Sentence Definition: An orchestration engine that automates the deployment and management of a standard web application stack (EC2 + LB + ASG).

3. Core Components (No Marketing)

  1. Application: The logical folder for your project (e.g., "MyWebApp").
  2. Environment: The actual running infrastructure (e.g., "Production", "Staging"). You can swap URLs between them.
  3. Application Version: A specific build artifact (e.g., v1.0.zip). Saved in S3.
  4. Platform: The runtime environment (e.g., "Python 3.8 running on 64bit Amazon Linux 2").
  5. Configuration: Settings for the environment (Instance Type t3.micro, Env Vars DB_HOST).

4. How It Works Internally (Simplified)

  1. Upload: You run eb deploy. It zips your local folder and uploads to S3.
  2. Provision: Beanstalk reads your configuration and creates a CloudFormation stack.
  3. Deploy:
    • It launches EC2 instances.
    • It runs the Platform scripts (e.g., pip install -r requirements.txt).
    • It configures Nginx to reverse proxy to your app.
    • It registers instances with the Load Balancer.
  4. Monitor: It runs a "Health Agent" on the instance that reports complex health (e.g., "Latency is high", "5xx errors") back to the Beanstalk console.

5. Common Production Use Cases

  • Standard Web Apps: Django, Rails, Node.js, Spring Boot apps that fit the "Stateless Web Server" pattern.
  • Docker Deployments: Single-container Docker deployments where you don't need the complexity of ECS/Kubernetes.
  • Worker Environments: Processing background jobs from an SQS queue (Beanstalk manages the worker daemon for you).

6. Architecture Patterns

The "Blue/Green Deployment" (Zero Downtime)

Don't do "All at Once" deployments in production (downtime risk). Do use Blue/Green (CNAME Swap).

Architecture: 1. Current (Blue): Live Environment executing v1.0. URL api.myapp.com. 2. New (Green): You deploy v1.1 to a new separate environment. 3. Test: You test Green environment via its private URL green-env.us-east-1.elasticbeanstalk.com. 4. Swap: You click "Swap Environment URLs". 5. Traffic: AWS updates DNS. Traffic flows to Green. 6. Terminate: If stable, terminate Blue. If broken, swap back instantly.

7. IAM & Security Model

  • Service Role: The permission Beanstalk needs to call other AWS services (e.g., "Create EC2", "Create ALB").
  • Instance Profile: The permission your App generic needs (e.g., "Read S3", "Write DynamoDB"). Beanstalk attaches this capability to the instances it launches.
  • Managed Updates: Beanstalk can automatically patch the underlying OS during a weekly window.

8. Cost Model (Very Important)

  • Free: Elastic Beanstalk itself is free. You pay for the resources it creates.
  • Resource Costs:
    • EC2 Instances (Running 24/7).
    • Load Balancer (ALB) - Hourly + Data processing.
    • S3 Storage (for application versions).
    • Data Transfer Out.

Optimization: - Instance Types: Use T3/T4g (Graviton) instances for cheaper compute. - Spot Instances: You can configure the ASG to use Spot instances for non-critical environments (Staging).

9. Common Mistakes & Anti-Patterns

  • Configuration Drift: Making manual changes to the EC2 instance (SSH -> change config). Beanstalk will terminate that instance and replace it with a fresh one, wiping your changes. Fix: Use .ebextensions config files in your source code.
  • Bloated Artifacts: Uploading node_modules or venv in the ZIP file. Fix: Use .ebignore to exclude dependencies; let the server install them.
  • Git-based Deployments: Deploying uncommitted code. Beanstalk zips the folder, not the git commit. Use CLI carefully.

10. When NOT to Use This Service

  • Microservices at Scale: If you have 50 microservices, managing 50 Beanstalk environments is a nightmare. Use ECS or EKS.
  • Complex Stateful Apps: If your app needs persistent disk state or complex clustering (e.g., Elasticsearch), Beanstalk will fight you. Use EC2 or Kubernetes.
  • Modern Tech: Beanstalk update cycles are slow. If you need the latest bleeding-edge Node.js version the day it drops, use Docker/ECS.

11. Interview-Level Summary

  • User Data: How do you customize the instance? .ebextensions (YAML files in .ebextensions/ folder).
  • Deployment Policies: All at once (Downtime), Rolling (Reduced Capacity), Rolling with Additional Batch (No Cap reduction), Immutable (New implementations).
  • Worker Tier: Built-in daemon (SQS -> Localhost HTTP POST) for background processing.
  • Underlying Tech: It is a wrapper around CloudFormation.