Cloud Infrastructure Foundations

Introduction

Cloud computing has transformed information technology from a model based primarily on purchasing and operating physical equipment into a model based on accessing computing capabilities as services. Organisations can obtain storage, networks, databases, operating systems, application platforms, and complete software products over a network, often paying according to consumption.

For cloud professionals, understanding infrastructure foundations is essential. Cloud deployment decisions affect cost, security, performance, resilience, compliance, operational responsibility, and the skills required by an organisation. Cloud computing is therefore not simply “someone else’s computer”; it is an organised approach to delivering configurable computing resources through abstraction, automation, resource pooling, and measured service.

This chapter introduces the terminology and architectural concepts needed for later study of cloud deployment, administration, security, and optimisation.

Learning Objectives

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

1. Define cloud computing and explain its essential characteristics.
2. Distinguish major cloud infrastructure terms.
3. Explain virtualization and its role in resource abstraction.
4. Describe regions, availability zones, and fault domains.
5. Compare IaaS, PaaS, and SaaS service models.
6. Compare public, private, hybrid, and multi-cloud deployment models.
7. Apply the shared-responsibility model to practical situations.
8. Evaluate cloud choices in terms of resilience, security, governance, and operational responsibility.

1. What Is Cloud Computing?

A widely used definition describes cloud computing as on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or provider interaction. The resources may include networks, servers, storage, applications, and services.

This definition contains several important ideas:

• On-demand access: Resources can be requested when required rather than obtained through a lengthy procurement process.
• Network access: Services are normally accessed through networks using standard mechanisms such as web consoles, command-line tools, APIs, and software agents.
• Resource pooling: A provider serves multiple customers using a shared physical and logical infrastructure while maintaining isolation between customers.
• Rapid elasticity: Capacity can increase or decrease in response to demand.
• Measured service: Usage can be monitored, controlled, and commonly billed according to consumption.

Cloud computing is best understood as a service-delivery and operating model supported by technology. Virtualization, distributed systems, automation, software-defined networking, high-speed connectivity, and large-scale data-centre operations make the model practical, but no single technology alone constitutes cloud computing.

2. Essential Cloud Terminology

2.1 Resource and service

A resource is a technical capability such as CPU capacity, memory, storage, a virtual network, or an IP address. A service is a managed capability made available to a consumer, such as a virtual machine service, object-storage service, or hosted database service.

2.2 Provisioning

Provisioning is the process of allocating and configuring resources. In traditional environments, provisioning may involve purchasing hardware, installing systems, and connecting networks. In cloud environments, provisioning may be completed through a portal, command-line interface, API, or infrastructure-as-code tool.

2.3 Deprovisioning

Deprovisioning is the removal or release of resources that are no longer required. Failure to deprovision unused resources is a common cause of unnecessary cloud expenditure.

2.4 Elasticity and scalability

Scalability is the ability of a system to handle increased workload by adding resources or improving capacity. Scaling may be:

• Vertical scaling: Increasing the capacity of an existing instance, such as adding virtual CPU or memory.
• Horizontal scaling: Adding more instances, servers, or application replicas.

Elasticity is the ability to scale resources up or down dynamically as demand changes. A system may be scalable without being highly elastic if changes require manual intervention or significant delay.

2.5 Availability, reliability, and resilience

Availability is the proportion of time a service is operational and accessible. Reliability is the ability of a system to perform consistently over a period of time. Resilience is the ability to withstand, recover from, and adapt to failures.

A simple availability expression is:

Uptime and downtime must be measured over the same period and in the same units. For example, 99 hours of uptime and 1 hour of downtime produce an availability of 99 ÷ 100 = 0.99, or 99%. Availability targets do not guarantee that every failure will be prevented; they express a service objective or commitment.

2.6 Fault tolerance

Fault tolerance is the capability of continuing operation when a component fails. Redundant servers, replicated data, multiple network paths, and automated failover can improve fault tolerance. Redundancy is not automatically fault tolerance: components must be designed so that failure of one does not cause unacceptable service interruption.

2.7 Multitenancy and isolation

Multitenancy means that multiple customers use a shared provider infrastructure. Logical isolation, identity controls, encryption, network segmentation, and secure software design help prevent one customer from accessing another customer’s resources. Physical separation may also be available but usually costs more and is not required for every workload.

2.8 API and automation

An application programming interface (API) is a defined interface through which software requests operations from another system. Cloud APIs allow resources to be created, modified, monitored, and deleted programmatically. Automation improves repeatability and speed, but poorly controlled automation can also distribute errors rapidly.

2.9 Infrastructure as code

