Cloud Service, Deployment and Architecture Models

Introduction and Context

Cloud computing is a foundational delivery model for modern artificial intelligence and machine learning (AI/ML). Training systems, inference APIs, data platforms, notebooks, model registries, and monitoring tools can all be obtained as cloud resources rather than built entirely in an organization’s own data centre. However, “the cloud” is not a single technology. It consists of service models, deployment models, architectural patterns, contractual arrangements, and operational responsibilities.

Selecting a cloud model is therefore an architectural and business decision. A data scientist may require rapid access to GPUs, while a regulated institution may require data sovereignty and dedicated infrastructure. A start-up may prefer a fully managed machine-learning platform, whereas a large enterprise may retain control over its operating systems and networking. Effective selection balances capability, control, cost, security, performance, portability, compliance, and organizational skills.

This chapter compares Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), managed AI services, and public, private, hybrid, community, and multi-cloud deployment models. It then introduces reference architectures and a workload-assessment framework for cloud selection and migration.

Learning Objectives

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

1. Explain the responsibilities and trade-offs associated with IaaS, PaaS, SaaS, and managed AI services.

2. Compare public, private, hybrid, community, and multi-cloud deployment models.

3. Identify the major layers of a cloud architecture for AI/ML workloads.

4. Assess workloads using technical, economic, organizational, and regulatory criteria.

5. Recommend a suitable service and deployment model for a given scenario.

6. Explain migration strategies, governance requirements, and limitations of cloud adoption.

1. Cloud Responsibility and Service Models

A service model describes how computing capability is packaged and which party manages each layer. The layers commonly include facilities, physical hardware, virtualization, networking, storage, operating systems, runtime environments, applications, and data. The customer never transfers all responsibility: security and data governance remain shared responsibilities even when a provider manages most technical layers.

1.1 Infrastructure as a Service

Infrastructure as a Service provides virtual machines, networks, block and object storage, load balancers, and related infrastructure primitives. The provider manages facilities, physical servers, core networking, and virtualization. The customer generally manages the operating system, installed software, runtime configuration, applications, identities, and much of the data protection.

IaaS is appropriate when an organization needs:

• detailed control over operating systems and networking;
• specialized drivers or libraries for GPUs and accelerators;
• support for legacy applications;
• custom security agents or unusual runtime configurations; or
• migration of existing servers with limited redesign.

For AI/ML, IaaS can support self-managed Kubernetes clusters, distributed training, custom CUDA environments, feature stores, and specialized inference servers. Its flexibility is accompanied by operational effort. Teams must patch systems, configure firewalls, manage images, plan capacity, monitor failures, and secure credentials. A virtual machine is not automatically secure simply because it runs in a cloud data centre.

1.2 Platform as a Service

Platform as a Service provides a managed application or development platform. The provider normally manages the operating system, runtime, scaling mechanisms, and much of the underlying infrastructure. Customers deploy code, configure services, and manage application logic and data.

Examples include managed application runtimes, managed databases, container platforms, serverless functions, data-processing platforms, and machine-learning development platforms. PaaS reduces infrastructure administration and can improve developer productivity. It is particularly useful when teams want to focus on model development and deployment rather than cluster maintenance.

The principal trade-off is reduced control. A platform may restrict supported frameworks, networking patterns, hardware types, operating-system settings, or deployment formats. PaaS can also create switching costs when applications depend on proprietary APIs.

1.3 Software as a Service

Software as a Service delivers a complete application through a browser, API, or client. The provider manages the application, infrastructure, upgrades, availability mechanisms, and much of the security implementation. Customers configure the service, manage users and permissions, and control the content and business processes placed in it.

Examples include hosted collaboration tools, customer relationship management systems, business intelligence applications, and some data-science workspaces. SaaS is valuable when an organization needs business functionality quickly without developing and operating the complete application.

For AI/ML teams, SaaS may provide annotation tools, experiment tracking, dashboards, governance systems, or automated business applications. The customer should nevertheless examine data retention, model-training rights, export capabilities, identity integration, service-level commitments, and the provider’s use of customer data.

1.4 Managed AI Services

Managed AI services are specialized cloud capabilities for machine learning and artificial intelligence. They may include:

