Cloud Computing Models and Architecture

Introduction

Cloud computing is a model for delivering computing capabilities—such as processing, storage, databases, networking, platforms and software—over a network, usually the Internet. Instead of purchasing and operating all infrastructure directly, an organisation consumes resources from a provider or from an internally operated cloud environment. Cloud computing therefore changes not only technology deployment but also cost structures, operational responsibilities, security practices and organisational decision-making.

The modern cloud model is commonly described through five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. These characteristics distinguish cloud computing from simple hosting or traditional outsourcing. Cloud services may be classified by service model—Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)—and by deployment model, including public, private, hybrid and multi-cloud.

This chapter presents the architecture and decision principles required to select, design and govern cloud solutions. It also explains the shared-responsibility model, reference architectures, reliability considerations and practical migration choices.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain the essential characteristics of cloud computing.
2. Distinguish elasticity, scalability, availability and resilience.
3. Compare IaaS, PaaS and SaaS service models.
4. Compare public, private, hybrid and multi-cloud deployment models.
5. Apply the shared-responsibility model to security and operations.
6. Describe a layered cloud reference architecture.
7. Evaluate cloud designs using business, technical, security and governance criteria.

1. Foundations of Cloud Computing

1.1 From data centres to utility computing

Traditional computing commonly required an organisation to estimate future demand, purchase servers, install software and operate a data centre. Capacity was often underused during normal periods but insufficient during peaks. Cloud computing approaches computing more like a utility: consumers request capabilities when needed, pay according to an agreed commercial model and allow the provider to operate much of the underlying infrastructure.

Cloud computing does not eliminate physical infrastructure. Servers, storage systems, network equipment, facilities and energy remain necessary. Rather, it abstracts these resources behind programmable interfaces, automation and service-level agreements (SLAs). A cloud customer normally interacts with portals, command-line tools, application programming interfaces (APIs) and infrastructure-as-code systems instead of physically installing equipment.

1.2 Essential characteristics

The following characteristics are widely used to identify cloud computing.

On-demand self-service. A consumer can provision capabilities automatically, without requiring a provider employee to perform every request. For example, a development team may create a virtual network and database through an approved portal.

Broad network access. Services are available through standard network mechanisms and can be accessed by suitable clients such as browsers, mobile applications, workstations and automated systems. Access must still be controlled through authentication, authorisation and network policy.

Resource pooling. A provider serves multiple consumers using a shared pool of physical and virtual resources. Resources are dynamically assigned and reassigned according to demand. Logical isolation, identity controls and encryption are essential because physical sharing must not imply unauthorised data sharing.

Rapid elasticity. Capacity can be increased or decreased quickly in response to demand. To users, available capability may appear nearly unlimited, although real technical, contractual and financial limits exist.

Measured service. Usage is monitored, controlled and reported. Measurements may include storage volume, processing time, requests, data transfer or active users. This supports transparency, chargeback, capacity planning and pay-per-use billing.

1.3 Scalability, elasticity and resilience

These terms are related but not interchangeable.

Scalability is the ability of a system to handle increased workload by adding resources or improving its design. Vertical scaling increases the capacity of one instance, such as adding memory to a server. Horizontal scaling adds instances, such as running several application servers behind a load balancer.

Elasticity is the ability to scale resources dynamically, often up and down, as workload changes. A system that can add ten servers during a peak but never removes them is scalable but not fully elastic.

Availability is the proportion of time a service is operational and accessible. A simple availability ratio is:

Uptime and downtime must use the same time unit. For example, 99.9% availability over a 30-day month allows approximately 43.2 minutes of total downtime because 30 × 24 × 60 × 0.001 = 43.2 minutes. This is a planning approximation; contractual definitions may exclude scheduled maintenance or particular incidents.

Resilience is the ability to continue operating, or to recover acceptably, when components fail or adverse events occur. Resilience may involve redundancy, backups, replication, automated recovery and tested disaster-recovery procedures.

2. Cloud Architecture as a Layered System

A cloud environment can be understood as a set of cooperating layers rather than as a single product.

