Cloud Infrastructure and Platform Services

Introduction

Cloud computing has transformed infrastructure from a capital-intensive collection of owned facilities into an on-demand operating model. Organizations can provision compute, storage, networks, databases, security controls, and application platforms through programmable interfaces. For business analytics, this transformation is especially important: analytical workloads fluctuate significantly, require large temporary datasets, and often combine transactional, streaming, machine-learning, and visualization services.

Cloud engineering is not simply the act of renting virtual machines. It is the disciplined design of a dependable, secure, observable, automated, and economically sustainable environment. This chapter develops the foundations required to design such environments. It examines the major service models, regional architecture, compute and storage choices, networking, identity, containers, serverless computing, infrastructure as code, and hybrid or multi-cloud patterns.

Learning Objectives

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

1. Distinguish infrastructure as a service, platform as a service, and software as a service.
2. Select appropriate compute, storage, networking, identity, container, and serverless services.
3. Explain the relationship among regions, availability zones, fault domains, scalability, and resilience.
4. Design a secure cloud network using segmentation and least privilege.
5. Compare virtual machines, containers, managed platforms, and serverless execution.
6. Estimate availability and capacity using appropriate assumptions.
7. Describe how infrastructure as code supports repeatable delivery and governance.
8. Evaluate hybrid and multi-cloud architectures, including their trade-offs.

1. The Cloud Service Model

The National Institute of Standards and Technology characterizes cloud computing through on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These properties distinguish cloud computing from a conventional data center, although the underlying technologies—servers, storage devices, networks, and operating systems—remain familiar.

Three service models are particularly useful:

The shared-responsibility model is central. A provider may secure the physical data center and hypervisor, while the customer remains responsible for identity configuration, data classification, application vulnerabilities, and—often—guest operating-system patching. Responsibility varies by service. Moving from a virtual machine to a managed database generally transfers more operational responsibility to the provider, but it does not eliminate the customer’s responsibility for access control, data use, or regulatory compliance.

Cloud design therefore involves a division of labor. The engineering question is not merely “Which service is available?” but “Which party can perform each operational responsibility most reliably and economically?”

2. Regions, Availability Zones, and Resilience

A region is a geographically distinct area containing one or more data centers. An availability zone (AZ) is an isolated location or fault domain within a region. Providers design zones with independent power, cooling, and network infrastructure, although the exact implementation differs among providers. Zones are connected through high-capacity networks, but they are not identical to separate regions.

A region supports data-residency and latency requirements. Multiple zones within a region support resilience against localized failures. Multiple regions can address regional disasters, geopolitical constraints, or global latency, but introduce additional complexity in data replication, consistency, cost, and operations.

Availability is commonly expressed as the proportion of time a service is operational:

Uptime and downtime must use the same time unit. If a service has a 30-day measurement period and is unavailable for 43.2 minutes, total time is 43,200 minutes and availability is approximately 99.9%.

A useful approximation for independent serial components is:

where A_i is the availability of component i. This model applies when every component is required and component failures are independent. It should not be used uncritically: cloud failures may be correlated, and managed-service service-level agreements do not guarantee actual application availability.

For redundant components in parallel, where at least one component must operate, the availability is approximately:

For two identical independent components with availability A, this becomes A_parallel = 1 − (1 − A)². Redundancy improves resilience only when failure domains, dependencies, and recovery procedures are genuinely separated.

A design objective should be expressed as a recovery plan. Recovery time objective (RTO) is the maximum acceptable time to restore service. Recovery point objective (RPO) is the maximum acceptable amount of data loss measured in time. For example, an RPO of 15 minutes means that losing the most recent 15 minutes of transactions is considered tolerable; it does not mean that recovery will necessarily occur within 15 minutes.

3. Compute Services

Virtual Machines

A virtual machine (VM) is a software-defined computer running on a hypervisor. VMs offer strong operating-system control, broad compatibility, and predictable execution. They are appropriate for legacy applications, customized networking, specialized software, and workloads that cannot be easily refactored.

However, VM-based designs require operating-system patching, image management, capacity planning, hardening, and agent maintenance. A machine image should be versioned, scanned, immutable where practical, and promoted through environments rather than modified manually in production.

Managed Compute Platforms

Managed application platforms abstract servers and provide deployment, scaling, health checks, and runtime management. They reduce undifferentiated operational work but may constrain runtime versions, networking, filesystem access, or deployment patterns. They are attractive when development speed and standardized operations are more important than low-level control.

Containers

