Cloud engineers and machine learning engineers spend much of their week on someone else's computers. This intermediate course explains how the public cloud really works and lets you try it safely on a free tier. You will learn the service models (IaaS, PaaS, SaaS and serverless), how regions and availability zones let a system survive a failure, and who is responsible for what under the shared responsibility model. Before you create anything you set a budget alert. Then you launch and connect to a small virtual machine, store files in object storage with access rules, and sketch a VPC with public and private subnets. The last module covers identity and access management with least-privilege policies, keeping secrets out of code, monitoring with alarms and health checks, and planning an entry-level certification such as AWS Certified Cloud Practitioner, Azure Fundamentals (AZ-900) or Google Cloud Digital Leader. Examples use AWS because its free plan is easy to start, and every lesson names the Azure and Google Cloud equivalents. Every hands-on task ends with a cleanup step. It builds on Linux Administration.

Learn how the public cloud works: service models, regions, shared responsibility, compute, storage, networking, IAM, secrets and cost control, using free tiers only.

Cloud Fundamentals

## Why it matters

"Put it in the cloud" can mean very different things. You might rent a bare virtual machine and install everything yourself, or you might upload a single function and never think about a server at all. Each choice moves work (and control) between you and the provider. Picking the wrong model is one of the most common reasons a cloud project costs too much or takes too long to run.

## The core idea: who manages which layer

Think of an application as a stack of layers, from the bottom up: physical data centre, network, servers and storage, virtualisation, operating system, runtime (for example Python or Node.js), your application code, and your data. The service models differ only in where the line sits between "the provider manages it" and "you manage it".

| Model | Provider manages | You manage | Examples |
|---|---|---|---|
| On-premises | nothing | everything | your own server room |
| IaaS (Infrastructure as a Service) | hardware, network, virtualisation | OS, patches, runtime, app, data | AWS EC2, Azure Virtual Machines, Google Compute Engine |
| PaaS (Platform as a Service) | everything up to the runtime | app code, configuration, data | AWS Elastic Beanstalk, Azure App Service, Google App Engine |
| Serverless / FaaS | servers, scaling, runtime | individual functions and data | AWS Lambda, Azure Functions, Google Cloud Run functions |
| SaaS (Software as a Service) | the whole application | your data and user settings | Gmail, Microsoft 365, Salesforce |

A useful analogy is getting a meal. On-premises is cooking at home from scratch. IaaS is renting a kitchen: the room and appliances are provided, but you buy ingredients and cook. PaaS is a meal kit: the hard parts are done, you assemble. SaaS is eating at a restaurant. Serverless is ordering a single dish only when you are hungry and paying per plate.

## What serverless really means

Serverless does not mean there are no servers. It means you never see, size or patch them. You upload code, say what event should trigger it (an HTTP request, a file landing in storage, a timer), and the provider runs it on demand. You pay per request and per unit of compute time, and when nothing is happening you usually pay nothing. The trade-offs are limits on how long one run can last, a "cold start" delay when a function has not run recently, and less control over the environment.

Managed databases (AWS RDS, Azure SQL Database, Google Cloud SQL) sit between IaaS and PaaS: the provider patches and backs up the database engine, and you design the schema and queries.

## Worked example: three workloads

**1. A legacy accounting application** that needs a specific Windows version and a licensed add-on. It must control the operating system, so **IaaS** (a virtual machine) is the realistic choice. You will patch it yourself.

**2. A new web API** written in Python by a team of three who do not want to manage servers. **PaaS** (or a container platform) lets them push code and get load balancing, scaling and HTTPS. They still own the code and the data.

**3. A thumbnail generator** that runs whenever a user uploads an image, a few hundred times a day. Long idle periods and short bursts are the ideal shape for **serverless**: a function triggered by each upload, costing almost nothing at low volume.

And if the company just needs email and shared documents, it should buy **SaaS** rather than build anything.

## How to choose

Ask these questions in order:

1. Does a SaaS product already do this well enough? If yes, buy it.
2. Does the workload need control of the operating system, special drivers or a licence tied to a machine? If yes, IaaS.
3. Is it event-driven, short-running and spiky? Consider serverless.
4. Otherwise, a PaaS or managed container service is usually the best balance of control and effort.

## Common mistakes

- **Lifting everything onto VMs** because it feels familiar, then paying for idle servers around the clock and patching them forever.
- **Forcing long jobs into serverless.** A batch job that runs for hours does not fit function time limits; use a VM, a container job or a batch service.
- **Forgetting that "managed" still has a customer side.** On PaaS you are still responsible for your code's security and your data.
- **Comparing only the price per hour.** Include the people-time spent on patching, scaling and on-call work.

## Quick recap

- The models differ in which layers the provider manages: IaaS (you manage the OS and up), PaaS (you manage the app), SaaS (you manage your data), serverless (you manage functions).
- Serverless still runs on servers; you just never manage them, and you pay per use.
- Choose SaaS first, IaaS when you need OS control, serverless for short event-driven work, and PaaS for most new applications.


Compare the cloud service models and pick the right one for a workload.

IaaS, PaaS, SaaS, serverless

AZ-900 Episode 5 | IaaS vs PaaS vs SaaS cloud service models | Microsoft Azure Fundamentals Course

What is Serverless?

## Why it matters

Hardware fails, power fails, and sometimes an entire building goes dark. Cloud providers cannot stop that, but they give you the building blocks to keep running when it happens. If you put every server in one place, one bad afternoon takes your whole service down. Understanding regions and zones is the first step in designing for availability.

## The core idea

- A **region** is a geographic area, such as `us-east-1` (North Virginia) on AWS, `West Europe` on Azure or `europe-west1` on Google Cloud. Each region is independent: its own power, network and services. Data you store in a region stays there unless you copy it out.
- An **availability zone (AZ)** is one or more data centres inside a region, with separate power, cooling and networking, connected to the other zones by fast, low-latency links. AWS names them like `us-east-1a`, `us-east-1b`. Most regions have three or more zones.
- **Edge locations** (points of presence) are smaller sites close to users that cache content for a content delivery network (CDN) such as Amazon CloudFront.