• managed notebooks and development environments;
• training jobs using CPUs, GPUs, or other accelerators;
• model registries and artifact stores;
• automated hyperparameter tuning;
• managed batch and online inference;
• monitoring for latency, errors, drift, and data quality;
• pre-trained APIs for language, speech, vision, translation, and search; and
• foundation-model hosting or generative-AI APIs.

Managed AI services are often a specialized form of PaaS, although some are consumed like SaaS APIs. They reduce the work required to build an ML operations (MLOps) system. They may also offer elastic accelerator capacity, integrated identity, audit logging, and deployment automation.

Their limitations include opaque model behavior, variable pricing, provider-specific interfaces, limited access to low-level hardware, possible data-residency restrictions, and difficulty reproducing results when models or hosted dependencies change. Organizations must distinguish between using a managed service to train their own model and calling a provider-owned model through an API. These arrangements create different obligations regarding intellectual property, privacy, explainability, and portability.

1.5 Comparison of Service Models

The following general pattern is useful:

| Model | Customer control | Provider operational responsibility | Typical AI/ML use |

|---|---|---|---|

| IaaS | High | Physical infrastructure and virtualization | Custom clusters, legacy workloads, specialized training |

| PaaS | Medium | Infrastructure, OS, runtime, scaling platform | Managed training, databases, containers, pipelines |

| SaaS | Low at technical layers | Complete application and platform | Annotation, dashboards, collaboration, business AI |

| Managed AI service | Medium to low, depending on service | ML infrastructure and selected AI capabilities | Training, deployment, pre-trained models, monitoring |

These categories are not absolute. A managed Kubernetes service, for example, may expose many infrastructure choices while still automating control-plane operations. Service classification should therefore be based on actual responsibilities in the contract and architecture, not only on product labels.

2. Deployment Models

A deployment model describes where resources are hosted, who can use them, and how infrastructure is governed.

2.1 Public Cloud

A public cloud is operated by a provider and shared among multiple customers through logical isolation and access controls. Customers normally pay for consumption or subscription capacity. Public clouds offer broad geographic coverage, rapid provisioning, extensive managed services, and access to large accelerator pools.

Public cloud is attractive for variable workloads, experimentation, global applications, and organizations that do not want to operate data centres. Risks include dependence on provider availability, changing prices, egress charges, regional service limitations, and regulatory constraints. Multi-tenant infrastructure also requires careful isolation and assurance, even though reputable providers implement extensive hardware and software controls.

2.2 Private Cloud

A private cloud is dedicated to one organization. It may be operated by the organization or by a third party and may be located on-premises or externally. A private cloud can provide greater control over physical location, network design, specialized hardware, and regulatory processes.

Private cloud does not automatically mean cheaper or more secure. The organization must fund hardware, facilities, upgrades, capacity planning, skilled personnel, and resilience. A private environment that lacks automation, identity management, patching, and monitoring may be less secure than a mature public cloud.

2.3 Hybrid Cloud

Hybrid cloud combines private infrastructure with one or more public-cloud environments, connected through appropriate networking, identity, and data-management mechanisms. A workload may remain on private infrastructure while using public cloud for burst capacity, experimentation, disaster recovery, or selected managed services.

Hybrid design is useful when data cannot freely move to a public region, when existing investments must be retained, or when specialized systems are difficult to replace. Its major challenge is complexity. Identity federation, network latency, data synchronization, consistent policy, observability, and operational responsibility must work across boundaries.

2.4 Community Cloud

A community cloud is designed for organizations with shared objectives, policies, or compliance requirements. Examples may include public-sector institutions, universities, healthcare organizations, or research communities. The infrastructure may be operated by one member, a consortium, or a service provider.

Community clouds can support common governance and sector-specific requirements, but they may have a smaller service catalogue and less economic scale than large public clouds. Clear rules are required for membership, cost allocation, data ownership, incident response, and exit.

2.5 Multi-Cloud

Multi-cloud means using services from more than one public-cloud provider. It may be deliberate, such as placing a workload with the provider offering the best accelerator availability, or accidental, resulting from independent departmental purchases.

