Infrastructure as a Service (IaaS): Virtual Servers, Storage, and Networks on Demand

When a company decided to move from a physical data centre to the cloud, the first question used to be: do we rewrite everything, or do we lift and shift? For teams with large existing systems — custom databases, proprietary middleware, OS-specific software — the answer was almost always lift and shift. Infrastructure as a Service made that possible.

IaaS sits at the bottom of the cloud service model stack. It provides raw virtualised compute, storage, and networking. You get the building blocks; you assemble and manage what sits on top. The provider handles physical hardware, power, cooling, hypervisors, and the physical network.

What IaaS Actually Gives You

When you provision an IaaS resource, you are renting capacity on physical hardware that the provider owns, logically isolated for your use. The three core components are:

Compute: Virtual machines (VMs) with configurable CPU count, memory, and clock speed. AWS calls these EC2 instances; Azure calls them Virtual Machines; GCP calls them Compute Engine instances. You choose the size, the operating system image, and the storage configuration. The VM behaves exactly like a physical server — you SSH into it, install software, configure services, and manage it.

Storage: Block storage (raw disk volumes attached to VMs), object storage (flat namespaced storage for any file type), and file storage (shared network file systems). Each has different performance characteristics and pricing. Block storage is fastest; object storage is cheapest at scale.

Networking: Virtual Private Clouds (VPCs) let you define private IP address ranges, subnets, routing tables, and gateways. You control which resources can talk to which, which can reach the internet, and which are isolated. Firewalls (security groups and network ACLs) operate at both the instance and subnet level.

IaaS Responsibility Boundary
------------------------------
Customer manages:
  +---------------------------+
  |  Your Application Code    |
  |  Your Data                |
  |  Runtime / Middleware     |
  |  Operating System         |
  |  VM Configuration         |
  +---------------------------+

Provider manages:
  +---------------------------+
  |  Hypervisor               |
  |  Physical Network         |
  |  Physical Storage         |
  |  Data Centre Facilities   |
  +---------------------------+

IaaS vs PaaS: The Critical Distinction

The line between IaaS and PaaS trips up many engineers. IaaS gives you a VM with nothing installed — you get a blank Linux or Windows instance. PaaS gives you a runtime environment where you push code and the platform handles deployment, scaling, and patching.

Choose IaaS when:

Your software requires specific OS configurations or kernel parameters
You are migrating legacy applications that cannot run in a container or managed runtime
You need to install licensed software (Oracle Database, SAP) with specific system requirements
You require persistent long-running processes that PaaS platforms terminate on idle

Choose PaaS when you are building new applications and have no reason to manage the OS layer.

Major IaaS Providers

Amazon Web Services (EC2, EBS, VPC): The market leader by revenue and service breadth. EC2 has over 500 instance types optimised for general-purpose, compute-intensive, memory-intensive, GPU, and storage-dense workloads. The global footprint spans 30+ regions.

Microsoft Azure (Virtual Machines, Managed Disks, VNet): Strong in enterprises that already run Microsoft workloads. Azure Hybrid Benefit lets customers apply existing Windows Server licences to cloud VMs, materially reducing cost for Microsoft shops.

Google Cloud Platform (Compute Engine, Persistent Disk, VPC): Known for custom machine types — you specify exact vCPU and memory counts rather than choosing from predefined sizes. GCP’s global VPC is a single flat network spanning all regions, unlike AWS where VPCs are regional.

IBM Cloud and Oracle Cloud Infrastructure: Niche positions. IBM targets regulated industries with a focus on hybrid deployments. Oracle Cloud attracts organisations running Oracle Database workloads, offering substantial licensing incentives.

Real-World Use Case: Disaster Recovery

A retail bank operates its core banking system on-premises. Regulations require a disaster recovery site that can take over within four hours of a primary site failure. Maintaining a physical secondary data centre costs over $2 million annually.

With IaaS, the bank uses a cloud DR strategy. During normal operations, critical VM images are replicated to the cloud using snapshot replication. The cloud environment stays dormant — no running VMs, minimal cost. If the primary site fails, the operations team powers on the replicated VMs in the cloud. Because the infrastructure is pre-configured with matching network settings and security groups, RTO (recovery time objective) drops to under two hours.

Cost comparison: $2 million per year for the physical DR site vs. roughly$ 40,000 per year for storage and standby compute in the cloud.

Disaster Recovery Architecture (IaaS)
---------------------------------------
Primary DC (On-Prem)              Cloud DR (IaaS)
  [Core Banking VMs]  -- replicate --> [Dormant Snapshots]
  [Oracle DB]         -- replicate --> [Dormant DB Image]
  [Load Balancer]                      [Standby LB Config]
       |                                      |
  Failure detected                     Team activates
       |                                      |
  Traffic rerouted  <--- DNS failover ---  VMs start

Security and the Shared Responsibility Model in IaaS

IaaS gives you the most control among cloud service models, which also means you carry the most security responsibility. The provider secures the physical layer and the hypervisor. Everything above the hypervisor is yours.

Practical implications:

You must patch the operating system. If you run Linux and a kernel vulnerability is disclosed, you apply the patch.
You configure firewalls. A misconfigured security group that allows SSH from 0.0.0.0/0 is your mistake.
You manage credentials. IAM roles, SSH keys, and application secrets are your responsibility.
You encrypt data. While the provider may offer encryption options, enabling and configuring them correctly is the customer’s job.

Cost Structure and Optimisation

IaaS billing is typically per-instance-hour for compute, per-GB for storage, and per-GB transferred for egress (data leaving the cloud). The on-demand rate is highest. Reserved instances (committing to one or three years) cut compute costs by 30–70%. Spot instances (using spare capacity at market prices, interruptible with short notice) can be 70–90% cheaper, suitable for batch workloads, rendering jobs, and CI/CD pipelines.

The most common cost mistake: leaving instances running when they are not needed. A development VM left running overnight costs almost as much as one used all day. Automated scheduling — stopping non-production instances outside business hours — typically cuts development environment costs by 60–70%.

IaaS remains the workhorse of cloud adoption. Even as PaaS and serverless attract new greenfield development, the vast majority of enterprise cloud spending goes through IaaS because of the sheer volume of existing workloads that require OS-level control.