Cloud Computing and Deployment Foundations

Introduction

Cloud computing has become a dominant method for delivering computing infrastructure, platforms, and software. Instead of purchasing and operating all hardware locally, an organisation can obtain computing resources through a network, usually the internet, and pay according to consumption or subscription. Cloud services support rapid experimentation, global application delivery, automated deployment, elastic scaling, and improved access to specialist infrastructure.

For DevOps practitioners, cloud knowledge is foundational. Continuous integration and continuous delivery pipelines frequently build software in cloud environments; applications may run across virtual machines, containers, managed databases, and serverless services; and operational responsibilities are distributed between the cloud provider and the customer. A technically successful deployment therefore requires more than knowing how to create a server. It requires an understanding of service models, geographical architecture, security boundaries, resilience, cost, and governance.

This chapter introduces the conceptual and practical foundations required to deploy workloads on platforms such as Amazon Web Services (AWS) and Google Cloud Platform (GCP). Product names differ between providers, but the underlying principles are widely transferable.

Learning Objectives

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

• explain major cloud-computing terminology;
• describe virtualization, containers, elasticity, scalability, and measured service;
• distinguish regions, availability zones, and edge locations;
• compare IaaS, PaaS, and SaaS service models;
• compare public, private, hybrid, and multi-cloud deployment models;
• apply the shared-responsibility model to practical security decisions; and
• evaluate a basic cloud deployment using reliability, security, operational, and cost considerations.

What Is Cloud Computing?

Cloud computing is a model for providing on-demand network access to a shared pool of configurable computing resources. These resources may include servers, storage, networks, databases, application platforms, analytics systems, and software. They can be provisioned rapidly, released when no longer needed, and managed with varying degrees of automation.

Several characteristics distinguish cloud computing from traditional fixed infrastructure:

• On-demand self-service: authorised users can provision resources without waiting for manual hardware installation.
• Broad network access: services are accessible through standard networks and client technologies.
• Resource pooling: provider infrastructure serves multiple customers through logical isolation and allocation controls.
• Rapid elasticity: capacity can increase or decrease in response to demand.
• Measured service: usage is monitored and may be charged according to consumption.

Cloud computing does not mean that physical infrastructure disappears. Servers, storage devices, networks, cooling systems, and data centres still exist. Rather, physical resources are abstracted, pooled, automated, and exposed through service interfaces.

Essential Terminology

A workload is a set of computing activities and resources supporting a business or technical function. An online retail application, for example, may include web servers, an application service, a database, object storage, and monitoring.

A resource is an individual cloud capability, such as a virtual machine, storage bucket, database instance, or virtual network. A service is a provider-managed offering through which resources are created and used. A tenant is a customer or logical customer environment sharing a provider platform with other customers.

An API, or application programming interface, allows software to request actions from a service. The AWS CLI, Google Cloud CLI, Terraform, and deployment pipelines use APIs to create and manage cloud resources. Infrastructure as code (IaC) represents infrastructure in machine-readable configuration files, allowing environments to be reviewed, versioned, tested, and reproduced.

A region is a distinct geographical area containing cloud infrastructure. An availability zone is an isolated location within a region, normally consisting of one or more data centres with independent power, cooling, and network characteristics. Cloud providers use different terminology, but the design principle is similar.

Provisioning is the process of creating and configuring resources. Deprovisioning is their removal or release. Scalability is the ability of a system to accommodate changing workload by adding resources or improving capacity. Elasticity is the ability to scale resources dynamically, often automatically, as demand changes. A system may be scalable without being highly elastic if scaling requires a lengthy manual process.

Virtualization and Abstraction

Virtualization separates a logical computing environment from the underlying physical hardware. A software layer called a hypervisor creates and manages virtual machines (VMs). Each VM can have its own operating system, virtual CPU, memory, storage, and network interfaces. The hypervisor schedules access to physical resources while maintaining isolation between VMs.

Virtualization provides several important benefits:

1. Hardware utilization: multiple VMs can share one physical server.
2. Isolation: faults and configuration changes in one VM are less likely to affect another.
3. Portability: VM images can often be copied or redeployed across compatible infrastructure.
4. Automation: APIs can create, configure, snapshot, and terminate VMs quickly.
5. Standardization: teams can build repeatable machine images and environments.