Potential benefits include negotiation leverage, access to specialized services, geographic coverage, resilience against provider-specific disruption, and avoidance of a single supplier’s limitations. Multi-cloud also increases complexity in identity, networking, monitoring, skills, data movement, security policy, and cost management. It is not equivalent to resilience: an application deployed in two clouds may still fail if both depend on the same identity provider, data source, model, or deployment pipeline.

3. Architectural Models for AI/ML Cloud Systems

A cloud architecture organizes components, data flows, trust boundaries, and operational controls. A useful AI/ML reference architecture contains the following logical layers.

3.1 Access and Governance Layer

Users and applications enter through identity and access management, single sign-on, role-based or attribute-based authorization, policy enforcement, audit logging, and secrets management. Governance also includes account or subscription structure, resource tagging, budgets, approval workflows, and separation of development, testing, and production environments.

Least privilege is a central principle: identities should receive only the permissions required for their tasks. Workload identities are preferable to embedding long-lived keys in code. Administrative access should be strongly authenticated and audited.

3.2 Data Ingestion and Storage Layer

Data may arrive through batch uploads, event streams, application databases, sensors, or external APIs. Object storage is commonly used for raw and curated datasets, while relational, key-value, graph, or analytical stores serve particular access patterns. A data catalogue records ownership, schema, lineage, quality, retention, and sensitivity.

For AI, the architecture should distinguish training data, validation data, test data, feature data, model artifacts, prompts, responses, and operational logs. Data leakage between these categories can produce misleading evaluation results or privacy violations.

3.3 Processing and Feature Layer

Processing services clean, transform, join, and validate data. Features may be computed in batch, online, or both. If training uses a different feature definition from inference, training-serving skew can occur. A feature-store pattern can reduce this risk by standardizing feature definitions and access, although it adds operational complexity.

3.4 Model Development and Training Layer

This layer includes notebooks, code repositories, experiment tracking, distributed training infrastructure, hyperparameter configuration, model evaluation, and artifact storage. Reproducibility requires versioning code, data references, configurations, dependencies, and random seeds where relevant. A model registry can record lineage, approval status, evaluation results, and deployment versions.

3.5 Serving and Application Layer

Models may be exposed through synchronous APIs, asynchronous queues, batch jobs, embedded applications, or edge devices. Online inference architecture must address latency, throughput, autoscaling, authentication, input validation, and fallback behavior. Batch inference is often more economical when immediate responses are unnecessary.

3.6 Operations and Observability Layer

Monitoring should cover infrastructure health, application errors, request latency, resource utilization, model quality, data drift, concept drift, and cost. Logs should be useful without collecting unnecessary personal data. Alerts need ownership and defined response procedures; collecting metrics without operational action does not constitute effective monitoring.

4. Workload Assessment and Cloud Selection

Cloud selection should begin with workload requirements rather than provider preference. A practical assessment considers the following dimensions.

4.1 Functional and Technical Fit

Identify the workload’s processing type, data volume, accelerator requirement, operating-system dependencies, storage pattern, network topology, integration points, availability target, recovery objectives, and performance constraints. Important questions include:

• Is the workload batch, interactive, streaming, or real-time?
• Does it require GPUs, high-memory nodes, or specialized accelerators?
• Can it tolerate interruption or delayed capacity?
• Are latency and data locality requirements strict?
• Does it depend on proprietary hardware or legacy protocols?

4.2 Data, Security, and Compliance Fit

Classify data according to sensitivity and legal obligations. Examine residency, cross-border transfer, encryption, key ownership, retention, deletion, access logging, contractual processing terms, and incident notification. AI systems require additional controls for prompts, generated outputs, training data provenance, model artifacts, and possible memorization of sensitive information.

A provider’s compliance certification is evidence of controls, not a substitute for the customer’s own risk assessment. Responsibility must be mapped explicitly between provider and customer.

4.3 Economic Fit

Cloud costs include compute, storage, requests, networking, managed-service fees, support, licenses, security tooling, observability, migration, and staff time. Data egress can be significant when large datasets or inference results move between regions or providers.

A simple total-cost model over a chosen period can be expressed as:

Total cost = direct service charges + migration cost + operation cost + risk or expected-loss cost.

The terms must be defined for the decision being made. Direct service charges may include compute and storage; operation cost includes engineering and administration; risk cost represents estimated financial impact of outages, non-compliance, or security incidents. This is a decision model, not a universal accounting identity, and estimates should use a stated time horizon and workload assumptions.