1. Physical layer: data centres, power, cooling, servers, storage and network equipment.
2. Virtualisation and abstraction layer: hypervisors, containers, virtual networks and software-defined storage.
3. Resource-control layer: scheduling, orchestration, identity, policy, monitoring and automation.
4. Service layer: compute, storage, databases, messaging, analytics, security and developer services.
5. Application layer: business applications, APIs, web interfaces and data-processing workloads.
6. Management and governance plane: billing, compliance, configuration management, logging, risk management and service operations.

A useful architecture separates the data plane, where application traffic and workload processing occur, from the control plane, where resources and policies are configured. A failure or compromise of the control plane can affect many workloads; therefore privileged access, strong authentication, logging and emergency procedures are particularly important.

Cloud architecture normally contains several common components:

• Clients and edge services: browsers, mobile devices, content delivery networks and DNS.
• Identity and access management: users, roles, policies, federation and privileged-access controls.
• Network services: virtual networks, subnets, routing, firewalls, gateways and load balancers.
• Compute services: virtual machines, containers, serverless functions and batch systems.
• Storage services: object, block and file storage, each with different access and performance characteristics.
• Data services: relational databases, NoSQL databases, caches, queues and data warehouses.
• Observability: logs, metrics, traces, alerts and audit records.
• Security services: key management, vulnerability management, threat detection and security information and event management.

A sound design uses automation and repeatable configuration. Infrastructure as code allows network, compute and policy definitions to be reviewed, tested and version-controlled. It reduces manual drift but does not automatically guarantee secure or correct configurations.

3. Service Models

Service models define how much of the technology stack the provider operates and how much remains the customer’s responsibility.

3.1 Infrastructure as a Service

IaaS provides fundamental computing resources such as virtual machines, disks, networks and sometimes bare-metal servers. The customer generally controls the operating system, installed software, data and many network settings. The provider manages the physical facilities, hardware and core virtualisation platform.

IaaS offers flexibility and is suitable when an organisation needs operating-system control, must migrate an existing application with limited redesign, or requires specialised configurations. Its disadvantages include greater administration, patching, security configuration and capacity-management responsibilities.

3.2 Platform as a Service

PaaS provides a managed application platform, such as a runtime environment, managed database, message broker or application deployment service. The customer supplies application code and data while the provider operates more of the operating system, runtime and underlying infrastructure.

PaaS can accelerate development, standardise deployment and reduce patching work. However, it may introduce vendor dependence, platform-specific constraints and migration effort if the application uses proprietary interfaces.

3.3 Software as a Service

SaaS delivers a complete application to end users, usually through a browser or mobile client. The provider normally operates the application, runtime, infrastructure and much of the security architecture. The customer remains responsible for account management, data governance, configuration, user behaviour and compliance obligations.

SaaS is appropriate for standard business capabilities such as collaboration, customer relationship management or human-resources administration. It provides rapid adoption but generally offers less control over application internals, release schedules and data location.

3.4 Function as a Service and containers

Function as a Service (FaaS), often called serverless computing, allows developers to deploy small units of code triggered by events. The provider manages servers and typically charges according to invocations, execution time and related resources. FaaS can be highly elastic, but cold starts, execution limits, observability and distributed debugging require attention.

Containers package an application and its dependencies in a portable unit. A container platform may be consumed through IaaS, PaaS or a managed container service. Containers improve consistency but do not remove the need for image security, identity control, network segmentation and patch management.

4. Deployment Models

4.1 Public cloud

A public cloud is operated by a provider for multiple customers. Resources are accessed through provider services and are logically isolated between tenants. Advantages include rapid provisioning, broad service choice, geographic reach and reduced capital expenditure. Risks include misconfiguration, regulatory restrictions, unpredictable usage costs and dependence on provider availability or commercial policy.

4.2 Private cloud

A private cloud is dedicated to one organisation. It may be hosted in the organisation’s own data centre or by a third party. Private cloud can offer greater control over placement, custom security and integration with specialised systems. However, the organisation still bears substantial responsibility for capacity, facilities, skills, upgrades and resilience. Calling a virtualised data centre a private cloud is not sufficient unless automation, self-service, pooling and measurement are also present.

4.3 Hybrid cloud