Virtual machines include a complete guest operating system, so they generally consume more resources and start more slowly than containers. Containers isolate application processes while sharing the host operating system kernel. A container image packages application code, libraries, and configuration assumptions in a standard format. Containers are lightweight and portable, but they do not provide exactly the same isolation boundary as a VM and must be secured appropriately.

A managed container platform or orchestrator schedules containers, replaces failed instances, provides service discovery, and supports rolling updates. Kubernetes is a widely used example, although cloud providers also offer managed container services. Serverless platforms provide an additional abstraction: the customer supplies code or a deployment package while the provider manages most server and runtime operations.

Abstraction creates operational advantages but also trade-offs. Higher-level services reduce infrastructure administration, yet they may restrict configuration, introduce provider-specific dependencies, or make migration more complex. DevOps professionals must select an abstraction level that matches the workload’s requirements and the team’s capabilities.

Scalability, Elasticity, and Availability

A system can scale vertically by increasing the size of an existing resource, such as assigning more memory to a VM. It can scale horizontally by adding more instances and distributing requests among them. Horizontal scaling is often preferred for highly available web systems because it can provide both capacity and fault tolerance.

A load balancer distributes traffic among healthy application instances. An auto-scaling policy changes the number or size of resources according to rules or signals such as CPU utilization, request rate, queue length, or custom application metrics.

Elasticity must be designed carefully. Rapidly adding instances may increase cost without solving the real bottleneck if the database, network, or external dependency cannot scale. Removing instances too aggressively may interrupt requests. Effective elasticity therefore requires:

• measurable demand signals;
• defined minimum and maximum capacity;
• health checks;
• graceful startup and shutdown;
• stateless application design where practical; and
• testing under realistic load.

Availability describes whether a service is usable when required. A common availability representation is:

Here, uptime and downtime must be measured over the same observation period and use the same time units. Availability is often expressed as a percentage. This simple ratio does not by itself explain performance, data correctness, or user experience. Service-level agreements may define additional terms, measurement windows, exclusions, and remedies.

Redundancy improves availability by providing alternative components. However, redundancy is effective only when failures are sufficiently independent. Two servers in the same rack may not protect against a rack power failure; two instances in the same availability zone may not protect against a zone outage.

Regions, Availability Zones, and Edge Locations

Cloud providers divide infrastructure geographically to support latency reduction, regulatory requirements, resilience, and operational separation.

A region is a broad geographic area. Selecting a region involves considering:

• distance from users and resulting network latency;
• legal or regulatory requirements concerning data location;
• service availability and feature support;
• price differences;
• disaster risks and provider capacity; and
• connectivity to on-premises systems and other regions.

An availability zone (AZ) is a failure-isolated location within a region. A highly available application may place instances in multiple AZs and use a load balancer to route traffic only to healthy instances. Data services require special attention because replication may be synchronous or asynchronous, automatic or customer-managed, and limited to one region or extended across regions.

An edge location is a point of presence closer to end users, commonly used for content delivery, caching, DNS responses, and edge security functions. Edge locations do not necessarily provide the same general-purpose compute and storage capabilities as a region.

A multi-region design can reduce the impact of a regional outage and improve global latency, but it introduces complexity. Data replication, conflict resolution, identity management, deployment coordination, cost, and testing become more demanding. Multi-region deployment should be justified by business requirements rather than adopted automatically.

Cloud Service Models

Service models describe how much infrastructure and software operation is managed by the provider.

Infrastructure as a Service

IaaS supplies fundamental computing resources such as virtual machines, block storage, object storage, and virtual networks. It provides substantial control and supports legacy applications, custom operating systems, and specialized configurations. The cost is greater administration: customers normally manage operating-system patching, installed software, host firewalls, identities, and application security.

Platform as a Service

PaaS provides a managed environment for deploying applications. The provider typically manages the operating system, runtime patching, and much of the underlying capacity. Developers can focus on application code and data. PaaS can accelerate delivery, but supported runtimes, networking models, scaling behavior, and deployment constraints must be understood.

Software as a Service

SaaS delivers a complete application through a browser, client, or API. The customer usually manages accounts, roles, configuration, data classification, and appropriate use. SaaS reduces infrastructure work but does not eliminate governance. Organisations remain responsible for selecting trustworthy providers, configuring controls, managing identities, and understanding data retention and exit arrangements.

