Infrastructure as a Service: Renting Foundational Cloud Resources
📑 On this page
- A concrete example: a cloud virtual machine
- Virtual compute
- Images
- Virtual networking
- Security groups and firewalls
- Block storage
- Instance-local storage
- Operating-system responsibility
- Immutable infrastructure
- Autoscaling groups
- Load balancing
- Identity for instances
- High availability
- Backups and snapshots
- Infrastructure as code
- Patching strategies
- When IaaS fits
- Hidden operational cost
- Knowledge check
- The one idea to remember
Infrastructure as a Service lets an organization rent compute, networking, and storage without purchasing and operating physical data-center hardware.
The provider manages the building and virtualization layer. The customer receives flexible infrastructure primitives and substantial control.
IaaS removes physical hardware ownership, not the need to operate the operating system and workload safely.
It is useful when teams need customization that a higher-level platform does not provide.
A concrete example: a cloud virtual machine
A team provisions a Linux virtual machine in minutes.
The provider supplies:
- physical server,
- power and cooling,
- hypervisor,
- regional network,
- and virtual disk service.
The team still configures:
- operating system,
- patches,
- firewall rules,
- application runtime,
- backups,
- monitoring,
- identities,
- and deployment.
Virtual compute
IaaS compute commonly exposes virtual machines with selected:
- CPU,
- memory,
- architecture,
- local storage,
- accelerator,
- and network capacity.
The instance type describes a bundle of resources, but actual performance can depend on storage, network limits, neighboring load, and CPU generation.
Benchmark the workload rather than choosing only by vCPU count.
Images
An image is a template used to create instances.
It may contain:
- operating system,
- base packages,
- security configuration,
- agents,
- and application dependencies.
Images should be versioned, built reproducibly, scanned, and replaced regularly instead of manually patched into unique long-lived servers.
Virtual networking
Customers design logical networks:
- address ranges,
- subnets,
- routes,
- gateways,
- firewall rules,
- private endpoints,
- and load balancers.
Cloud networking is software-controlled, but mistakes can expose services publicly or block recovery traffic just as physical-network mistakes can.
Security groups and firewalls
Network policies should allow only required communication.
For example:
- the public load balancer accepts HTTPS,
- application instances accept traffic only from the load balancer,
- the database accepts traffic only from the application tier.
Broad rules such as "all ports from everywhere" remove valuable isolation.
Block storage
Virtual disks commonly use block-storage services.
Important choices include:
- size,
- performance tier,
- throughput,
- encryption,
- snapshot policy,
- and zone attachment.
A disk can persist after an instance is deleted, but it may still be tied to one zone and need restoration elsewhere.
Instance-local storage
Some instances include fast local disks.
Their data may disappear when the instance stops, fails, or moves. Use them for:
- caches,
- temporary processing,
- replicated data,
- or scratch space.
Do not place the only copy of critical data on ephemeral storage.
Operating-system responsibility
The customer normally manages:
- OS updates,
- package vulnerabilities,
- user accounts,
- SSH or remote access,
- time synchronization,
- audit logs,
- malware protection where needed,
- and hardening.
An unpatched cloud VM is still an unpatched server.
Immutable infrastructure
Rather than modifying servers manually, teams can build a new image and replace instances.
This improves:
- repeatability,
- rollback,
- fleet consistency,
- and auditability.
Emergency changes still need to be captured in the image pipeline or they disappear during replacement.
Autoscaling groups
IaaS can create and remove instances based on demand or health.
For replacement to work, instances should:
- start automatically,
- retrieve configuration securely,
- register with traffic systems,
- avoid important local-only state,
- and report readiness.
Autoscaling a manually configured server only creates more unconfigured servers.
Load balancing
A load balancer distributes traffic across instances and zones.
It can provide:
- health checks,
- TLS termination,
- routing,
- connection management,
- and stable endpoints.
Application capacity and database dependencies still determine whether the fleet can handle demand.
Identity for instances
Applications should use machine roles or workload identities rather than permanent cloud keys stored on disk.
The platform can issue short-lived credentials according to the instance's assigned role. Permissions should be limited to the resources the workload needs.
Compromising one VM should not grant control of the whole cloud account.
High availability
One virtual machine is one failure point.
Resilience may require:
- multiple instances,
- multiple zones,
- replicated storage,
- health-based replacement,
- and tested capacity.
The provider promises infrastructure behavior according to service terms; the customer designs the workload topology.
Backups and snapshots
Snapshots can capture virtual disks, but a crash-consistent snapshot may not represent a valid application state if writes were in progress.
Databases may need application-aware backup procedures. Test restoration, permissions, encryption keys, and cross-region recovery.
Creating snapshots is not the same as proving recovery.
Infrastructure as code
Infrastructure definitions can describe:
- networks,
- instances,
- disks,
- load balancers,
- policies,
- and monitoring.
Versioned code supports review and repeatable environments. It also can reproduce a dangerous mistake quickly, so plans, policy checks, and staged application matter.
Patching strategies
Teams can:
- patch instances in place,
- replace them with updated images,
- or combine both for urgent and routine updates.
Rolling replacement preserves capacity while updating the fleet. Monitor compatibility and have a rollback image.
When IaaS fits
IaaS is useful for:
- specialized operating systems,
- legacy software,
- custom network appliances,
- workloads needing kernel control,
- or migration with minimal application change.
For ordinary web code, managed platforms may reduce operational burden.
Hidden operational cost
VM price is only one cost.
Include:
- engineering time,
- monitoring,
- patching,
- backup,
- incident response,
- licensing,
- data transfer,
- idle capacity,
- and compliance.
Greater control creates more decisions to own.
Knowledge check
- Which layers does an IaaS provider normally manage?
- Why can manually configured long-lived servers drift?
- When is instance-local storage appropriate?
- How do workload identities improve over stored permanent keys?
- Why is a disk snapshot not always an application-consistent backup?
The one idea to remember
IaaS rents flexible compute, network, and storage primitives while leaving the customer responsible for operating systems, workload security, configuration, resilience, and data recovery. Choose it when that control is worth the operational ownership.