A Docker container is a running instance of a Docker image: a lightweight, isolated package that holds an application together with everything it needs to run — code, libraries, system tools and configuration. It starts in seconds and behaves the same way on a developer’s laptop, on a test server and in production.
Docker is the technology that builds and runs those containers. It is one of the foundational pieces of application modernization and modern DevOps work, and the unit that AWS container services such as Amazon ECS, Amazon EKS and AWS Fargate are designed to run.
This guide covers what a container actually contains, how an image differs from a container, why containers are lighter than virtual machines, and how all of it runs on AWS.
What problem does Docker solve?
For years, the biggest pain in shipping software was the classic “it works on my machine.” An application ran fine in the developer’s environment and failed in production because library versions, configuration variables, or the operating system were different.
Docker solves this by packaging the application with everything it needs to run: the code, the libraries, the system tools, and the configuration. That package —the container— behaves the same everywhere, which removes the surprises when moving from development to production.
How does Docker work?
Docker’s model revolves around three concepts:
- Image: an immutable, versioned template that describes everything the application contains. It is built once and reused as many times as needed.
- Container: a running instance of an image. It can be created, stopped, and deleted in seconds, and many can be launched at once from the same image.
- Registry: a repository where images are stored and shared, such as Amazon ECR or Docker Hub.
The typical flow is straightforward: you define the application in a recipe file, build the image, publish it to a registry, and run it as a container in any environment that has Docker available.
What is a Docker container?
A container is a running instance of a Docker image: a lightweight, isolated unit that holds the application and everything it needs to run. It starts in seconds, uses only the resources it needs, and can be created or destroyed without touching the image it came from.
Three properties explain why containers became the standard unit for shipping software:
- Isolated: each container runs with its own filesystem, processes, and network view, so one application does not interfere with another on the same server.
- Ephemeral by design: a container can be replaced by an identical one at any moment. That is what makes automatic recovery and progressive deployments possible.
- Identical everywhere: the same image produces the same container on a laptop, in testing, and in production.
A useful way to hold the distinction: the image is the recipe, the container is the dish being served. From one recipe you can serve many dishes at once, and throwing one out does not affect the recipe.
What is inside a Docker container (and what is not)
The most common misunderstanding about containers is imagining a small computer inside the server. It is not that.
What the container carries: the application, its libraries and runtime, the system tools it depends on, and the configuration needed to start. All of that is fixed in the image at build time, which is why the result is reproducible.
What the container does not carry: a full operating system. The container shares the kernel of the host it runs on and only isolates what belongs to the application — its filesystem view, its processes and its network. That is exactly why an image is measured in megabytes while a virtual machine disk is measured in gigabytes, and why a container starts in seconds rather than minutes.
What does not survive a restart: anything the application writes inside the container. A container is designed to be replaced by an identical one at any moment, so data that must persist lives outside it — in a volume, in a managed database, or in object storage. Treating a container as if it were a server with its own disk is the most frequent mistake when teams start out, and it shows up the first time a container is replaced.
The lifecycle of a container, end to end
Understanding the five states makes the operational conversation much simpler:
- Build. A recipe file describes the application and its dependencies, and the build produces an immutable image with a version tag.
- Publish. The image is pushed to a registry — Amazon ECR in AWS — where it is stored, versioned and can be scanned for known vulnerabilities.
- Run. An orchestrator pulls the image and starts one or more containers from it, on the servers it decides.
- Observe. The container emits logs and metrics to the outside; nothing useful is diagnosed by getting inside it.
- Replace. A new version means a new image and new containers. The previous ones are removed rather than patched in place.
That last step is the cultural change that containers bring: infrastructure stops being repaired and starts being replaced. It is the same principle behind CI/CD pipelines and progressive deployments.
Docker vs virtual machines
This is the most useful comparison for understanding why containers gained ground:
| Docker container | Virtual machine | |
|---|---|---|
| What it packages | The application and its dependencies | A full operating system plus the application |
| Weight | Light (megabytes) | Heavy (gigabytes) |
| Startup time | Seconds | Minutes |
| Isolation | Process level, shares the host kernel | Full, with its own operating system |
A container shares the host operating system kernel and only isolates the application, which is why it is far more efficient. A virtual machine includes an entire operating system, giving more isolation but consuming many more resources.
Docker and Kubernetes: where each one fits
Docker handles creating and running individual containers. When a company goes from a few containers to hundreds in production, it needs a layer to coordinate them: that is where Kubernetes comes in, distributing containers across servers, scaling them with demand, and automatically replacing any that fail.
Put simply: Docker builds the unit; Kubernetes operates it at scale. They do not compete, they complement each other.
How Docker runs on AWS
AWS offers managed services to run containers in production without manually administering the infrastructure:
- Amazon ECS and Amazon EKS orchestrate containers at scale.
- AWS Fargate lets you run them without provisioning or managing servers.
- Amazon ECR stores and versions images securely.
If you are unsure whether to orchestrate with Kubernetes, use ECS, or go straight to functions, we compare when each option makes sense in EKS vs ECS vs Lambda: how to choose AWS compute.
This combination makes containers the natural foundation for modernizing applications: you split a monolith into independent services, each packaged as a container, and deploy them on an elastic platform.
Business benefits of Docker
- Real portability: the same image runs in any environment, which reduces errors and speeds up delivery.
- Faster deployments: containers start in seconds and integrate naturally into a CI/CD pipeline.
- Better resource usage: because they are lightweight, several containers coexist efficiently on the same server.
- Foundation for microservices: Docker is the first step in modernizing monolithic applications toward modular cloud architectures.
Docker as a gateway to modernization
Adopting containers is rarely an end in itself: it is the path to more agile, scalable, and operable applications. At Caleidos we guide that journey as part of our application modernization and DevOps practice, with documented production cases in our success stories.
Frequently asked questions
What is Docker in simple terms? It is a technology that packages an application and everything it needs into a portable container that runs the same in any environment.
Is Docker the same as Kubernetes? No: Docker creates and runs containers; Kubernetes orchestrates them at scale in production.
How do you run Docker on AWS? With Amazon ECS or Amazon EKS for orchestration, AWS Fargate to run without managing servers, and Amazon ECR to store images.
What is a container in Docker? It is a running instance of an image: a lightweight, isolated unit with the application and its dependencies, created and deleted in seconds.
Is Docker free? The Docker engine is open source and free. There are commercial products such as Docker Desktop, but the core container technology can be used at no cost.
Want to bring containers to your operation?
Let’s talk about your current platform and we will give you a concrete recommendation on how to get started with containers on AWS.
