Virtual Machine #

In the cloud computing ecosystem, the Virtual Machine (VM) or virtual instance is the main foundation providing on-demand compute power. Before the birth of containerization technology (like Docker and Kubernetes) or serverless computing models, Virtual Machines were the primary means for developers to run their workloads in the cloud. To this day, although computing technology has advanced rapidly, VMs remain an irreplaceable infrastructure pillar because almost all higher-level services (managed databases, Kubernetes worker nodes, FaaS platforms) essentially run on top of a hidden VM virtualization layer. Understanding how virtualization works, instance anatomy, lifecycle, and VM cost optimization is crucial for designing efficient and secure cloud architectures.

How Virtualization Works and the Hypervisor’s Role #

A Virtual Machine isn’t a standalone physical server. A VM is a software-defined computer running on top of a real physical server through an intermediary software layer called the Hypervisor.

The hypervisor’s main responsibility is abstracting physical hardware (like CPU, RAM, storage, and network cards) and dividing it into several isolated virtual environments, each acting as if it were a separate physical computer.

flowchart TD
    subgraph PhysicalServer ["Physical Server (Bare Metal Host)"]
        PhysicalHW["Physical Hardware<br>(CPU Cores, System RAM, NIC, SSDs)"]
        HypervisorLayer["Hypervisor Layer<br>(Nitro / KVM / ESXi)"]
        
        PhysicalHW --> HypervisorLayer
    end
    
    subgraph VM_A ["Virtual Machine A"]
        AppA["Application A"] --> OSA["Guest OS (Linux)"]
    end
    
    subgraph VM_B ["Virtual Machine B"]
        AppB["Application B"] --> OSB["Guest OS (Windows)"]
    end
    
    subgraph VM_C ["Virtual Machine C"]
        AppC["Application C"] --> OSC["Guest OS (Linux)"]
    end
    
    HypervisorLayer -->|"Virtual CPU & RAM Allocation"| VM_A
    HypervisorLayer -->|"Virtual CPU & RAM Allocation"| VM_B
    HypervisorLayer -->|"Virtual CPU & RAM Allocation"| VM_C

Hypervisor Types #

1. Type 1 (Bare-Metal Hypervisor): This hypervisor type installs directly on physical server hardware without an intermediary operating system. Examples are the AWS Nitro System, KVM (Kernel-based Virtual Machine), VMware ESXi, and Microsoft Hyper-V. This type is used exclusively by public cloud providers because it offers the lowest latency, near-bare-metal performance, and high-level hardware isolation security.
2. Type 2 (Hosted Hypervisor): This hypervisor type runs as software on top of a physical computer’s main operating system (Host OS). Examples are VirtualBox or VMware Workstation, commonly installed on personal laptops for local testing needs.

Modern hypervisors leverage special hardware instructions from CPU manufacturers (like Intel VT-x or AMD-V) to direct VM compute operations straight to the physical CPU without software translation overhead, making virtual CPU (vCPU) performance almost identical to physical CPUs.

Cloud Instance Anatomy and Components #

When we launch a Virtual Machine instance in the cloud, the hypervisor assembles various virtual components to form a complete computer system:

1. vCPU (Virtual Central Processing Unit) #

A vCPU is the virtual processing unit allocated to our VM. Physically, one vCPU usually maps to one hyperthread (logical thread) on the host server’s physical processor core. If the physical server has a 32-Core, 64-Thread processor, the hypervisor can distribute a maximum of 64 vCPUs to various VMs in parallel.

2. Virtual RAM (Random Access Memory) #

Physical host memory allocation strictly isolated by the hypervisor for use by one specific VM. The hypervisor guarantees the OS inside VM A can’t see or read memory sectors belonging to VM B for data security.

3. Virtual Storage (Disk Volumes) #

VMs need storage media for the operating system (boot volume) and application data.

• Root Volume: Persistent block storage containing the OS filesystem. Usually mounted over a private storage network.
• Ephemeral Storage (Instance Store): Physical SSD disks installed directly inside the VM’s physical host server. These disks offer very fast I/O performance for temporary files, but data on them is permanently deleted when the VM instance is stopped or moved.

4. VNIC (Virtual Network Interface Card) #

The virtual network card attached to the VM, connecting it to our private VPC network. This VNIC has a fixed private IP address and can optionally have a public IP address.

5. Metadata Service and IMDS #

Every VM instance in the cloud has access to an internal metadata server through a special link-local IP address: http://169.254.169.254. The metadata service stores dynamic information about the VM, such as the instance name, IAM role security role, IP address, and start-up script configuration (user-data).

# CORRECT: Querying metadata using IMDSv2 (Secure Token-based) on Linux
# Step 1: Get the Security Token
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: Use the token to retrieve instance ID details
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

