Containers vs VMs — Why Memory Leaks Crash Neighbors

The containerization vs virtualization decision is not a technology preference — it is a security, performance, and operational trade-off that directly impacts cost, startup time, and isolation guarantees. Getting it wrong means either overpaying for VMs where containers suffice, or under-isolating workloads where VMs are required.

The architectural difference is at the kernel level. Virtualization virtualizes hardware — each VM runs its own kernel on top of a hypervisor. Containerization virtualizes the OS — containers share the host kernel and use Linux namespaces for isolation and cgroups for resource limits. This single difference cascades into every other trade-off.

Common misconceptions: containers are not insecure by default (misconfiguration is the problem), VMs are not always better (they are heavier and slower), and the choice is not binary (gVisor and Kata Containers provide hybrid approaches). The right answer depends on your workload's trust boundary, performance requirements, and compliance needs.

Why Containers Share the Kernel and VMs Don't

Containerization and virtualization both isolate workloads, but they differ at the kernel level. A virtual machine runs a full guest OS on top of a hypervisor, emulating hardware — each VM gets its own kernel, memory, and device drivers. A container shares the host OS kernel and runs as an isolated user-space process, using cgroups and namespaces to limit CPU, memory, and filesystem access. That shared kernel is the single most important distinction: containers are lightweight (start in milliseconds, not minutes) but have a weaker isolation boundary.

In practice, a VM allocates a fixed chunk of RAM (e.g., 4 GB) that the hypervisor reserves. A container uses a memory limit (e.g., --memory=512m) enforced by cgroups, but it shares the host's page cache and kernel memory. If a container leaks memory, it consumes host kernel memory — slab, dentries, or anonymous pages — which can starve other containers on the same host. VMs don't have this cross-talk because each guest OS manages its own memory independently.

Use containers when you need density and fast startup — microservices, CI runners, ephemeral batch jobs. Use VMs when you need strong isolation — multi-tenant workloads with untrusted code, legacy OS requirements, or compliance mandates that demand separate kernels. The real decision isn't about performance; it's about how much failure isolation you need per unit of cost.

Architecture: Hardware Virtualization vs OS-Level Virtualization

The fundamental difference between virtualization and containerization is where the abstraction boundary sits. Virtualization abstracts hardware. Containerization abstracts the OS. This single difference cascades into every other trade-off.

Virtualization architecture: A hypervisor (VMware ESXi, KVM, Hyper-V) sits between the hardware and the guest operating systems. Each VM runs a full guest OS with its own kernel, drivers, system libraries, and init system. The hypervisor virtualizes CPU, memory, disk, and network for each VM. The guest OS believes it has exclusive access to hardware — the hypervisor translates and multiplexes requests to the real hardware.

Hypervisor types: - Type 1 (bare-metal): runs directly on hardware. Examples: VMware ESXi, KVM, Xen, Hyper-V. More efficient — no host OS overhead. Used by cloud providers (AWS uses KVM/Xen, Azure uses Hyper-V). - Type 2 (hosted): runs on top of a host OS. Examples: VirtualBox, VMware Workstation, Parallels. Less efficient — adds an extra layer of overhead. Used primarily for developer laptops.

Containerization architecture: The container runtime (containerd, runc) leverages Linux kernel features — namespaces for isolation and cgroups for resource limits. Each container gets its own view of the filesystem (mount namespace), network stack (network namespace), process tree (PID namespace), and user IDs (user namespace). But all containers share the same kernel. There is no guest OS — the container process runs directly on the host kernel.

Hardware virtualization support: Modern CPUs include hardware extensions for virtualization — Intel VT-x and AMD-V. These extensions allow the hypervisor to run guest OS kernel code directly on the CPU without emulation. Without these extensions, the hypervisor must emulate CPU instructions, which is 10-100x slower. VT-x/AMD-V are the reason VMs are practical for production workloads.

The isolation boundary matters: Because VMs have a separate kernel, a kernel vulnerability in one VM does not affect other VMs or the host. Because containers share the host kernel, a kernel vulnerability affects all containers on that host. This is the fundamental security trade-off.

#!/bin/bash
# Inspect the architecture differences between VMs and containers

