9. Cloud Data Science and Platform Services

Introduction and context

Cloud computing has changed data science from an activity dependent on locally installed software and departmental servers into a distributed discipline supported by elastic infrastructure, managed services, and collaborative platforms. A data scientist may now store petabytes of data in object storage, execute distributed transformations on demand, train a model using specialized accelerators, deploy it through an API, and monitor its performance without owning the underlying hardware.

This change is not merely technical. Cloud adoption affects architecture, operating costs, security responsibilities, team structure, governance, and the speed at which analytical ideas become operational products. A cloud platform can reduce the time required to provision infrastructure, but it can also create dependence on proprietary interfaces, unpredictable expenditure, and complex regulatory obligations. Consequently, selecting cloud services is an architectural and managerial decision, not simply a procurement decision.

This chapter examines the principal cloud services used in data science: storage, computation, databases, managed analytics, machine learning, and deployment platforms. It also provides criteria for comparing public, private, hybrid, and multi-cloud approaches. The focus is on the reasoning required to design a reliable, economical, interoperable, and governable cloud data science environment.

Learning objectives

After studying this chapter, students should be able to:

1. Explain the role of cloud storage, compute, databases, analytics platforms, and managed AI services in a data science lifecycle.

2. Distinguish infrastructure as a service, platform as a service, and software as a service.

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

4. Select cloud services using scalability, resilience, cost, interoperability, security, governance, and vendor-lock-in criteria.

5. Design a high-level cloud architecture for an analytical or machine-learning workload.

6. Identify operational, ethical, regulatory, and financial risks in cloud data science.

7. Evaluate emerging developments such as serverless analytics, lakehouse architectures, confidential computing, and generative AI platforms.

Cloud as an operating model for data science

Cloud computing provides on-demand access to configurable computing resources that can be provisioned and released with limited direct interaction with hardware. Its most important characteristics for data science are elasticity, self-service provisioning, network accessibility, resource pooling, measured usage, and automation.

Elasticity is especially valuable for analytical workloads. A development environment may require only a small virtual machine, whereas a model-training job may temporarily need hundreds of processing units or graphics accelerators. Cloud platforms allow capacity to expand for the job and contract afterward. This avoids maintaining peak capacity permanently, although it does not guarantee low cost: poorly controlled workloads can consume resources continuously.

A cloud data science environment normally contains several layers. Data is ingested from operational systems, devices, applications, or external sources. It is stored in object stores, databases, or analytical warehouses. Processing services clean and transform it. Notebooks and development environments support exploration. Training services create models, while deployment services expose predictions through batch jobs, APIs, or embedded applications. Monitoring, identity, governance, and cost-management services operate across all these layers.

The cloud shared-responsibility model is fundamental. The provider generally secures the physical facilities, underlying network, and basic managed service infrastructure. The customer remains responsible for matters such as identity configuration, data classification, access permissions, encryption choices, code, model behavior, and regulatory use. The exact division varies by service. A managed database removes much administrative work, but it does not make an incorrectly configured database secure.

Service models and levels of abstraction

Infrastructure as a Service (IaaS) supplies virtual machines, networks, storage volumes, and related infrastructure. Users control operating systems, installed libraries, runtime configuration, and applications. IaaS offers flexibility and portability but requires responsibility for patching, scaling logic, hardening, and operational support. It is appropriate when workloads require specialized configurations or legacy software.

Platform as a Service (PaaS) provides a managed environment for developing and running applications, data pipelines, databases, or machine-learning workflows. The provider manages more of the operating system and runtime. PaaS can improve developer productivity and standardization, although platform-specific APIs may make later migration difficult.

Software as a Service (SaaS) delivers a complete application through a subscription or usage model. Examples include hosted business intelligence, collaboration, customer analytics, and model-monitoring applications. SaaS minimizes infrastructure administration but provides the least control over architecture, data location, and customization.

Serverless services are a related abstraction in which users submit functions, queries, or jobs without managing persistent servers. They can be highly efficient for irregular workloads and event-driven pipelines. However, cold-start delays, execution limits, opaque pricing, and provider-specific interfaces may restrict their suitability for long-running or highly predictable workloads.

