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! đ
Top comments (0)