Have you ever wondered what really happens under the hood when you launch an EC2 instance, install Docker, and run your containers on it ?
Cloud computing often abstracts away infrastructure, but understanding the layers gives you superpowers as a developer, DevOps engineer, or architect.
Most of us start by running a container on a cloud VM, but lets see
how the entire stack is layered.
We will be seeing right from Hardware,Hypervisior, Bare Metal , Cloud, VM, Docker, Pod work together. So Lets jump in.
Let’s break this down in simple terms, from the hardware all the way up to your containers, and answer a fundamental question:
Where exactly does our container live inside AWS?
The Typical DevOps Stack:
🧞♂️Build a Docker image using a Dockerfile
🧞♂️Launch an EC2 instance (say, Ubuntu)
🧞♂️Install Docker or containerd
🧞♂️Run your container (e.g., Django, Node.js, etc.)
But what’s the full architecture behind this?
The Layer: Container → EC2 → Hypervisor → Physical Server
Here’s how the stack actually looks:
Container (Your App)
This is your running application, isolated with its own filesystem, environment variables, and dependencies. You can run multiple containers, each hosting your different microservice.Docker Engine (or containerd)
Below container, this is the runtime that manages your containers.
It handles pulling images, starting/stopping containers, networking, and more.EC2 Virtual Machine (Guest OS)
This is the Ubuntu or Amazon Linux OS you selected while creating the EC2 instance.
It’s a Guest OS running inside a virtual machine and it’s fully yours to control.AWS Nitro Hypervisor (The LEGEND)
AWS uses a lightweight bare-metal hypervisor called Nitro.
Unlike traditional hypervisors, Nitro doesn’t sit on top of a host OS.
It runs directly on the hardware, creating isolated VMs with high performance & security.
There’s no general-purpose host OS under the Nitro hypervisor , just a lean hypervisor layer and AWS’s custom hardware modules.Physical Server (The Actual Machine)
At the very bottom is a real, physical server inside an AWS data center.
The Nitro hypervisor slices this machine into many virtual machines (EC2 instances) for users like us.
Your Container is Actually… 5 Layers Deep
So when you docker run something on your EC2 instance (on cloud), here’s what’s happening:
🤖Our container runs our app (e.g., Django)
☸️But our created container is running on top of…
🐳A container engine(docker),which installed on…
🐧A guest OS, which is running inside…
☁️A virtual machine(EC2),which created by…
💻A hypervisor,which is sitting on real hardware.
You’re not just running a container:
You’re running it inside a container engine, on a guest OS, inside a VM, on a hypervisor, on AWS bare metal.
Like Inception for DevOps 🍰 layers on layers!
Why Should You Care?
Understanding this layering helps you:
Debug better: Know if an issue is in the container, the VM, or deeper.
Architect smarter: Choose EC2 vs Fargate vs Lambda more effectively.
Secure more: Understand isolation between containers, VMs, and tenants.
Ace certifications: Like the CKAD, where container fundamentals matter.
But then a natural question should pop up:
“We know containers share the Host OS.
But I’m also using FROM ubuntu in my Dockerfile , isn’t that an OS too?”
Q: So what’s going on here, are there 2 OS, one of Container and one of Host?
Ans: Yes… but not in the way you might think.
When you use a Docker image like:
FROM ubuntu
You’re not pulling in a full-blown OS ,you’re only getting the userland i.e:
Shell (/bin/bash)
Libraries (libc, apt, etc.)
Utilities (curl, ls, etc.)
What you don’t get is the kernel , that’s always provided by the Host OS.
Let’s Split the Concept of an “OS” into Two Parts:
Kernel-> The core of the OS, responsible for talking to hardware, managing resources, etc.
Userland -> Everything else: shell (bash), utilities (ls, cat, apt), libraries (glibc), and file system structure (/bin, /etc, etc.)
So When You Write:
dockerfile
FROM ubuntu:22.04
You’re NOT packaging the kernel of Ubuntu.
You’re only including:
The Ubuntu userland
Tools and libraries to make your app run like it would on Ubuntu
The container still uses the Host OS’s kernel to make system calls.
So our running CONTAINER, isn’t a full VM, it’s just a lightweight, isolated process that shares the Host’s kernel but has its own filesystem, processes, and networking.
NOTE:
🚀In VM: Each VM has its own full OS (Guest OS), which is a copy separate from the Host OS.
It keeps using system resources even when idle.
🚀In Containers: They share the Host OS kernel.
🚀When no process is running inside a container, it stops (because a container is just a process).
Final Thoughts
Cloud computing often abstracts away infrastructure, but understanding the layers gives you superpowers as a developer, DevOps engineer, or architect.
So next time when you SSH into your EC2 instance running a container, remember: you’re operating five layers above the metal.
Personal Thought:
And If you’re worried about AI replacing jobs or questioning your ability to keep up, remember:
Every expert was once a beginner. 🌱
I have already written blogs on AI/ML with AWS. Check them out if you like.
And please, Stay curious and motivated, keep learning and moving forward. 🚀
Keep Calm, Stay Aware, and Keep Your Chin Up! 😊 You will do it! ✨
If you want any personal suggestions or a one-to-one call with me, I’d be more than happy to chat🌿
Let’s connect on Linkedin for a Hi !! 🤝
Now, take a deep breath 🌬️ and Go Learn! 🌏