A container packages an application and its dependencies while sharing the host operating-system kernel. Unlike a VM, a container does not normally include a complete guest kernel. Containers improve portability and deployment consistency, but they are not automatically secure isolation boundaries. Images must be minimized, signed or otherwise verified, scanned for vulnerabilities, and rebuilt when dependencies change.

A container orchestration platform schedules containers across a cluster, provides service discovery, health checking, rolling deployment, and automated rescheduling. It also introduces operational complexity: cluster upgrades, policy enforcement, observability, network configuration, and resource requests must be managed carefully.

Resource requests and limits are important. A request informs scheduling and capacity allocation; a limit constrains consumption. Poorly chosen limits can cause throttling or termination, while absent requests can produce noisy-neighbor effects and unreliable scheduling.

Serverless Computing

Serverless services execute code or workflows without requiring the customer to manage servers directly. They may be event-triggered functions, managed container execution, workflow engines, or fully managed databases. Serverless does not mean that servers do not exist; it means that server management is largely delegated to the provider.

Serverless is effective for irregular workloads, event processing, APIs, automation, and rapid experimentation. Limitations include execution duration limits, startup latency, platform-specific interfaces, concurrency controls, and complex distributed debugging. Stateless design is normally preferred; durable state should reside in managed storage.

4. Storage and Data Services

Cloud storage should be selected according to access pattern, durability, latency, consistency, retention, and cost—not simply capacity.

Object Storage

Object storage stores objects identified by keys in buckets or equivalent logical containers. It is well suited to data lakes, backups, logs, media, and analytical files. It commonly provides lifecycle rules, versioning, replication, encryption, and tiered storage classes.

Object storage is not a conventional filesystem. Applications should not assume low-latency random updates, POSIX locking, or directory semantics. Analytical data is often organized using columnar formats and partitioning by useful predicates such as date, region, or business unit. Excessive small files can harm query performance and increase metadata overhead.

Block and File Storage

Block storage presents virtual disks to compute instances and is appropriate for operating systems, databases, and applications requiring low-latency block access. File storage presents shared filesystem semantics and supports applications requiring shared directories or file locking. Both may offer different performance tiers, throughput limits, snapshots, and replication behavior.

Databases and Analytical Stores

Relational databases provide structured schemas, transactions, and strong query capabilities. NoSQL databases may provide flexible schemas or high-scale key-value, document, column-family, or graph access. Data warehouses optimize analytical queries, while data lakes store varied data economically and defer some schema decisions. Lakehouse architectures combine low-cost object storage with transaction, catalog, and governance features.

A sound analytical architecture separates raw, refined, and curated data. Raw data preserves source fidelity; refined data applies validation and standardization; curated data is modeled for business consumption. Cataloging, lineage, quality checks, and retention policies are necessary for trustworthy analytics.

5. Networking Architecture

A cloud virtual network provides an isolated logical network. Common components include address spaces, subnets, route tables, security groups or firewall rules, load balancers, gateways, private endpoints, and network monitoring.

A typical three-tier design separates:

• A public or edge tier containing externally reachable load-balancing components.
• A private application tier containing application services without direct public addresses.
• A restricted data tier containing databases and sensitive storage.

Public accessibility should be minimized. An application server that only receives traffic from a load balancer should not accept arbitrary Internet traffic. Egress deserves equal attention: unrestricted outbound access can enable data exfiltration and command-and-control activity.

A load balancer distributes requests among healthy targets and can terminate TLS, perform health checks, and support gradual deployment. It is not a substitute for application-level resilience. Session state should generally be externalized so that requests can be routed to any healthy instance.

Network design also requires IP planning. Overlapping address ranges complicate peering, VPN connections, routing, and future mergers. Private connectivity can reduce exposure and improve predictable access, but it must still be monitored and governed.

6. Identity, Security, and Governance

Identity and access management (IAM) is the primary control plane for cloud resources. A mature design distinguishes human identities, workload identities, and emergency access. Long-lived access keys should be avoided where short-lived credentials or workload roles are available.

The principle of least privilege grants only the permissions required for a task, for the shortest practical duration. Permissions should be reviewed through policy analysis, access logs, periodic recertification, and automated detection of unused privileges. Multi-factor authentication is essential for privileged human access.

Security controls operate at several layers:

Encryption reduces exposure but does not solve authorization. Key management requires rotation, access separation, recovery planning, and careful handling of deletion or revocation. Secrets should not be embedded in source code, container images, or machine images.

Cloud governance should be preventive and detective. Preventive policies block prohibited configurations, such as public storage containing regulated data. Detective controls identify drift, excessive permissions, anomalous access, and unexpected cost. Governance must support legitimate engineering rather than creating undocumented manual workarounds.

