10  Cloud Computing for Data Science

10.1 Cloud Platforms for Data Science

As your projects grow in size and complexity, you may need more computing power than your local machine can provide, or somewhere to keep data that isn’t one laptop’s hard drive. Cloud platforms rent both by the hour, along with a set of tools built specifically for this kind of work.

10.1.1 Why Use Cloud Platforms?

The case comes down to renting rather than owning. You can have a machine with 256 GB of memory for the afternoon you need one and stop paying for it at five, instead of buying hardware that then sits idle for most of the year. The same goes for GPUs and TPUs — processors built for the parallel arithmetic that training a neural network needs, and much faster at it than an ordinary CPU — which are expensive to own and easy to rent by the hour.

Two things come along with that. Storage that isn’t one laptop’s disk, so a dataset survives the laptop and a colleague can reach it. And managed services, where the provider runs the database or the notebook server and you don’t.

10.1.2 Getting Started with Google Colab

Colab gives you a Python notebook running on Google’s machines, with optional GPU and TPU access, free. It’s the cheapest place to start, since there’s nothing to install and no card to enter.

  1. Visit Google Colab
  2. Sign in with your Google account
  3. Click “New Notebook” to create a new notebook

It is Jupyter with the common data science libraries already installed, a GPU behind a dropdown, and sharing that works like a Google Doc. The limits are real — sessions time out, and free GPU access is rationed when demand is high — but for learning, for a one-off training run, or for handing someone a notebook they can run without installing anything, it is hard to beat.

10.1.3 Basic Cloud Storage Options

For a few gigabytes, the consumer services you already have will do: Google Drive mounts directly into Colab, OneDrive and Dropbox sync to a folder, and GitHub takes code and small reference datasets provided no single file is over 100 MB. Free allowances differ and change; check the current one rather than a figure printed anywhere, including here.

Past that, you want object storage built for the job — Amazon S3, Google Cloud Storage, Azure Blob Storage. These hold terabytes without complaint, are reachable from code rather than a sync folder, and charge by what you store and what you pull back out. The egress note below is the part that catches people.

10.1.4 The Major Cloud Platforms

For more advanced needs, consider these major cloud platforms:

10.1.4.1 Amazon Web Services (AWS)

The largest provider, with a correspondingly large catalogue. The services relevant here:

  • SageMaker: Managed Jupyter notebooks with integrated ML tools
  • EC2: Virtual machines for customised environments
  • S3: Scalable storage for datasets
  • Redshift: Data warehousing
  • Lambda: Serverless computing — you upload a function rather than running a server, and AWS starts it on demand, runs it, and bills you for the milliseconds it was executing. Useful for data processing triggered by an event, such as a file landing in S3

AWS offers a free tier that includes limited access to many of these services, allowing you to experiment before committing financially.

10.1.4.2 Google Cloud Platform (GCP)

GCP provides similar capabilities:

  • Vertex AI: End-to-end machine learning platform
  • Compute Engine: Virtual machines
  • BigQuery: Serverless data warehousing
  • Cloud Storage: Object storage
  • Dataproc: Managed Spark and Hadoop

10.1.4.3 Microsoft Azure

Azure is particularly well-integrated with Microsoft’s other tools:

  • Azure Machine Learning: End-to-end ML platform
  • Azure Databricks: Spark-based analytics
  • Azure Storage: Various storage options
  • Azure SQL Database: Managed SQL
  • Power BI: Business intelligence and visualisation

Each platform has its strengths, and many organisations use multiple clouds for different purposes. AWS has the broadest service catalogue. GCP’s machine learning tooling is the most developed of the three. Azure is the path of least resistance if your organisation already runs on Microsoft.

10.1.5 Choosing the Right Cloud Services

For most readers the choice is already made: use whatever your organisation pays for, because the account, the billing, and the person who can grant you permissions all exist there already. Where you do have a choice, the deciding factor is usually which provider’s documentation you can follow without getting stuck.

One consideration overrides preference. Where your data physically lives matters legally. Personal data about EU residents falls under GDPR; South African personal data falls under POPIA; similar laws exist in most jurisdictions. Pick a region in the right country or economic area for your data subjects, and check whether your employer or client has contractual restrictions on where data can be stored or processed. AWS, GCP and Azure all have regions in both South Africa and Europe.

Start with a small project on your chosen platform, so you learn the environment before committing a real workload to it.

10.1.6 Getting Started with a Cloud Platform

