Cloud Infrastructure: Compute, Storage and Networking

Introduction

Cloud infrastructure is the physical and logical foundation on which cloud applications operate. It combines data-centre hardware, virtualization, software-defined networking, distributed storage, automation, and operational controls. A well-designed infrastructure does more than provide servers and disks: it provides an appropriate balance among performance, availability, durability, elasticity, security, observability, and cost.

The central architectural challenge is that compute, storage, and networking are interdependent. A high-throughput application may require fast compute instances, block storage with sufficient input/output operations per second (IOPS), low-latency network paths, and a load-balancing strategy that prevents uneven distribution. Conversely, a data archive may prioritize durability and cost over latency. Infrastructure design therefore begins with workload requirements rather than with a particular vendor service.

Cloud infrastructure is commonly delivered through a service model. Infrastructure as a Service (IaaS) exposes virtual machines, networks, and storage. Platform as a Service (PaaS) abstracts more operational responsibility, while managed services such as databases, queues, and content-delivery networks provide specialized capabilities. This chapter concentrates on the infrastructure layer while recognizing that modern cloud architecture frequently combines all three models.

Learning Objectives

By the end of this chapter, a learner should be able to:

• distinguish physical, virtual, and software-defined infrastructure;
• select virtual compute resources according to workload characteristics;
• explain autoscaling, elasticity, availability zones, and capacity planning;
• compare object, block, and file storage;
• design virtual networks using subnets, routes, gateways, DNS, and load balancers;
• explain software-defined networking and its security implications;
• evaluate infrastructure using latency, throughput, IOPS, availability, and durability;
• construct an infrastructure design that addresses resilience, governance, cost, and operational risk.

1. From Physical Data Centres to Software-Defined Infrastructure

A traditional data centre consists of servers, storage arrays, switches, routers, power systems, cooling systems, and physical security. Capacity is purchased in advance and applications are usually tied to particular machines. Cloud infrastructure virtualizes or abstracts these resources so that capacity can be provisioned through APIs.

A cloud region is a geographic area containing one or more physically separated availability zones. An availability zone normally contains independent power, cooling, and network infrastructure. The exact implementation differs by provider, but the design principle is consistent: failure of one zone should not necessarily disable the entire application. A region may be selected for regulatory location, user proximity, disaster recovery, or service availability.

Virtualization inserts an abstraction layer between hardware and operating systems. A hypervisor allocates CPU, memory, storage, and virtual network interfaces to virtual machines (VMs). Type 1 hypervisors run directly on hardware; Type 2 hypervisors run above a host operating system and are more common in desktop or laboratory environments. Cloud providers primarily use hardware-level virtualization, often supplemented by paravirtualized drivers and hardware-assisted virtualization.

Containers provide a different abstraction. A container shares the host kernel but isolates processes, filesystems, and resource limits. VMs generally provide stronger operating-system isolation, whereas containers usually start faster and provide greater workload density. A Kubernetes cluster, for example, may run containers on a fleet of virtual machines. The two abstractions are therefore complementary rather than mutually exclusive.

Figure: Logical layers through which cloud infrastructure is delivered and controlled.

The control plane manages provisioning, configuration, identity, policies, and lifecycle operations. The data plane carries application traffic and performs actual computation or storage operations. A control-plane outage may prevent new resources from being created while existing data-plane workloads continue operating. This distinction is important when designing operational dependencies.

2. Virtual Compute and Capacity Design

A virtual compute instance is characterized by vCPUs, memory, local or attached storage, network bandwidth, virtualization features, and a pricing model. vCPU counts should not be interpreted as equivalent to physical-core counts: a provider may implement vCPUs as hardware threads or as scheduled virtual processors. Benchmarking and workload testing are therefore more reliable than nominal size alone.

Compute workloads can be classified as follows:

The fundamental capacity relationship is:

Here, C_required is provisioned capacity, C_demand is expected demand, and M is a safety margin expressed as a decimal. The formula assumes that capacity is measured consistently—for example, requests per second, CPU units, or storage throughput—and that the safety margin is intended to accommodate forecast error and short-term variation. It does not replace performance testing.

