How Hypervisors Actually Work in AWS (Beyond the Basics)
Cloud platforms like AWS rely heavily on hypervisors, yet they are often explained only at a surface level.
This post takes a practical, internal view of what a hypervisor actually does and how it enables virtualization across CPU, memory, storage, and networking.
The goal here is not definitions, but mechanisms.
What Is a Hypervisor?
A hypervisor is a low-level system software layer that controls physical hardware and allows multiple operating systems (virtual machines) to run on the same machine in strict isolation.
Each virtual machine believes:
- It owns the CPU
- It owns memory
- It owns disks
- It owns a network interface
In reality, these are virtual resources created and enforced by the hypervisor.
Mental model:
A hypervisor does not trick the OS. It enforces a controlled reality where each OS’s assumptions remain true.
Types of Hypervisors
Type 1: Bare-Metal Hypervisors
These run directly on hardware, without a host operating system.
Characteristics:
- No host OS
- Minimal codebase
- Hardware-enforced isolation
- High performance
Examples:
- AWS Nitro Hypervisor
- VMware ESXi
- Xen
A bare-metal hypervisor replaces the need for a host OS, but it is not a general-purpose kernel.
There is no shell, no user space, and no applications.
Type 2: Hosted Hypervisors
These run on top of an existing operating system.
Characteristics:
- Uses host OS drivers
- Easier to install and use
- Higher overhead
Examples:
- VirtualBox
- VMware Workstation
These are common for local development and learning, but not for large-scale cloud platforms.
CPU Virtualization
What the VM Believes
Each VM believes it owns:
- One or more CPU cores
- Direct execution on hardware
What Actually Happens
- Physical CPUs are shared
- The hypervisor schedules entire operating systems, not just processes
- Hardware virtualization extensions (Intel VT-x / AMD-V) allow safe execution
Privileged instructions are trapped and handled by the hypervisor.
Analogy:
Multiple operating systems take turns controlling the CPU, with fast, hardware-enforced switching.
Memory Virtualization (Core to Isolation)
The Problem
How do multiple VMs share RAM without accessing each other’s memory?
The Solution
Memory translation occurs in two stages:
Guest Virtual Address
↓
Guest Physical Address
↓
Host Physical Address
Responsibility split:
- Guest OS: virtual → guest physical
- Hypervisor: guest physical → host physical
The hypervisor programs the CPU’s MMU so memory regions never overlap.
Key point:
Memory isolation is enforced by hardware, not by software trust.
Storage Virtualization
What the VM Sees
/dev/xvda
What Actually Happens
- Disk I/O requests are intercepted
- Requests are redirected to:
- Network-attached storage (EBS)
- Local NVMe devices (via Nitro)
The guest OS never sees real disk addresses.
Every read/write:
- Is associated with a VM identity
- Is routed only to allocated storage blocks
- Cannot access another VM’s data
Network Virtualization
Virtual Network Interfaces (vNICs)
Each VM is assigned:
- A virtual NIC
- A virtual MAC address
- A private IP address
None of these exist physically.
Outbound Traffic Flow
- VM sends packet via virtual
eth0 - Hypervisor intercepts the packet
- Headers are rewritten or encapsulated
- Packet is transmitted via physical NIC
Inbound Traffic Flow
- Physical NIC receives packet
- Hypervisor inspects headers
- Destination MAC/IP mapped to vNIC
- Packet delivered to the correct VM
Packets never move directly between the VM and hardware.
Why MAC Addresses Matter in the Cloud
MAC addresses act as virtual identifiers.
The hypervisor maintains mappings like:
Virtual MAC → VM → NIC Queue
This ensures:
- Traffic isolation
- No packet leakage
- No cross-tenant visibility
AWS Nitro Architecture
AWS modernized hypervisor design using Nitro.
Nitro offloads:
- Networking
- Storage
- Security
Into dedicated hardware cards.
Results:
- Near bare-metal performance
- Smaller hypervisor codebase
- Reduced attack surface
Mental model:
The hypervisor becomes a control plane, not a performance bottleneck.
Hypervisor vs Operating System Kernel
| Capability | OS Kernel | Hypervisor |
|---|---|---|
| Runs applications | Yes | No |
| Manages users | Yes | No |
| Manages filesystems | Yes | No |
| Controls hardware | Indirect | Direct |
| Schedules OSs | No | Yes |
Why Hypervisors Matter in AWS
Without hypervisors:
- No multi-tenancy
- No isolation
- No elasticity
- No cloud economics
Hypervisors make it possible to:
- Securely share hardware
- Launch VMs on demand
- Enforce strong tenant isolation
Key Takeaways
- Hypervisors enforce isolation using hardware
- Virtual machines never access physical resources directly
- CPU, memory, storage, and networking are all virtual views
- AWS Nitro modernizes hypervisor design through hardware offload
References (Official & Authoritative)
AWS Nitro System Overview
https://aws.amazon.com/ec2/nitro/AWS Virtualization Overview
https://docs.aws.amazon.com/whitepapers/latest/aws-overview/virtualization.htmlIntel Hardware Virtualization (VT-x)
https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.htmlAMD Secure Virtual Machine (SVM)
https://www.amd.com/en/technologies/virtualization
Top comments (0)