# ── Container: check kernel sharing ──────────────────────────────────────────
# Run two containers and compare their kernel versions
docker run --rm alpine:3.19 uname -r
# Output: 6.1.0-18-amd64 (host kernel version)

docker run --rm ubuntu:22.04 uname -r
# Output: 6.1.0-18-amd64 (SAME kernel — they share the host kernel)

# Check namespaces for a running container
CONTAINER_PID=$(docker inspect --format '{{.State.Pid}}' <container-name>)
ls -la /proc/$CONTAINER_PID/ns/
# Output shows: ipc, mnt, net, pid, user, uts — each is an isolated namespace

# Check cgroup resource limits
cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.shares
# Default: 1024 (1 CPU share). Adjust with --cpus flag.

cat /sys/fs/cgroup/memory/docker/<container-id>/memory.limit_in_bytes
# Shows the memory limit set by --memory flag

# ── VM: check hardware virtualization ────────────────────────────────────────
# Check if the host supports hardware virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo
# Output > 0 means hardware virtualization is supported

# Check loaded hypervisor modules
lsmod | grep -E 'kvm|vbox|vmw'
# kvm_intel or kvm_amd = KVM is loaded
# vboxdrv = VirtualBox is loaded

# Check VM disk driver (inside a VM)
lsblk -o NAME,TYPE,TRAN,MODEL
# virtio = paravirtualized driver (fast)
# ide/scsi = emulated driver (slow)

# ── Compare startup time ─────────────────────────────────────────────────────
# Container startup
time docker run --rm alpine:3.19 echo 'container started'
# Typical: 0.3-0.5 seconds

# VM startup (using a minimal cloud image)
time virsh start my-vm && while ! virsh dominfo my-vm | grep -q 'running'; do sleep 1; done
# Typical: 15-60 seconds depending on OS and cloud-init

Performance Benchmarks: CPU, Memory, Disk I/O, and Network

Performance differences between VMs and containers are real but context-dependent. For most application workloads, the difference is negligible. For I/O-intensive and network-intensive workloads, the difference can be significant.

CPU performance: Containers deliver near-native CPU performance — typically within 1-2% of bare metal. The overhead comes from cgroup accounting and namespace switching. VMs add 5-15% overhead from hardware virtualization (VT-x/AMD-V) and guest OS scheduling. The overhead is higher for workloads with frequent context switches (many threads, high syscall rate).

Memory performance: Containers use the host's native memory management — no overhead. VMs require the hypervisor to manage memory translation (EPT/NPT), which adds 2-5% overhead. Memory overcommit (allocating more virtual memory than physical) is common in VM environments and can cause swapping, which degrades performance dramatically.

Disk I/O performance: This is where the difference is most significant. Containers using the host's filesystem (bind mounts) deliver near-native I/O performance. VMs using virtualized disk drivers (virtio-blk) add 10-30% I/O overhead. Emulated drivers (IDE, legacy SCSI) can add 50%+ overhead. NVMe passthrough eliminates this overhead but limits VM mobility.

Network performance: Containers using bridge networking add 5-10% overhead from NAT and virtual bridge processing. Containers using host networking deliver near-native performance. VMs using virtio-net add 5-15% overhead. SR-IOV passthrough eliminates this overhead but requires hardware support.

Startup time: This is the most dramatic difference. Containers start in 0.3-2 seconds. VMs start in 15-60 seconds (full boot) or 1-5 seconds (resume from snapshot). For auto-scaling workloads that need to respond to traffic spikes in seconds, containers are the only viable option.

#!/bin/bash
# Benchmark container vs VM performance across CPU, memory, I/O, and network

# ── CPU Benchmark ────────────────────────────────────────────────────────────
# Container: CPU performance (sysbench)
docker run --rm severalnines/sysbench sysbench cpu --cpu-max-prime=20000 run
# Look for 'events per second' — higher is better

# VM: CPU performance (run inside VM)
apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 run
# Compare 'events per second' with container result

# ── Memory Benchmark ────────────────────────────────────────────────────────
# Container: memory throughput
docker run --rm severalnines/sysbench sysbench memory --memory-block-size=1M --memory-total-size=10G run
# Look for 'transferred' throughput in MiB/sec