Storage: from files to analytical data estates

Cloud object storage is the foundation of many data platforms. It stores objects—usually files and associated metadata—in a highly durable, addressable repository. It is well suited to raw data, logs, images, documents, feature datasets, model artifacts, and backups. Object storage separates storage capacity from compute capacity, allowing different analytical engines to use the same data.

A common pattern is the data lake. Raw data is retained in its original or near-original form, while cleaned and curated datasets are created for analysis. This supports exploratory work and future use cases that were not anticipated when data was first collected. A lake, however, can become a “data swamp” if files lack ownership, metadata, quality rules, naming conventions, and lifecycle management.

Data warehouses provide structured, governed environments optimized for SQL analytics and reporting. They traditionally use schemas designed before data is loaded, although modern warehouses increasingly support semi-structured data. A lakehouse combines low-cost, flexible storage with warehouse-like transaction management, schema enforcement, cataloguing, and performance features. The distinction is architectural rather than absolute; many platforms now provide overlapping capabilities.

Storage design should address:

• Data format: Columnar formats such as Parquet often reduce analytical I/O compared with row-oriented formats.
• Partitioning: Organizing data by frequently filtered attributes can improve query performance, but excessive partitions create metadata overhead.
• Lifecycle: Infrequently accessed data can be moved to lower-cost storage tiers, subject to retrieval requirements.
• Durability and availability: Durability concerns whether data is preserved; availability concerns whether it can be accessed when required.
• Metadata and lineage: Catalogues should identify owners, definitions, sensitivity, quality, and transformations.
• Deletion and retention: Retention schedules must support legal obligations and legitimate deletion requests.

Data movement also matters. Transferring large volumes between regions or providers can incur financial charges, latency, and security exposure. A design that appears inexpensive at rest may become costly if every analytical service repeatedly copies the same data.

Compute for exploration, engineering, and training

Cloud compute includes virtual machines, containers, clusters, batch systems, serverless functions, and specialized accelerators. The appropriate choice depends on workload duration, repeatability, latency, software control, and scale.

Virtual machines provide familiar control and are useful for development servers, custom applications, and software that cannot easily be containerized. Containers package code and dependencies consistently and are commonly orchestrated through Kubernetes or a managed equivalent. They improve portability, but operating a container platform still requires expertise in networking, security, image management, scheduling, and observability.

Distributed processing engines divide data or computation across multiple workers. They are useful for large transformations, feature engineering, and some training algorithms. Distribution introduces overhead, so a large cluster is not automatically faster or cheaper than a well-designed single-node job. Partition skew, excessive data shuffling, poor serialization, and repeated reading from storage can reduce performance.

Graphics processing units and other accelerators can substantially reduce training time for deep-learning workloads. Their economic value depends on utilization. Keeping expensive accelerators running while a team is inactive is wasteful; queues, autoscaling, checkpointing, and scheduled shutdowns can improve efficiency. Spot or preemptible capacity may lower costs for fault-tolerant jobs, but interruptions must be anticipated.

Interactive notebooks are valuable for investigation and communication, yet they can produce irreproducible analysis when users rely on hidden state, manually installed packages, or undocumented data versions. Professional environments should combine notebooks with version control, parameterized pipelines, environment specifications, code review, and automated tests.

Cloud databases and analytical engines

Different data structures require different persistence technologies. Relational databases support transactions, constraints, and structured relationships. They are appropriate for operational applications and curated analytical data with stable schemas. NoSQL systems—including key-value, document, wide-column, and graph databases—offer alternatives for high-scale access patterns or flexible structures, but they require careful data modelling around application queries.

Analytical warehouses optimize scans, aggregations, concurrency, and SQL workloads. Data lake query engines allow analysts to query files directly, often separating storage from computation. Stream-processing systems handle events continuously and support low-latency detection, monitoring, and personalization. A data scientist should therefore begin with access patterns and consistency requirements rather than selecting a database because it is fashionable.

Important design questions include whether transactions are required, how quickly data must be available, whether workloads are batch or streaming, how many users will query concurrently, and whether data must remain in a particular jurisdiction. Managed services reduce administration but may impose proprietary storage formats, query dialects, limits, or migration costs.

