Cloud Infrastructure Services

Introduction

Cloud infrastructure services are the technical building blocks from which cloud applications are designed and operated. They include compute resources, machine images, storage, networks, addressing, routing, load balancing, DNS, content delivery, and connectivity to external environments. Although providers expose these capabilities through different names and interfaces, the underlying design principles are broadly similar.

A cloud architect rarely selects a single service in isolation. A web application, for example, may require virtual machines in private subnets, an internet-facing load balancer, object storage for media, a relational database, DNS records, and a content delivery network. The quality of the solution depends on how these components interact, particularly with respect to availability, security, scalability, performance, and cost.

This chapter develops the foundations needed to design such solutions. Provider-specific examples are expressed using generic terms so that the concepts can be transferred among major cloud platforms.

Learning Objectives

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

1. Explain the role of virtual machines, images, and autoscaling.
2. Select block, file, and object storage for appropriate workloads.
3. Design a basic virtual network using subnets, routing, and security controls.
4. Explain addressing, load balancing, DNS, and content delivery.
5. Compare common connectivity options between cloud and on-premises environments.
6. Analyze a basic cloud architecture for reliability, security, performance, and cost.

1. Compute Infrastructure: Virtual Machines and Images

A virtual machine (VM) is a software-defined computer that receives virtual CPU, memory, storage interfaces, and network interfaces. A hypervisor abstracts physical hardware and allows multiple VMs to share a host while remaining logically isolated. The cloud provider normally manages the physical hosts and hypervisor; the customer manages the guest operating system, installed software, configuration, and data unless a managed service is used.

A VM is commonly specified by an instance type or size. Important attributes include:

• vCPU count and processor characteristics;
• memory capacity;
• network bandwidth and packet-processing limits;
• local temporary storage;
• attached persistent volumes;
• supported operating systems and hardware features.

A VM is not automatically a complete application. It is a computing environment on which an operating system and application stack must be installed, patched, monitored, and secured.

Machine images

A machine image is a reusable template containing an operating system and, optionally, applications, libraries, configuration, and initialization scripts. Images support repeatable provisioning. Instead of manually installing ten servers, an organization can create or select an approved image and launch each server consistently.

Images may be:

• General-purpose base images: minimal operating systems maintained by a provider or distribution vendor.
• Customized golden images: organization-approved images containing security agents, monitoring tools, and standard configuration.
• Application images: images with a particular application version already installed.
• Container images: portable application packages used by container runtimes; these are conceptually related to VM images but are not VM replacements in every workload.

An image should be versioned, scanned for vulnerabilities, documented, and retired when unsupported software is present. Secrets should not normally be embedded in images. They should be obtained at runtime from an approved secrets-management service.

Provisioning and initialization

Cloud-init or equivalent initialization mechanisms can assign hostnames, install updates, retrieve configuration, and register an instance with a load balancer. Initialization must be idempotent: running it more than once should not corrupt the system or create unintended duplicate resources.

Availability zones and placement

A cloud region is a geographic area containing one or more isolated availability zones. A highly available application distributes instances across multiple zones so that failure of one zone does not remove all capacity. Distribution alone is insufficient if a shared database, network route, or storage dependency remains a single point of failure.

2. Autoscaling and Capacity Design

Autoscaling changes the number or size of resources in response to demand or policy. A horizontal scaling group adds or removes VM instances; vertical scaling changes the capacity of an existing instance. Horizontal scaling is generally preferable for stateless web services because it improves fault tolerance as well as capacity.

A common autoscaling policy is based on average CPU utilization, request rate, queue depth, or a custom application metric. The policy should include:

• minimum capacity for baseline availability;
• desired capacity under normal conditions;
• maximum capacity to control cost and protect dependencies;
• health checks and replacement behavior;
• cooldown or stabilization periods;
• scale-out and scale-in thresholds.

A simple capacity estimate is:

where N is the number of instances required, L is the expected workload rate, and C is the sustainable workload rate per instance. Workload rate must use consistent units, such as requests per second. The ceiling function ensures that a fraction of an instance is not treated as a complete instance. This estimate assumes reasonably similar requests, stable instance performance, and no bottleneck elsewhere. Production designs add headroom for bursts, failures, deployment, and measurement uncertainty.

For example, if a service must handle 1,000 requests per second and testing shows that one instance safely handles 180 requests per second, the minimum theoretical capacity is ⌈1000/180⌉ = 6 instances. If one instance is reserved as failure capacity, at least seven instances may be provisioned, subject to cost and availability requirements.

Autoscaling cannot solve every performance problem. If a database allows only 500 connections, adding application servers may increase failure. Scaling policies must therefore consider downstream limits, queue behavior, connection pools, and graceful degradation.

3. Storage Services

Cloud storage is commonly divided into block, file, and object storage. The distinction concerns the interface presented to applications and the way data is organized and accessed.

Block storage

A block volume appears to an operating system as a disk. The operating system creates a filesystem or database structure on it. Block storage is appropriate when software expects a disk device, such as a transactional database or VM boot volume.

Performance may be described using IOPS and throughput. IOPS means input/output operations per second. Throughput is commonly measured in MB/s or GB/s. Small random operations may be limited by IOPS, while large sequential transfers may be limited by throughput. The selected volume must also satisfy capacity, latency, durability, backup, encryption, and availability requirements.

A volume attached to one VM is not automatically safe from data loss. Backups, snapshots, replication, and tested restoration are necessary. Snapshots are point-in-time representations and may require application-consistent procedures for databases.

File storage

File storage exposes directories and files through protocols such as NFS or SMB. It is useful when several compute instances need a shared namespace. File locking, permissions, latency, throughput, and concurrent access behavior must be tested. A shared filesystem can simplify deployment but may become a performance bottleneck or create a larger failure domain.

Object storage

Object storage stores an object consisting of data, metadata, and a key in a bucket or similar namespace. Applications access objects through APIs rather than by mounting a conventional disk. Object storage is well suited to images, videos, backups, software packages, logs, and static website content.

Object storage typically supports lifecycle policies that transition objects to lower-cost archival classes or delete them after a retention period. Versioning can protect against accidental overwrites and deletion, but it may increase cost. Access should normally be private by default, with narrowly scoped permissions and temporary signed URLs where controlled sharing is required.

Object stores usually provide strong durability, but durability is not identical to immediate availability, protection from incorrect deletion, or application-level consistency. Organizations should define recovery objectives:

• Recovery point objective (RPO): maximum acceptable amount of data loss measured in time.
• Recovery time objective (RTO): maximum acceptable time to restore service.

A backup policy is adequate only when it is tested against the stated RPO and RTO.

4. Virtual Networks

A virtual private cloud or equivalent virtual network is an isolated logical network defined by address ranges, subnets, routes, and security policies. It provides control over how resources communicate with one another and with external networks.

Addressing and subnets

An IPv4 address consists of 32 bits and is commonly represented in dotted decimal notation. A CIDR block expresses a network prefix and prefix length, such as 10.20.0.0/16. The prefix length indicates how many leading bits identify the network. Under conventional IPv4 subnetting, the number of addresses in a block is:

where A is the number of IPv4 addresses and p is the prefix length. This count includes network and broadcast addresses in traditional subnetting; cloud platforms may reserve additional addresses and may not use broadcast in the same way. Therefore usable addresses must be checked against the provider's documented reservation rules.

For example, a /24 block contains 2^(32−24) = 256 IPv4 addresses. If a provider reserves five addresses in each subnet, 251 may be assignable; the exact result is provider-dependent.

A subnet is a subdivision of a network address range. Subnets are usually associated with a single availability zone. Public and private are logical designations: a public subnet generally has a route to an internet gateway and may assign public addresses, whereas a private subnet lacks direct inbound internet routing. A public IP address alone does not make an application secure.