The key design rule: a zone can fail, so anything important should run in **at least two zones**. A whole region failing is much rarer, and protecting against it (multi-region) costs a lot more.

## Choosing a region

Pick a region based on, in rough order:

1. **Data rules.** Some laws or contracts require personal data to stay in a country or the EU.
2. **Latency.** Closer to your users means faster responses.
3. **Service availability.** New services and GPU types often launch in some regions first.
4. **Price.** The same instance can cost noticeably different amounts in different regions.

## Measuring availability

Availability is often written as "nines": 99.9% ("three nines") allows about 8.8 hours of downtime a year; 99.99% allows about 53 minutes. If one zone gives your server 99.5% availability and zones fail independently, two zones in parallel give roughly:

```text
1 - (1 - 0.995) * (1 - 0.995) = 1 - 0.000025 = 99.9975%
```

Real systems are never perfectly independent, but the maths shows why a second zone is such a big win.

Two related terms you will hear: **RTO** (recovery time objective: how long you can be down) and **RPO** (recovery point objective: how much data, measured in time, you can afford to lose). They drive every availability decision.

## Worked example: a web shop that survives a zone failure

A small shop runs a web app and a database in one region, `eu-west-1`.

**Fragile design:** one VM running both the app and the database, in `eu-west-1a`. If that zone fails, the shop is down and recent orders may be lost.

**Zone-resilient design:**

```text
          Internet
             |
     Load balancer (spans zones a and b)
        /                 \
  App VM (zone a)     App VM (zone b)
        \                 /
  Managed database: primary (zone a) + standby (zone b)
  Backups and images in object storage (regional, multi-zone)
```

- The **load balancer** sends traffic only to healthy app servers. If zone a fails, it routes everything to zone b.
- An **auto scaling group** keeps the number of app servers at the target and replaces failed ones in a healthy zone.
- The **managed database** runs a synchronous standby in another zone (AWS calls this Multi-AZ) and fails over automatically, usually within a minute or two.
- **Object storage** such as S3 Standard already stores data across several zones.

The app servers must be **stateless**: no user sessions or uploads stored only on the local disk, or a failover loses them. Put sessions in the database or a cache and uploads in object storage.

## Common mistakes

- **"It's in the cloud, so it's highly available."** A single VM in one zone is no more resilient than a server in a cupboard.
- **Two servers, one zone.** Redundancy inside a single zone does not survive a zone outage.
- **Stateful app servers** that keep files or sessions locally.
- **Never testing failover.** Stop one zone's servers on purpose (in a test environment) and watch what happens.
- **Paying for multi-region before you need it.** Most beginners' systems need multi-zone, not multi-region.

## Quick recap

- Region = geographic area; availability zone = isolated data centre(s) inside it; edge location = cache near users.
- Run anything important across at least two zones behind a load balancer, with a multi-zone database and stateless app servers.
- Choose regions by data rules, latency, service availability and price; use RTO and RPO to decide how much resilience you need.


Use regions and availability zones to design a system that survives a zone failure.

Regions, zones, and availability

AWS Global Infrastructure Overview - Regions, Availability Zones, Edge Locations and more

AZ-900 Episode 7 | Geographies, Regions & Availability Zones | Microsoft Azure Fundamentals Course

Open the AWS Pricing Calculator (calculator.aws) without logging in. Create an estimate for one small Linux VM (EC2) running 730 hours a month in the region closest to you, with a 20 GB gp3 disk.

Add 10 GB a month of data transfer out to the internet and a public IPv4 address. Note the monthly total and which line costs the most.

Change the VM to run only 40 hours a month (a few study sessions). Write down how much the total changes. This is why you stop or delete resources after each session.

If you choose to create an account, sign up at aws.amazon.com/free, choose the Free plan, and turn on multi-factor authentication (MFA) for the root user straight away.

In Billing and Cost Management, open Budgets and create a budget from the Zero spend budget template (or a monthly cost budget of 1 US dollar). Enter an email address you check daily.

Confirm the budget appears in the Budgets list and note its name. Every later lesson assumes it exists.

Write a three-row table for a VM, a storage bucket and a managed database: for each, list one thing the provider secures and one thing you secure.

Cleanup: you created no billable resources in this lesson. Keep the budget alert (AWS does not charge for a small number of budgets), and sign out of the root user.

## Why it matters

Two of the most common cloud disasters have nothing to do with clever attacks. The first is a storage bucket left open to the public because someone assumed "the cloud provider handles security". The second is a surprise bill because a large instance ran for a month after a tutorial ended. This lesson covers both: who is responsible for security, and how cloud pricing works so that you can control it.

## The shared responsibility model

Every major provider publishes a shared responsibility model. The short version: the provider is responsible for security **of** the cloud, and you are responsible for security **in** the cloud.

| Provider (security of the cloud) | You (security in the cloud) |
|---|---|
| Physical data centres, guards, hardware | Who can log in (IAM users, roles, MFA) |
| The network between data centres | Firewall rules and security groups you create |
| The virtualisation layer | Patching the OS on your VMs (IaaS) |
| Managed service infrastructure | Your application code and its dependencies |
| | Your data: classification, encryption settings, backups, public or private access |

The line moves with the service model. On a VM you patch the operating system; on a managed database the provider patches the engine; on SaaS the provider runs almost everything. But **your data and your identities are always yours**. No provider will stop you from making your own bucket public if your account allows it.

## How cloud pricing works

Most bills come from a few meters:

- **Compute time:** per second or hour that a VM or container runs, by size. A stopped VM usually stops compute charges, but its disk still costs money.
- **Storage:** per GB per month, plus per request for object storage.
- **Data transfer:** data coming in is usually free; data going **out** to the internet, or between regions, is charged per GB.
- **Managed services:** per hour, per request or per unit of capacity.
- **Things people forget:** public IPv4 addresses, NAT gateways, load balancers, snapshots and log storage all charge while they exist, even if nothing uses them.

Ways to pay less: turn off what is not in use, right-size (pick the smallest size that works), use commitments (reserved instances or savings plans) for steady workloads, and use spot or preemptible capacity for interruptible jobs.

## Worked example: estimating a small app

