Elastic Beanstalk, App Runner and Lightsail

## Beanstalk is an orchestrator, not a runtime The single most useful fact about Elastic Beanstalk is that it does not run anything itself. It is a control plane that composes ordinary AWS services. When you create an environment, Beanstalk generates a CloudFormation template and creates a stack from it; every resource in your environment is a normal resource that stack owns. This is why "why not just use Beanstalk?" is a fair question with a nuanced answer — you are not buying different compute, you are buying someone else's opinion about how to wire the compute you would have used anyway. ## The inventory For a load-balanced web server environment on a language platform, expect roughly: - a **launch template** and an **Auto Scaling group** with the min/max you configured; - **EC2 instances** booted from the platform AMI, each running the Beanstalk host manager and, with enhanced health reporting enabled, a health agent that reports per-instance metrics and request statistics back to the service; - an **Application Load Balancer** (the default for new environments; Classic and Network load balancers are selectable at creation and cannot be changed afterwards) with a target group and listener; - **security groups** for the instances and the load balancer, wired so only the load balancer reaches the app port; - **CloudWatch alarms** that implement the environment's scaling triggers; - an **S3 bucket** in the account holding application version bundles and requested log bundles; - an environment **CNAME** under `elasticbeanstalk.com`; - for a *worker* environment instead of a load balancer: an **SQS queue** plus the on-instance daemon that reads it and POSTs each message to the application on localhost, and, when periodic tasks are configured, a **DynamoDB table** used for leader election. A single-instance environment swaps the load balancer and Auto Scaling group work for one instance with an Elastic IP — cheaper, and the usual shape for `dev`. ## How configuration is supposed to flow Everything Beanstalk knows about the environment is expressed as **option settings**, which are namespaced key/values. `aws:autoscaling:asg` carries `MinSize`/`MaxSize`; `aws:autoscaling:launchconfiguration` carries `InstanceType` and the key pair; `aws:elasticbeanstalk:application:environment` carries your environment variables. You set them from the console, the EB CLI, a saved configuration, or a `.config` file under `.ebextensions/` in the source bundle: ```yaml option_settings: aws:autoscaling:asg: MinSize: 2 MaxSize: 6 ``` Beanstalk translates those into the CloudFormation stack. That is the whole contract. ## Why manual edits bite Suppose traffic spikes and someone raises the Auto Scaling group's desired capacity in the EC2 console. It works — for a while. But the environment's option settings still say what they said, so the next configuration update regenerates the stack from them, a scaling action driven by the alarms moves capacity anyway, and an immutable deployment replaces the group wholesale. The change evaporates and nobody can explain why. The same applies to editing listener rules, swapping a security group, or attaching a volume by hand. Two harder edges follow. First, **terminating the environment deletes what Beanstalk created**, so a database provisioned *inside* the environment dies with it — which is why production databases are always created outside and attached by environment variable. Second, resources you attach by hand are not deleted on termination and become orphans nobody recognises. ## The supported escape hatches In increasing order of power: option settings for anything Beanstalk models; a `Resources:` block inside an `.ebextensions` `.config` file, which injects raw CloudFormation resources into the environment's own stack so they are created and deleted with it; `files:`, `packages:` and `container_commands:` for on-instance setup; and, on Amazon Linux 2 and 2023 platforms, **platform hooks** — executable scripts under `.platform/hooks/prebuild`, `predeploy` and `postdeploy` in the source bundle, with `.platform/confighooks/` running the equivalent on configuration updates. Hooks are the modern route and are much easier to reason about than `container_commands`. ## Deployments replace or mutate instances The deployment policy decides which. *All at once* is fastest and drops capacity. *Rolling* and *rolling with an additional batch* update instances in batches. *Immutable* launches a full set of new instances in a temporary Auto Scaling group, health-checks them, moves them into the environment's group and terminates the old ones — slow and it needs double capacity, but a failed deployment leaves the original instances untouched. *Traffic splitting* sends a percentage of requests to a temporary set for canary evaluation. Anything you did by hand on the old instances is gone after any of the instance-replacing policies, which is the practical reason the escape hatches live in the source bundle rather than in someone's SSH session.