Infrastructure as code (IaC) represents infrastructure configuration in machine-readable files. IaC supports version control, peer review, repeatable deployment, and recovery. It should be combined with secure secret management, testing, policy validation, and controlled deployment pipelines.

3. Essential Characteristics of Cloud Computing

The following characteristics distinguish cloud computing from simple remote hosting.

Self-service provisioning

Consumers can request resources without requiring a provider employee to perform every individual task. Self-service does not mean unrestricted access; identity, approval, quotas, and policy controls remain important.

Broad network access

Cloud capabilities are available through standard network mechanisms and can support different client types, including laptops, mobile devices, applications, and administrative tools. Network quality, latency, bandwidth, and identity security remain practical constraints.

Resource pooling

Providers pool physical resources and allocate them dynamically among customers. Pooling improves utilisation and supports economies of scale, but it makes isolation and governance essential.

Rapid elasticity

Capacity can be provisioned and released quickly. Elasticity may be automated through monitoring rules, load balancers, orchestration platforms, or application-level scaling mechanisms.

Measured service

Cloud platforms expose measurements such as storage consumed, data transferred, requests processed, or compute time. Measurement supports billing, capacity planning, chargeback, and optimisation.

4. Virtualization and Abstraction

Virtualization separates logical computing environments from the physical hardware on which they run. A hypervisor, also called a virtual-machine monitor, manages virtual machines and controls their access to CPU, memory, storage, and network resources.

A physical server may host several virtual machines. Each virtual machine normally has a guest operating system and applications, while the hypervisor manages the underlying hardware. Virtual machines are not necessarily equivalent to physical machines: their performance, device access, boot behaviour, and failure characteristics depend on the implementation and workload.

There are two broad hypervisor categories:

• Type 1 hypervisors run directly on physical hardware and are common in data-centre environments.
• Type 2 hypervisors run above a conventional host operating system and are common for desktop laboratories and development.

Virtualization provides:

• improved hardware utilisation;
• rapid creation and removal of environments;
• isolation between workloads;
• migration and recovery capabilities;
• support for standardised machine images.

However, virtualization does not eliminate risk. A failure of a physical host, storage system, network fabric, or management plane may affect multiple virtual machines. This is sometimes called a shared-failure domain. Virtual machines also require secure configuration, patching, monitoring, and access control.

Containers

A container packages an application and its dependencies while sharing the host operating-system kernel. Containers are generally lighter and faster to start than full virtual machines, but they do not provide exactly the same isolation boundary. Container images, registries, orchestration systems, runtime permissions, and software dependencies must be secured and maintained.

Virtual machines and containers are complementary. A container platform may itself run on virtual machines, and a workload may require virtual-machine isolation even when containers are used inside it.

5. Regions, Availability Zones, and Fault Domains

Cloud providers divide their infrastructure into geographic and logical structures. Terminology differs between providers, but the underlying design principles are similar.

Region

A region is a distinct geographic area containing one or more provider data-centre groupings. Regions are selected according to latency, data-residency requirements, service availability, disaster-recovery objectives, and regulatory obligations.

Choosing a region close to users may reduce network latency. Choosing a region in a particular country may support legal or organisational requirements. Regions are not always identical: a service or feature available in one region may be unavailable or differently configured in another.

Availability zone

An availability zone is an isolated location or group of locations within a region, designed to reduce the likelihood that a local failure affects all zones. Zones commonly have separate power, cooling, and network arrangements, although the exact architecture is provider-specific.

Deploying an application across multiple zones can improve resilience against a zone-level failure. It does not automatically protect against regional failure, application defects, data corruption, incorrect configuration, or credential compromise.

Fault domain

A fault domain is a set of resources that may be affected by the same failure. Examples include a physical host, rack, power circuit, zone, region, or shared software control plane. Effective architecture identifies relevant fault domains and places redundant components across appropriate boundaries.

Latency and data transfer

Geographic distribution introduces trade-offs. Cross-region communication may increase latency and data-transfer cost. Replication can improve recovery capability but may create consistency, bandwidth, and privacy challenges. Designers should distinguish:

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

For example, an RPO of 15 minutes means that, under the recovery design, the organisation aims to lose no more than approximately 15 minutes of data. An RTO of 2 hours means that service restoration is targeted within two hours. These are requirements, not guarantees, unless supported by tested procedures and suitable service commitments.

6. The Shared-Responsibility Model

Cloud security and operations are shared between the provider and the customer. The provider is generally responsible for the security of the cloud: physical facilities, core hardware, foundational networking, and managed platform components. The customer is generally responsible for security in the cloud: identities, data, configurations, applications, and the operating system where the selected service model requires customer management.