Suppose a tutorial asks you to run one small Linux VM 24 hours a day, with a 20 GB disk and about 10 GB of downloads a month. Using the provider's pricing calculator (for AWS, the AWS Pricing Calculator at calculator.aws) you would add:

```text
VM:         hours per month (about 730) x hourly price for the size
Disk:       20 GB x price per GB-month
Public IP:  about 730 hours x price per IP-hour
Transfer:   10 GB out x price per GB (after any free allowance)
Total:      sum of the above, per month
```

Prices change and differ by region, so always use the calculator rather than numbers from a blog post. Notice how a VM that is "only a few cents an hour" still adds up over 730 hours.

## Free tiers, and why a budget alert comes first

All three big providers offer a way to learn for free, but the rules differ and they change. At the time of writing, AWS offers new accounts a **Free plan** with credits for a limited period, where you are not charged unless you upgrade to a paid plan; Azure and Google Cloud offer trial credits plus some always-free services. Read the current terms on the official pages: [AWS Free Tier](https://aws.amazon.com/free/), [Azure free services](https://azure.microsoft.com/en-us/pricing/free-services) and [Google Cloud free program](https://cloud.google.com/free). Checked on 2026-10-23.

Whatever plan you are on, **set a budget alert before you create any resource.** A budget alert emails you when actual or forecast spend crosses a threshold. On AWS, Billing and Cost Management offers a "zero spend" budget template that alerts you as soon as you spend anything at all. Alerts do not stop spending by themselves, but they turn a month-long surprise into a same-day email.

## Common mistakes

- Assuming the provider will stop you from exposing your own data.
- Using the root (account owner) login for daily work instead of a separate user with MFA.
- Stopping a VM and forgetting its disk, snapshot or public IP, which keep billing.
- Following a tutorial in an expensive region or with a large default size.
- Creating resources before setting a budget alert.

## Quick recap

- Provider: security of the cloud. You: security in the cloud, especially identities and data.
- Bills come from compute time, storage, data out, managed services and forgotten extras.
- Estimate with the official calculator, learn on a free tier, and set a budget alert first.

## Try it

Open the Do tab: you will estimate a small workload with a pricing calculator and set up your budget alert, which the rest of this course depends on.


Explain who secures what in the cloud, estimate a monthly bill and set a budget alert before building anything.

Shared responsibility and cost

Simplify the AWS Shared Responsibility Model | Amazon Web Services

How to Estimate AWS Costs with the AWS Pricing Calculator | Tutorial for Beginners

Service models, regions and availability zones, the shared responsibility model and how cloud pricing works.

Cloud Concepts

Confirm your budget alert from the Shared responsibility and cost lesson exists (Billing and Cost Management, Budgets). Do not continue without it.

In the EC2 console, check the region in the top bar is the one you chose. Choose Launch instance, name it `practice-vm`, and select an Ubuntu Server LTS image.

Choose an instance type marked Free tier eligible. Do not pick a larger size.

Create a new key pair (`practice-key`, ED25519 or RSA, .pem). Save the downloaded file somewhere private and never commit it to Git.

Under Network settings, allow SSH traffic from My IP only. Leave HTTP and HTTPS unticked. Keep the default 8 GB disk and launch.

When the instance state is Running, copy its public IPv4 address. In your terminal run `chmod 400 practice-key.pem` and then `ssh -i practice-key.pem ubuntu@<public-ip>`.

On the VM run `uname -a`, `df -h` and `free -h` and note the results. Type `exit` to disconnect.

Cleanup: select the instance and choose Instance state, Terminate. Then check Elastic Block Store, Volumes and Network & Security, Elastic IPs and delete anything left with `practice` in its name or not attached to an instance.

Next day, open Billing and Cost Management and confirm no unexpected charges appear.

## Why it matters

Virtual machines are the oldest and most flexible cloud building block. Even teams that mostly use containers or serverless still run VMs for build agents, databases, GPU training jobs and legacy software. A cloud engineer should be able to launch one, connect to it securely and clean it up without thinking twice. A machine learning engineer will rent GPU VMs for training and must know how to stop paying for them.

## The core idea

A cloud VM (AWS **EC2 instance**, Azure **Virtual Machine**, Google **Compute Engine instance**) is a slice of a physical server that you rent by the second. When you launch one, you choose:

- **Image:** the starting disk, such as Ubuntu Server LTS or Amazon Linux. On AWS this is an AMI (Amazon Machine Image).
- **Instance type (size):** CPUs, memory and sometimes GPUs, for example `t3.micro` (2 vCPUs, 1 GiB). Families are tuned for general, compute, memory or GPU work.
- **Storage:** a block disk (AWS EBS volume) attached as the root drive.
- **Network:** which VPC and subnet the VM goes in, and whether it gets a public IP.
- **Firewall:** a **security group** that lists which ports are open to which sources.
- **Key pair:** the SSH public key placed on the VM so you can log in with your private key.

Instances move through states: pending, running, stopping, stopped, terminated. **Stopped** keeps the disk (and its charges); **terminated** deletes the instance, and by default its root disk too.

## Worked example: a secure first launch

The safe pattern for a practice VM looks like this:

1. Pick the region you used in your pricing estimate.
2. Choose an Ubuntu Server LTS image and a size labelled **Free tier eligible** in the console.
3. Create a new key pair and download the private key file, for example `practice-key.pem`. You only get to download it once.
4. Create a security group that allows **SSH (port 22) from My IP only**, not from `0.0.0.0/0` (the whole internet).
5. Keep the default 8 GB disk.

Then connect from your own terminal (macOS, Linux or Windows PowerShell all include `ssh`):

```bash
chmod 400 practice-key.pem          # ssh refuses keys that others can read
ssh -i practice-key.pem ubuntu@203.0.113.25
```

Replace the address with your instance's public IPv4 address. The default user is `ubuntu` on Ubuntu images and `ec2-user` on Amazon Linux. Once in, the Linux skills from the previous course apply directly:

```bash
uname -a
df -h
curl -s http://checkip.amazonaws.com    # shows the public IP the internet sees
```

## User data: automating setup

Most real VMs are not configured by hand. A **user data** script runs once at first boot:

```bash
#!/bin/bash
apt-get update -y
apt-get install -y nginx
echo "Hello from $(hostname)" > /var/www/html/index.html
```

Better still, you capture a configured VM as an image, or you describe the whole setup in infrastructure-as-code (covered in the DevOps & Cloud Delivery course). The goal is that any VM can be thrown away and rebuilt automatically.

## Scaling compute

- **Vertical scaling:** stop the VM and change its size. Simple, but it has a ceiling and causes downtime.
- **Horizontal scaling:** run more identical VMs behind a load balancer, managed by an auto scaling group that adds or removes VMs on a schedule or based on CPU load.

## Common mistakes

- Opening SSH to the whole internet. Bots scan every public IP within minutes.
- Losing the only copy of the private key, or committing it to Git.
- Choosing a large or GPU instance "to be safe" and leaving it running.
- Forgetting that a stopped instance's disk and public IP still cost money.
- Treating a VM as a pet that is hand-tuned and irreplaceable, instead of something you can rebuild from a script.

## Quick recap

- A VM is defined by image, size, disk, network, security group and key pair.
- Allow SSH from your IP only, keep the private key safe and connect with `ssh -i`.
- Stop to pause compute charges; terminate (and delete leftover disks and IPs) to stop all charges.

## Try it

The Do tab walks you through launching, connecting to and deleting a free-tier VM.


Launch a free-tier virtual machine, connect to it over SSH and delete it when you are done.

Compute

UPDATED - Amazon/AWS EC2 Basics | Create an EC2 Instance | AWS Tutorials for Beginners

AWS Free Tier and the New AWS Experience

Confirm your budget alert exists. Then open the S3 console and check the region.

Create a bucket named `<yourname>-practice-<date>` (lowercase, globally unique). Leave Block all public access ON and leave default encryption on.

Open the bucket's Properties tab and turn on Bucket Versioning.

Upload a small text file containing no personal information to a `notes/` prefix. Open the object and copy its Object URL.

Open the Object URL in a private browser window. You should get Access Denied: that proves the bucket is private.

Select the object and choose Object actions, Share with a presigned URL, valid for 5 minutes. Open that link in the private window and confirm it downloads. Wait 5 minutes and confirm it stops working.

Upload the same file name again with different text, then open the Versions toggle and see both versions.

Cleanup: choose Empty for the bucket (this deletes all versions), then Delete the bucket. Confirm the bucket list no longer shows it.

## Why it matters

Almost every cloud system stores files somewhere: user uploads, logs, backups, website assets, training datasets and model files. Object storage is the cheapest and most durable place to keep them, and it is also where many of the largest data leaks have happened, through buckets that were accidentally made public. Knowing how to store data and how to lock it down is a core skill for both cloud and ML engineers.

## Three kinds of cloud storage

| Type | What it is | AWS / Azure / Google | Good for |
|---|---|---|---|
| Block | A virtual disk attached to one VM | EBS / Managed Disks / Persistent Disk | OS drives, databases on VMs |
| File | A shared network file system | EFS / Azure Files / Filestore | Several servers sharing one folder |
| Object | Files (objects) in a flat namespace, reached over HTTPS | S3 / Blob Storage / Cloud Storage | Uploads, backups, logs, datasets, static sites |

## How object storage works

In Amazon S3 you create a **bucket** (a container with a globally unique name) in a region. Each **object** has a **key** (its name, which can contain slashes so it looks like a path), the data itself, and metadata:

```text
s3://acme-ml-datasets-2026/raw/2026/10/sales.csv
     bucket                key
```

There are no real folders; `raw/2026/10/` is just part of the key, and the console displays it as folders for convenience. S3 Standard stores each object across several availability zones and is designed for extremely high durability, so losing an object to hardware failure is very unlikely. Losing it to human error is much more likely, which is why **versioning** (keeping old versions when an object is overwritten or deleted) is worth turning on for important buckets.

**Storage classes** trade retrieval speed for price: Standard for frequently used data, Infrequent Access for data read a few times a year, and Glacier classes for archives. **Lifecycle rules** move or delete objects automatically, for example "move logs to Glacier after 30 days, delete after 365".

## Access control

By default a new S3 bucket is private, and **Block Public Access** is on. Access is then granted in layers:

- **IAM policies** say what a user or role can do (next module).
- **Bucket policies** are JSON documents attached to the bucket that say who can do what with its objects.
- **Pre-signed URLs** give one person temporary access to one object without making anything public.

A bucket policy that allows one IAM role to read objects under `reports/` looks like this:

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:role/report-reader" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::acme-reports-2026/reports/*"
  }]
}
```

Encryption at rest is applied by default to new S3 objects, and you can choose provider-managed or customer-managed keys.

## Worked example with the CLI

If you have the AWS CLI configured (with a user that is not root), the everyday commands are short:

```bash
aws s3 mb s3://yourname-practice-2026-10 --region eu-west-1   # make bucket
echo "hello cloud" > hello.txt
aws s3 cp hello.txt s3://yourname-practice-2026-10/notes/hello.txt
aws s3 ls s3://yourname-practice-2026-10/notes/
aws s3 presign s3://yourname-practice-2026-10/notes/hello.txt --expires-in 300
aws s3 rb s3://yourname-practice-2026-10 --force                # delete bucket and contents
```

The `presign` command prints a URL that works for 300 seconds. Anyone with the link can download the file during that time, so treat it like a password.

## Common mistakes

- Turning off Block Public Access to "make sharing easier". Use pre-signed URLs or a CDN instead.
- Putting secrets or personal data in a bucket without knowing who can read it.
- No versioning on important data, so an accidental delete is permanent.
- Storing millions of tiny files with no lifecycle rule and paying for them forever.
- Forgetting request and data-transfer charges when a public dataset gets popular.

## Quick recap

- Block storage is a VM's disk, file storage is a shared folder, object storage holds objects in buckets reached over HTTPS.
- Keys look like paths but are just names; turn on versioning and lifecycle rules where they matter.
- Buckets are private by default; grant access with IAM and bucket policies, and share single files with pre-signed URLs.

## Try it

In the Do tab you create a private bucket, upload a file, share it with a pre-signed link and delete everything.


Store files in object storage, control who can read them and clean up the bucket.

Storage

Amazon/AWS S3 (Simple Storage Service) Basics | S3 Tutorial, Creating a Bucket | AWS for Beginners

Introduction to Amazon Simple Storage Service (S3) - Cloud Storage on AWS

Pick an app to design for: a web app with an API and a PostgreSQL database that must survive one availability zone failing.

Choose a VPC CIDR such as 10.20.0.0/16 and write down why it will not overlap with your home or office network (check yours with `ip addr` or `ipconfig`).

Plan four subnets in two zones: two public and two private, each a /24. Write their CIDRs in a table with their zone and purpose.

Draw the VPC, the two zones, the four subnets, an internet gateway, one NAT gateway, a load balancer, two app servers and a database primary and standby.

Write both route tables (public and private) as destination -> target lines.

Write three security groups (load balancer, app, database) with inbound rules that reference each other, as in the lesson.

Mark which resources in your diagram would cost money per hour if you built it, and write how you would reach the private app servers for maintenance without giving them public IPs.

Cleanup: if you experimented in a real account, delete any NAT gateway, load balancer, Elastic IP and VPC you created, then check your budget alert shows no new spend.

## Why it matters

Every VM, database and container you create lands inside a virtual network. If you do not understand that network, you will either expose things that should be private or spend an afternoon wondering why your server cannot reach the internet. The Networking Fundamentals course taught IP addresses, subnets and routing; the cloud reuses all of it, with new names.

## The core idea: a VPC

A **VPC** (Virtual Private Cloud; Azure calls it a **VNet**, Google Cloud also says VPC) is your own private network inside a region. You give it an address range in CIDR notation, such as `10.0.0.0/16` (65,536 addresses). Inside it you create **subnets**, each tied to one availability zone on AWS, such as `10.0.1.0/24` (256 addresses, of which AWS reserves 5).

What makes a subnet **public** or **private** is not a checkbox; it is the **route table**:

- A **public subnet** has a route `0.0.0.0/0 -> internet gateway`. Resources in it with a public IP can be reached from, and reach, the internet.
- A **private subnet** has no route to the internet gateway. Its resources can only talk inside the VPC, unless you add a **NAT gateway**, which lets them make outbound connections (for updates) while staying unreachable from outside.

## Worked example: a two-tier VPC

A web app with a database, resilient across two zones:

```text
VPC 10.0.0.0/16 (region eu-west-1)

  Zone a                              Zone b
  +--------------------------+       +--------------------------+
  | Public  10.0.1.0/24      |       | Public  10.0.2.0/24      |
  |   load balancer node     |       |   load balancer node     |
  |   NAT gateway            |       |                          |
  +--------------------------+       +--------------------------+
  | Private 10.0.11.0/24     |       | Private 10.0.12.0/24     |
  |   app server             |       |   app server             |
  |   database primary       |       |   database standby       |
  +--------------------------+       +--------------------------+