Let’s create a basic starter project on AWS as an example:

  1. Sign up for an AWS account
  2. Navigate to SageMaker AI → Studio in the AWS console
  3. Create a Studio domain (for personal use, pick “Quick setup”)
  4. Open Studio and launch a JupyterLab space, choosing a small instance type such as ml.t3.medium. Check what your account’s current free-tier terms cover before you start it — see the note on free tiers below
  5. Start the space, open JupyterLab, create a notebook, and start working

This gives you a fully configured Jupyter environment with access to more computational resources than your local machine likely has. SageMaker comes pre-installed with popular data science libraries and integrates with other AWS services like S3 for storage.

WarningShut it down when you’re done

Studio spaces and notebook instances bill by the minute they’re running, not by how much you use them. A notebook left running over a weekend is the classic first surprise bill. Stop the space from the Studio UI when you finish a session.

10.1.7 Managing Cloud Costs

A handful of traps account for most surprise bills:

  • Idle notebook and VM instances: Cloud notebooks bill by wall-clock time, not usage. An instance left running overnight can cost more than a whole week of active work.
  • Data egress: Moving data out of a cloud provider (to your laptop, to another region, to another cloud) is almost always charged. Moving it in is usually free. Pulling a 500 GB dataset to your machine “just to look at it” is a classic expensive mistake.
  • NAT gateways and load balancers: Networking components that a tutorial may have had you create — one lets private machines reach the internet, the other spreads incoming traffic across several servers. On AWS especially, they run 24/7 and bill by the hour even when nothing is using them. Delete them when the project ends.
  • Storage classes: Object storage — the kind that holds whole files you address by name, like S3, rather than rows you query — has cheap long-term tiers (S3 Glacier, GCS Coldline, Azure Archive) for data you rarely read. Use them for raw archives.
  • Free tier expiry: Free tiers end, and their terms change often enough that no figure printed in a book stays right. AWS restructured its offer in July 2025, replacing a fixed-length allowance with a credit-based plan for new accounts, so even guidance written recently may describe something you won’t be offered. Check the provider’s current terms before assuming anything is free.

The habits that prevent all of this are dull and short. Set a billing alert before you launch anything. Stop instances when you finish for the day, or schedule the shutdown so you don’t have to remember. Delete storage, load balancers and services at the end of a project rather than leaving them running against a card. For batch work that can be interrupted and restarted, which covers most training jobs, use spot or preemptible instances — the same hardware at a steep discount.

In AWS, a budget with alerts takes four steps:

  1. Navigate to AWS Billing Dashboard
  2. Select “Budgets” from the left navigation
  3. Create a budget with monthly limits
  4. Set up email alerts at 50%, 80%, and 100% of your budget

Do this before you launch anything, not after the first bill.

10.1.8 Security Best Practices in the Cloud

Two rules carry most of the weight. Turn on multi-factor authentication for the account, because a cloud login is a login to something that can spend money. And grant the narrowest permissions that let the job run — a notebook that reads one bucket shouldn’t hold credentials that can drop the account’s databases.

Encryption is the third, and it is mostly a matter of switching it on in the right place rather than writing any code.

AWS offers three ways to encrypt what’s in a bucket, distinguished by who holds the key: SSE-S3 (AWS manages it entirely, nothing for you to do), SSE-KMS (a key you own in AWS’s Key Management Service, so you can control and audit its use), and SSE-C (you supply the key on every request). In practice, the cleanest approach for most data science work is to enable default encryption on the S3 bucket itself with one of the first two (AWS console → Bucket → Properties → Default encryption → SSE-S3 or SSE-KMS). Once that’s set, every object written to the bucket is encrypted at rest automatically, and your notebook code doesn’t need to pass keys at all:

import boto3
from botocore.exceptions import ClientError

def get_data(bucket, key):
    # Credentials come from the instance IAM role, not from code.
    # Encryption is handled by the bucket's default policy.
    s3 = boto3.client('s3')
    try:
        response = s3.get_object(Bucket=bucket, Key=key)
        return response['Body'].read()
    except ClientError as e:
        print(f"Error accessing data: {e}")
        return None

A few principles to notice:

  • No access keys in code. When running on an EC2 instance, SageMaker notebook, or Lambda, attach an IAM role — a named set of permissions granted to the machine itself rather than to a person, so nothing has to carry a key around — with the minimum permissions the job needs; boto3 picks up credentials automatically. For local development, use aws configure to store credentials in ~/.aws/credentials (which is already outside your git repository).
  • Let the bucket policy enforce encryption, not the client. This avoids the trap of one script forgetting to encrypt.
  • Avoid SSE-C unless you have a specific compliance reason. Holding the key yourself means losing the key loses the data, permanently and with no recourse. SSE-KMS is almost always the better choice.