The models form a continuum rather than perfectly separate categories. A provider may offer a managed database, container platform, or serverless function service between traditional IaaS and PaaS. The more the provider manages, the less direct operational control the customer has, but the customer may gain faster delivery and reduced maintenance.

Cloud Deployment Models

A public cloud is operated by a provider and serves multiple customers through logically isolated environments. It offers broad service choice, rapid provisioning, and potentially global reach. Customers must still design strong identity, network, data, and monitoring controls.

A private cloud is dedicated to one organisation. It may be operated internally or by a third party. Private cloud can support specific regulatory, control, or customization requirements, but the organisation may bear more capital, staffing, and operational responsibility.

A hybrid cloud combines private infrastructure with public-cloud services and enables some movement or integration between them. Common motivations include gradual migration, retention of sensitive systems, capacity expansion, and disaster recovery. Hybrid systems require reliable connectivity, compatible identity, consistent security policy, and clear data flows.

A multi-cloud strategy uses services from more than one public-cloud provider. It may reduce dependence on one provider, support regional requirements, or use specialized capabilities. It also increases complexity in skills, monitoring, security policy, networking, cost management, and application portability. Multi-cloud should be treated as an architectural choice with measurable benefits, not as a universal sign of maturity.

The Shared-Responsibility Model

Cloud security is a shared responsibility. The provider is responsible for security of the cloud: physical data centres, hardware, core networking, and the security of managed service infrastructure. The customer is responsible for security in the cloud: identity, data, configuration, application code, and other controls determined by the selected service.

The boundary changes by service model. With IaaS, the customer normally patches the guest operating system and secures applications running on it. With PaaS, the provider manages more of the operating stack, while the customer remains responsible for code, data, identities, and configuration. With SaaS, the provider operates the application, but the customer still controls user access, data governance, and appropriate configuration.

The exact division must be verified in the provider’s documentation for each service. “The provider secures the cloud” does not mean that every customer workload is secure by default. A publicly readable storage bucket, an overly permissive role, or an exposed administrative port is usually a customer configuration failure.

Applying Shared Responsibility in Practice

A practical review asks:

1. What service is being used, and where is its responsibility boundary?
2. Who manages identities, operating systems, patches, and encryption keys?
3. Which data is stored, where is it located, and who can access it?
4. What logs and alerts detect misuse or failure?
5. How are backups tested and how is the service recovered?
6. What evidence demonstrates compliance and operational control?

Security best practices include least-privilege access, multi-factor authentication, separation of duties, encryption in transit and at rest where appropriate, secret management rather than hard-coded credentials, network segmentation, vulnerability management, central logging, alerting, backup testing, and regular review of unused permissions.

A Practical Deployment Method

A basic cloud deployment should follow a controlled sequence rather than an improvised series of console clicks.

First, define business and technical requirements: users, performance, availability, data sensitivity, recovery objectives, budget, and regulatory constraints. Second, select the region and service model. Third, design identity and network boundaries before exposing workloads. Fourth, deploy using repeatable IaC or documented automation. Fifth, configure monitoring, logs, backups, and alerting. Sixth, test functionality, security, scaling, failure recovery, and cost behavior. Finally, document ownership and review the environment continuously.

A useful distinction is between recovery point objective (RPO) and recovery time objective (RTO). RPO describes the maximum acceptable amount of data loss measured in time. RTO describes the maximum acceptable time to restore service. For example, an RPO of 15 minutes means that losing up to 15 minutes of recent changes is considered tolerable; an RTO of two hours means the service should be restored within two hours. These are business requirements that influence replication, backup frequency, architecture, and cost.

Illustrative Case: Online Learning Portal Migration

Background

An illustrative college operates an online learning portal on one physical server. During examination periods, students experience slow responses. Backups are performed manually, and the institution has limited evidence that restoration works.

Problem

The portal needs higher capacity during predictable peaks, improved resilience, secure access for staff, and a manageable operating cost. Course records contain personal information and must be protected.

Analysis

The application consists of a web tier, an application tier, a relational database, uploaded documents, and an email integration. The web and application tiers can be made stateless and scaled horizontally. Uploaded documents are better suited to managed object storage. The database requires controlled access, backups, and tested recovery. Because the portal is primarily used by one geographic population, a single region with multiple availability zones may initially provide an appropriate balance of resilience and complexity.