For a service receiving 800 requests per second and a 25% capacity margin, the required nominal capacity is 1,000 requests per second. If one instance safely processes 250 requests per second, at least four instances are required under this simplified model. In production, a minimum healthy instance count, deployment overhead, failure tolerance, and load imbalance must also be considered.

Autoscaling and elasticity

Autoscaling changes resource count or size in response to demand. Horizontal scaling adds instances; vertical scaling increases the resources of an existing instance. Horizontal scaling is usually preferred for stateless web services because it improves fault isolation and avoids the upper size limit of a single machine.

A target-tracking policy might maintain average CPU utilization near 55%, while a queue-based policy may add workers when queue depth rises. CPU utilization is not always a suitable metric: an I/O-bound application can be slow at low CPU utilization, and a garbage-collected application may experience latency before CPU thresholds are reached. Good policies use business or saturation metrics such as requests per second, queue age, active sessions, or p95 latency.

Autoscaling has a control-loop structure: measure, compare with a target, adjust capacity, and observe the result. Cooldown periods and stabilization windows reduce oscillation. Scale-out should generally be faster than scale-in because insufficient capacity may violate service objectives, whereas excess capacity primarily increases cost.

Availability planning requires capacity after failures. If an application needs four instances during normal operation and must tolerate loss of one zone, placing two instances in each of two zones is insufficient if all traffic must continue after a zone failure. A design might distribute three instances across each of three zones, or use a provider-specific capacity calculation. The correct choice depends on failure assumptions, workload statefulness, and recovery time objectives.

3. Storage Models and Selection

Cloud storage is not one technology. Object, block, and file storage expose different data models and performance behaviours.

Object storage

Object storage stores objects identified by keys within buckets or similar logical containers. An object includes data, metadata, and an identifier. It is accessed through APIs rather than as a conventional mounted disk. Object storage is well suited to images, video, backups, data lakes, logs, software artifacts, and static website content.

Its strengths include massive scale, high durability, lifecycle policies, versioning, replication options, and integration with analytics and content delivery. Its limitations include API-oriented access, variable request latency, object-level rather than in-place block updates, and application changes when POSIX filesystem semantics are required.

Durability describes the likelihood that data will not be lost or corrupted over a stated period. Availability describes the likelihood that the service is accessible when requested. They are different properties: a storage service may be highly durable but temporarily unavailable. Replication, erasure coding, checksums, and geographically independent copies are common durability mechanisms, but replication does not eliminate deletion, corruption, or credential misuse.

Block storage

Block storage presents raw virtual volumes to a VM. The operating system creates a filesystem or database structure on the volume. It is suitable for boot disks, transactional databases, enterprise applications, and workloads requiring low-latency random access.

Important measures include IOPS, throughput, latency, queue depth, and volume size. IOPS is the number of input/output operations per second. Throughput is the amount of data transferred per second. They are related by request size:

If a volume performs 4,000 operations per second with an average request size of 16 KiB, the theoretical throughput is 64,000 KiB/s, approximately 62.5 MiB/s when using 1 MiB = 1,024 KiB. The result assumes all operations are transfers of the stated size and ignores protocol overhead, read/write asymmetry, queueing, and provider limits. A storage service may cap IOPS or throughput independently, so both limits must be checked.

Latency is the elapsed time between an I/O request and its completion. Tail latency, such as p95 or p99 latency, is often more useful than the mean for user-facing systems because a small number of slow requests can affect transactions and user experience.

File storage

File storage exposes directories and files through protocols such as NFS or SMB. It is useful when multiple instances require shared access, hierarchical directories, file locking, or compatibility with existing applications. Its performance depends on metadata operations, concurrency, network conditions, and the storage service’s scaling model. File storage may become a bottleneck when many clients access a single directory or when applications perform large numbers of small operations.

Storage selection should also consider consistency semantics. Strong read-after-write behaviour simplifies application logic, while eventual consistency may require retries, reconciliation, or version-aware processing. The architect must consult the service contract rather than infer behaviour from a small test.

