AWS Elastic Beanstalk
Service 06

AWS Elastic Beanstalk

PaaSManagedCompute

AWS Elastic Beanstalk is a platform-as-a-service that takes your application code and runs it on AWS. You upload a zip, pick a platform — Java, .NET, Node.js, Python, Ruby, Go, PHP, or Docker — and Beanstalk creates the surrounding infrastructure: an EC2 Auto Scaling Group, a load balancer, security groups, and CloudWatch alarms.

Those resources stay visible and tunable; Beanstalk is a wrapper that wires them together with sensible defaults. Launched in 2011, it remains a fast code-to-AWS path for traditional web applications.

Key Concepts

An application is the top-level container for versions and environments. An application version is a specific build, usually a zip in S3. An environment is one running deployment of a version — you typically run separate dev, staging, and prod environments. Each environment is a web server tier for HTTP apps or a worker tier that processes jobs from SQS.

The platform is the managed runtime installed on the instances, such as 'Amazon Linux 2023 + Python 3.12'. Amazon Linux 2 platforms reach end of life on June 30, 2026 — pick an Amazon Linux 2023 platform for any new environment.

Deployment Policies

Beanstalk offers several update strategies trading speed for safety. All at once updates every instance together — fastest, with brief downtime. Rolling and rolling with an additional batch update in batches with no downtime. Immutable launches a fresh Auto Scaling Group before switching — slowest and safest. Blue/green stands up a second environment and swaps the URL.

For production, use immutable or blue/green; reserve all-at-once for development.

Pricing

There is no charge for Beanstalk itself — you pay only for the underlying resources: EC2 instances, EBS volumes, the load balancer, and any extras like RDS. It is cost-equivalent to building the same architecture by hand; the savings are in your time, not a discount.

Elastic Beanstalk vs ECS/EKS vs Lambda

Elastic Beanstalk — a conventional web app you want running on AWS quickly, with the underlying resources still visible.

ECS / EKS — container-native or microservice applications that need finer orchestration control.

Lambda / App Runner — serverless or event-driven apps where you do not want to manage an environment at all.

Common Mistakes
  • Using all-at-once deployments in production — a bad build takes the whole environment down at once. Use immutable or blue/green.
  • Letting Beanstalk auto-upgrade the managed platform — an unexpected platform bump can break a running app. Pin the platform version.
  • Launching new environments on an Amazon Linux 2 platform — it reaches end of life on June 30, 2026; start on Amazon Linux 2023.
  • Putting secrets in plaintext environment properties instead of reading them from Secrets Manager or Parameter Store at startup.
  • Choosing Beanstalk when you need fine control of every resource — it creates many resources behind the scenes that feel unpredictable; use CloudFormation or Terraform directly.
  • Expecting fast, short-lived environments — Beanstalk environments take minutes to create.
Best Practices
  • Capture environment settings as saved configurations so you can re-create them reliably.
  • Use environment variables for configuration and Secrets Manager or Parameter Store for secrets.
  • Use the worker tier for background jobs that read from SQS.
  • Pin the platform version and upgrade deliberately.
  • Use immutable deployments in production; keep all-at-once for development only.
Comparable services GCP App EngineAzure App Service

Knowledge Check

What does Elastic Beanstalk create when you upload your application code?

  • The surrounding infrastructure — EC2 Auto Scaling Group, load balancer, security groups, and alarms — which remain visible and tunable
  • A single Lambda function fronted by API Gateway, with no servers of any kind to manage
  • A managed Kubernetes cluster that schedules your code as pods across worker nodes
  • Only an S3 bucket to hold the uploaded code; you still wire up the EC2 instances, the load balancer, the security groups, and the alarms entirely by hand

Which deployment policy is safest for production, and why?

  • Immutable or blue/green — a fresh set of instances is launched and verified before traffic switches, with no downtime
  • All at once — updating every instance simultaneously is fastest, so the risky window stays the shortest
  • Rolling — it updates in small batches and always rolls back automatically the instant any error appears
  • There is no difference in safety between the policies, so any one of them is equally fine to run in a production environment

How is Elastic Beanstalk priced?

  • No charge for Beanstalk itself — you pay only for the underlying resources it provisions
  • A flat monthly platform fee charged on top of whatever the underlying provisioned resources cost
  • A per-deployment charge billed each time you push a new application version
  • A percentage markup layered on top of the underlying EC2 instance cost

When is Elastic Beanstalk the wrong choice?

  • When you need fine control over every resource — it provisions many behind the scenes; use CloudFormation or Terraform instead
  • When deploying a conventional Python or Node.js web app that follows a standard request-response pattern behind a load balancer
  • When you want a quick path from uploaded code to a running, load-balanced environment
  • When you want AWS to manage scaling, health checks, and load balancing on your behalf

You got correct