Approach

The college deploys the application behind a load balancer across two availability zones. It uses an autoscaling group or managed application service for the web tier, a managed relational database with automated backups, and object storage for documents. Administrative access requires multi-factor authentication and least-privilege roles. Infrastructure is defined in version-controlled IaC. Monitoring records request latency, error rates, resource health, and authentication events. A staging environment is used to test releases before production deployment.

The design does not assume that a managed database removes all responsibility. The college still defines retention, restricts network access, reviews database roles, protects sensitive data, and performs restoration tests. Cost alerts and resource tags support financial accountability.

Outcome

The portal can add application capacity during examination periods and reduce it afterward. Failure of one application instance does not necessarily interrupt users. Backups and restoration procedures become testable, and operational responsibilities are documented. The college accepts that a regional disaster would require a future business decision about multi-region recovery rather than silently assuming that two availability zones provide regional protection.

Learning Points

The case demonstrates that cloud adoption is not simply relocation. Benefits arise from matching architecture to workload characteristics, automating repeatable operations, distributing failure domains, and assigning responsibility explicitly. Managed services reduce some work but do not remove governance, security, or recovery obligations.

Challenges, Limitations, and Governance

Cloud platforms introduce risks as well as benefits. Costs can become unpredictable when resources are untagged, overprovisioned, or left running. Service outages can affect dependent applications. Provider APIs and proprietary services may create vendor lock-in. Network failure can interrupt access to remote services. Poor identity configuration can expose data at large scale.

Governance should address data classification, approved regions and services, identity lifecycle, logging retention, vulnerability management, change control, incident response, backup policy, contractual terms, and supplier exit. Compliance is not achieved merely by selecting a certified provider; the customer must configure and operate services correctly and retain suitable evidence.

Ethically, cloud deployment should consider privacy, surveillance, accessibility, energy consumption, and the impact of automated decisions. Organisations should collect only necessary data, restrict secondary use, communicate material risks, and ensure that operational convenience does not override individual rights.

Contemporary cloud engineering increasingly combines IaC, policy as code, continuous delivery, managed Kubernetes, serverless computing, confidential-computing features, and AI-assisted operations. AI tools can help analyse logs, draft configurations, or identify anomalies, but generated recommendations require human review. Secrets, personal data, and proprietary configurations should not be supplied to tools without an approved data-handling policy.

Best-Practice Checklist

Before considering a foundational deployment complete, verify that:

• the workload owner and service owner are named;
• the region and failure assumptions are documented;
• identities use least privilege and multi-factor authentication where appropriate;
• public exposure is intentional and reviewed;
• patches, dependencies, and secrets have an ownership process;
• logs, metrics, alerts, and audit trails are enabled;
• backups exist and restoration has been tested;
• scaling limits and cost alerts are configured;
• infrastructure changes are version-controlled and reviewable; and
• incident response and recovery objectives are understood.

Chapter Summary

Cloud computing delivers shared, network-accessible resources through abstraction, automation, elasticity, and measured use. Virtualization enables multiple logical machines to share physical hardware, while containers and managed platforms provide progressively higher levels of abstraction. Scalability may be vertical or horizontal; elasticity adds dynamic adjustment to changing demand.

Regions, availability zones, and edge locations support geographical placement, resilience, and performance, but they provide different failure boundaries. IaaS, PaaS, and SaaS distribute operational responsibility differently. Public, private, hybrid, and multi-cloud models represent different ownership and integration choices, each with benefits and costs.

The shared-responsibility model is central to secure cloud deployment. Providers secure the underlying cloud infrastructure, while customers remain responsible for workload configuration, identities, data, applications, and appropriate operational controls. Effective deployment combines architectural reasoning, automation, monitoring, recovery testing, governance, and continuous cost and security review.

Key Terms

Availability: The proportion of an agreed observation period during which a service is usable.

Availability zone: An isolated infrastructure location within a cloud region.

Cloud computing: On-demand network access to pooled, configurable computing resources.

Container: An isolated application process packaged with its dependencies while sharing a host kernel.

Elasticity: The ability to adjust capacity dynamically as demand changes.

Edge location: A provider point of presence close to users, commonly used for caching and edge services.