IPv6 uses 128-bit addresses and supports very large address spaces. Dual-stack designs operate IPv4 and IPv6 together, while IPv6-only designs require all dependencies and operational tools to support IPv6.

Routing

A route table maps destination prefixes to next hops, such as a local network, internet gateway, NAT gateway, peering connection, transit gateway, or VPN endpoint. Route selection generally uses longest-prefix matching: the most specific matching route is preferred. A default route, such as 0.0.0.0/0 for IPv4, is used when no more specific route exists.

Routing is directional in effect. Return traffic must also have a valid path. A common diagnostic error is to configure an outbound route but omit the corresponding return route or security rule.

Security controls

Security groups or equivalent controls are often stateful, instance- or interface-level firewalls. Network ACLs or subnet-level filters may be stateless and require explicit rules for both directions. Least privilege means allowing only required protocols, ports, source ranges, and destinations.

For example, an internet-facing load balancer may accept HTTPS on TCP port 443 from the internet, while application instances accept traffic only from the load balancer's security identity. Database instances should accept database traffic only from the application tier, not from the public internet.

5. Load Balancing

A load balancer distributes client connections or requests across healthy backend targets. It improves availability, supports horizontal scaling, and can centralize TLS termination, health checks, and traffic policies.

Common forms include:

• Layer 4 load balancing: operates primarily with TCP or UDP flows and preserves high performance with limited application awareness.
• Layer 7 load balancing: understands HTTP or HTTPS and can route by hostname, path, headers, cookies, or other application information.

A health check should test meaningful service readiness rather than merely whether a process is running. Health checks that are too shallow send traffic to broken applications; checks that are too strict may remove healthy instances during temporary dependency failures.

Load balancing does not automatically provide session-state management. Stateless applications are easiest to scale. If sessions must be retained, designers may use encrypted client-side tokens, a shared session store, or carefully configured session affinity. Session affinity can simplify legacy applications but may reduce balancing effectiveness and complicate failover.

TLS may terminate at the load balancer, at the application, or at both. Termination at the edge simplifies certificate management, while end-to-end encryption may be required by policy or threat model.

6. DNS and Service Discovery

The Domain Name System translates names into records such as IPv4 addresses, IPv6 addresses, mail servers, and canonical names. Important records include:

• A: maps a name to an IPv4 address.
• AAAA: maps a name to an IPv6 address.
• CNAME: aliases one name to another name.
• MX: identifies mail servers.
• TXT: stores text used for verification and email policies.
• NS: identifies authoritative name servers.

A DNS resolver caches answers according to their time to live (TTL). A low TTL can make changes visible sooner but increases query volume and dependency on authoritative DNS. DNS is not an instantaneous failover mechanism because cached answers may remain available until their TTL expires.

Managed DNS services often provide health-checked routing, weighted routing for experiments, latency-based routing, geographic policies, and failover records. These features should be tested because DNS-level routing cannot observe every application condition.

Internal service discovery uses private DNS names, registries, or orchestrator-native mechanisms. Stable names are preferable to embedding changing IP addresses in application code.

7. Content Delivery Networks

A content delivery network (CDN) caches content at geographically distributed edge locations. Users retrieve cacheable content from a nearby edge rather than from the origin for every request. This reduces origin load and often lowers latency.

A basic cache-hit ratio is:

where H is the cache-hit ratio, C_h is the number of cache hits, and C_t is the total number of cacheable requests. Both counts must refer to the same period and cache population. A high hit ratio is useful but does not by itself prove good user performance; object size, network path, misses, and origin latency also matter.

CDN design requires explicit cache-control policies. Immutable, versioned assets such as app.4f21.js can have long lifetimes. Frequently changing or personalized responses should have short lifetimes or bypass caching. Caching private data publicly is a serious confidentiality risk. Signed URLs, signed cookies, and origin access controls can restrict delivery.

