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.