Hypervisor: Software that creates and manages virtual machines.

Infrastructure as a Service (IaaS): Cloud provision of fundamental computing resources with substantial customer control.

Infrastructure as code: Machine-readable, version-controlled definition of infrastructure.

Multi-cloud: Use of services from more than one public-cloud provider.

Platform as a Service (PaaS): A managed application platform that abstracts much infrastructure administration.

Private cloud: Cloud infrastructure dedicated to one organisation.

Public cloud: Provider-operated infrastructure shared by multiple customers through logical isolation.

Region: A geographical area containing cloud infrastructure.

Scalability: The ability to accommodate changing workload by changing capacity or capability.

Shared responsibility: The principle that provider and customer divide security and operational duties.

Software as a Service (SaaS): A complete provider-hosted application delivered to customers.

Virtual machine: A software-defined computer running on virtualized physical infrastructure.

Review Questions

Short Answer Questions

1. What are the five commonly cited essential characteristics of cloud computing?
2. How does a container differ from a virtual machine?
3. Distinguish a cloud region from an availability zone.
4. What is the difference between scalability and elasticity?
5. Why does the shared-responsibility model matter to cloud customers?

Long Answer Questions

1. Compare IaaS, PaaS, and SaaS in terms of control, administration, and typical use cases.
2. Explain how a multi-availability-zone application can improve resilience and identify its limitations.
3. Compare public, private, hybrid, and multi-cloud deployment models.
4. Discuss the security responsibilities of a customer deploying an application on IaaS.
5. Explain why cloud migration requires governance and operational change, not merely technical relocation.

Analytical / Application Questions

1. An organisation runs a customer portal on one VM. Propose a more resilient design using a load balancer, multiple availability zones, managed storage, and monitoring. Explain the failure assumptions behind your design.
2. A company wants to use two cloud providers mainly to avoid vendor lock-in. Analyse the likely benefits, costs, and technical conditions required for this strategy to be worthwhile.
3. A team discovers that a storage bucket containing personal information is publicly readable. Identify the shared-responsibility failure, immediate actions, and longer-term preventive controls.

Multiple Choice Questions with Answers

Question 1

Which characteristic allows cloud resources to be provisioned and released as demand changes?

A. Measured service

B. Elasticity

C. Physical isolation

D. Manual provisioning

Correct Answer: B. Elasticity

Question 2

What is the primary role of a hypervisor?

A. To distribute DNS records globally

B. To encrypt all application data

C. To create and manage virtual machines

D. To replace an application database

Correct Answer: C. To create and manage virtual machines

Question 3

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

A. SaaS

B. PaaS

C. IaaS

D. Managed email

Correct Answer: C. IaaS

Question 4

What is an availability zone?

A. A billing account shared by several users

B. An isolated infrastructure location within a region

C. A software license for a VM

D. A customer support channel

Correct Answer: B. An isolated infrastructure location within a region

Question 5

Which deployment model combines private infrastructure with public-cloud services?

A. Hybrid cloud

B. Private cloud

C. Single-tenant SaaS

D. Edge computing only

Correct Answer: A. Hybrid cloud

Question 6

Under the shared-responsibility model, who is commonly responsible for configuring customer IAM permissions?

A. Only the physical data-centre operator

B. The customer

C. The internet service provider

D. The hardware manufacturer

Correct Answer: B. The customer

Question 7

Which approach is horizontal scaling?

A. Increasing the memory of one VM

B. Replacing a hard disk with a larger one

C. Adding application instances behind a load balancer

D. Changing a region name

Correct Answer: C. Adding application instances behind a load balancer

Question 8

An edge location is primarily intended to do which of the following?

A. Provide a customer-owned physical data centre

B. Place selected services closer to end users

C. Replace all availability zones

D. Manage employee payroll

Correct Answer: B. Place selected services closer to end users

Question 9

An RPO of 15 minutes indicates the maximum acceptable amount of what, measured in time?

A. Service restoration time

B. Database query latency

C. Potential data loss

D. User authentication delay

Correct Answer: C. Potential data loss

Question 10

Which practice best supports repeatable and reviewable infrastructure deployment?

A. Manual console changes without records

B. Infrastructure as code in version control

C. Sharing one administrator password

D. Disabling monitoring during releases

Correct Answer: B. Infrastructure as code in version control