We close Part IV with one of the most important topics in modern computing: containers. Before seeing how AWS manages them (ECR, ECS, EKS in the following subchapters), you need to understand what Docker and containers are. If you already know them, this will be a quick review; if not, here are the essentials.

You’ve surely heard (or experienced) this classic phrase: a program works perfectly on the developer’s computer, but when moved to the server... it fails. Why? Because the server has a different version of the language, is missing a library, the operating system is different, a configuration doesn’t match... Environment differences break applications.

A container packages your application along with everything it needs to run: the code, libraries, dependencies, configuration... all in a single package. That package works the same anywhere: on your laptop, on the server, in the cloud. No more “it works on my machine.”

Analogy: a container is like a shipping container (those on ships and trucks). It doesn’t matter what’s inside (clothes, electronics, food): the container has a standard size and shape, so any ship, crane, or truck in the world can transport it without knowing what’s inside. Same with software: the container is standard, and any system that “knows” about containers can run it.

Docker is the most popular technology for creating and running containers. It has become an industry standard. It handles three key concepts you should clearly distinguish:

An image is the template for the container: the “frozen” package with your application and everything it needs. It’s like a recipe or a mold. It doesn’t run by itself; it’s the definition of what will be inside.

A container is an image in execution: a live instance of the image, running. From a single image, you can launch many identical containers.

Analogy: the image is like a cookie cutter (or a blueprint); the container is each cookie that comes out of the mold. One mold, many identical cookies.

A Dockerfile is a text file with the instructions to build the image. It describes step by step what it contains: which base system it starts from, what gets installed, what code is copied, how it starts. It’s the written recipe.

From this Dockerfile, Docker builds the image, which you can then run as containers wherever you want.

Bringing the three concepts together, the cycle is:

You might wonder: how is a container different from an EC2 instance (virtual machine)? The key is that containers are lighter:

Containers share the host server’s operating system, instead of each carrying a full one. That’s why they’re so light and fast: you can run many containers on a single machine.

Why this matters in AWS: containers are ideal for the cloud. They start quickly (great for scaling, Chapter 13), are portable, and make good use of resources. That’s why AWS has dedicated services to run them, which we’ll see in the next subchapters: ECR (to store images), ECS and EKS (to run containers).

• A container packages your application with everything it needs (code, libraries, dependencies, configuration), and works the same anywhere. It ends the “it works on my machine” problem. Like a standard shipping container.
• Docker is the standard container technology, with three concepts: image (the template/mold), container (the running image/the cookie), and Dockerfile (the written recipe to build the image).
• The flow: Dockerfile → build → Image → run → Containers.
• Compared to virtual machines, containers are lighter and faster because they share the host’s operating system; many fit per server.
• AWS offers dedicated container services: ECR, ECS, and EKS (next subchapters).

In the next subchapter, we’ll see where to store your images privately and securely: the ECR registry.