A CDN may also provide TLS termination, compression, web application firewall functions, bot controls, and edge functions. These features introduce additional configuration and debugging considerations.

8. Connectivity Services

Cloud resources may need to communicate with the public internet, corporate data centers, branch offices, or other clouds.

• Internet gateway: provides a path between a virtual network and the public internet, subject to routing and security rules.
• NAT gateway or appliance: allows private resources to initiate selected outbound internet connections without accepting unsolicited inbound connections. NAT is not a complete security boundary and does not replace egress filtering.
• Site-to-site VPN: encrypts traffic across an internet connection. It is comparatively quick to deploy but may have variable latency and limited throughput.
• Dedicated private connection: uses a provider or telecommunications circuit. It can offer more predictable performance and compliance advantages, but usually requires planning, contracts, and redundant circuits.
• Network peering: connects two virtual networks privately. Some peering models are non-transitive, meaning that A connected to B and B connected to C does not necessarily connect A to C.
• Transit hub: provides centralized connectivity among many networks and can simplify routing governance.

Redundancy should exist at the appropriate layers: two VPN tunnels, diverse physical paths, redundant routers, and multiple availability zones where justified. A connectivity design should document address ownership, route propagation, encryption, monitoring, failure behavior, and operational responsibility.

9. Integrated Architecture Pattern

A common three-tier architecture consists of a public entry tier, a private application tier, and a private data tier. DNS points the application name to a public load balancer. The load balancer sends HTTPS requests to healthy application instances distributed across zones. Application instances retrieve static assets from a CDN and store uploaded files in object storage. They access a database or file service through restricted private routes. Administrative access uses a controlled management path rather than exposing SSH or remote desktop ports to the internet.

Figure: A basic layered cloud architecture using public entry services, private application subnets, and protected data services.

The architecture is only a starting point. Designers must decide whether the application is stateless, how files are uploaded, where encryption keys are managed, how backups are restored, and how the system behaves when a zone or dependency fails.

10. Illustrative Case: Online Examination Platform

Background

A university wants an online examination platform for 20,000 students. Examinations generate heavy but predictable demand during scheduled periods. Students upload answers, and instructors later download reports.

Problem

The existing single-server system becomes unavailable during examinations. It stores uploaded files locally, has no tested backup, and exposes its administration interface directly to the internet.

Analysis

The workload is bursty, the student-facing service should remain available if one zone fails, and uploaded answers must not be lost. Static examination instructions and scripts are suitable for edge caching. The application must not depend on a single VM's local disk.

Approach and solution

The university creates a virtual network with public load balancer subnets and private application subnets in two availability zones. A managed DNS name points to the load balancer. Application VMs are created from a hardened image and managed by an autoscaling group. Health checks remove failed instances, while scaling responds to request rate and queue depth.

Uploaded answers are written directly, through controlled application APIs, to private object storage with encryption and versioning. A database stores examination metadata and uses automated backups. Static, non-personalized content is delivered through a CDN. Administrative access uses a private management channel with multi-factor authentication; no administrative port is open to the public internet.

Assume load testing shows that one VM safely processes 250 submissions per minute. A peak of 2,400 submissions per minute requires:

Ten is the theoretical minimum under the stated test conditions. The design may choose 12 or more to accommodate uneven distribution, one failed instance, deployment, and measurement error. The database and object-storage request limits must also be checked.

Outcome

The platform no longer relies on local VM disks, can add capacity during examination windows, and isolates administrative access. Recovery procedures are tested before the academic term. Cost is controlled by scaling down outside examination periods and applying lifecycle policies to old submissions according to retention rules.

Learning points

The case demonstrates that availability comes from removing single points of failure, scalability requires attention to dependencies, and storage selection should follow access patterns rather than habit. It also shows that security architecture and operational recovery are part of infrastructure design, not optional additions.