For variable workloads, consumption pricing may be advantageous. For predictable workloads, committed-use discounts or reserved capacity may reduce cost but create underutilization risk. Cost comparisons should use realistic utilization, not only the nominal hourly price.

4.4 Organizational Fit

Assess internal skills, support coverage, procurement constraints, operating-model maturity, and ability to respond to incidents. A technically optimal platform may fail if the organization cannot secure, monitor, and maintain it. Skills gaps can make a managed platform more appropriate than self-managed infrastructure.

4.5 Portability and Strategic Fit

Portability is affected by data formats, container standards, orchestration interfaces, model formats, APIs, identity integration, observability tools, and proprietary services. Portability is not free. Abstracting every service to avoid lock-in may reduce the performance and productivity benefits of specialized cloud capabilities.

A sensible strategy is selective portability: keep critical data and model artifacts in open or well-documented formats where practical, document provider-specific dependencies, and maintain tested export and recovery procedures.

5. Migration Strategies

Migration is a change to systems, data, processes, and responsibilities. Common strategies include:

• Rehost: move an application with minimal changes. This is rapid but may preserve inefficiency.
• Replatform: make limited changes to use managed databases, containers, or autoscaling.
• Refactor: redesign components to exploit cloud-native capabilities.
• Repurchase: replace an existing system with SaaS.
• Retain: keep a workload where it is because migration value is insufficient.
• Retire: remove an obsolete workload.

These strategies are not mutually exclusive across a portfolio. A legacy reporting application may be rehosted, while a model-training pipeline is refactored and an email system is repurchased as SaaS.

A responsible migration sequence generally includes discovery, dependency mapping, data classification, target architecture, pilot testing, security design, performance benchmarking, migration execution, validation, cutover, and post-migration optimization. Rollback criteria should be defined before cutover. For AI workloads, validation should compare not only system availability but also model accuracy, fairness indicators where applicable, latency, cost per prediction, and data lineage.

6. Worked Selection Example

An organization wants to deploy a demand-forecasting model. Training occurs weekly, requires GPUs for four hours, and uses confidential sales data. Inference runs every night in batch mode. The data must remain in a specified legal jurisdiction. The organization has a small ML team but an experienced infrastructure team.

A fully managed global AI API is unsuitable because it does not provide the required control over training data location and the workload uses a proprietary forecasting model. Pure SaaS is also unsuitable because the organization must control the model and data pipeline. IaaS can provide suitable GPUs and data-location control, but the ML team would need to manage much of the training environment. A managed regional ML platform is attractive if its contractual and technical controls satisfy residency requirements.

Because inference is nightly rather than real-time, batch execution can avoid the cost and operational burden of continuously running an online endpoint. A hybrid arrangement may be selected if sensitive source data remains in a private environment while de-identified or approved training extracts are processed in a public regional cloud. The final decision should be confirmed through a proof of concept measuring training duration, data-transfer time, cost, model reproducibility, security controls, and forecast quality.

The example illustrates that the “best” model depends on the intersection of workload characteristics and organizational constraints. No single service model is universally superior.

7. Illustrative Case Study: University Health Analytics Platform

Background

This illustrative case concerns a university hospital consortium developing a model to predict patient appointment non-attendance. The consortium has three hospitals, an existing private data centre, and a research group with limited production-operations experience.

Problem

The research group needs elastic compute for experimentation, while patient records are subject to strict privacy and governance requirements. The hospitals also require an auditable production process and the ability to discontinue a cloud provider if contractual conditions change.

Analysis

The raw identifiable records should remain within a controlled environment. Researchers require approved, de-identified datasets rather than unrestricted access to production records. The workload is periodic and computationally intensive during experimentation but modest during routine inference. A fully self-managed private GPU cluster would provide control but would be expensive and difficult to operate. A public cloud can provide elastic accelerators and managed ML tooling, but data transfer and provider contracts must be controlled.

Approach and Solution

The consortium adopts a hybrid architecture. Identifiable data is stored and governed in the private environment. A controlled pipeline creates de-identified datasets, records transformation lineage, and transfers approved datasets to a public-cloud region that satisfies residency requirements. Training runs in a managed ML environment using short-lived compute. Model artifacts are scanned, registered, and approved before deployment. Predictions are returned through a controlled interface, and production logs exclude unnecessary patient identifiers.

