Containers on AWS: Concepts and Docker Basics

A container packages an application together with the specific dependencies (libraries, runtime, configuration) it needs to run, in a way that behaves consistently wherever it's run. This solves a genuinely old, genuinely common problem: "it works on my machine" — a container carries its own dependencies with it, instead of depending on whatever happens to already be installed on the machine running it.

A virtual machine runs a hypervisor on physical hardware, and each virtual machine on top of it runs its own complete guest operating system, with the application running inside that guest OS. A container, by contrast, runs on a container runtime sitting on a host, and each container shares the underlying host OS kernel rather than running its own separate operating system.

The practical consequence: containers are typically lighter weight and faster to start than a full virtual machine, because they don't need to boot an entire separate operating system — but that same shared-kernel design means a container's isolation model is genuinely different from a VM's, not simply "the same thing, smaller."

This is worth stating precisely, because the two terms get used interchangeably in casual conversation: a container image is a packaged, immutable template — application code, dependencies, and configuration, bundled together. A container is a running instance created from an image.

Docker is the tool most commonly associated with building and running containers this way. A Dockerfile is a text file describing how to build an image — what base to start from, what files to copy in, and what command to run when a container starts from it. A short, deliberately simple, educational-only example:

FROM php:8.3-cli

WORKDIR /app

COPY . .

CMD ["php", "artisan", "serve", "--host=0.0.0.0"]

This lesson doesn't walk through the full Docker CLI — the beginner-level goal is recognizing the shape (a Dockerfile builds an image, an image runs as a container), not memorizing every command. And to be direct about the example above: this is a minimal teaching illustration, not a production-ready Laravel deployment — a real production image would need considerably more consideration (dependency installation, a proper web server, configuration handling) than fits in a beginner-level example.

This is worth stating directly, the same way Module 7 stated it for Lambda's execution environment: a container's own local filesystem should not be treated as durable application storage. When a container restarts or is replaced — which happens routinely, as later lessons in this module cover — anything written only to its own local filesystem can disappear with it.

Durable application state belongs in a service built for it: S3 (Module 4) for files and objects, EFS (Module 6) for shared file storage across multiple running containers, EBS where the architecture genuinely calls for attached block storage, or RDS/Aurora/DynamoDB (Module 5) for structured data. A container should read whatever state it needs from one of those services, and write back to one of them — never assume anything written only to its own local disk survives past that specific container's lifetime.