11. Governance, Security, and Professional Practice

Infrastructure decisions have legal and ethical consequences. Student records, health information, financial data, and personal identifiers may be subject to privacy and data-residency requirements. The organization must identify the data owner, classification, permitted locations, retention period, access authority, and destruction procedure.

Important controls include:

• encryption in transit and at rest;
• centralized identity and least privilege;
• separation of production, test, and development accounts or projects;
• immutable or protected audit logs;
• vulnerability and image scanning;
• patch management;
• infrastructure as code with peer review;
• budgets, quotas, and cost alerts;
• tested backup and disaster-recovery procedures.

The shared-responsibility model must be explicit. The provider secures the underlying facilities and managed service infrastructure, while the customer remains responsible for configuration, identities, data, and often operating systems and applications. Misconfigured storage permissions and exposed management interfaces are customer-side failures even when the cloud platform is functioning correctly.

AI-assisted operations can summarize logs, predict capacity, and recommend configuration changes. Such tools should not receive unrestricted secrets or make unreviewed production changes. Recommendations require human validation, auditability, protection against prompt or data manipulation, and assessment of false positives and false negatives.

12. Challenges and Limitations

Cloud infrastructure offers rapid provisioning and elasticity, but it introduces trade-offs:

• abstracted services may reduce low-level control;
• provider-specific APIs can create portability challenges;
• data transfer and cross-region traffic may be expensive;
• distributed systems are harder to observe and troubleshoot;
• autoscaling can amplify overload when dependencies are constrained;
• poorly designed networks can create excessive latency or large blast radii;
• shared responsibility can be misunderstood;
• service outages can affect dependent workloads despite local redundancy.

A sound design uses measured workload tests, documented assumptions, failure injection where appropriate, observability, and regular review. Architecture should be evaluated against explicit service-level objectives rather than vague claims of being scalable or highly available.

Best-Practice Checklist

1. Use approved, patched, versioned images.
2. Keep application instances replaceable and avoid important local state.
3. Spread critical capacity across availability zones.
4. Choose storage according to access interface, performance, durability, and recovery needs.
5. Use private subnets for application and data tiers unless public access is required.
6. Apply least-privilege security rules and restrict administrative access.
7. Design routes and return paths together.
8. Use meaningful health checks and bounded autoscaling.
9. Protect object-storage data with encryption, access policies, versioning, and lifecycle controls.
10. Test backups, restoration, failover, and capacity assumptions.
11. Monitor latency, errors, saturation, traffic, cost, and security events.
12. Document ownership, dependencies, and failure behavior.

Chapter Summary

Cloud infrastructure services form an interconnected design system. Virtual machines provide configurable compute, while images make provisioning repeatable and autoscaling adjusts capacity. Block storage behaves like a disk, file storage provides shared hierarchical access, and object storage offers API-based access to highly scalable data repositories. Virtual networks organize address ranges, subnets, routes, and security controls. Load balancers distribute traffic and support health-based failover; DNS provides naming and policy-based resolution; CDNs move cacheable content closer to users. VPNs, dedicated links, peering, and transit hubs connect cloud environments to other networks.

Effective designs are based on workload measurements, explicit availability and recovery objectives, least privilege, redundancy, observability, and tested operational procedures. No individual service guarantees a reliable system: reliability emerges from the architecture and its dependencies.

Key Terms

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

Machine image: A reusable template for provisioning an operating system and software.

Autoscaling: Automatic adjustment of resource capacity according to demand or policy.

Availability zone: An isolated location within a cloud region.

Block storage: Disk-like storage accessed as blocks by an operating system or application.

File storage: Shared hierarchical storage accessed through file protocols.

Object storage: API-based storage of data, metadata, and keys in buckets.

RPO: Maximum acceptable time-based amount of data loss.

RTO: Maximum acceptable time to restore service.