Identity is federated with hospital directories, while privileged operations require stronger authentication and approval. The architecture uses containers for preprocessing and stores model artifacts in a documented format where feasible. Exit procedures include exporting datasets, code, configurations, model artifacts, and audit records.

Outcome

The research group gains elastic experimentation without granting the public cloud unrestricted access to identifiable records. The hospitals retain governance over sensitive data, while the consortium accepts additional complexity in identity, networking, and data synchronization.

Learning Points

1. Hybrid architecture can separate sensitive data custody from elastic computation.

2. De-identification is a process requiring assessment; it is not a guarantee that re-identification is impossible.

3. Managed services reduce operations but do not remove governance responsibilities.

4. Portability requires deliberate documentation and tested exit procedures.

5. AI validation must include privacy, model performance, operational behavior, and fairness considerations.

8. Challenges, Governance, and Ethical Considerations

Cloud adoption can produce vendor lock-in, unpredictable bills, outages, performance variation, data-residency problems, and skills shortages. AI adds risks of biased outcomes, privacy leakage, opaque decisions, insecure prompts, model misuse, and generated content that is inaccurate or harmful.

Governance should define data ownership, approved services, model approval gates, human oversight, retention, incident response, access reviews, and acceptable use. Contracts should address service availability, support, audit rights, breach notification, subcontractors, data deletion, model-training use of customer data, and exit assistance.

Responsible architecture includes encryption in transit and at rest, network segmentation, least privilege, secure software supply chains, vulnerability management, reproducible deployment, input and output validation, and continuous monitoring. For high-impact decisions, technical controls should be supplemented by documented accountability and meaningful human review.

9. Contemporary Developments and Best Practices

Cloud platforms increasingly offer serverless inference, confidential computing, specialized AI accelerators, retrieval-augmented generation components, model gateways, and managed governance tools. These developments improve productivity but can increase dependence on proprietary interfaces and make cost and behavior more difficult to predict.

Best practices include:

• assess workloads before choosing a provider or service;
• separate development, testing, and production environments;
• use infrastructure as code and version-controlled deployment pipelines;
• apply least privilege and short-lived credentials;
• classify data and enforce residency and retention policies;
• benchmark real workloads, including data movement and cold-start effects;
• monitor quality, security, reliability, and cost together;
• maintain tested backup, recovery, and provider-exit procedures; and
• use managed services where they reduce undifferentiated work, while documenting proprietary dependencies.

Chapter Summary

Cloud service models distribute technical responsibility differently. IaaS provides control but requires substantial administration; PaaS reduces infrastructure work while limiting some choices; SaaS delivers complete applications; and managed AI services provide specialized capabilities for training, deployment, inference, and model operations. These categories overlap in practice, so actual responsibilities must be examined.

Public, private, hybrid, community, and multi-cloud models differ in ownership, access, control, scale, and complexity. AI architectures commonly include governance, data, processing, model development, serving, and observability layers. Workload selection should consider technical requirements, data and compliance, economics, organizational capability, portability, and strategic fit. Migration may involve rehosting, replatforming, refactoring, repurchasing, retaining, or retiring workloads.

A sound cloud decision is evidence-based and workload-specific. It uses pilots, realistic cost and performance measurements, explicit security responsibilities, and tested recovery and exit plans. For AI/ML, model quality, data lineage, fairness, privacy, and operational monitoring are as important as infrastructure availability.

Key Terms

Cloud computing: On-demand access to shared computing resources and services.

IaaS: A service model providing virtualized infrastructure resources such as machines, storage, and networks.

PaaS: A managed platform for developing and running applications without managing all underlying infrastructure.

SaaS: A complete software application delivered and operated by a provider.

Managed AI service: A cloud service that provides specialized machine-learning or artificial-intelligence capabilities.

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

Private cloud: Cloud infrastructure dedicated to one organization.

Hybrid cloud: An integrated arrangement combining private and public cloud environments.

Community cloud: Infrastructure designed for organizations sharing sectoral or policy requirements.