Managed analytics and machine-learning services

Managed analytics services commonly provide data ingestion, orchestration, transformation, SQL querying, distributed processing, dashboarding, and governance. They can standardize development and allow teams to focus on analytical questions rather than server maintenance. Their value is highest when they integrate identity, catalogues, monitoring, and deployment controls.

Managed machine-learning platforms typically cover several stages of the machine-learning lifecycle:

1. Preparation: data labelling, cleansing, feature engineering, and dataset versioning.

2. Experimentation: notebooks, distributed training, hyperparameter tuning, and experiment tracking.

3. Registry: storage of approved model versions, metadata, evaluation results, and ownership.

4. Deployment: batch scoring, real-time endpoints, edge deployment, or embedded inference.

5. Operations: monitoring of latency, errors, input drift, prediction drift, and business outcomes.

6. Governance: approval workflows, explainability records, access controls, and audit trails.

AutoML can search algorithms, features, and hyperparameters, making experimentation accessible and faster. It does not remove the need to define the target correctly, assess data quality, check fairness, or interpret results. A highly accurate model can still be inappropriate if its predictions are not actionable or if its training data reflects discriminatory practices.

Cloud AI services also include pre-trained language, vision, speech, translation, search, and generative models. These services can accelerate prototyping, but organizations must examine data-use terms, retention, model updates, hallucination risk, intellectual-property questions, prompt injection, and the possibility that sensitive information will be exposed through inputs or outputs.

Architectural patterns for cloud data science

A useful reference architecture begins with governed ingestion. Batch files and application events enter a landing zone, where checks validate format, provenance, and malware status. Data is stored in a raw layer and then transformed into trusted and consumption layers. A catalogue records schemas, classifications, ownership, lineage, and quality indicators.

Analysts and data scientists access curated data through SQL engines, notebooks, or feature stores. Training pipelines retrieve versioned datasets, produce reproducible artifacts, evaluate models against technical and business criteria, and register approved versions. Deployment may use a real-time endpoint for low-latency decisions or batch scoring for periodic reports. Monitoring feeds operational and governance information back into the platform.

Infrastructure as code describes networks, permissions, storage, and compute in version-controlled files. Continuous integration and continuous delivery can test pipeline code, scan images, validate configurations, and promote models through development, staging, and production. This practice reduces configuration drift and makes environments more reproducible.

A practical design principle is to separate data, control, and compute planes. Data planes hold and process information; control planes manage policies, identities, orchestration, and metadata. This separation improves security and allows compute services to change without necessarily moving data.

Comparing deployment models

A public cloud uses provider-owned infrastructure shared among customers through logical isolation. It offers rapid provisioning, broad service choice, and global reach. It is often suitable for variable workloads and organizations that do not want to operate large data centres. Its disadvantages may include ongoing consumption charges, regulatory concerns, and dependence on provider-specific services.

A private cloud is dedicated to one organization, either on its own premises or hosted by another party. It can support particular compliance, sovereignty, latency, or customization requirements. It generally demands greater capital, operational expertise, and responsibility for capacity management.

A hybrid cloud combines private and public environments. Sensitive systems may remain under tighter organizational control while elastic analytics runs in a public environment. Hybrid designs are powerful but difficult: identity federation, networking, data synchronization, consistent policy, and monitoring must work across boundaries.

A multi-cloud strategy uses services from more than one public provider. It may improve bargaining power, regional coverage, resilience, or access to specialized capabilities. However, genuine portability is costly. Different identity systems, APIs, data formats, networking models, and operational tools can increase complexity. Multi-cloud should be adopted for a clear business or risk reason rather than as an assumption that duplication automatically creates resilience.

The following criteria provide a disciplined comparison:

| Criterion | Questions to ask |

|---|---|

| Scalability | Can capacity expand and contract with workload demand? |

| Resilience | What happens when a zone, region, service, or provider fails? |

| Cost | What are storage, compute, transfer, licensing, support, and personnel costs? |

| Interoperability | Can data and workloads use open formats, standard interfaces, and portable tools? |

| Vendor lock-in | How difficult and expensive would migration be? |

