IaaS #

Within the cloud computing ecosystem, Infrastructure as a Service (IaaS) is the most fundamental service model with the lowest level of abstraction. If we compare cloud services to building an office tower, IaaS is like renting an empty plot of land along with the basic construction materials — cement, foundation rebar, and bricks. We’re fully responsible for designing the building’s architecture, erecting walls, installing the roof, and painting the interior. IaaS offers the highest level of control, customization, and flexibility among all cloud service models. However, this maximum control comes with the consequence of enormous operational responsibility and technical expertise demands on our engineering team. Understanding the IaaS architectural components, the precise division of responsibilities, and ideal usage scenarios is the key to designing robust, cost-efficient cloud infrastructure.

Basic Concepts and Abstraction Philosophy #

The core philosophy behind IaaS is combining the cloud provider’s physical resources (hardware), then dividing them virtually using Hypervisor (virtualization) technology to rent to many customers (multi-tenancy). The hypervisor acts as the abstraction layer sitting on top of physical server hardware. It splits CPU resources, RAM, hard drives, and physical network cards into hundreds of independent virtual machines we know as Virtual Machines (VMs).

  Traditional On-Premise Data Center:
    [ Our Application ] -> [ Runtime & OS ] -> [ Virtualization ] -> [ Physical Server & Storage ]
    * We manage 100%, from physical building security to network cable installation.

  Infrastructure as a Service (IaaS):
    [ Our Application ] -> [ Runtime & OS ]
    ------------------------- ABSTRACTION BOUNDARY -------------------------
    [ Virtualization ] -> [ Physical Server & Storage ]
    * The provider manages physical hardware; we manage the OS and above ourselves.

In the IaaS model, the responsibility demarcation line is drawn right above the hypervisor. The cloud provider guarantees the physical availability of the data center, server hardware integrity, and hypervisor stability. Beyond that boundary — from guest operating system installation, virtual network firewall configuration, database middleware installation, to application code security — everything is fully under our own control and responsibility.

Core IaaS Components #

IaaS infrastructure consists of three main pillars connected to form a unified virtual server ecosystem:

1. Compute (Virtual Machine / VM) #

The Virtual Machine is the primary compute unit in IaaS. We can choose the operating system (various Linux distros like Ubuntu, RedHat, Rocky Linux, or Windows Server) and configure its virtual hardware capacity.

Cloud providers classify VM types by workload characteristics:

• General Purpose: Balanced CPU and RAM performance. Good for medium-scale web servers, testing servers, or code repositories.
• Compute Optimized: Optimized with high-speed CPUs. Good for batch processing, game servers, video transcoding, and scientific computing.
• Memory Optimized: Provides massive RAM capacity. Ideal for in-memory databases (like SAP HANA or large-scale Redis caches).
• Storage Optimized: Equipped with ultra-low-latency local NVMe drives. Great for NoSQL database systems (Cassandra, MongoDB) or distributed file systems.

2. Virtual Networking #

The data center’s physical network is abstracted by IaaS into software-defined networking (SDN). We can design our own isolated virtual network topology using the following components:

• VPC (Virtual Private Cloud): Our main virtual network isolation boundary in the cloud.
• Subnetting: Dividing the VPC into several network segments. We separate instances into a Public Subnet (directly accessible from the internet, e.g., Load Balancer) and a Private Subnet (isolated from the outside internet, e.g., Database Servers).
• Security Groups & Network ACLs: Instance-level (stateful) and subnet-level (stateless) virtual firewalls that we must configure to control which ports data traffic may enter.
• NAT Gateway: Connects private subnet instances to the outside internet (for downloading OS security patches) without allowing outside parties into the instances.

Here’s a common IaaS virtual network topology diagram implemented to secure the application data plane:

flowchart TD
    subgraph VPC["Virtual Private Cloud (VPC)"]
        direction TB
        subgraph PublicSubnet["Public Subnet (With Route to Internet Gateway)"]
            LB["Load Balancer (Multi-AZ)"]
            NAT["NAT Gateway"]
        end
        
        subgraph PrivateSubnet["Private Subnet (Internet Access via NAT)"]
            VM1["VM Server A (App)"]
            VM2["VM Server B (App)"]
        end
        
        LB --> VM1
        LB --> VM2
        VM1 -. "Outbound Traffic" .-> NAT
        VM2 -. "Outbound Traffic" .-> NAT
    end
    
    User["User (Internet)"] --> LB
    NAT --> Internet["Internet Gateway (Public)"]

3. Storage Layer (Virtual Storage) #

In an IaaS environment, storage is divided into several types based on latency and data persistence needs:

• Ephemeral Storage (Instance Store): Physical drives attached directly to the physical host server where the VM runs. Extremely fast read/write speeds, but non-persistent. If the VM is stopped or moved to another host by the provider, all data on this storage is lost forever.
• Block Storage (Persistent Disk): Independent virtual drives connected to the VM through a dedicated storage network. Data inside is permanent even if the VM is stopped or deleted. We can detach this block storage from VM-A and attach it to VM-B.
• File Storage: Shared storage (like NFS/SMB) allowing thousands of VMs to read and write to the same storage medium simultaneously.

The table below compares the characteristics of the three main storage types in IaaS:

When IaaS Is the Right Choice #

Although PaaS and Serverless models offer operational convenience without server management, IaaS remains the top choice for organizations in the following scenarios:

1. Legacy System Migration (Lift-and-Shift) #

Many legacy corporate applications are tightly coupled to local OS configuration, specific drivers, or require software licenses tied to a physical server’s MAC address. Rewriting these applications for PaaS or container compatibility requires expensive re-engineering time and cost. Deploying them to IaaS VMs is the fastest, safest migration path.

2. High-Level OS and Kernel Customization #

If your application requires low-level Linux kernel modifications (for example, enabling real-time kernel modules, customizing swap files, or TCP stack performance tuning at the OS level), you must use IaaS. PaaS services block access at this level for multi-tenant security.

3. Strict Regulatory Compliance #

Some financial or government industry regulations require organizations to have full audit of their server operating systems, restrict active SSH encryption versions, install antivirus/IDS agents at the OS level, and control the physical location of hard disk partitions. Strict audit requirements like these can only be met with the full administrative access latitude of IaaS.

4. Specialized Network Virtual Appliances #

If you want to run commercial firewalls from third parties (like Palo Alto Networks, Fortinet) or design custom virtual routers to connect your local data center to the cloud via IPSec VPN, you must deploy those appliance images on IaaS VMs.

Cost Leaks: The Danger of “VM Sprawl” and Its Mitigation #

One of the biggest economic losses in IaaS environments is VM Sprawl — the uncontrolled proliferation of virtual machines. This happens when developers create new VMs for temporary testing but forget to shut down or delete them after testing finishes.

Because IaaS charges rental fees based on instance uptime (per second or per hour), idle VMs with no traffic keep draining the organization’s monthly budget. This problem is compounded by Orphaned Block Storage — virtual drives left behind that keep being billed even after their parent VM is deleted.

VM Sprawl Mitigation Strategies #

To prevent IaaS cost waste, we must implement the following automation strategies:

• Enforce Mandatory Tagging: Every VM created must carry an owner tag, project name, and expiration date.
• Automated Cleanup Scripts: Run periodic cleanup scripts to shut down VMs in the development environment at night when the office is quiet, and detect orphaned volumes not connected to any VM for safe immediate deletion.

Here’s a simple Terraform automation example that enables accidental-deletion protection (prevent_destroy) and enforces tagging when creating IaaS VMs to control resource lifecycle:

# ✓ CORRECT: Use lifecycle rules and mandatory tagging to mitigate IaaS cost leaks
resource "aws_instance" "development_app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.small"
  subnet_id     = aws_subnet.dev_private.id

  # Enable accidental-deletion prevention lifecycle for production VMs
  lifecycle {
    prevent_destroy = false # Set true for critical production VMs
  }

  # Mandatory tagging for cost monitoring (FinOps) and automated audit
  tags = {
    Name        = "Dev-App-Server"
    Environment = "Development"
    Owner       = "Platform-Engineering-Team"
    Project     = "System-Modernization"
    AutoStop    = "20:00-WIB" # External script reads this tag to shut down VMs at night
  }
}

IaaS Service Comparison Across Providers (Vendor-Agnostic) #

For a cloud architect committed to being vendor-agnostic (not tied to one vendor), it’s important to remember that the IaaS concept is universal. Although product names and CLI commands differ, the functionality behind the services is the same.

The table below maps IaaS component terminology across the world’s three largest cloud providers:

Summary #

• IaaS is the cloud model with the lowest abstraction level, giving full control over the OS and virtual network, with the consequence of the highest operational responsibility burden on our engineering team.
• Compute (VM), virtual networking, and block storage are the three main pillars composing IaaS architecture on any cloud provider.
• IaaS is ideal for lift-and-shift migrations, legacy applications not ready to be refactored, high-level OS kernel customization, and strict data regulation compliance needs.
• Beware of VM Sprawl and Orphaned Storage, the main causes of daily IaaS infrastructure budget leaks. Implement mandatory tagging and automatic shutdown schedulers.
• Understand the separation of stateful (Security Group) and stateless (Network ACL) firewalls in IaaS virtual networking to minimize internal network security gaps.
• The IaaS concept is universal across providers — moving IaaS architecture from AWS to Google Cloud or Azure only requires adapting terminology and API syntax, without changing your core network architecture logic.

← Previous: Control Plane vs Data Plane   Next: FaaS/Serverless →