4. Virtual Networks and Traffic Flow

A virtual private cloud or equivalent construct provides an isolated logical network. It is divided into subnets, commonly separated by availability zone and by function. Public subnets may contain resources with controlled inbound exposure, while private subnets contain application and database tiers without direct public addresses.

A route table maps destination prefixes to next hops such as local interfaces, internet gateways, NAT gateways, transit gateways, or virtual appliances. The most specific matching route is generally preferred. For example, a route for 10.20.0.0/16 is less specific than one for 10.20.5.0/24. Incorrect route propagation or overlapping address ranges can create outages that are difficult to diagnose.

A typical three-tier design places a public load balancer in public subnets, application instances in private subnets, and databases in isolated subnets. Outbound internet access for private instances may use a NAT service, but NAT does not automatically provide inbound access to those instances. Network access controls should use least privilege: permit only required protocols, ports, source ranges, and destinations.

Security groups or stateful virtual firewalls commonly apply rules to interfaces or instances. Network access control lists may operate at subnet boundaries and can be stateless. Both mechanisms should be understood because a packet may be accepted by one layer and rejected by another.

Routing, load balancing, and DNS

A load balancer distributes requests across healthy targets. Layer 4 balancing uses transport information such as TCP or UDP; Layer 7 balancing can interpret HTTP paths, headers, cookies, and hostnames. Layer 7 routing enables policies such as sending /api traffic to one service and /images traffic to another, but it introduces greater processing and configuration complexity.

Health checks must test meaningful readiness, not merely process existence. A service that returns HTTP 200 while unable to reach its database is not necessarily healthy. Health checks should be lightweight, bounded in time, and designed to avoid cascading failure.

DNS translates names into resource records. Common records include A or AAAA records for addresses, CNAME records for aliases, MX records for mail routing, and TXT records for verification or policy. DNS-based traffic management can use weighted, latency-based, geographic, or failover policies. DNS is cached according to time to live (TTL), so changes are not instantaneous. DNS failover is therefore not a substitute for application-level resilience.

Content delivery networks (CDNs) cache content at edge locations near users. They reduce origin traffic and user-perceived latency, especially for static assets and cacheable API responses. Correct cache-control headers, invalidation procedures, encryption, and protection against cache poisoning are essential. Personal or authorization-sensitive content must not be cached publicly without a carefully designed cache key and access policy.

5. Software-Defined Networking

Software-defined networking (SDN) separates the network control function from packet forwarding. A logically centralized controller or control plane programs distributed forwarding devices through APIs. The physical network still carries packets, but policies such as segmentation, routing, service insertion, and traffic engineering can be expressed in software.

SDN supports infrastructure as code, repeatable network creation, micro-segmentation, automated policy validation, and rapid environment replication. However, logical centralization does not imply a single physical failure point. Controllers require redundancy, consistent state management, access control, and careful handling of partial failures.

Overlay networks encapsulate one packet inside another to create logical topologies over shared physical infrastructure. They enable tenant isolation and flexible addressing, but encapsulation adds overhead and may complicate troubleshooting. Network virtual appliances can provide firewalls, intrusion detection, proxies, or inspection, but they may introduce throughput limits and asymmetric routing problems.

Network design should be observable. Flow logs, route inspection, packet capture where permitted, load-balancer metrics, DNS query logs, and distributed tracing help distinguish application errors from network errors. Observability data may contain addresses, identifiers, or payload fragments and must therefore be governed as sensitive operational data.

6. Quantitative Infrastructure Decisions

Infrastructure choices should be based on service-level objectives (SLOs), not only on provider feature lists. Common requirements include:

• latency: how quickly a request or operation completes;
• throughput: how much data or work is processed per unit time;
• availability: the proportion of time a service is usable;
• durability: the probability of retaining data without loss or corruption;
• recovery time objective (RTO): maximum acceptable restoration time;
• recovery point objective (RPO): maximum acceptable data-loss interval;
• scalability: ability to handle increased demand;
• cost efficiency: required capability per unit expenditure.