| Security | Are identity, encryption, isolation, logging, and response capabilities adequate? |

| Governance | Can the organization enforce retention, lineage, access, and audit requirements? |

| Performance | Are latency, throughput, concurrency, and locality suitable? |

Total cost of ownership should include engineering time, monitoring, support, egress, downtime, migration, training, and compliance—not only the advertised unit price. FinOps practices connect cloud consumption to budgets, owners, forecasts, and business value. Useful controls include tagging, budgets, quotas, anomaly alerts, rightsizing, scheduled shutdowns, and review of idle resources.

Security, governance, and responsible use

Cloud security begins with identity. Least privilege, role separation, strong authentication, short-lived credentials, and periodic access reviews reduce the risk of unauthorized use. Secrets should be stored in managed secret systems rather than notebooks or source code. Network segmentation, private endpoints, encryption in transit and at rest, key management, vulnerability scanning, and centralized logging provide additional controls.

Data governance should classify information according to sensitivity and define who may collect, use, share, retain, and delete it. Personally identifiable information, health records, financial data, and confidential business information may be subject to different legal duties. Data residency and cross-border transfer rules can affect architectural choices. Contracts should clarify provider access, incident notification, subprocessors, deletion, audit rights, and service continuity.

Responsible data science extends beyond infrastructure security. Teams should document data provenance, consent or legal basis, intended use, limitations, model assumptions, evaluation populations, and known failure modes. Fairness testing should be appropriate to the decision context, and human review may be necessary for high-impact decisions. Generative AI systems require additional controls for confidential prompts, fabricated content, harmful outputs, and unauthorized automated action.

Illustrative case: a regional hospital network

Background

This illustrative case concerns a regional hospital network that operates several hospitals and clinics. It wants to predict appointment non-attendance and identify patients who may require additional follow-up. Data exists in electronic health-record systems, scheduling databases, laboratory systems, and patient communications platforms.

Situation and problem

The existing approach consists of manually exported spreadsheets and a server used by a small analytics team. Processing is slow, data definitions differ between hospitals, and the organization cannot reliably reproduce earlier reports. Patient data is highly sensitive, and clinical leaders require explanations and an audit trail before using predictions operationally.

Analysis

The workload includes periodic batch ingestion, exploratory analysis, model training, and daily scoring. It does not initially require millisecond-level predictions. The organization needs strong access control, encryption, regional data residency, retention policies, and separation between development and production. A fully public, unmanaged environment would create unacceptable governance risk, while a wholly private platform might delay implementation and require substantial capital investment.

Approach and solution

The network adopts a hybrid design. Identifiable source data remains in a controlled environment, while a governed cloud analytics environment receives approved, minimized datasets through encrypted connections. Object storage holds versioned raw and curated data. A managed warehouse supports reporting, and an orchestration service schedules ingestion and validation. A managed machine-learning service tracks experiments and registers models, but deployment requires approval by clinical, legal, and information-security representatives.

The first model is deployed as a daily batch process rather than a real-time service. Its outputs are presented as prioritization signals, not clinical diagnoses. The design uses role-based access, data masking in development, immutable audit logs, model documentation, drift monitoring, and a process for clinicians to report harmful or incorrect recommendations. Costs are controlled through scheduled compute, storage lifecycle policies, and resource tagging.

Outcome

The architecture improves reproducibility and reduces manual data preparation. More importantly, it establishes a controlled route from data collection to operational use. The organization postpones a multi-cloud design because the additional networking and governance complexity is not justified by the initial use case. It retains open data formats and documented interfaces to preserve future options.

Learning points

The case demonstrates that the best architecture is determined by risk, workload, and organizational capability rather than by the maximum number of available cloud services. Batch inference may be more appropriate than real time; hybrid deployment may be justified by sensitivity; and model governance must be designed before, not after, production deployment.

Challenges and common mistakes

Cloud migration frequently fails when organizations move poorly designed workloads without redesigning them. Common mistakes include storing sensitive data in public locations, granting broad administrative permissions, ignoring data-transfer charges, running idle notebooks, selecting a service without an exit plan, and assuming that managed services eliminate governance responsibilities.