7. Infrastructure as Code

Infrastructure as code (IaC) expresses infrastructure in declarative or procedural definitions stored in version control. A declarative specification states the desired end state; an IaC engine determines the operations required to reach it. Examples include networks, identity roles, compute resources, storage policies, databases, and monitoring rules.

A professional IaC workflow includes:

1. Reusable modules with documented inputs and outputs.
2. Version control and peer review.
3. Automated validation, security scanning, and policy checks.
4. A plan or preview stage before deployment.
5. Separate state management with encryption and controlled access.
6. Environment promotion rather than manual production changes.
7. Drift detection and reconciliation.
8. Tested rollback or forward-recovery procedures.

IaC does not automatically guarantee reproducibility. External dependencies, mutable images, provider changes, undeclared manual actions, and unmanaged data can create differences. State files may contain sensitive information and must be protected accordingly.

Infrastructure pipelines should use the same engineering disciplines as application pipelines: small changes, automated tests, approvals appropriate to risk, audit trails, and rapid recovery. “Click-ops” can be useful for exploration but should not be the authoritative production process.

8. Hybrid and Multi-Cloud Patterns

Hybrid cloud combines private infrastructure with one or more public clouds. Common motivations include regulatory constraints, existing investments, latency-sensitive systems, data sovereignty, and gradual migration. Hybrid designs require reliable connectivity, unified identity, consistent security policy, and clear data ownership.

Multi-cloud uses services from multiple public-cloud providers. It may reduce dependence on one provider, support geographic requirements, or exploit specialized services. However, multi-cloud is not automatically more resilient. It can multiply skills requirements, monitoring systems, network complexity, identity models, and data-transfer costs. Portability is often greatest at the application and data-format layers, but provider-specific managed services may produce substantial lock-in.

Useful patterns include:

• Cloud bursting: additional capacity is obtained from a public cloud during peaks.
• Backup and disaster recovery: a secondary environment supports restoration after a major failure.
• Data gravity: compute is placed near large datasets to reduce transfer and latency.
• Federated identity: one organizational identity system provides controlled access across environments.
• Active-active deployment: multiple sites serve traffic simultaneously, requiring careful data consistency design.

Architecture decisions should be based on business requirements rather than ideological avoidance of lock-in. A managed service may be economically and operationally superior when its benefits exceed migration risk.

9. Capacity, Cost, and Observability

Cloud elasticity does not eliminate capacity planning. Engineers must understand workload demand, service quotas, scaling time, concurrency, and downstream bottlenecks. Autoscaling based only on CPU can fail when the true constraint is queue depth, database connections, memory, or external API rate limits.

A simple resource estimate is:

The result must be rounded up to a whole number of instances and adjusted for redundancy, headroom, warm-up time, and failure scenarios. “Sustainable capacity” should be measured under representative load, not inferred from a theoretical maximum.

Cloud cost includes compute time, storage, requests, data transfer, managed-service charges, licenses, support, and operational labor. Cost allocation requires tagging or equivalent metadata, budgets, showback or chargeback, and unit metrics such as cost per transaction, cost per customer, or cost per analytical query.

Observability combines logs, metrics, traces, events, and service-level indicators. A service-level objective (SLO) defines a target such as successful request rate or latency. The error budget is the permitted unreliability over the measurement period. If an SLO is 99.9% over a 30-day month, the approximate error budget is 43.2 minutes, assuming a 30-day, 43,200-minute period. This budget is a management mechanism: it balances feature delivery against reliability investment.

10. Illustrative Case: Regional Analytics Platform

Background

A fictional retail organization, Northstar Markets, operates stores in three countries. Its analytics team receives point-of-sale events, inventory updates, supplier files, and customer-service data. The existing on-premises environment processes nightly reports but cannot support near-real-time inventory analysis during seasonal peaks.

Problem

The organization requires dashboards within five minutes of an event, must retain raw records for seven years, and must restrict customer data according to national privacy requirements. It also needs a recovery strategy for a regional outage. The team initially proposes a single large virtual machine and a shared public storage bucket.

Analysis

The proposal creates several risks: a single compute failure, excessive public exposure, poor separation of customer data, weak scaling, and unclear recovery procedures. The workload is event-driven and has variable demand, so a managed streaming service and elastic processing are more appropriate than one fixed server. Raw records require durable object storage, whereas dashboards require curated, query-optimized data.

Approach and Solution