# VM: memory throughput (run inside VM)
sysbench memory --memory-block-size=1M --memory-total-size=10G run

# ── Disk I/O Benchmark ──────────────────────────────────────────────────────
# Container: disk I/O with fio
docker run --rm -v $(pwd)/fio-test:/test loicmahieu/alpine-fio \
  fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
  --numjobs=4 --size=256M --runtime=10 --time_based --filename=/test/file
# Look for 'IOPS' and 'lat avg' — IOPS higher and latency lower is better

# VM: disk I/O (run inside VM)
fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
  --numjobs=4 --size=256M --runtime=10 --time_based --filename=/tmp/fio-test/file

# ── Network Benchmark ────────────────────────────────────────────────────────
# Container: network throughput with iperf3
# Server:
docker run -d --name iperf-server -p 5201:5201 networkstatic/iperf3 -s
# Client:
docker run --rm networkstatic/iperf3 -c <host-ip> -t 10
# Look for 'sender' bandwidth in Gbits/sec

# VM: network throughput (run inside VM)
iperf3 -c <host-ip> -t 10

# ── Startup Time Benchmark ───────────────────────────────────────────────────
# Container: measure cold start
time docker run --rm alpine:3.19 echo 'started'
# Typical: 0.3-0.5s

# Container: measure warm start (image already pulled)
time docker run --rm alpine:3.19 echo 'started'
# Typical: 0.1-0.2s

# VM: measure boot time (run on hypervisor)
time virsh start test-vm && sleep 1 && while ! virsh dominfo test-vm | grep -q running; do sleep 0.5; done
# Typical: 15-60s

Security Isolation: Kernel Sharing, Attack Surface, and Defense in Depth

Security isolation is the most important trade-off between containerization and virtualization. The difference is not theoretical — it has caused real production breaches.

VM isolation: Each VM has its own kernel. A kernel vulnerability in VM A does not affect VM B or the host. The hypervisor is the only shared component, and hypervisors have a much smaller attack surface than full kernels (fewer lines of code, fewer syscalls, simpler state machine). This is why cloud providers (AWS, GCP, Azure) use VMs for multi-tenant isolation.

Container isolation: All containers share the host kernel. A kernel vulnerability (like Dirty Pipe, CVE-2022-0847, or CVE-2020-14386) affects every container on the host. The attack surface is the entire kernel — millions of lines of code, hundreds of syscalls, complex state. Container runtimes mitigate this with seccomp (syscall filtering), AppArmor/SELinux (mandatory access control), and capabilities dropping — but these are defense-in-depth layers, not a separate kernel.

The multi-tenant boundary: For single-tenant workloads (your code, your infrastructure, your team), container isolation is sufficient. The risk of a kernel CVE being exploited by your own code is low, and you control the patching cadence. For multi-tenant workloads (running untrusted customer code), the shared kernel is an unacceptable attack surface. Use VMs (Firecracker, Kata Containers) or a user-space kernel (gVisor).

Hybrid approaches: - gVisor: intercepts syscalls in user space, providing a kernel-like interface without exposing the host kernel. Adds 2-10% overhead but dramatically reduces attack surface. - Kata Containers: runs each container in a lightweight VM with its own kernel. Provides VM-level isolation with container-like management. - Firecracker: AWS's microVM technology used for Lambda and Fargate. Starts a VM in 125ms with minimal memory overhead (5MB per microVM).

Seccomp and capabilities: Even within the container isolation model, seccomp and capabilities provide defense in depth. The default seccomp profile blocks ~44 dangerous syscalls. Dropping all capabilities (--cap-drop=ALL) and adding back only what is needed minimizes the blast radius of a compromised container.

#!/bin/bash
# Security isolation inspection and hardening

# ── Check container security features ────────────────────────────────────────

# Check seccomp profile (syscall filtering)
docker inspect <container> --format '{{.HostConfig.SecurityOpt}}'
# Output: [seccomp=/path/to/profile.json] or [seccomp=unconfined]
# Default profile blocks ~44 dangerous syscalls out of ~300+

# Check if container is running as root
docker exec <container> id
# uid=0(root) = running as root (bad in production)
# uid=1000(appuser) = running as non-root (good)

