In AWS Elastic Beanstalk, how do an application, an application version, and an environment relate to one another, and what does Beanstalk itself add to your AWS bill?

## Why the vocabulary matters Elastic Beanstalk is AWS's oldest "just give me a URL for my code" platform. It does not run your code on some hidden AWS-owned fleet; it creates ordinary AWS resources in your account and manages them for you. Because of that, almost every Beanstalk question in an interview reduces to *what is the object model, and what is underneath it*. Getting the three nouns straight is the first half. ## Application An application is a naming and grouping construct — think of it as one service, product, or deployable unit. It owns two lists: the application versions that have been uploaded, and the environments that are running. It costs nothing and does nothing by itself. Creating an application without an environment gives you a container with nothing in it. ## Application version An application version is one immutable, labelled source bundle. When you run `eb deploy` or upload a zip in the console, Beanstalk pushes that bundle to an S3 bucket in your account (named `elasticbeanstalk-<region>-<account-id>`) and registers it under a version label. Two consequences follow. First, **rollback is just another deploy**: because the previous bundle is still in the version list, redeploying it is a normal deployment cycle, not a special recovery mode. Second, versions accumulate, which is why each application has an *application version lifecycle policy* — a rule that deletes old versions after a count or an age, optionally deleting the S3 objects too. Teams that never set one eventually hit the account's version limit and see deployments fail for a reason that has nothing to do with their code. ## Environment An environment is the running system. It has: - **exactly one application version deployed** at a time (a traffic-splitting deployment briefly serves two, but the steady state is one); - a **tier** — a *web server* environment serves HTTP behind a load balancer or on a single instance, while a *worker* environment has no public listener and instead runs a daemon that pulls messages from an SQS queue and POSTs them to the application on localhost; - a **platform** — the managed runtime image, e.g. "64bit Amazon Linux 2023 running Corretto 21". Platform *versions* are patched and retired on AWS's schedule, entirely independently of your application versions; - a **configuration** — a set of *option settings* covering instance type, scaling bounds, environment variables, load-balancer settings and more, which can be saved as a reusable *saved configuration*; - a **CNAME** — `<name>.<region>.elasticbeanstalk.com` — which is the hinge of blue/green deployment: you can swap the CNAMEs of two environments so traffic moves from the old to the new without redeploying anything. A useful mental model: the application is a folder, versions are the artifacts in it, and an environment is a machine with one artifact currently installed. ## What it costs Beanstalk adds **no service charge**. There is no per-environment hourly fee and no per-deployment fee. You are billed exactly as if you had created the same EC2 instances, Auto Scaling group, load balancer, EBS volumes, CloudWatch alarms and S3 storage yourself — because that is what exists in the account. This is worth saying out loud in an interview, because candidates often assume a managed platform must carry a markup, and it changes the honest answer to "why not just use Beanstalk?": the objection to Beanstalk is never price, it is the ceiling of the abstraction. The corollary is that a Beanstalk environment is **not** free when idle. A load-balanced environment keeps at least the minimum number of instances plus a load balancer running around the clock, so a forgotten `staging` environment costs real money — one of the most common surprise line items on a small AWS bill. ## The mistakes to avoid Confusing application versions with platform versions is the classic slip; they are different lifecycles owned by different parties (you, and AWS). Assuming that terminating an environment deletes the application is another: terminating an environment deletes the resources it created, but the application, its version list and the S3 bundles survive, which is exactly what makes re-creating an environment from a saved configuration quick.