Public route table:  10.0.0.0/16 -> local ; 0.0.0.0/0 -> internet gateway
Private route table: 10.0.0.0/16 -> local ; 0.0.0.0/0 -> NAT gateway
```

Only the load balancer is internet-facing. App servers and the database have private addresses only. Leaving gaps in the numbering (`.1`, `.2` for public, `.11`, `.12` for private) makes the plan easy to read and to extend.

## Firewalls: security groups and network ACLs

- A **security group** is a stateful firewall attached to a resource. You list allowed inbound traffic; replies are allowed automatically. Security groups can reference each other, which is the cleanest way to build tiers:

```text
sg-lb   inbound: 443 from 0.0.0.0/0
sg-app  inbound: 8080 from sg-lb
sg-db   inbound: 5432 from sg-app
```

  The database accepts connections only from app servers, wherever their IPs happen to be.

- A **network ACL** is a stateless filter on a whole subnet, with numbered allow and deny rules for both directions. Most teams leave ACLs at the default and do the real work in security groups.

## Reaching private servers

Do not give private servers public IPs just to log in. Options, from simplest to most traditional: a provider session tool such as AWS Systems Manager Session Manager (no open SSH port at all), a VPN into the VPC, or a small hardened **bastion host** in a public subnet that allows SSH only from your IP.

## Cost notes

VPCs, subnets, route tables and security groups are free. **NAT gateways, load balancers and public IPv4 addresses are billed per hour** whether or not traffic flows, and NAT gateways also charge per GB processed. For learning, sketch them rather than create them, and delete any you do create on the same day.

## Common mistakes

- Overlapping CIDR ranges between VPCs (or with the office network) that later need to be connected.
- Putting databases in public subnets.
- Security groups with `0.0.0.0/0` on database or SSH ports.
- Subnets in only one zone, which undoes all your availability planning.
- Leaving a NAT gateway running after a tutorial.

## Quick recap

- A VPC is a private network in a region; subnets live in one zone each.
- Public vs private is decided by the route table: internet gateway route or not.
- Security groups (stateful, per resource) do most filtering; reference groups to build tiers.

## Try it

In the Do tab you design and draw a VPC for a real app, on paper or in a free diagramming tool, without creating any billable resources.


Sketch a VPC with public and private subnets, route tables and security groups.

Cloud networking

Amazon/AWS VPC (Virtual Private Cloud) Basics | VPC Tutorial | AWS for Beginners

AWS VPC & Subnets For Beginners

The three building blocks of almost every cloud system: compute, object storage and the virtual network that joins them.

Core Services

Confirm your budget alert exists and that you are signed in as a non-root user or through IAM Identity Center (create an admin user with MFA for yourself if you have only root).

Pick the task: "A reporting job uploads files to `s3://<yourname>-reports/daily/` and must not read, list or delete anything." Write down the single action it needs and the exact resource ARN.

