Elastic Beanstalk

The plain-language idea

Elastic Beanstalk is a PaaS (Platform as a Service) layer over EC2: you upload your application code (or a container image), and Beanstalk provisions and wires together the underlying infrastructure that would otherwise be assembled manually — EC2 instances, an Auto Scaling group, a load balancer, security groups, and CloudWatch alarms for health checks. It isn't a fourth compute option alongside Lambda, ECS/Fargate, and EC2 from this track's compute-options lesson — it's automation on top of EC2, using the exact same primitives.

That makes Beanstalk the middle point on control versus convenience, but along a different axis than compute choice itself: raw EC2 means assembling every piece by hand (instances, load balancer, scaling policy, all separately); Beanstalk provisions the same pieces for you from a single deploy, but still gives direct access to every resource underneath if something needs customizing — unlike a fully managed platform such as Amplify, where the underlying infrastructure is largely abstracted away and not meant to be touched directly.

See it in a real thing: one deploy, several resources provisioned

eb init my-app --platform node.js --region us-east-1
eb create production-env
eb deploy

eb create alone provisions an EC2 Auto Scaling group, an Application Load Balancer, security groups scoped to the environment, a versioned S3 bucket to hold each deployed application version, and CloudWatch alarms watching instance health — all from one command, with no individual resource created by hand. eb deploy after that uploads a new application version and rolls it out according to whichever deployment policy the environment is configured with: all-at-once (fastest, causes downtime — every instance updates simultaneously), rolling (updates a batch of instances at a time, no full downtime, capacity briefly reduced), or immutable (spins up an entirely new, fully separate set of instances running the new version, verifies health, then swaps traffic over — slowest and momentarily most expensive, but safest, since a failed deploy never touches a running instance).

What people usually miss

Watch out

• Beanstalk isn't a separate compute type — it's automation over EC2, ELB, and Auto Scaling. The underlying cost model, patching responsibility, and scaling behavior are the same as if those resources were built by hand; Beanstalk changes who assembles them, not what they fundamentally are or cost.
• The underlying resources stay accessible, not hidden. Unlike a fully abstracted platform, an environment's EC2 instances can be SSH'd into, its security groups edited directly, and its scaling policy tuned in the console — Beanstalk provisions the standard shape but doesn't lock it away from direct access if something needs to break out of the defaults.
• The deployment policy is a real tradeoff, not a default to leave alone. All-at-once is fast but causes downtime; immutable avoids ever touching running instances but takes longer and briefly doubles capacity — picking one without understanding the tradeoff means either unplanned downtime or an unexpectedly slow, costly rollout.
• .ebextensions config files let Beanstalk stay customizable without giving up the automation. Custom OS packages, environment variables, or resource tweaks can be declared in config files bundled with the app, rather than requiring a fully manual setup the moment a default doesn't fit.

Why this matters in interviews

"When would you reach for Beanstalk instead of provisioning EC2 directly, or instead of a fully managed platform like Amplify?" tests whether a candidate can place a tool correctly on the control-versus-convenience spectrum — Beanstalk trades manual provisioning work for automation while keeping the underlying resources reachable, which is a meaningfully different answer than either extreme.