3.4 Elastic Beanstalk & Container Deploys

Elastic Beanstalk

AWS Elastic Beanstalk is a platform-as-a-service (PaaS): you upload an application source bundle and Beanstalk provisions and manages the EC2 instances, load balancer, Auto Scaling group, and health monitoring for you. It is the exam's answer when a developer wants to deploy a web app quickly without managing the underlying infrastructure, while still retaining full access to the AWS resources it creates (you can open the EC2 console, edit the ASG, etc.).

Beanstalk supports many platforms out of the box — Node.js, Python, Java, .NET, PHP, Ruby, Go, and Docker. You are charged only for the underlying resources (EC2, ELB, S3); Beanstalk itself adds no fee.

Under the hood every Beanstalk environment is actually a CloudFormation stack that Beanstalk creates and owns, which is why you can extend it with .ebextensions (the same option-setting and resource model) and why deleting the environment cleanly tears down the stack. An environment is one of two tiers: a web server tier (behind a load balancer, serving HTTP) or a worker tier (pulling messages from an SQS queue), and the tier choice changes what Beanstalk provisions.

Environments and customization

A Beanstalk application contains one or more environments (for example dev, staging, prod), and each environment runs exactly one application version at a time. You customize the platform with two files:

• .ebextensions/*.config — YAML or JSON files placed in an .ebextensions/ folder in the source bundle. They set option_settings, install packages, write files, and run commands (before the app/proxy is set up) and container_commands (after the app is staged but before it is live — the right place for database migrations). They customize the EC2 instances and the environment.
• Procfile — placed at the bundle root, it names the process or processes that run the application and the command to start each one (for example web: gunicorn app:app).

The exam often contrasts these: a setup command or OS package install is .ebextensions/container_commands, while which process starts the app is the Procfile. When you outgrow Beanstalk's abstraction and need fine-grained control of networking or scheduling, move to ECS/EKS or define infrastructure directly in CloudFormation.

Containers and Lambda images

For container workloads, know which service owns which job:

ECR is where you push and store images; authenticate the Docker client first with a token from aws ecr get-login-password. ECS runs those images. With the EC2 launch type you manage the container host instances; with Fargate AWS runs tasks serverlessly and you pay per task vCPU and memory. ECS uses two distinct IAM roles: the task execution role lets the ECS agent pull images from ECR and write logs to CloudWatch, while the task role grants the application code inside the container its AWS permissions (least privilege per app).

Lambda container images

Lambda can be packaged as a .zip archive (50 MB zipped direct upload, 250 MB unzipped hard limit including layers) or as a container image — an OCI image up to 10 GB stored in ECR. The container option is ideal when dependencies exceed the .zip ceiling (e.g. a 4 GB ML library) or when you want one container toolchain across compute services. Lambda still invokes your handler the same way; only the packaging and the size ceiling differ. To use a base image other than an AWS-provided one, your image must include the Lambda Runtime Interface Client (RIC) so the runtime can talk to the Lambda service.

Choosing the right compute target

The exam asks you to map a scenario to the leanest service:

A recurring trap pairs Beanstalk with fine-grained Kubernetes scheduling (wrong — that is EKS) or pairs Fargate with custom kernel modules / privileged daemons (wrong — that needs the EC2 launch type). Read for whether the team wants to avoid managing servers (Fargate/Beanstalk/Lambda) or specifically wants host-level control (ECS on EC2).

ECS task definitions and ECR workflow

An ECS task definition is the blueprint for one or more containers: it specifies the image URI, CPU and memory, port mappings, environment variables, the logging driver (commonly awslogs to CloudWatch), and the two IAM roles. A service keeps a desired number of task copies running and registers them with a load balancer; a one-off task runs to completion (good for batch jobs).

The push-to-ECR workflow you should be able to recite: authenticate Docker with aws ecr get-login-password | docker login, docker build and docker tag the image with the ECR repository URI, then docker push. ECR supports immutable tags (so a tag cannot be overwritten) and lifecycle policies that expire old images automatically — both common answers when a question asks how to keep image history clean or guarantee a deployed tag is never silently changed.