For independent sequential components, end-to-end availability is approximately:

Here, A_i is the availability of component i, and the approximation assumes that component failures are independent and that every component is required for the transaction. If three mandatory components each have availability 0.99, the combined availability is 0.99 × 0.99 × 0.99 ≈ 0.9703, or 97.03%. This illustrates why adding dependencies can reduce availability.

For redundant parallel components, a simplified availability expression is:

Here, A is the availability of one identical component, k is the number of components, and failures are assumed independent with a functioning system requiring at least one component. Two components each with availability 0.99 yield 1 − 0.01² = 0.9999, or 99.99%. Real systems may share power, software, networks, or operational dependencies, so actual availability is usually lower than this idealized result.

Capacity planning also requires queueing awareness. If incoming work approaches the sustainable service rate, waiting time can increase sharply. A system should retain headroom and use backpressure, admission control, caching, or queue-based smoothing rather than relying solely on larger instances.

7. Applied Case: A Regional Digital Learning Platform

Background

This illustrative case concerns a university platform serving course pages, video lectures, assessments, and instructor uploads. Users are distributed across several regions. The platform experiences predictable peaks at the start of semesters and short intense bursts during examinations.

Problem

The initial deployment uses a small group of VMs, a shared filesystem for all content, and a single public application endpoint. During peak periods, page latency rises, uploads compete with database traffic, and a zone failure requires manual recovery. The university requires an RPO of 15 minutes, an RTO of 60 minutes, and strong protection for student records.

Analysis

Course videos and static images are large, relatively immutable objects. Student submissions require durable storage and controlled access. Transactional assessment records require low-latency block-backed database storage. The web tier is mostly stateless, but instructor sessions and assessment transactions require careful session and consistency handling.

The design separates traffic classes and data models. Object storage is selected for videos, images, generated reports, and backups. A CDN caches public course assets and reduces origin bandwidth. A managed relational database uses multi-zone synchronous or provider-supported high-availability capabilities, with encrypted block storage and automated backups. A file service is retained only for a legacy application that requires shared directory semantics.

Approach and solution

The platform is deployed across three availability zones. A Layer 7 load balancer terminates TLS and routes requests to private application subnets. Application instances are in an autoscaling group based on request rate, p95 latency, and queue depth. The minimum capacity is chosen to survive the loss of one zone, while scale-out policies address examination bursts.

The network uses separate public, private application, and restricted database subnets. Route tables prevent direct inbound access to application and database instances. Security policies allow the load balancer to reach the application tier, and the application tier to reach only required database and storage endpoints. Administrative access uses an audited management channel rather than open SSH from the internet.

Object lifecycle rules move old recordings to lower-cost storage classes, while legal-retention requirements prevent automatic deletion of protected records. Versioning and immutable backup controls reduce the impact of accidental deletion or ransomware. Cross-region copies are used for disaster recovery, with replication lag monitored against the 15-minute RPO.

Outcome

The architecture separates high-volume static delivery from transactional processing, allows compute capacity to follow demand, and reduces the blast radius of zone failure. The principal trade-offs are greater operational complexity, CDN invalidation management, cross-region data-transfer cost, and the need to test restoration rather than merely configure backups.

Learning points

The case demonstrates that infrastructure is an integrated system. Object storage is not a replacement for a transactional database; autoscaling cannot repair a stateful bottleneck; and multi-zone deployment is not equivalent to disaster recovery. Requirements, failure assumptions, and measurable service objectives must guide every choice.

8. Governance, Security, and Professional Practice

Infrastructure is also a governance concern. Resource identities should use short-lived roles rather than embedded credentials. Encryption should protect data in transit and at rest, with key ownership, rotation, access logging, and recovery procedures defined. Sensitive workloads may require regional residency, contractual controls, retention schedules, and sector-specific regulation.

Infrastructure as code improves repeatability and reviewability. Changes should pass code review, automated policy checks, security scanning, and controlled deployment pipelines. State files and configuration repositories may contain sensitive information and require restricted access. Drift detection identifies resources changed outside the approved process.