The exact boundary changes according to the service model.

The table is a general model, not a universal contract. Customers must read provider documentation, service descriptions, security guides, and contracts.

Typical customer failures include public storage exposure, excessive privileges, unpatched guest operating systems, insecure application interfaces, unmanaged credentials, and inadequate backup testing. The provider’s physical security does not protect a customer from a poorly configured identity policy.

A practical accountability process should identify each control, its owner, evidence of implementation, monitoring method, and escalation route. Compliance responsibility is not automatically transferred to the provider merely because infrastructure is hosted in the cloud.

7. Cloud Service Models

Infrastructure as a Service (IaaS)

IaaS supplies fundamental computing resources such as virtual machines, virtual networks, block storage, and sometimes load-balancing services. The customer controls much of the operating environment, including guest operating systems, installed software, network rules, and applications.

IaaS offers flexibility and is suitable for legacy applications, custom operating-system requirements, specialised networking, and migration of existing servers. It also imposes more administration, patching, monitoring, and security responsibility.

Platform as a Service (PaaS)

PaaS provides a managed application platform. The provider may manage the operating system, runtime, scaling mechanisms, and much of the underlying infrastructure. The customer generally supplies application code, configuration, data, and identity controls.

PaaS can increase developer productivity and reduce routine infrastructure administration. Its limitations may include platform-specific constraints, version dependencies, migration difficulty, and reduced control over the underlying environment.

Software as a Service (SaaS)

SaaS delivers a complete application, such as email, collaboration, accounting, or customer relationship management software. The provider manages most infrastructure and application operations. The customer remains responsible for users, permissions, data classification, configuration, acceptable use, and often integration security.

SaaS reduces infrastructure administration but does not remove governance. Organisations must examine data location, retention, export capability, service availability, identity integration, audit records, and contractual terms.

Service-model comparison

These models form a continuum rather than three perfectly separate categories. Managed databases, serverless functions, and container platforms may occupy intermediate positions.

8. Cloud Deployment Models

Public cloud

A public cloud is operated by a provider and made available to multiple customers. It offers extensive services, rapid provisioning, global reach, and consumption-based pricing. Governance, configuration, data location, and provider dependency require careful management.

Private cloud

A private cloud is dedicated to one organisation. It may be operated by the organisation or a third party and may exist on-premises or in a hosted facility. Private cloud can support specific control, customisation, or regulatory requirements, but the organisation may retain substantial responsibility for hardware, capacity, skills, and operations.

Not every virtualised data centre is a private cloud. A private cloud should provide cloud-like capabilities such as self-service, automation, pooling, measurement, and rapid provisioning.

Hybrid cloud

Hybrid cloud combines private infrastructure with public-cloud services and provides some form of integration or portability between them. A common pattern uses private infrastructure for sensitive or stable workloads and public cloud for elastic capacity, development, analytics, or disaster recovery.

Hybrid environments introduce integration complexity. Identity, networking, monitoring, data movement, security policy, and operational processes must work across both environments.

Multi-cloud

Multi-cloud uses services from two or more public-cloud providers. Organisations may adopt it to access specialised services, reduce concentration risk, support regional requirements, or negotiate commercially. Multi-cloud is not automatically more resilient: common application dependencies, shared credentials, identical misconfigurations, and weak operational processes can affect every provider.

Multi-cloud also increases complexity in skills, governance, monitoring, networking, cost management, and service integration. It should be adopted for a clear business or technical reason rather than as an assumption that more providers always produce better architecture.

9. Selecting an Appropriate Model

Cloud selection should begin with requirements rather than technology preference. Important questions include:

1. What availability, performance, and recovery levels are required?
2. What data classification, privacy, residency, and retention rules apply?
3. How much operating-system and network control is necessary?
4. Which skills and support capabilities are available?
5. What are the predictable and variable costs?
6. How difficult would migration or exit be?
7. Which provider services are mature and supported in the required region?
8. How will identity, logging, monitoring, backup, and incident response operate?

A useful professional principle is to choose the highest level of managed service that satisfies requirements without creating unacceptable dependency or control limitations. This can reduce undifferentiated operational work, but it must be balanced against portability, customisation, performance, and governance.

10. Applied Case: Regional Online Retailer

Background

This illustrative case concerns Northstar Retail, a medium-sized online retailer whose existing application runs on two physical servers in one office. Traffic increases sharply during seasonal promotions. The company experiences slow releases, limited backup testing, and a single-site failure risk.

Problem

Northstar requires higher availability, faster deployment, improved recovery, and the ability to handle temporary demand. Its customer data must be protected, and management needs predictable visibility into costs.