Multi-cloud: Deliberate use of services from multiple cloud providers.

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

MLOps: Practices for developing, deploying, monitoring, and governing machine-learning systems.

Model registry: A managed repository recording model versions, metadata, lineage, and approval status.

Training-serving skew: Difference between feature processing used during training and that used during inference.

Data residency: The geographic location in which data is stored or processed.

Rehost: Migrating a workload with minimal modification.

Refactor: Redesigning a workload to exploit cloud-native capabilities.

Vendor lock-in: Difficulty or cost associated with changing providers or technologies.

Data egress: Data transferred out of a cloud service or region, often subject to charges.

Infrastructure as code: Declarative or programmatic management of infrastructure configurations.

Review Questions

Short Answer Questions

1. What are the principal customer responsibilities in an IaaS environment?

2. How does PaaS differ from SaaS in terms of customer control?

3. Define hybrid cloud and identify one reason for using it.

4. What is training-serving skew?

5. Why should cloud selection include organizational skills and support capability?

Long Answer Questions

1. Compare IaaS, PaaS, SaaS, and managed AI services for an AI product lifecycle.

2. Explain the benefits and limitations of public, private, hybrid, community, and multi-cloud deployment models.

3. Describe a reference architecture for a production machine-learning system.

4. Explain the major factors in a workload-assessment framework for cloud selection.

5. Discuss governance, privacy, security, and portability issues in managed AI services.

Analytical / Application Questions

1. A start-up has a small operations team, highly variable demand, and no regulatory restriction on its customer-support chatbot. Recommend a service and deployment model, and justify your decision.

2. A bank must keep identifiable transaction data in its own controlled environment but needs occasional large-scale model training. Design a suitable hybrid architecture and identify two major risks.

3. An organization is considering multi-cloud deployment solely to improve resilience. Analyze why this may fail and propose the dependencies and tests that should be examined before proceeding.

Multiple Choice Questions with Answers

Question 1

Which service model gives the customer the greatest control over the operating system and installed runtime?

A. SaaS

B. PaaS

C. IaaS

D. Community cloud

Correct Answer: C. IaaS

Question 2

Which deployment model combines private infrastructure with one or more public-cloud environments?

A. Hybrid cloud

B. Community cloud

C. Private cloud

D. SaaS

Correct Answer: A. Hybrid cloud

Question 3

Which is a typical benefit of a managed AI service?

A. Elimination of all governance duties

B. Reduced effort for model training and deployment infrastructure

C. Guaranteed portability across every provider

D. No dependence on provider APIs

Correct Answer: B. Reduced effort for model training and deployment infrastructure

Question 4

What does training-serving skew describe?

A. Different cloud prices between regions

B. A mismatch between training-time and inference-time feature processing

C. A failure of physical storage hardware

D. A difference between public and private clouds

Correct Answer: B. A mismatch between training-time and inference-time feature processing

Question 5

Which migration strategy involves replacing an existing system with a hosted software product?

A. Rehost

B. Retain

C. Refactor

D. Repurchase

Correct Answer: D. Repurchase

Question 6

Which cost may arise when large datasets are transferred out of a cloud provider or region?

A. Data egress cost

B. Model registry cost only

C. Identity federation cost only

D. De-identification accuracy cost

Correct Answer: A. Data egress cost

Question 7

Why might batch inference be preferred to online inference?

A. It always produces more accurate models

B. It avoids the need for any data validation

C. It can be more economical when immediate responses are unnecessary

D. It eliminates the need for model monitoring

Correct Answer: C. It can be more economical when immediate responses are unnecessary

Question 8

Which principle gives identities only the permissions needed for their tasks?

A. Least privilege

B. Repurchase

C. Elasticity

D. Data locality

Correct Answer: A. Least privilege

Question 9

Which deployment model is specifically intended for organizations sharing sectoral or policy requirements?

A. Public cloud

B. Community cloud

C. Multi-cloud

D. IaaS

Correct Answer: B. Community cloud

Question 10

Which statement about multi-cloud is most accurate?

A. It automatically guarantees resilience

B. It always costs less than single-cloud deployment

C. It can increase provider diversity but also operational complexity

D. It means using only private infrastructure

Correct Answer: C. It can increase provider diversity but also operational complexity