Hybrid cloud combines two or more distinct environments—often private and public—with technology or processes that allow data and workloads to interoperate. Examples include bursting temporary workloads into a public cloud, retaining regulated records in a private environment, or using cloud disaster recovery for an on-premises production system.

Hybrid designs are operationally complex. Network latency, identity federation, inconsistent security policy, data-transfer costs and differing monitoring systems can undermine expected benefits. A hybrid architecture should therefore have explicit integration patterns and a clear reason for each workload location.

4.4 Multi-cloud

Multi-cloud uses services from two or more cloud providers. It may reduce dependence on one provider, support geographic or regulatory requirements, or allow selection of specialised capabilities. It does not automatically improve resilience: an application deployed identically in two providers may still share a faulty design, identity weakness or data dependency.

Multi-cloud increases skills requirements, policy complexity, monitoring effort and data-movement costs. Portability should be treated as a business requirement with a defined level, such as data portability, container portability, application portability or full operational portability.

5. The Shared-Responsibility Model

Cloud security is shared between provider and customer, but the boundary changes with the service model. The provider is generally responsible for security of the cloud: facilities, physical hardware and core services. The customer is responsible for security in the cloud: identities, data, configuration and appropriate workload controls. These statements are general principles, not substitutes for a specific provider contract.

In IaaS, the customer commonly patches guest operating systems, configures firewalls, protects credentials and secures applications. In PaaS, the provider assumes more responsibility for operating systems and runtime components, while the customer still protects code, data, identities and configuration. In SaaS, the provider manages the application platform, but the customer remains responsible for users, access rights, data classification, retention and secure use.

Key controls include:

• least-privilege roles and separation of duties;
• multi-factor authentication, particularly for administrators;
• encryption in transit and at rest, with controlled key management;
• secure configuration baselines and continuous compliance checks;
• centralised, tamper-resistant logs;
• vulnerability and dependency management;
• tested backup, restoration and incident-response procedures;
• supplier, legal, privacy and regulatory assessment.

A frequent failure is assuming that moving a workload to a reputable provider transfers all accountability. It does not. The customer must understand the service boundary, configure it correctly and retain evidence that controls operate effectively.

6. Reference Architecture and Design Method

A practical cloud reference architecture can be organised as follows:

Users and external systems → edge protection → application services → data services → backup and analytics, with identity, networking, monitoring, security and governance operating across every layer.

A typical request might enter through DNS and a content-delivery or web-application-firewall service, pass through a load balancer, reach stateless application instances, and access a managed database through private network paths. Queues can decouple producers and consumers. Object storage can hold documents and backups. Monitoring records metrics, logs and traces for both technical and business events.

A repeatable design method is:

1. Identify business objectives, users, data and compliance obligations.
2. Classify workloads by criticality, sensitivity, latency and performance.
3. Choose service and deployment models based on required control and skills.
4. Design identity, network boundaries, encryption and secret management first.
5. Select availability zones or regions and define recovery objectives.
6. Automate infrastructure and application delivery through tested pipelines.
7. Establish monitoring, cost controls, incident response and governance.
8. Test failure, restoration, security controls and capacity assumptions.

Recovery objectives are important. The Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time. The Recovery Time Objective (RTO) is the target time to restore service after disruption. For example, an RPO of 15 minutes requires a backup or replication strategy whose possible data loss does not exceed 15 minutes; it does not guarantee that recovery will finish within 15 minutes. Recovery procedures must be tested rather than inferred from product features.

7. Cost and Measured Service

Cloud economics involve more than a provider’s hourly price. Total cost may include compute, storage, database consumption, requests, data transfer, support, security tools, licensing, staff training and migration. Measured service makes usage visible, but visibility alone does not create efficiency.

A simplified monthly estimate can be expressed as:

This is an estimation model, not a universal billing formula. Rates, discounts, taxes, reservations, minimum commitments and tiered pricing must be checked in the applicable contract. Cost governance practices include budgets, tagging, rightsizing, schedule-based shutdown, committed-use analysis and review of unused resources.

8. Case Study: Illustrative Retail Migration

Background

