Elastic Beanstalk

Elastic Beanstalk is AWS’s platform as a service. You bring the code; it provisions the resources, deploys the application and manages the environment from then on. Despite being one of AWS’s older services it remains widely used, because for a conventional web application it removes a large amount of assembly work without removing access to the underlying resources — the EC2 instances, load balancer and Auto Scaling group it creates are ordinary resources in your account.

What it manages

Platforms. Managed platforms exist for Docker, Node.js, Java, .NET, PHP, Python, Ruby and Go, each with a supported set of runtime versions. AWS retires platform branches on a published schedule, so a long-lived environment needs a platform upgrade plan; managed platform updates can apply patch and minor versions during a maintenance window automatically.

Docker. A Dockerfile or a Dockerrun.aws.json is enough to get a container running: Elastic Beanstalk provisions the instances, pulls the image and starts the container without any further configuration.

Environments. One application can hold several environments — development, QA, staging, production — each with its own resources, configuration and environment variables, and each with its own URL. Environments can be cloned, which is what makes the blue-green pattern practical.

The three layers

Application. The management layer and the container for everything else. It holds the versions and the environments.

Application version. A specific deployable bundle of code, stored in S3. Versions are retained and can be redeployed, which is the rollback mechanism for in-place deployment options. A version lifecycle policy is worth setting, or the S3 bucket accumulates every build ever made.

Environment. A running set of resources — EC2 instances, load balancer, Auto Scaling group, monitoring, and optionally a database — with exactly one application version deployed to it at a time. Environments come in two tiers: a web server tier behind a load balancer, and a worker tier that reads from an SQS queue.

Configuration

Environment configuration is expressed as option settings, which can be supplied through the console, the EB CLI, a saved configuration, or .ebextensions YAML files committed alongside the source:

.ebextensions/01-options.config

option_settings:
  aws:autoscaling:asg:
    MinSize: '2'
    MaxSize: '6'
  aws:elasticbeanstalk:environment:
    EnvironmentType: LoadBalanced
  aws:elasticbeanstalk:application:environment:
    LOG_LEVEL: info

Committing the configuration alongside the source is the difference between an environment that can be recreated and one that only exists because somebody clicked through the console once.

Deployment options

Option	What happens	Deployment time	Downtime	Rollback
All at once	The new version is deployed to every existing instance simultaneously	Fastest	Yes	Manual redeploy of the previous version
Rolling	Deployed to existing instances in batches	Longer	No	Manual redeploy
Rolling with additional batch	A new batch is launched before any old instance is taken out of service, so capacity is never reduced	Longer still	No	Manual redeploy
Immutable	A full set of new-version instances is launched in a separate Auto Scaling group and cut over only after health checks pass	Slow	No	Terminate the new instances
Traffic splitting	A percentage of client traffic is routed to new instances for canary testing	Slow	No	Reroute traffic and terminate the new instances
Blue-green	A second environment is brought fully up, verified, and then the environment URLs are swapped	Slow	No	Swap the URLs back

All at once suits development environments where a brief outage is free. Rolling and rolling with additional batch trade deployment time for availability; the additional batch also keeps capacity constant, which matters when the fleet is running near its limit. Immutable is the safest in-place option: nothing existing is modified, the new instances either pass their health checks or are discarded, and rollback is a termination rather than a redeploy. Traffic splitting is immutable deployment plus a canary, so a regression is detected on a small share of real traffic. Blue-green is the only option where the previous version stays fully running and available after the switch.

Rolling and rolling-with-additional-batch leave the fleet running two versions for the duration, so both versions must tolerate the same database schema and the same session store.

Blue-green with environment URL swap

Elastic Beanstalk implements blue-green natively. Clone the running environment, deploy the new version to the clone, verify it on its own URL, then swap the environment URLs. The swap works by updating the CNAME records the two environments resolve through, so rollback is a second swap.

The caveat is the one that applies to every DNS-based cutover: clients and resolvers cache DNS, so traffic drains from the old environment over the record’s TTL rather than instantly. Keep the old environment running until it stops receiving requests, not until the swap completes.

Limitations

Elastic Beanstalk’s value is that it decides things for you, and its limitations are the same fact seen from the other side:

• Less granular control over individual resources than assembling them yourself.
• Load balancer and Auto Scaling settings are exposed through option settings, which cover most but not all of what the underlying services support.
• Complex or unusual architectures — multiple services sharing an environment, unusual network topologies, sidecar containers — fit awkwardly.
• Platform retirement is on AWS’s schedule, not yours.

Where those constraints bite, the alternatives are Amazon ECS on Fargate for containers, or assembling the components directly with CloudFormation.

Practices

Name environments predictably (example-service-prod, example-service-staging) and keep configuration consistent between them, so the difference between staging and production is sizing rather than shape.

Keep configuration in .ebextensions or saved configurations, in version control, so an environment can be rebuilt from the repository.

Set a version lifecycle policy, or the application accumulates every build ever uploaded.

Choose the deployment option per environment, not per application: all-at-once in development, immutable or blue-green in production.

Enable enhanced health reporting so a failing deployment is detected by the platform rather than by users, and turn on managed platform updates within a maintenance window.