Security Note: Always use IMDSv2 (token-based) like the example above instead of the old IMDSv1 to prevent SSRF (Server-Side Request Forgery) security vulnerabilities in our applications.

Cloud Instance Type Classification #

Cloud providers divide VM instances into various family categories to help us match hardware specifications with application workload characteristics.

Instance Lifecycle and Cost Implications #

Understanding VM lifecycle states is crucial for controlling operational cloud bills. Many organizations make the mistake of keeping VMs running 24 hours a day when those VMs are only used for testing during office hours.

stateDiagram-v2
    [*] --> Pending: Launch / Run Instance
    Pending --> Running: Booting Complete
    
    Running --> Stopping: Stop request
    Stopping --> Stopped: Shutdown complete
    
    Stopped --> Pending: Start request
    
    Running --> Terminating: Terminate / Delete request
    Stopped --> Terminating: Terminate / Delete request
    
    Terminating --> Terminated: Cleanup & delete disks
    Terminated --> [*]: Object removed from console
    
    Running --> Rebooting: OS Restart
    Rebooting --> Running: Booting Complete

Lifecycle Details and Billing Rules: #

1. Pending: The instance is being prepared by the cloud controller, including finding a physical host server with free hardware capacity. Billing Rule: Free.
2. Running: The OS inside the VM is actively running. Billing Rule: We’re charged full per-second rates for compute capacity (vCPU & RAM), commercial OS licenses (like Windows Server or RHEL), disk storage, and static public IP addresses.
3. Stopped: The instance is cleanly shut down. Physical RAM memory is released back to the host pool. Billing Rule: We’re not charged for compute (vCPU & RAM). However, we still pay rental fees for the storage volume (root block storage) attached to the VM because our data is fully retained.
4. Terminated: The instance is permanently removed from the cloud system. Billing Rule: Rental fees stop entirely. The root disk is automatically deleted by default, while secondary volume data can be retained based on the Delete on Termination tag configuration.

Cost Efficiency Tips: Scheduled Start/Stop #

For non-production environments (like Dev, QA, and Staging), servers are usually only needed on weekdays Monday-Friday from 09:00 - 17:00 (40 hours per week out of 168 total weekly hours).

• ANTI-PATTERN: Leaving staging servers on 24/7 wastes budget by: $$\frac{168 - 40}{168} \times 100% = 76.1% \text{ of budget wasted}$$
• Solution: Apply scheduler automation scripts (like AWS Instance Scheduler or Azure Automation) to automatically shut VMs down at night and start them back up in the morning. This immediately reduces non-production server compute bills by over 70%.

Instance Security and Access Management #

Securing administrative shell access to cloud VMs is the number one security priority. Opening administrative ports to the public internet is one of the most fatal mistakes exploited by hackers.

Traditional SSH Danger Holes #

Many developers create firewall rules (Security Groups) opening SSH (port 22) or RDP (port 3389) to IP address 0.0.0.0/0 (everyone on the internet) so they can manage VMs from anywhere.

// ANTI-PATTERN: Security Group opening administrative ports to the public internet
Type: SSH
Port: 22
Source: 0.0.0.0/0          // DON'T: Our VM will be constantly brute-forced!

// CORRECT: Restrict SSH access only to office VPN IPs or private Bastion Host IPs
Type: SSH
Port: 22
Source: 192.168.10.0/24    // ✓ CORRECT: Only IPs from our private VPN network

Best Solution: Agentless Access / Session Manager #

The modern recommended method is eliminating public SSH ports entirely.

• How It Works: We install a small official agent from the cloud provider inside the VM (like the SSM Agent on AWS). This agent opens a secure private outbound connection to the cloud management service.
• Advantages: We can directly enter the Linux VM terminal through the cloud console web interface or using AWS CLI/Azure CLI authorized with IAM policies. We don’t need SSH key pairs, don’t manage .pem files, and don’t open port 22 on external firewalls. All shell command typing activities are also transparently logged to a centralized audit system.

Summary #

• Virtual Machines divide the physical host server’s hardware capacity into several isolated virtual computers using low-latency Type 1 Hypervisor layers.
• Choose instance families based on our application workload’s bottleneck characteristics — General Purpose for standard web servers, Compute Optimized for transcoding/batch processing, and Memory Optimized for large transactional databases.
• Distinguish Stop and Terminate states — stopped instances release CPU/RAM allocation (compute billing stops, only disk storage is paid), while terminated instances permanently delete the server object.
• Apply scheduled start/stop policies on non-production environments (staging/development) to avoid wasting compute rental costs at night and weekends.
• Use token-based IMDSv2 for secure internal instance metadata queries against SSRF security exploit risks.
• Avoid opening SSH (22) or RDP (3389) ports to the public internet — use private VPN tunnels or services like Session Manager integrated with IAM authorization.

← Previous: Lifecycle & Data Tiering   Next: Container →