A fictional medium-sized retailer operates an online store in a small data centre. Demand rises sharply during seasonal promotions. The store experiences slow response times during peaks, while servers remain underused for much of the year. Customer data is sensitive, and the company has a small operations team.

Problem and analysis

The existing monolithic application is difficult to scale horizontally. The database is a bottleneck, deployments are manual, and backups have not been restored in a test environment. The business requires an RTO of four hours and an RPO of one hour. It does not require all components to remain on premises.

Approach

The retailer adopts a staged hybrid-to-public-cloud strategy. A managed application platform hosts stateless web services, while a managed relational database provides automated backups and replicas. Object storage holds product images and encrypted backup copies. A queue separates order submission from fulfilment tasks. A web application firewall and load balancer protect and distribute traffic. Identity federation connects corporate administrators to cloud roles, with multi-factor authentication and least privilege.

The application is first modified to externalise sessions and configuration, allowing multiple instances. Infrastructure is defined as code, deployments use a controlled pipeline, and dashboards track latency, error rate, queue depth, database performance and spending. Restoration tests are scheduled quarterly.

Outcome

The design supports horizontal scaling during promotions and reduces routine operating-system maintenance. The company retains a limited on-premises integration for legacy warehouse software. Costs become more variable, so budgets and alerts are introduced. The migration does not remove risk: database credentials, application vulnerabilities, supplier outages and incorrect access policies remain possible.

Learning points

1. Elasticity depends on application design, not merely on purchasing cloud capacity.
2. Managed services reduce some work but do not remove governance.
3. Hybrid architecture is justified by a specific integration requirement, not by habit.
4. Recovery objectives must be supported by tested procedures.
5. Cost, security and operational simplicity must be evaluated together.

9. Challenges, Governance and Contemporary Practice

Cloud adoption can produce vendor lock-in through proprietary databases, APIs, identity systems and data formats. Open standards, containerisation, abstraction layers and documented exit plans can reduce—but rarely eliminate—this risk. Portability also has a cost; avoiding every provider-specific service may reduce performance or productivity.

Data sovereignty and privacy require attention to location, processing purpose, retention, access and deletion. Organisations should map data flows, assess cross-border transfers and maintain contractual and audit evidence. Industry regulations may require particular controls, certifications or breach-reporting processes.

Environmental responsibility is also relevant. Cloud providers can improve utilisation and use renewable energy, but total impact depends on workload design, storage retention, data transfer and resource waste. Efficient architectures, appropriate instance sizes and deletion of unnecessary data support both cost and sustainability goals.

Artificial intelligence services are increasingly consumed through cloud platforms. They introduce additional concerns, including training-data rights, confidential-data exposure, model bias, explainability, prompt injection and output validation. AI workloads should use explicit data classifications, access controls, human oversight and monitoring. Cloud availability does not make AI outputs accurate or ethically acceptable.

Best practice is therefore not simply to “move to the cloud.” It is to select an appropriate operating model, establish accountability, automate safely, measure outcomes and continually test assumptions.

Chapter Summary

Cloud computing delivers pooled, network-accessible capabilities through on-demand provisioning, elasticity and measured service. Its architecture spans physical infrastructure, virtualisation, service platforms, applications and governance. IaaS provides the greatest infrastructure control, PaaS reduces platform administration, and SaaS provides complete applications; FaaS offers event-driven execution with additional constraints. Public, private, hybrid and multi-cloud deployments address different combinations of control, scale, integration and risk.

The shared-responsibility model requires customers to secure identities, data and configurations even when providers operate much of the underlying technology. Effective reference architectures integrate networking, identity, compute, storage, data services, observability, security and governance. Sound decisions consider reliability, RPO, RTO, cost, compliance, portability, skills and operational complexity. Cloud is a means of delivering computing capability, not a guarantee of security, resilience, low cost or good architecture.

Key Terms

Cloud computing: Network-based delivery of configurable computing resources.

Resource pooling: Sharing provider resources among multiple consumers with logical isolation.

Elasticity: Dynamic expansion and contraction of capacity as demand changes.

Scalability: Ability to handle increased workload by adding or improving resources.

Measured service: Monitoring and reporting resource consumption for control and billing.