Providers call this shared responsibility: they secure the infrastructure, you secure what you put on it. The breaches that reach the news are nearly always the second half.

10.1.9 Hands-On Exercise: Your First Cloud Analysis with Google Colab

Let’s walk through a complete example of using Google Colab for a data science task. This exercise demonstrates the practical workflow of cloud-based analysis.

10.1.9.1 Step 1: Create a New Notebook

  1. Go to colab.research.google.com
  2. Click “New Notebook”
  3. Rename it by clicking on “Untitled0.ipynb” at the top

10.1.9.2 Step 2: Load and Explore Data

In the first cell, load a dataset directly from a URL:

import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns

# Load a sample dataset directly from the web
url = "https://raw.githubusercontent.com/mwaskom/seaborn-data/master/penguins.csv"
df = pd.read_csv(url)

# Display basic information
print(f"Dataset shape: {df.shape}")
print(f"\nColumn types:\n{df.dtypes}")
print(f"\nFirst few rows:")
df.head()

10.1.9.3 Step 3: Perform Analysis

In subsequent cells, perform your analysis:

# Summary statistics
df.describe()
# Create a visualisation
plt.figure(figsize=(10, 6))
sns.scatterplot(data=df, x='bill_length_mm', y='bill_depth_mm',
                hue='species', style='island', s=100)
plt.title('Penguin Bill Dimensions by Species and Island')
plt.xlabel('Bill Length (mm)')
plt.ylabel('Bill Depth (mm)')
plt.legend(bbox_to_anchor=(1.05, 1), loc='upper left')
plt.tight_layout()
plt.show()

10.1.9.4 Step 4: Enable GPU Acceleration (Optional)

For machine learning tasks, you can enable GPU acceleration:

  1. Go to Runtime → Change runtime type
  2. Select “T4 GPU” from the Hardware accelerator dropdown
  3. Click Save

Then verify GPU availability:

import torch

if torch.cuda.is_available():
    print(f"GPU available: {torch.cuda.get_device_name(0)}")
    print(f"GPU memory: {torch.cuda.get_device_properties(0).total_memory / 1e9:.1f} GB")
else:
    print("No GPU available - using CPU")

10.1.9.5 Step 5: Save Your Work

Colab notebooks are automatically saved to your Google Drive. You can also:

  • Download the notebook: File → Download → Download .ipynb
  • Save to GitHub: File → Save a copy in GitHub
  • Share with collaborators: Click the Share button in the top right

That is the whole shape of cloud-based analysis: read data in, work on it, draw something, optionally on hardware you don’t own, without installing anything locally.

10.1.10 Connecting Cloud Storage to Your Analysis

When working with larger datasets, you’ll want to connect cloud storage to your notebooks. Here’s how to mount Google Drive in Colab:

from google.colab import drive

# Mount Google Drive
drive.mount('/content/drive')

# Now you can access files in your Drive
import pandas as pd
df = pd.read_csv('/content/drive/MyDrive/data/my_dataset.csv')

For AWS S3 from a Colab notebook, use the boto3 library with credentials supplied through Colab’s secret manager rather than typing them into cells:

# In Colab: click the 🔑 key icon in the left sidebar and add two secrets
# named AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Then:
import os
from google.colab import userdata
import boto3

os.environ["AWS_ACCESS_KEY_ID"] = userdata.get("AWS_ACCESS_KEY_ID")
os.environ["AWS_SECRET_ACCESS_KEY"] = userdata.get("AWS_SECRET_ACCESS_KEY")

s3 = boto3.client("s3", region_name="us-east-1")
s3.download_file("your-bucket", "data.csv", "data.csv")

Never paste access keys directly into notebook cells or commit them to a repository. Anything written in a cell gets saved to the .ipynb file and is trivially recoverable. Use Colab secrets, environment variables, or (better) IAM roles for service-to-service access.

If a key does leak, rotate it in the AWS console immediately. Don’t try to scrub the notebook history.

Either way the data stays where it is and the notebook reaches for it, rather than you shipping files around by hand.

10.2 Conclusion

The cloud is worth reaching for when your laptop is the constraint — on memory, on time, or on the fact that it goes home with you.

By the end of this chapter you should have:

  • A notebook running in Google Colab, with a GPU attached at least once so you’ve seen how to request one
  • Data read into that notebook from cloud storage rather than uploaded by hand
  • A billing alert configured on any paid account you opened
  • Credentials read from a secrets store or environment variable — never typed into a notebook cell

The next chapter, Web Development for Data Scientists, covers building the applications and dashboards you might eventually host on these platforms. Containerisation and Deploying Data Science Projects then cover packaging them and getting them online.