Cost governance includes budgets, tagging, rightsizing, scheduling non-production resources, storage lifecycle rules, commitment analysis, and monitoring of network egress. The cheapest resource is not necessarily the least expensive architecture: an inexpensive storage service may incur substantial retrieval or transfer charges, while excessive replication may increase both cost and resilience.

Ethical practice requires attention to unequal access, privacy, environmental impact, and operational accountability. Data-intensive infrastructure consumes energy and materials. Architects should consider efficient instance families, workload scheduling, lifecycle deletion, regional choices, and measured—not assumed—sustainability benefits. Automation must include safeguards because an erroneous scaling or deletion policy can affect thousands of users.

9. Contemporary Developments and Limitations

Serverless compute, managed Kubernetes, confidential computing, specialized accelerators, edge computing, and distributed databases increasingly blur the boundary between infrastructure and platform services. AI workloads intensify requirements for GPU capacity, high-bandwidth interconnects, data locality, and storage throughput. Edge architectures reduce latency by placing computation near users or devices, but they increase fleet-management and consistency challenges.

Abstraction does not remove complexity; it moves complexity into APIs, identity systems, quotas, provider dependencies, and distributed failure modes. Multi-cloud strategies may reduce concentration risk or satisfy regulatory requirements, but they can duplicate tooling, increase skills requirements, and expose differences in networking, storage semantics, and observability. Portability should therefore be evaluated against measurable business value rather than treated as an unconditional objective.

Best-Practice Design Checklist

1. Begin with workload, latency, throughput, availability, durability, RTO, and RPO requirements.
2. Select compute based on measured performance, not only vCPU count.
3. Design stateless tiers for horizontal scaling where practical.
4. Use object, block, and file storage according to their access semantics.
5. Separate public, application, and data network zones.
6. Distribute critical resources across failure domains.
7. Treat health checks, DNS TTLs, cache policies, and route tables as operational controls.
8. Encrypt, log, monitor, and test recovery procedures.
9. Model cost, quotas, data transfer, and lifecycle behaviour.
10. Test failure, load, restoration, and security assumptions continuously.

Chapter Summary

Cloud infrastructure combines virtual compute, storage, networking, and software-defined control into an elastic service platform. Virtual machines and containers provide different isolation and density characteristics. Compute capacity must be matched to workload behaviour and controlled through carefully designed autoscaling policies.

Object storage is appropriate for scalable API-based data such as media and backups; block storage supports low-latency volumes and databases; file storage supports shared hierarchical access. Their selection depends on access model, latency, IOPS, throughput, consistency, durability, and cost.

Virtual networks use subnets, route tables, gateways, firewalls, load balancers, DNS, and CDNs to control and optimize traffic. SDN makes network configuration programmable but introduces control-plane, policy, and observability responsibilities. Availability calculations are useful only when their assumptions—especially independence and shared dependencies—are made explicit.

Professional infrastructure design integrates performance, resilience, security, governance, cost, compliance, and sustainability. The most reliable designs are requirement-driven, automated, observable, tested under failure, and explicit about trade-offs.

Key Terms

Virtual machine: A software-defined computer running under a hypervisor.

Hypervisor: Software that allocates physical resources to virtual machines.

Container: An isolated process environment that generally shares the host kernel.

Availability zone: A physically separated infrastructure location within a region.

Elasticity: The ability to adjust capacity in response to changing demand.

Autoscaling: Automatic addition, removal, or resizing of resources.

Object storage: API-accessed storage of data objects and metadata.

Block storage: Raw virtual volumes presented to an operating system or database.

File storage: Shared hierarchical storage accessed through filesystem protocols.

IOPS: Input/output operations per second.

Throughput: Quantity of data or work processed per unit time.

Latency: Time taken to complete an operation or transfer.

Durability: Likelihood that stored data remains intact over a stated period.

Availability: Proportion of time a service is usable.

Virtual private cloud: An isolated logical network in a cloud environment.