IaaS: Delivery of virtualised infrastructure such as compute, storage and networking.

PaaS: Managed platform for developing and running applications.

SaaS: Complete application delivered to end users as a service.

FaaS: Event-triggered execution of provider-managed functions.

Public cloud: Cloud environment operated for multiple customers by a provider.

Private cloud: Cloud environment dedicated to one organisation.

Hybrid cloud: Interconnected use of distinct cloud or on-premises environments.

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

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

Availability: Proportion of an agreed period during which a service is operational.

Resilience: Ability to withstand failure or recover acceptably.

RPO: Maximum tolerable period of data loss measured in time.

RTO: Target time for service recovery after disruption.

Infrastructure as code: Version-controlled, automated definition of infrastructure.

Vendor lock-in: Difficulty or cost of changing provider, platform or service.

Review Questions

Short Answer Questions

1. What is meant by resource pooling in cloud computing?
2. Distinguish scalability from elasticity.
3. Identify two responsibilities normally retained by a SaaS customer.
4. What is the purpose of a Recovery Point Objective?
5. Name two characteristics of measured service.

Long Answer Questions

1. Compare IaaS, PaaS and SaaS in terms of control, responsibility, benefits and risks.
2. Explain the essential characteristics of cloud computing and show how they differ from traditional hosting.
3. Compare public, private, hybrid and multi-cloud deployment models.
4. Explain the shared-responsibility model and discuss how it changes across IaaS, PaaS and SaaS.
5. Describe a layered cloud reference architecture and explain the function of its major components.

Analytical / Application Questions

1. A university must host a student portal with seasonal peaks, sensitive records and a small IT team. Recommend a service and deployment model, justify your decision and identify three controls.
2. An organisation proposes using two public clouds solely to improve resilience. Critically evaluate the proposal and identify dependencies that must be tested.
3. Design a migration approach for a monolithic application that has poor peak performance, an RTO of four hours and an RPO of one hour. State assumptions, architecture choices and validation tests.

Multiple Choice Questions with Answers

Question 1

Which characteristic allows a consumer to provision computing resources without manually contacting provider staff?

A. On-demand self-service

B. Resource pooling

C. Measured service

D. Broad network access

Correct Answer: A. On-demand self-service

Question 2

Which cloud service model normally gives the customer control of the guest operating system?

A. SaaS

B. PaaS

C. IaaS

D. FaaS

Correct Answer: C. IaaS

Question 3

A system adds and removes application instances automatically as workload changes. This most directly demonstrates:

A. Portability

B. Elasticity

C. Data sovereignty

D. Vendor lock-in

Correct Answer: B. Elasticity

Question 4

Which deployment model combines distinct environments with mechanisms for interoperability?

A. Private cloud

B. Public cloud

C. Hybrid cloud

D. Single-tenant SaaS

Correct Answer: C. Hybrid cloud

Question 5

In the shared-responsibility model, which activity is generally the customer’s responsibility in every service model?

A. Replacing the provider’s physical disks

B. Managing the provider’s cooling system

C. Protecting customer identities and access rights

D. Patching the provider’s hypervisor

Correct Answer: C. Protecting customer identities and access rights

Question 6

A service has 99.9% availability over a 30-day month. Approximately how much downtime does this percentage allow?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 7

Which model is usually most suitable when an organisation wants to use a complete business application through a browser?

A. IaaS

B. PaaS

C. SaaS

D. Bare metal hosting

Correct Answer: C. SaaS

Question 8

What does an RPO of one hour specify?

A. The maximum target time to restart a server

B. The maximum acceptable amount of data loss measured in time

C. The maximum number of users per hour

D. The guaranteed duration of a maintenance window

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 9

Which architectural component distributes incoming requests across multiple application instances?

A. Load balancer

B. Object store

C. Key-management service

D. Archive vault

Correct Answer: A. Load balancer

Question 10

Which statement about multi-cloud is most accurate?

A. It automatically guarantees resilience against all failures

B. It eliminates the need for identity management

C. It may reduce provider dependence but increases operational complexity

D. It always costs less than using one provider

Correct Answer: C. It may reduce provider dependence but increases operational complexity