Northstar designs a regional environment with separate private subnets for ingestion, processing, and analytical services. An identity service provides workload roles, and customer data is encrypted with centrally managed keys. Events enter through authenticated endpoints and are placed on a durable stream. Containerized transformation services validate and enrich records; bursty validation tasks use serverless functions. Raw data is stored in versioned object storage, while curated data is loaded into a managed analytical warehouse.

A catalog records schema, lineage, retention, and classification. Network policies prevent direct Internet access from processing and data tiers. Dashboards access curated datasets through controlled service identities. Infrastructure is deployed through reviewed IaC modules. A second region receives replicated critical data and hosts tested recovery procedures. The organization defines an RPO of 15 minutes and an RTO of two hours for inventory analytics.

Outcome

The architecture scales processing during seasonal demand, reduces manual server administration, and improves auditability. It does not eliminate complexity: streaming operations, schema evolution, data-transfer cost, and cross-region consistency require continuous management. Recovery tests reveal that restoring compute is easy, but recreating permissions, catalog metadata, and dashboard configurations requires explicit automation.

Learning Points

The case demonstrates that cloud architecture is an end-to-end system. Storage, networking, identity, compute, governance, observability, and recovery must be designed together. Elasticity without data governance is unsafe; redundancy without tested recovery is hypothetical; and managed services reduce some work while creating new responsibilities in configuration and integration.

11. Limitations, Ethics, and Contemporary Developments

Cloud environments concentrate substantial data and operational power in provider platforms. Ethical and regulatory analysis therefore includes privacy, surveillance risk, data sovereignty, accessibility, environmental impact, and concentration of market power. Organizations should classify data before migration, document processing purposes, define retention, support lawful access and deletion requirements, and evaluate provider subprocessors and geographic locations.

Energy efficiency is also relevant. Region selection, workload scheduling, storage lifecycle rules, right-sizing, and efficient data formats can reduce cost and environmental impact. Sustainability claims should be evaluated using transparent boundaries and evidence rather than marketing language alone.

Contemporary engineering increasingly combines policy as code, confidential computing, zero-trust architecture, managed Kubernetes, event-driven integration, and AI-assisted operations. AI can help summarize logs, recommend rightsizing, and detect anomalies, but automated changes require bounded permissions, human oversight, reproducible evidence, and protection against leaking sensitive operational data. AI-generated infrastructure definitions must be reviewed like any other untrusted code.

Best-Practice Design Checklist

A foundational cloud environment should normally include:

• Clearly stated business, security, compliance, RTO, and RPO requirements.
• A region and zone strategy based on latency, sovereignty, and failure analysis.
• Private-by-default networking with controlled ingress and egress.
• Federated human identity, workload identities, MFA, and least privilege.
• Managed services selected according to operational capability and lock-in tolerance.
• Versioned, scanned, and reproducible images or deployment artifacts.
• IaC stored in version control with review, testing, policy checks, and protected state.
• Centralized logs, metrics, traces, alerts, and audit records.
• Backups with restoration tests rather than backup creation alone.
• Cost allocation, budgets, tagging, and unit-economics measures.
• Documented incident response, change management, and decommissioning procedures.

Chapter Summary

Cloud infrastructure is a programmable operating model built from compute, storage, networking, identity, and managed platform services. IaaS provides control, PaaS reduces operational burden, and SaaS delegates most application management. Regions and availability zones support geographic placement and fault isolation, but resilience depends on independent dependencies and tested recovery.

Virtual machines, containers, managed platforms, and serverless services represent different points on the control-versus-abstraction spectrum. Object, block, file, relational, NoSQL, warehouse, lake, and lakehouse services serve different access patterns. Secure networking uses segmentation, private services, controlled routing, and careful ingress and egress. IAM, encryption, monitoring, policy, and governance are shared responsibilities rather than optional additions.

Infrastructure as code makes environments repeatable and auditable when supported by version control, testing, protected state, and drift management. Hybrid and multi-cloud architectures can meet legitimate business requirements but add operational and data complexity. Effective cloud engineering therefore integrates technical architecture with reliability, cost, governance, privacy, sustainability, and organizational capability.

Key Terms

Cloud computing: On-demand delivery of shared computing resources over a network.

IaaS: Cloud delivery of virtualized infrastructure resources.

PaaS: Managed application platform that abstracts much infrastructure operations.

SaaS: Provider-managed software delivered to end users.

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

Region: Geographically distinct cloud location containing one or more zones.

Availability zone: Isolated fault domain within a cloud region.

RTO: Maximum acceptable time to restore service.

RPO: Maximum acceptable period of data loss.

Virtual machine: Software-defined computer with a guest operating system.