# Check capabilities (fine-grained privilege control)
docker inspect <container> --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}'
# CapDrop: [ALL] CapAdd: [NET_BIND_SERVICE] = minimal privileges

# Check AppArmor profile
docker inspect <container> --format '{{.AppArmorProfile}}'
# docker-default = AppArmor is active (good)
# unconfined = no AppArmor (bad in production)

# ── Check if running on gVisor (user-space kernel) ───────────────────────────
docker info | grep -i runtime
# runsc = gVisor runtime (enhanced isolation)
# runc = standard runtime (standard isolation)

# Run a container with gVisor
docker run --runtime=runsc --rm alpine:3.19 dmesg | head -5
# gVisor intercepts syscalls — dmesg output differs from standard Linux

# ── Check VM isolation (inside a VM) ─────────────────────────────────────────
# Each VM has its own kernel — verify with different kernel versions
docker run --rm alpine:3.19 uname -r  # Shows host kernel
# Inside VM: uname -r  # Shows guest kernel (can be different)

# Check if the hypervisor exposes hardware virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo
# > 0 = hardware virtualization available

# ── Kernel CVE check (critical for container hosts) ──────────────────────────
# Check kernel version
uname -r

# Cross-reference with known CVEs
# Example: Dirty Pipe affects kernels 5.8 through 5.16.10
# If uname -r shows 5.10.0-amd64, the host is vulnerable
# Fix: apt update && apt upgrade linux-image-$(uname -r)

Operational Trade-offs: Scaling, Density, Patching, and Debugging

Beyond architecture and performance, the operational differences between VMs and containers determine day-to-day engineering velocity.

Scaling speed: Containers scale in seconds — start a new container, it is ready to serve traffic in 1-2 seconds. VMs scale in minutes — boot a new VM, wait for cloud-init, install dependencies, start the application. For auto-scaling workloads that respond to traffic spikes, containers are the only option that provides sub-minute scaling.

Density: On the same hardware, you can run 10-50x more containers than VMs. A server with 64GB RAM might run 10-15 VMs (each consuming 2-4GB for the guest OS alone) or 100-200 containers (each consuming 50-200MB for the application only). This density difference directly impacts infrastructure cost.

Patching: VM patching requires updating the guest OS inside each VM — either manually, with configuration management (Ansible, Puppet), or with golden image rebuilds. Container patching requires rebuilding the image with an updated base layer and redeploying — a single docker build && docker push. Container patching is faster and more reproducible because the image is immutable.

Debugging: VMs provide a full OS environment — you can SSH in, install debugging tools, inspect logs, and run diagnostics. Containers are minimal by design — many production containers do not have a shell, let alone debugging tools. Debugging containers requires docker exec (if a shell exists), docker logs, or sidecar containers with debugging tools.

Networking: VMs typically use the hypervisor's virtual switch (vSwitch) or the cloud provider's VPC networking. Containers use software-defined networking (bridge, overlay, macvlan). VM networking is simpler to reason about (standard IP networking). Container networking adds complexity (DNS-based service discovery, overlay encapsulation, ingress routing mesh) but provides better integration with orchestration platforms.

Immutability: Container images are immutable — once built, they do not change. Deployments replace the entire container with a new image. This eliminates configuration drift. VMs are mutable by default — you can SSH in and modify the filesystem. Configuration drift in VMs is a common source of 'works on staging but not production' bugs.

#!/bin/bash
# Operational comparison: scaling, density, patching, and debugging

# ── Scaling: container vs VM auto-scaling ─────────────────────────────────────

# Container: scale from 1 to 10 replicas in seconds
docker compose up -d --scale api=10
# All 10 containers are ready in 2-5 seconds

# VM: scale from 1 to 10 instances (AWS example)
aws autoscaling set-desired-capacity \
  --auto-scaling-group-name my-asg \
  --desired-capacity 10
# New VMs take 2-5 minutes to boot, run cloud-init, and become healthy

# ── Density: compare resource usage ──────────────────────────────────────────

# Container: check resource usage per container
docker stats --no-stream --format '{{.Name}}: {{.MemUsage}}'
# Typical output:
# api-1: 85MiB / 15.55GiB
# api-2: 92MiB / 15.55GiB
# postgres: 120MiB / 15.55GiB
# Total: ~300MB for 3 containers