Another error is treating scalability as a substitute for architecture. More compute cannot correct duplicated data, poor partitioning, unbounded queries, or weak data contracts. Teams also underestimate observability. A pipeline may be technically available while producing stale or incomplete data. Monitoring must therefore include freshness, completeness, schema changes, lineage, cost, and business outcomes.

Portability has a cost. Using only generic tools may reduce lock-in but sacrifice productivity or specialized capability. Conversely, deeply integrating proprietary services may deliver speed and performance while increasing migration risk. The appropriate decision depends on the strategic importance of the workload, expected lifetime, switching costs, and the organization’s negotiating position.

Current developments and best practices

Cloud platforms increasingly support lakehouse table formats, unified catalogues, vector search, serverless data processing, and automated governance. Confidential computing aims to protect data while it is being processed through hardware-supported trusted execution environments. Edge-cloud architectures move selected inference or preprocessing closer to devices when latency, connectivity, or privacy requires it.

Generative AI is being incorporated into managed platforms for coding, data preparation, document analysis, conversational querying, and model assistance. Its use should be governed by evaluation datasets, human review, access restrictions, prompt and output logging where lawful, and explicit controls against sensitive-data leakage.

Effective practice includes the following:

• design security, identity, and governance before loading production data;
• use open formats, documented APIs, and versioned infrastructure where practical;
• separate experimentation from production and require controlled promotion;
• automate quality checks, testing, lineage, monitoring, and rollback;
• measure total cost and assign resources to accountable owners;
• select batch, streaming, serverless, container, or accelerator compute according to workload characteristics;
• create an exit strategy for important data and models;
• review architecture periodically as usage, regulation, and provider pricing change.

Chapter Summary

Cloud data science combines elastic infrastructure with managed services for storage, computation, databases, analytics, machine learning, deployment, and monitoring. Object storage supports flexible data lakes, warehouses support governed SQL analysis, and lakehouse designs seek to combine flexibility with transactional and analytical controls. Virtual machines, containers, distributed engines, serverless functions, and accelerators serve different workload requirements.

IaaS, PaaS, SaaS, and serverless services represent increasing levels of provider-managed abstraction. Public, private, hybrid, and multi-cloud models offer different balances of control, agility, resilience, cost, and complexity. Sound selection requires evaluation of scalability, resilience, total cost of ownership, interoperability, security, governance, performance, and vendor lock-in. Cloud responsibility remains shared: providers operate foundational infrastructure, while customers remain accountable for data, identity, configuration, code, and responsible use.

A mature cloud data science platform uses versioned data, automated pipelines, managed identity, infrastructure as code, model registries, monitoring, cost controls, and governance. Emerging capabilities such as lakehouses, confidential computing, edge processing, vector search, and generative AI expand possibilities but also introduce new operational and ethical risks.

Key Terms

Cloud computing: On-demand access to shared configurable computing resources over a network.

Elasticity: The ability to increase or decrease resources in response to workload demand.

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

PaaS: A managed environment for developing and running applications or analytical workloads.

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

Object storage: A repository that stores files as objects with metadata and unique addresses.

Data lake: A scalable store retaining data in diverse formats, often including raw data.

Data warehouse: A structured analytical repository optimized for SQL queries and reporting.

Lakehouse: An architecture combining flexible lake storage with warehouse-style management and performance.

Data catalogue: A governed inventory describing datasets, ownership, schemas, sensitivity, and lineage.

Serverless computing: Execution in which users submit functions, queries, or jobs without managing servers.

Container: A packaged application and its dependencies designed to run consistently across environments.

Autoscaling: Automatic adjustment of computing capacity according to demand.

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

Model registry: A controlled repository for model versions, metadata, evaluation results, and approvals.

Data drift: Change in the statistical properties of input data over time.

Vendor lock-in: Dependence on a provider that makes migration difficult or expensive.

FinOps: Organizational practices for managing cloud expenditure in relation to business value.

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

Infrastructure as code: Management of infrastructure through version-controlled, executable definitions.

Review Questions

Short Answer Questions

1. Why is elasticity valuable for cloud-based data science?

2. Distinguish object storage from a data warehouse.

3. What responsibilities remain with a customer under the shared-responsibility model?