Analysis

The current single-site architecture has a concentrated fault domain. Vertical expansion of the existing servers may provide additional capacity but does not solve the site-level failure risk. A complete rewrite would offer long-term benefits but would delay improvement and increase project risk.

Approach

Northstar adopts a staged hybrid-to-public-cloud strategy:

• The web tier is deployed as multiple instances across two availability zones.
• A load balancer distributes requests and removes unhealthy instances.
• Application images are version-controlled and deployed through an automated pipeline.
• A managed relational database is selected to reduce routine database administration.
• Backups are encrypted, monitored, and restored periodically in tests.
• Identity access is granted according to job role and protected with multi-factor authentication.
• Central logging records administrative and application events.
• A separate recovery environment is maintained in another region for critical data and procedures.
• Budgets, alerts, tags, and ownership metadata are introduced for cost governance.

The web tier uses a PaaS-style managed platform, while a small legacy fulfilment application initially remains on IaaS virtual machines. This mixed approach reflects different migration requirements rather than an attempt to force every workload into one model.

Outcome

Northstar gains improved resilience to an instance or availability-zone failure, faster application releases, and more transparent resource ownership. However, it still must manage application defects, database permissions, data protection, recovery testing, and provider dependency. The project is successful because responsibilities and requirements were documented rather than assumed to disappear after migration.

Learning points

• Redundancy must cross the relevant fault domain.
• Managed services reduce some work but do not eliminate governance.
• Recovery objectives must be tested, not merely written in a plan.
• Cost controls should be designed at the beginning of adoption.
• A staged architecture can combine IaaS, PaaS, and SaaS according to workload needs.

11. Challenges, Governance, and Best Practices

Cost management

Consumption-based pricing can make costs variable and difficult to predict. Unused storage, oversized instances, data transfer, duplicate environments, and uncontrolled experimentation are common sources of waste. Use budgets, tagging, rightsizing, lifecycle policies, approval workflows, and regular cost reviews.

Security and privacy

Use least privilege, multi-factor authentication, encryption appropriate to the risk, secure key management, network segmentation, vulnerability management, logging, and tested incident-response procedures. Data classification should determine where and how information is stored and processed.

Availability and recovery

Design for component failure, automate health checks and replacement, maintain backups, and test restoration. A backup that has never been restored is an assumption rather than verified recovery capability.

Portability and lock-in

Provider-specific services can improve productivity but may make migration difficult. Document dependencies, retain data-export procedures, use open standards where practical, and evaluate exit costs before committing to critical services.

Responsible use of automation and AI

Automation and AI-assisted operations can detect anomalies, recommend configurations, generate infrastructure code, and support incident analysis. Human review remains essential because generated configurations may contain insecure permissions, incorrect assumptions, or hidden costs. Sensitive operational data should not be submitted to tools without approved data-handling controls.

Environmental considerations

Cloud efficiency depends on utilisation, hardware efficiency, workload placement, and data-transfer patterns. Consolidating idle workloads, selecting appropriate regions, using autoscaling carefully, and deleting unnecessary resources can reduce both cost and environmental impact. Efficiency must not compromise legal, security, or resilience requirements.

Chapter Summary

Cloud computing provides on-demand, network-accessible, pooled, elastic, and measured computing capabilities. Its foundations include provisioning, scalability, elasticity, availability, resilience, multitenancy, APIs, and infrastructure as code. Virtualization abstracts physical resources into virtual machines, while containers provide a lighter application-packaging model with different isolation characteristics.

Regions and availability zones help architects reason about geography and fault domains. Deploying across zones can improve resilience, but it does not solve every form of failure. The shared-responsibility model assigns different security and operational duties to the provider and customer, and the boundary changes between IaaS, PaaS, and SaaS.

IaaS provides the greatest infrastructure control but also the greatest administrative burden. PaaS reduces platform management and supports developer productivity. SaaS delivers complete applications but still requires customer governance of identity, data, and configuration. Public, private, hybrid, and multi-cloud deployment models offer different balances of control, flexibility, complexity, and provider dependence.

Sound cloud architecture begins with business, security, performance, compliance, cost, and recovery requirements. Professional practice requires explicit ownership, tested recovery, controlled access, monitoring, cost governance, and careful evaluation of dependency and portability.

Key Terms

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

Provisioning: Allocating and configuring computing resources.

Elasticity: Ability to increase or decrease resources as demand changes.

Scalability: Ability of a system to handle increased workload by adding or improving capacity.

Availability: Proportion of time that a service is operational and accessible.