# VM: check resource usage per VM (inside each VM)
free -h
# Typical output:
# total: 3.8GiB  used: 1.2GiB  (OS overhead alone)
# Total: 1.2GB per VM just for the OS, before the application starts

# ── Patching: container rebuild vs VM patching ───────────────────────────────

# Container: rebuild with updated base image
docker build --no-cache -t my-app:patched .
docker push my-app:patched
# Entire patch process: 2-5 minutes, fully automated, reproducible

# VM: patch guest OS (run inside VM)
apt update && apt upgrade -y
# Or rebuild golden image with packer/ansible
# Entire patch process: 10-30 minutes per VM, or hours for golden image rebuild

# ── Debugging: container vs VM ───────────────────────────────────────────────

# Container: exec into running container
docker exec -it <container> sh
# Limited tools — production containers often have no shell

# Container: use a debug sidecar
docker run --rm -it --pid=container:<target> --net=container:<target> \
  nicolaka/netshoot bash
# Full debugging toolkit without modifying the production container

# VM: SSH into running VM
ssh user@vm-ip
# Full OS environment — install any debugging tool

The Hybrid Middle Ground: gVisor, Kata Containers, and Firecracker

The containerization vs virtualization debate is not binary. Three technologies provide hybrid approaches that combine the best of both worlds — at the cost of added complexity.

gVisor (Google): A user-space kernel that intercepts container syscalls and implements them in Go. The container process never directly touches the host kernel. gVisor implements ~70 of the ~400 Linux syscalls, filtering out the rest. This dramatically reduces the attack surface while maintaining container-like startup speed (1-2 seconds). The trade-off: 2-10% performance overhead and limited syscall compatibility (some applications do not work with gVisor).

Kata Containers: Runs each container in a lightweight VM with its own kernel. Provides VM-level isolation with container-like management (Docker, Kubernetes integration). Each Kata container is a microVM — it starts in 1-3 seconds and uses 20-50MB of overhead. The trade-off: higher overhead than standard containers but lower than full VMs.

Firecracker (AWS): A microVM technology designed for serverless workloads. AWS Lambda and Fargate use Firecracker to run each function in its own microVM. Firecracker starts a VM in 125ms with 5MB of memory overhead. The trade-off: limited device support (no GPU, no USB), designed for short-lived workloads, and requires KVM support.

When to use each: - gVisor: moderate-security multi-tenant workloads where syscall compatibility is acceptable - Kata Containers: high-security multi-tenant workloads requiring a real kernel per tenant - Firecracker: serverless platforms running short-lived, stateless functions

The cost of hybrid approaches: gVisor adds 2-10% overhead. Kata adds 10-20% overhead. Firecracker adds 3-8% overhead. All three add operational complexity — custom runtimes, different debugging workflows, and limited ecosystem support compared to standard containers or full VMs. Use them when the security benefit justifies the complexity cost.

#!/bin/bash
# Configure and compare hybrid runtimes

# ── gVisor: user-space kernel ────────────────────────────────────────────────

# Install gVisor
(
  set -e
  ARCH=$(uname -m)
  URL="https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}"
  wget ${URL}/runsc ${URL}/runsc.sha512 \
    ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc containerd-shim-runsc-v1
  sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin
)

# Configure Docker to use gVisor
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc",
      "runtimeArgs": ["--platform=systrap"]
    }
  }
}
EOF
sudo systemctl restart docker

# Run a container with gVisor
docker run --runtime=runsc --rm alpine:3.19 uname -a
# Output shows gVisor kernel info instead of host kernel

# ── Kata Containers: lightweight VMs ────────────────────────────────────────

# Install Kata Containers (Ubuntu)
sudo apt install -y kata-runtime kata-proxy kata-shim

# Configure Docker to use Kata
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "runtimes": {
    "kata": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}
EOF
sudo systemctl restart docker

# Run a container with Kata (it is actually a VM)
docker run --runtime=kata --rm alpine:3.19 dmesg | head -3
# Output shows a separate kernel — this is a VM, not a container