CIDR: Notation expressing a network prefix and prefix length.

Subnet: A subdivision of an IP network address range.

Route table: A set of destination-to-next-hop forwarding rules.

Security group: A stateful virtual firewall associated with a resource or interface.

Load balancer: A service that distributes traffic across backend targets.

DNS: The distributed naming system that maps domain names to records.

CDN: A geographically distributed caching and delivery service.

NAT: Network address translation, commonly used for controlled outbound access.

Peering: A private connection between virtual networks.

Least privilege: Granting only the access required for an authorized task.

Shared responsibility model: Division of security duties between provider and customer.

Review Questions

Short Answer Questions

1. What is the purpose of a machine image?
2. Distinguish block, file, and object storage.
3. Why are private subnets commonly used for application servers?
4. What is the function of a load-balancer health check?
5. Define RPO and RTO.

Long Answer Questions

1. Explain how a two-zone autoscaling architecture can improve availability and capacity.
2. Compare VPN connectivity with a dedicated private connection, including trade-offs.
3. Describe how DNS, a CDN, and a load balancer can cooperate in a web application.
4. Explain the security and operational risks of storing application state on local VM disks.
5. Discuss how routing, security rules, and return paths must be designed together.

Analytical / Application Questions

1. A service handles 1,800 requests per second, and testing shows that one instance safely handles 225 requests per second. Calculate the theoretical minimum number of instances and recommend additional factors that should influence the deployed number.
2. Design a storage strategy for a media application that stores thumbnails, original videos, transactional metadata, and temporary processing data. Justify the service selected for each category.
3. Analyze the online examination case and identify two remaining failure modes, two monitoring metrics for each, and one mitigation for each failure mode.

Multiple Choice Questions with Answers

Question 1

Which storage type is most appropriate for a VM boot disk?

A. Block storage

B. Object storage

C. DNS storage

D. CDN edge storage

Correct Answer: A. Block storage

Question 2

What is the main purpose of a machine image?

A. To route packets between subnets

B. To provide a reusable provisioning template

C. To translate domain names

D. To replace all security controls

Correct Answer: B. To provide a reusable provisioning template

Question 3

A service handles 900 requests per second, and one instance safely handles 200 requests per second. What is the theoretical minimum number of instances?

A. 4

B. 4.5

C. 5

D. 6

Correct Answer: C. 5

Question 4

Which component commonly distributes requests among healthy application instances?

A. Load balancer

B. Object bucket

C. Route registrar

D. Machine image

Correct Answer: A. Load balancer

Question 5

What does the /24 prefix indicate in an IPv4 CIDR block?

A. 24 total addresses

B. 24 leading network bits

C. 24 available subnets in every case

D. 24 reserved host addresses

Correct Answer: B. 24 leading network bits

Question 6

Which storage type is accessed primarily through bucket and object APIs?

A. Block storage

B. File storage

C. Object storage

D. Temporary VM memory

Correct Answer: C. Object storage

Question 7

What is the principal benefit of a CDN?

A. It makes every database transaction strongly consistent

B. It caches suitable content closer to users

C. It replaces all origin security controls

D. It automatically encrypts every stored secret

Correct Answer: B. It caches suitable content closer to users

Question 8

Which DNS record maps a name to an IPv4 address?

A. AAAA

B. MX

C. TXT

D. A

Correct Answer: D. A

Question 9

What is a key characteristic of a private subnet in a typical cloud design?

A. It must be physically outside the cloud region

B. It normally lacks a direct inbound route from the public internet

C. It cannot contain any compute resources

D. It automatically permits all internal traffic

Correct Answer: B. It normally lacks a direct inbound route from the public internet

Question 10

What does RTO measure?

A. Maximum acceptable restoration time

B. Maximum acceptable data loss measured in time

C. Average number of routing tables

D. Percentage of cache hits

Correct Answer: A. Maximum acceptable restoration time