Route table: A collection of destination-prefix and next-hop rules.

Load balancer: A service that distributes traffic among healthy targets.

Content delivery network: A distributed edge caching and delivery service.

Software-defined networking: Programmable networking that separates control from forwarding.

Recovery point objective: Maximum acceptable amount of data loss measured in time.

Review Questions

Short Answer Questions

1. How does object storage differ from block storage in its access model?
2. Why is CPU utilization not always an adequate autoscaling metric?
3. What is the difference between durability and availability?
4. What purpose does a route table serve in a virtual network?
5. Why are availability zones used in cloud architecture?

Long Answer Questions

1. Compare object, block, and file storage for a media-learning platform, explaining the trade-offs.
2. Explain how a three-tier virtual network can reduce attack surface and improve operational control.
3. Discuss horizontal and vertical scaling, including their benefits and limitations.
4. Explain the role of load balancing, DNS, and CDN services in reducing latency and improving resilience.
5. Critically evaluate the claim that multi-zone deployment automatically provides disaster recovery.

Analytical / Application Questions

1. A service requires 1,200 requests per second and a 20% safety margin. Each instance safely handles 300 requests per second. Calculate the minimum nominal instance count and identify two production factors that may require additional capacity.
2. Design compute, storage, and networking for an online examination system with high short-term demand, sensitive student data, an RPO of 15 minutes, and an RTO of one hour.
3. A database volume is configured for 5,000 IOPS with an average I/O size of 8 KiB. Estimate theoretical throughput in MiB/s, state the assumptions, and explain why measured throughput may differ.

Multiple Choice Questions with Answers

Question 1

Which storage model is most appropriate for large, immutable video files delivered through an HTTP-based application?

A. Object storage

B. Block storage

C. Local swap storage

D. A virtual CPU volume

Correct Answer: A. Object storage

Question 2

A volume performs 4,000 I/O operations per second, each of 16 KiB. What is the theoretical throughput, ignoring overhead?

A. 16 MiB/s

B. 32 MiB/s

C. 62.5 MiB/s

D. 128 MiB/s

Correct Answer: C. 62.5 MiB/s

Question 3

Which scaling approach generally adds more instances to a stateless web tier?

A. Horizontal scaling

B. Vertical scaling

C. Filesystem defragmentation

D. DNS delegation

Correct Answer: A. Horizontal scaling

Question 4

What is the principal function of a route table?

A. Encrypting stored objects

B. Mapping destination prefixes to next hops

C. Compressing application payloads

D. Measuring CPU temperature

Correct Answer: B. Mapping destination prefixes to next hops

Question 5

Which statement correctly distinguishes durability from availability?

A. Durability concerns data retention; availability concerns service accessibility

B. Durability and availability are identical measures

C. Availability concerns only storage capacity

D. Durability measures network latency

Correct Answer: A. Durability concerns data retention; availability concerns service accessibility

Question 6

A load balancer health check should ideally determine whether the service can perform its required function rather than merely whether:

A. The process exists

B. The DNS zone has expired

C. The storage is replicated globally

D. The instance has a public IP address

Correct Answer: A. The process exists

Question 7

For three mandatory independent components, each with availability 0.99, the simplified end-to-end availability is approximately:

A. 0.9703

B. 0.9900

C. 0.9999

D. 1.0300

Correct Answer: A. 0.9703

Question 8

Which service is most suitable when multiple instances require shared hierarchical directories and file semantics?

A. File storage

B. Object storage only

C. A DNS resolver

D. A CDN cache only

Correct Answer: A. File storage

Question 9

What is a major benefit of a content delivery network?

A. It places cacheable content closer to users

B. It converts block volumes into databases

C. It eliminates the need for identity management

D. It guarantees zero packet loss

Correct Answer: A. It places cacheable content closer to users

Question 10

In software-defined networking, the control plane primarily:

A. Programs and manages forwarding policies

B. Stores application video objects

C. Executes database transactions

D. Replaces all physical networking equipment

Correct Answer: A. Programs and manages forwarding policies