# ── Compare startup times ────────────────────────────────────────────────────
echo '--- Standard container ---'
time docker run --rm alpine:3.19 echo done
# ~0.3s

echo '--- gVisor container ---'
time docker run --runtime=runsc --rm alpine:3.19 echo done
# ~0.5s (2x slower than standard, but still fast)

echo '--- Kata container (microVM) ---'
time docker run --runtime=kata --rm alpine:3.19 echo done
# ~1.5s (5x slower, but provides full kernel isolation)

Cost Analysis: Infrastructure Spend, Operational Overhead, and Hidden Costs

The cost difference between containerization and virtualization extends beyond the infrastructure bill. It includes operational overhead, scaling efficiency, and hidden costs that appear at scale.

Infrastructure cost: Containers are 10-50x denser than VMs. A workload that requires 20 VMs (each t3.medium at $30/month = $600/month) might run on 5 containers on a single c5.xlarge ($130/month). The savings compound at scale — a team running 200 microservices saves $10K-50K/month by using containers instead of VMs.

Operational cost: VMs require more operational overhead — OS patching, configuration management, monitoring agents per VM, and manual scaling. Containers are patched by rebuilding an image (automated in CI/CD), configured declaratively (Docker Compose, Kubernetes), and scaled automatically by orchestrators. The operational savings are harder to quantify but often exceed the infrastructure savings.

Hidden costs of containers: - Resource limit enforcement: without --memory and --cpus, one container can starve others. Enforcing limits requires monitoring and tuning. - Orchestration complexity: Kubernetes adds a layer of complexity that requires dedicated platform engineers. - Security hardening: container hosts require kernel patching, seccomp profiles, and network policies — all of which require expertise. - Image storage: Docker images consume registry storage. Without cleanup policies, storage costs grow unbounded.

Hidden costs of VMs: - Over-provisioning: teams often provision VMs larger than needed to avoid performance issues. This wastes 30-50% of allocated resources. - Configuration drift: VMs are mutable. Over time, manual changes create drift that makes reproducibility impossible. - Boot time: VMs take 15-60 seconds to boot. Auto-scaling must over-provision to handle traffic spikes, wasting resources during normal load.

#!/bin/bash
# Compare infrastructure costs between VMs and containers

# ── VM cost calculation (AWS example) ────────────────────────────────────────
# 20 microservices, each on a t3.medium (2 vCPU, 4GB RAM)
VM_COUNT=20
VM_COST_PER_MONTH=30  # t3.medium on-demand price
TOTAL_VM_COST=$((VM_COUNT * VM_COST_PER_MONTH))
echo "VM cost: $VM_COUNT VMs x \$ $VM_COST_PER_MONTH/month = \$ $TOTAL_VM_COST/month"

# ── Container cost calculation (AWS EKS example) ─────────────────────────────
# Same 20 microservices on 3 c5.xlarge nodes (4 vCPU, 8GB RAM each)
NODE_COUNT=3
NODE_COST_PER_MONTH=130  # c5.xlarge on-demand price
EKS_COST=75  # EKS cluster management fee
TOTAL_CONTAINER_COST=$((NODE_COUNT * NODE_COST_PER_MONTH + EKS_COST))
echo "Container cost: $NODE_COUNT nodes x \$ $NODE_COST_PER_MONTH/month + \$ $EKS_COST EKS fee = \$ $TOTAL_CONTAINER_COST/month"

# ── Savings ──────────────────────────────────────────────────────────────────
SAVINGS=$((TOTAL_VM_COST - TOTAL_CONTAINER_COST))
PERCENT_SAVED=$((SAVINGS * 100 / TOTAL_VM_COST))
echo "Monthly savings: \$ $SAVINGS ($PERCENT_SAVED% reduction)"

# ── Operational overhead comparison ──────────────────────────────────────────
echo ""
echo "Operational overhead per month:"
echo "VM patching (20 VMs x 30 min): 10 hours"
echo "Container patching (rebuild + deploy): 30 minutes"
echo "VM scaling (manual or ASG lag): 5-15 min per event"
echo "Container scaling (Kubernetes HPA): 10-30 sec per event"
echo "VM monitoring agents (20 instances): 20 agents"
echo "Container monitoring (DaemonSet): 1 agent per node (3 total)"