Write the policy JSON by hand, like the lesson's final example. Do not use any wildcard in Action.

Write a second, wider policy that a beginner might use (for example `s3:*` on `*`) and list three bad things it would allow.

In the IAM console, open Policies, Create policy, JSON editor, paste your least-privilege policy, and check the editor shows no errors. Name it `practice-report-writer`.

Open the IAM policy simulator (policysim.aws.amazon.com), choose your policy, and simulate `s3:PutObject` on `arn:aws:s3:::<yourname>-reports/daily/test.csv` (expect allowed) and on `arn:aws:s3:::<yourname>-reports/other/test.csv` (expect denied).

Simulate `s3:DeleteObject` and `s3:GetObject` on the daily prefix and confirm both are denied.

Cleanup: delete the `practice-report-writer` policy (and any test role or user you created). Leave your own admin user with MFA in place.

## Why it matters

In the cloud, identity is the new perimeter. Anyone holding valid credentials with broad permissions can delete servers, read data or run up a huge bill, from anywhere in the world. Leaked access keys in public Git repositories are found by automated scanners within minutes. Identity and Access Management (IAM) is how you decide exactly who can do what, and it is the most important security control you own under the shared responsibility model.

## The core idea

Every request to a cloud API is checked: **who** is asking (the principal), **what** they want to do (the action), **on which** resource, and under what **conditions**. On AWS the building blocks are:

- **Root user:** the account owner. Use it only for a handful of account tasks; protect it with MFA and never create access keys for it.
- **Users and groups:** for people. Today most organisations sign people in through a central identity provider (AWS IAM Identity Center, Microsoft Entra ID, Google Workspace) instead of creating many IAM users.
- **Roles:** identities that people or services **assume** to get temporary credentials. An EC2 instance, a Lambda function or a CI pipeline should use a role, never a hard-coded access key.
- **Policies:** JSON documents that allow or deny actions.

Azure uses role assignments (RBAC) at a scope, and Google Cloud uses IAM roles bound to principals on a resource; the ideas are the same.

## Reading a policy

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-reports-2026/reports/*"
    },
    {
      "Sid": "ListReportsPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-reports-2026",
      "Condition": { "StringLike": { "s3:prefix": "reports/*" } }
    }
  ]
}
```

- `Effect` is `Allow` or `Deny`.
- `Action` names API operations, `service:Operation`.
- `Resource` is an ARN (Amazon Resource Name). Note that listing applies to the bucket ARN, while reading applies to object ARNs ending in `/*`.
- `Condition` narrows when the statement applies.

The evaluation rules: everything is **denied by default**; an explicit `Allow` grants access; an explicit `Deny` anywhere always wins.

## Least privilege, worked through

A nightly job copies a CSV export into `s3://acme-reports-2026/reports/`. A beginner might attach the managed policy `AmazonS3FullAccess`. That lets the job delete every bucket in the account. Least privilege asks: what is the smallest set of actions on the smallest set of resources that still lets the job work?

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::acme-reports-2026/reports/*"
  }]
}
```

That is the whole policy: the job can add files to one prefix in one bucket and nothing else. Attach it to a **role** that the job's compute (EC2, Lambda or a container task) assumes, so there are no keys to leak.

How to find the minimum: start from what the task needs, test, and add only what fails. AWS also offers IAM Access Analyzer, which can suggest policies based on recorded activity, and "last accessed" information that shows permissions nobody uses.

## Good habits

- MFA on every human login, especially root and administrators.
- Humans sign in through single sign-on and get temporary credentials; services use roles.
- Grant permissions to groups or roles, not to individuals one by one.
- Review and remove unused users, keys and permissions regularly.
- Use wildcards (`*`) sparingly and never as `"Action": "*", "Resource": "*"` outside a break-glass admin role.

## Common mistakes

- Daily work as the root user.
- Long-lived access keys pasted into code, scripts or `.env` files that get committed.
- `*FullAccess` policies attached "just to make it work".
- Forgetting that `s3:ListBucket` needs the bucket ARN, not the object ARN, and then widening everything to `*` out of frustration.

## Quick recap

- Every API call is checked against principal, action, resource and conditions; default deny, explicit deny wins.
- People use SSO and MFA; workloads use roles with temporary credentials.
- Least privilege means the smallest actions on the smallest resources; start small and add what is proven necessary.

## Try it

In the Do tab you write a least-privilege policy for a real task and test it with the IAM policy simulator.


Write a least-privilege IAM policy and use roles instead of long-lived keys.

UPDATED - AWS Identity and Access Management (IAM) Basics | AWS Tutorials For Beginners

How to Use AWS IAM Policies

## Why it matters

A secret is any value that grants access: database passwords, API keys, cloud access keys, private TLS keys, signing keys, webhook tokens. Once a secret is committed to a Git repository, you should assume it is public: forks, clones, CI logs and backups keep copies even after you delete the line. Attackers run bots that scan public repositories for cloud keys and start using them within minutes, often to mine cryptocurrency on your bill.

## The core idea

Code should say **which** secret it needs, never **what** the secret is. The value is supplied at runtime from a place designed to protect it, and access to that place is controlled by IAM.

A ladder from worst to best:

1. **Hard-coded in source.** Never.
2. **In a config file committed to Git.** Never.
3. **In environment variables** set by the deployment platform. Acceptable for many apps, as long as the values themselves are stored securely by the platform and not echoed into logs.
4. **In a secrets manager** (AWS Secrets Manager or Systems Manager Parameter Store SecureString, Azure Key Vault, Google Secret Manager), fetched at runtime by a role. Best for production: central storage, encryption with a managed key, access logging and rotation.
5. **No long-lived secret at all.** Use roles and short-lived tokens wherever the service supports it, for example a VM role instead of an access key, or a CI system using OpenID Connect to assume a cloud role.

## Worked example: from hard-coded to managed

The anti-pattern:

```python
# app.py  (do not do this)
DB_PASSWORD = "S3cretPassw0rd!"
```

Step one, read it from the environment and fail loudly if it is missing:

```python
import os

DB_PASSWORD = os.environ["DB_PASSWORD"]   # KeyError at start-up if not set
```

For local development, keep values in a `.env` file that is listed in `.gitignore`, and commit a `.env.example` with names but no values:

```bash
# .gitignore
.env

# .env.example (committed)
DB_PASSWORD=
PAYMENTS_API_KEY=
```

Step two, in production fetch the secret from a manager using the compute's role, so no secret ever sits in the deployment configuration:

```python
import json
import boto3

def get_db_password():
    client = boto3.client("secretsmanager")
    resp = client.get_secret_value(SecretId="prod/shop/db")
    return json.loads(resp["SecretString"])["password"]
```

The role's policy allows `secretsmanager:GetSecretValue` on that one secret only, which is least privilege applied to secrets.

## Keys and encryption

Encryption keys are a special kind of secret. Cloud key management services (AWS KMS, Azure Key Vault keys, Google Cloud KMS) keep the key material inside the service; you ask the service to encrypt or decrypt, and IAM controls who may do so. Most storage and database services can encrypt at rest with a managed key at the tick of a box. **Rotation** means replacing a key or password on a schedule, or immediately if it may have leaked. Secrets managers can rotate some database passwords automatically.

## If a secret leaks

Act in this order:

1. **Revoke or rotate it immediately** in the system that issued it. Deleting the commit is not enough.
2. Check access logs (for example AWS CloudTrail) for use of the leaked credential.
3. Remove it from the repository history if needed, and add scanning to stop a repeat.

Secret scanning tools (GitHub secret scanning and push protection, gitleaks, trufflehog) catch many leaks before or just after they happen.

## Common mistakes

- Printing configuration (including secrets) to logs at start-up.
- Sharing one powerful key across many apps and people, so it can never be rotated safely.
- Committing `.env` "just once" for a teammate.
- Putting secrets in container images or front-end JavaScript, where anyone can read them.
- Rotating a leaked key days later "after the release".

## Quick recap

- Code names the secret; the runtime supplies the value from environment variables or, better, a secrets manager.
- Prefer roles and short-lived tokens so there is no long-lived secret to leak.
- Keep `.env` out of Git, scan for secrets, and rotate immediately on any leak.


Keep passwords, API keys and other secrets out of code and fetch them safely at runtime.

Secrets and keys

What is Secrets Management?

Back to Basics: Secrets Management

Open Billing and Cost Management, Budgets, and confirm the budget from the first module exists. Edit it to add a second alert at 80% of forecast spend if it has none.

Open Cost Explorer (it can take up to a day to activate on a new account) and group spend by service for this month. Note any service with a non-zero cost.

Launch a free-tier VM exactly as in the Compute lesson (SSH from My IP only) and add a tag `project=practice`.

In CloudWatch, create an alarm on the instance's `StatusCheckFailed` metric: Maximum, 1 minute, >= 1 for 2 datapoints. For the action, create an SNS topic that emails you, and confirm the subscription email.

In the alarm list, check its state becomes OK after a few minutes. Write a two-line runbook for what you would do when it fires.

Optional: in the VM, run `sudo apt-get install -y nginx` and add a `/healthz` page in `/var/www/html` to see what a health endpoint returns (keep port 80 closed in the security group; test with `curl localhost/healthz` from the VM).

Cleanup: terminate the VM, delete the CloudWatch alarm and the SNS topic, and check EC2 Volumes and Elastic IPs for leftovers. Keep your budget.

Use the Resource Groups and Tag Editor to search all regions for `project=practice` and confirm nothing remains.

## Why it matters

If you cannot see what your system is doing, you find out about problems from angry users or a bill. Monitoring tells you when something is broken, slow or expensive, ideally before anyone else notices. In the cloud you also monitor money: cost is a metric like CPU, and it needs alerts just as much.

## The core idea: metrics, logs, traces, alarms

- **Metrics** are numbers over time: CPU percentage, requests per minute, error count, estimated charges. Cloud services publish many metrics automatically. On AWS they go to **Amazon CloudWatch**; Azure has **Azure Monitor**; Google has **Cloud Monitoring**.
- **Logs** are timestamped records of events: application output, web server access logs, and the audit log of who called which API (**AWS CloudTrail**, Azure Activity Log, Google Cloud Audit Logs).
- **Traces** follow one request across several services (covered in the DevOps & Cloud Delivery course).
- **Alarms** watch a metric and act when it crosses a threshold for a period: send an email or chat message, or trigger an automatic action.

## Health checks

A health check asks "is this working?" on a schedule.

- **Status checks:** EC2 runs system and instance status checks on every VM and publishes the `StatusCheckFailed` metric.
- **Load balancer health checks:** the load balancer calls a path such as `/healthz` on each server every few seconds and stops sending traffic to servers that fail.
- **External checks:** a probe outside your network loads your public URL, as a user would. This catches problems (DNS, certificates, a whole region) that internal checks miss.

A good health endpoint is cheap and honest:

```python
# Flask example
@app.get("/healthz")
def healthz():
    db_ok = ping_database(timeout_seconds=1)
    return ({"ok": db_ok}, 200 if db_ok else 503)
```

## Writing alarms people trust

An alarm should mean "a human needs to act". For each one decide:

```text
Metric:     StatusCheckFailed for instance practice-vm
Statistic:  Maximum over 1 minute
Threshold:  >= 1 for 2 consecutive periods
Action:     email the on-call address (via an SNS topic)
Runbook:    "Check the console, reboot, check system log, replace from image"
```

Alarm on symptoms users feel (errors, latency, health checks failing) before causes (CPU at 80%). Too many noisy alarms train people to ignore them.

## Billing alerts, revisited

In the first module you created a budget. Now make cost monitoring a habit:

- **Budgets** alert on actual or forecast spend for the month, for the whole account or filtered by service or tag.
- **Cost anomaly detection** (AWS Cost Anomaly Detection, and similar tools on other clouds) flags unusual spend patterns, such as a service that suddenly costs ten times more than usual.
- **Tags** such as `project=practice` and `owner=you` let you see which project is costing what and find forgotten resources.
- **Cost Explorer** (or Azure Cost Management, Google Billing reports) shows spend by service and day. Open it weekly.

Remember: a budget alert notifies, it does not stop resources. The cleanup habit is still yours.

## Worked example: a forgotten resource

You get a budget email: forecast spend is 14 US dollars against a 1-dollar budget. In Cost Explorer, grouped by service, "EC2 - Other" stands out. Grouped by usage type, it shows NAT gateway hours. You left a NAT gateway from a networking tutorial in another region. You delete it, then add a habit: tag everything with `project` and check all regions in the console after each session. Without the alert, that would have run all month.

## Common mistakes

- Alarms with no action, or sending to an inbox nobody reads.
- Only internal checks, so a DNS or certificate failure goes unnoticed.
- Logging secrets or personal data.
- Keeping debug-level logs forever and paying to store them; set retention periods.
- Treating a budget alert as a spending cap.

## Quick recap

- Metrics, logs, traces and alarms answer "what is happening and when must a human act?"
- Health checks run at three levels: status checks, load balancer checks and external probes.
- Budgets, anomaly detection, tags and a weekly cost review catch forgotten resources early.

## Try it

The Do tab has you add an alarm and a cost check to your account, then clean up.


Set a budget alert and a health-check alarm, and know where to look when something breaks.

Monitoring and billing alerts

AWS Budgets Tutorial - Setup Alerts for AWS Billing | Amazon Web Services

Basics of Amazon CloudWatch and CloudWatch Metrics | AWS Tutorials for Beginners

Search a job site for "cloud engineer" or "machine learning engineer" roles in your area. Read ten adverts and tally mentions of AWS, Azure and Google Cloud.

Open the official pages for AWS Certified Cloud Practitioner, Azure Fundamentals (AZ-900) and Google Cloud Digital Leader. For each, note the exam format, the domains and the current price. Write "Checked on" with today's date next to your notes.

Choose one certification and write one sentence explaining why.

Download or open its official exam guide. Make a table mapping each domain to the lessons in this course that cover it, and mark any gaps.

Find the provider's free official learning path and practice questions and bookmark them.

Write a four-week plan (or longer if you have less time) with specific sessions in your calendar, including at least two hands-on free-tier sessions, each ending with cleanup.

Pick a target exam week and write it at the top of your plan.

## Why it matters

Certifications do not replace hands-on skill, but for an entry-level cloud engineer they do two useful things: they give your study a clear syllabus, and they get your CV past filters that look for a recognised credential. Employers hiring cloud engineers usually look for associate-level certifications (for example AWS Solutions Architect Associate or Azure Administrator) plus real projects. A fundamentals certification is the common first step.

## The three foundational certifications

| Certification | Provider | Focus |
|---|---|---|
| [AWS Certified Cloud Practitioner](https://aws.amazon.com/certification/certified-cloud-practitioner/) | AWS | Cloud concepts, security and compliance, core AWS services, billing and pricing |
| [Microsoft Certified: Azure Fundamentals (AZ-900)](https://learn.microsoft.com/en-us/credentials/certifications/azure-fundamentals/) | Microsoft | Cloud concepts, Azure architecture and services, management and governance |
| [Google Cloud Digital Leader](https://cloud.google.com/learn/certification/cloud-digital-leader) | Google Cloud | Digital transformation with Google Cloud, data and AI, infrastructure, security and operations |

Checked on 2026-10-23. Exam codes, domains, prices, languages and validity periods change, so read the official exam guide on each page before you book. Do not rely on numbers in videos or blog posts, including this one.

All three are multiple-choice exams aimed at people new to the platform, and none require a degree or prior certification. They test whether you understand the concepts in this course: service models, regions and zones, shared responsibility, core compute, storage and networking services, IAM, and pricing. Microsoft Learn and AWS Skill Builder offer free official learning paths; Google Cloud Skills Boost has free introductory content.

## Which one first?

- **Look at job adverts** in your area for cloud or ML engineering roles. Count which provider appears most. That is usually your answer.
- If your school or employer already uses one provider, start there: you will get practice for free.
- If you are unsure, AWS has the largest market share, Azure dominates in organisations built on Microsoft 365 and Windows, and Google Cloud is strong in data and machine learning.
- For machine learning engineers, the fundamentals exam is a stepping stone toward the providers' ML or data certifications later.

Doing one fundamentals exam is enough. The concepts transfer, and your next step should be an associate-level certification plus projects, not a second fundamentals badge.

## Building a study plan

A realistic plan for someone who has completed this course is a few weeks of steady study. A sample four-week plan for the AWS exam:

```text
Week 1  Read the official exam guide; map each domain to lessons in this course.
        Work through the free official learning path, domain 1 (cloud concepts).
Week 2  Security and compliance: shared responsibility, IAM, MFA, encryption, audit logs.
        Redo the IAM and Secrets lessons' tasks.
Week 3  Technology and services: compute, storage, databases, networking, global infrastructure.
        Redo the Compute and Storage tasks on the free tier; clean up each time.
Week 4  Billing, pricing and support plans. Take the official practice question set.
        Review every wrong answer until you can explain why the right one is right.
```

Study habits that work:

- **Explain, do not memorise.** If you can explain why multi-AZ survives a zone failure, you can answer any question about it.
- **Keep an "I got this wrong" list** and revisit it every few days.
- **Use official practice questions first**, then reputable free resources. Avoid "exam dumps": using leaked questions breaks the providers' exam agreements and can lead to a revoked certification.
- **Book the exam** once practice scores are consistently comfortable. A date on the calendar focuses study.

## What employers also want

Pair the certificate with evidence. A small public portfolio project, built with infrastructure as code, with a README that explains the architecture, the costs and how you secured it, says far more than a badge. Combine it with the Linux and networking skills from earlier courses, which interviewers test directly.

## Common mistakes

- Collecting several fundamentals certifications instead of moving to associate level.
- Studying only from videos without doing hands-on tasks.
- Leaving free-tier resources running while studying.
- Trusting third-party claims about exam content instead of the official guide.

## Quick recap

- AWS Cloud Practitioner, Azure Fundamentals (AZ-900) and Google Cloud Digital Leader are the entry-level options; pick one based on local job adverts.
- Use the official exam guide and free official training; check details on the provider's page.
- A few focused weeks, hands-on practice and a portfolio project beat memorising questions.

## Try it

In the Do tab you compare the official pages and write your own study plan.


Compare the entry-level cloud certifications and make a realistic study plan for one.

Cloud practitioner exam prep

AZ-900 | Microsoft Azure Fundamentals Full Course, Free Practice Tests, Website and Study Guides

AWS Certified Cloud Practitioner Review and Passing Advice!

Least-privilege IAM, secrets handling, monitoring and billing alerts, and a plan for a cloud fundamentals certification.

Cloud Fundamentals

About this course

Course content

Cloud Concepts

Core Services

Identity and Security

Where this course leads

Next course on the path

Careers that use it