Reliability: Ability to perform consistently over time.

Resilience: Ability to withstand, recover from, and adapt to failures.

Multitenancy: Use of shared infrastructure by multiple customers with logical isolation.

Virtualization: Abstraction of computing resources from physical hardware.

Hypervisor: Software that manages virtual machines and their access to hardware.

Container: A packaged application environment that generally shares the host kernel.

Region: A geographic area containing one or more cloud infrastructure locations.

Availability zone: An isolated location or group of locations within a region.

Fault domain: A set of resources potentially affected by the same failure.

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

IaaS: Infrastructure delivered as configurable virtualised computing resources.

PaaS: Managed application-development and runtime platform.

SaaS: Complete software application delivered as a service.

Hybrid cloud: Integrated use of private infrastructure and public-cloud services.

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

Review Questions

Short Answer Questions

1. What is meant by resource pooling in cloud computing?
2. Distinguish scalability from elasticity.
3. What is the role of a hypervisor?
4. Define an availability zone.
5. What does the shared-responsibility model mean?

Long Answer Questions

1. Explain the essential characteristics of cloud computing and show how they differ from traditional hosting.
2. Compare IaaS, PaaS, and SaaS in terms of control, responsibility, and typical use.
3. Explain how regions, availability zones, and fault domains influence resilient architecture.
4. Discuss the benefits and limitations of public, private, hybrid, and multi-cloud deployment models.
5. Explain why virtualization is important to cloud computing and identify its limitations.

Analytical / Application Questions

1. An organisation requires rapid scaling but has a small operations team. Which service model would you initially investigate, and what trade-offs should be assessed?
2. A database and web server are deployed in two availability zones, but both use the same administrative account and an untested backup. Identify the resilience and security weaknesses.
3. A company proposes multi-cloud solely because it believes using two providers automatically doubles availability. Critically evaluate this proposal and recommend the evidence needed before proceeding.

Multiple Choice Questions with Answers

Question 1

Which characteristic allows a customer to request computing resources without requiring manual provider intervention for every request?

A. Self-service provisioning

B. Physical isolation

C. Static capacity planning

D. Manual patch management

Correct Answer: A. Self-service provisioning

Question 2

What is the primary function of a hypervisor?

A. To encrypt all customer data automatically

B. To manage virtual machines and their access to physical resources

C. To replace the need for an operating system

D. To provide business applications to end users

Correct Answer: B. To manage virtual machines and their access to physical resources

Question 3

Which statement best distinguishes elasticity from scalability?

A. Elasticity concerns only storage, whereas scalability concerns only networks

B. Elasticity is dynamic adjustment to changing demand, whereas scalability is the ability to handle increased workload

C. Elasticity applies only to private clouds, whereas scalability applies only to public clouds

D. Elasticity means physical separation, whereas scalability means logical separation

Correct Answer: B. Elasticity is dynamic adjustment to changing demand, whereas scalability is the ability to handle increased workload

Question 4

Which deployment arrangement is specifically designed to reduce the impact of a failure affecting one location within a region?

A. Deploying all resources on one virtual machine

B. Deploying redundant components across availability zones

C. Using only a larger instance size

D. Removing health checks from the application

Correct Answer: B. Deploying redundant components across availability zones

Question 5

Under the general shared-responsibility model, who is normally responsible for customer identity permissions and data configuration?

A. The cloud customer

B. The building landlord

C. The internet service provider only

D. The hardware manufacturer only

Correct Answer: A. The cloud customer

Question 6

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

A. SaaS

B. PaaS

C. IaaS

D. Managed office software

Correct Answer: C. IaaS

Question 7

A company uses a complete hosted customer-relationship application and mainly manages users, permissions, and business settings. Which model is this?

A. IaaS

B. PaaS

C. SaaS

D. Bare-metal colocation

Correct Answer: C. SaaS

Question 8

What is the main purpose of a recovery point objective (RPO)?

A. To specify the maximum acceptable amount of data loss measured in time

B. To specify the number of employees who may access a system

C. To measure the physical distance between data centres

D. To calculate the purchase price of a server

Correct Answer: A. To specify the maximum acceptable amount of data loss measured in time

Question 9

An organisation combines its on-premises infrastructure with integrated public-cloud services. Which deployment model does this describe?

A. Private cloud only

B. Hybrid cloud

C. Single-tenant SaaS only

D. Offline computing

Correct Answer: B. Hybrid cloud

Question 10

A service has 99 hours of uptime and 1 hour of downtime during a measurement period. What is its availability?

A. 90%

B. 95%

C. 99%

D. 99.9%

Correct Answer: C. 99%