4. Define vendor lock-in and identify one cause of it.

5. What functions does a model registry perform?

Long Answer Questions

1. Explain how storage, compute, databases, orchestration, and model deployment interact in a cloud data science lifecycle.

2. Compare IaaS, PaaS, SaaS, and serverless computing in terms of control, responsibility, and portability.

3. Discuss the architectural and managerial differences between public, private, hybrid, and multi-cloud deployment models.

4. Explain how total cost of ownership should be calculated for a cloud analytics platform.

5. Discuss security, governance, and responsible-use requirements for managed machine-learning services.

Analytical / Application Questions

1. A company runs monthly forecasting jobs that require substantial compute for six hours but little capacity during the rest of the month. Which cloud design would you recommend, and what cost controls would you apply?

2. An organization wants to place sensitive customer records in a public cloud while using a provider-specific machine-learning service. Analyse the benefits, risks, governance controls, and lock-in implications.

3. Design a high-level cloud architecture for a retailer receiving both daily sales files and continuous online events. Justify your choices of storage, processing, databases, deployment mode, and monitoring.

22. Multiple Choice Questions with Answers

Question 1

A data science team has highly variable training workloads and wants computing capacity to fall automatically when experiments finish. Which cloud characteristic is most directly relevant?

A. Elasticity

B. Data residency

C. Schema enforcement

D. Vendor lock-in

Correct Answer: A. Elasticity

Question 2

Which service is generally most appropriate for retaining raw images, logs, and model artifacts in diverse file formats?

A. Relational operational database

B. Object storage

C. Transaction processing queue

D. Identity directory

Correct Answer: B. Object storage

Question 3

A company uses a managed database but grants unrestricted public access to it. Which statement is most accurate?

A. The provider is solely responsible for the resulting exposure

B. Managed services eliminate the need for access controls

C. The customer has misconfigured a responsibility that remains with it

D. Public access improves resilience without security consequences

Correct Answer: C. The customer has misconfigured a responsibility that remains with it

Question 4

Which deployment model is most appropriate when sensitive systems must remain under organizational control while elastic analytics uses public-cloud capacity?

A. Private-only cloud

B. Hybrid cloud

C. SaaS-only deployment

D. Edge-only deployment

Correct Answer: B. Hybrid cloud

Question 5

Which practice most directly reduces irreproducibility in notebook-based machine learning?

A. Allowing analysts to install packages manually without records

B. Removing version control to speed experimentation

C. Using versioned data, environment specifications, and automated pipelines

D. Running every notebook on the largest available cluster

Correct Answer: C. Using versioned data, environment specifications, and automated pipelines

Question 6

A team repeatedly copies large datasets between cloud regions and providers. Which cost and design issue should it investigate first?

A. Data-transfer or egress charges and unnecessary movement

B. The colour scheme of dashboards

C. The number of model features only

D. Whether object storage supports metadata

Correct Answer: A. Data-transfer or egress charges and unnecessary movement

Question 7

What is the principal purpose of a model registry?

A. To replace all data-quality checks

B. To store approved model versions and their metadata and evaluation history

C. To provide physical security for cloud data centres

D. To guarantee that a model is fair

Correct Answer: B. To store approved model versions and their metadata and evaluation history

Question 8

For a hospital model that produces a daily prioritization list and does not require millisecond responses, which deployment approach is most suitable initially?

A. Daily batch inference

B. Continuous real-time inference regardless of need

C. Manual spreadsheet entry without audit records

D. Unrestricted public API access

Correct Answer: A. Daily batch inference

Question 9

Which criterion specifically addresses how difficult it would be to move a workload away from a provider?

A. Availability

B. Interoperability and vendor lock-in

C. Latency only

D. Data freshness only

Correct Answer: B. Interoperability and vendor lock-in

Question 10

Why should a generative-AI cloud service be evaluated for prompt and output handling?

A. Generative models never require governance

B. Prompts may contain sensitive information and outputs may be inaccurate or harmful

C. Cloud services cannot log requests

D. Model outputs are automatically legally approved

Correct Answer: B. Prompts may contain sensitive information and outputs may be inaccurate or harmful