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

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.