Container: Packaged application process sharing the host kernel.

Serverless: Execution model in which infrastructure management is largely delegated to the provider.

Object storage: Key-based storage for durable, scalable objects.

Load balancer: Service that distributes traffic across healthy targets.

IAM: Identity and access management for users, workloads, and resources.

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

Infrastructure as code: Versioned, executable definition of infrastructure configuration.

Hybrid cloud: Combination of private infrastructure and public-cloud services.

Multi-cloud: Use of services from multiple public-cloud providers.

Observability: Ability to understand system behavior through telemetry such as logs, metrics, and traces.

Review Questions

Short Answer Questions

1. What is the difference between IaaS, PaaS, and SaaS?
2. Why are availability zones important in cloud architecture?
3. Distinguish RTO from RPO.
4. State two advantages and two limitations of containers.
5. What does least privilege mean in IAM?

Long Answer Questions

1. Explain how a three-tier cloud network can reduce attack surface and improve operational control.
2. Compare virtual machines, containers, and serverless services for an analytical workload.
3. Discuss the shared-responsibility model and explain why moving to managed services does not eliminate customer obligations.
4. Explain how infrastructure as code supports reliability, governance, and auditability.
5. Critically evaluate the claim that multi-cloud automatically improves resilience.

Analytical / Application Questions

1. An application depends on two independent services with availabilities of 99.9% and 99.95%. Estimate the combined availability using the serial-component model and explain why the estimate may differ from real-world performance.
2. Design a cloud architecture for a university learning platform with unpredictable examination-period demand, sensitive student records, and a two-hour RTO. Justify compute, storage, identity, networking, and recovery choices.
3. A company wants to move a regulated data lake to the cloud but insists that all data remain in one region. Analyze the resulting resilience, compliance, cost, and disaster-recovery trade-offs, and recommend controls.

Multiple Choice Questions with Answers

Question 1

Which service model generally gives the customer the greatest control over the operating system?

A. Software as a Service

B. Platform as a Service

C. Infrastructure as a Service

D. Function as a Service

Correct Answer: C. Infrastructure as a Service

Question 2

What is the primary architectural purpose of using multiple availability zones within a region?

A. To eliminate all software defects

B. To isolate workloads from some localized infrastructure failures

C. To guarantee zero network latency

D. To avoid the need for backups

Correct Answer: B. To isolate workloads from some localized infrastructure failures

Question 3

A service is unavailable for 43.2 minutes during a 30-day month. What is its approximate availability?

A. 99.0%

B. 99.5%

C. 99.9%

D. 99.99%

Correct Answer: C. 99.9%

Question 4

Which storage type is most naturally suited to durable, large-scale data-lake objects?

A. Object storage

B. CPU cache

C. Block storage used only for boot disks

D. Temporary memory storage

Correct Answer: A. Object storage

Question 5

Which practice best represents least privilege?

A. Giving every developer administrator access

B. Using one shared permanent access key

C. Granting only the permissions required for a defined task

D. Allowing unrestricted outbound traffic

Correct Answer: C. Granting only the permissions required for a defined task

Question 6

What is a principal benefit of infrastructure as code?

A. It removes the need for security reviews

B. It makes infrastructure definitions repeatable and reviewable

C. It guarantees that providers never change APIs

D. It eliminates all operational costs

Correct Answer: B. It makes infrastructure definitions repeatable and reviewable

Question 7

Which statement about containers is correct?

A. Every container normally includes a complete independent kernel

B. Containers share the host kernel and package application dependencies

C. Containers cannot be orchestrated

D. Container images never require vulnerability scanning

Correct Answer: B. Containers share the host kernel and package application dependencies

Question 8

What does an RPO of 15 minutes indicate?

A. The system must recover in 15 minutes

B. The system may tolerate losing up to approximately 15 minutes of data

C. The system must have 15 availability zones

D. Every request must complete within 15 minutes

Correct Answer: B. The system may tolerate losing up to approximately 15 minutes of data

Question 9

Which design most directly reduces direct Internet exposure for application servers?

A. Placing all servers in a public subnet

B. Using private application subnets behind a controlled load balancer

C. Disabling identity controls

D. Storing secrets in container images

Correct Answer: B. Using private application subnets behind a controlled load balancer

Question 10

Why can multi-cloud increase operational complexity?

A. It always prevents data replication

B. It requires managing different service interfaces, policies, and operational skills

C. It makes networking unnecessary

D. It guarantees identical provider behavior

Correct Answer: B. It requires managing different service interfaces, policies, and operational skills