Cloud Computing Cheatsheet — Free Computer Courses

Models

Cloud computing

Renting compute, storage, networking, and managed services over the internet instead of buying and housing all the hardware yourself.

# First credential check (after install/login)
# AWS:   aws sts get-caller-identity
# Azure: az account show
# GCP:   gcloud config get-value project

IaaS

Infrastructure as a Service: you rent VMs, disks, and networks and manage the OS and apps.

# Rough mapping
AWS EC2 / Azure VMs / GCP Compute Engine
You patch the OS; provider runs the hardware

PaaS

Platform as a Service: you deploy code or containers; the provider handles much of the runtime and scaling glue.

# Fit
Web APIs without wanting to manage Linux day to day
Managed app platforms / serverless runtimes

SaaS

Software as a Service: you use a finished application (email, docs, CRM) in a browser or client.

# Examples
Google Workspace, Microsoft 365, many ticketing tools
You manage users and data; vendor runs the app

Public / private / hybrid

Public cloud is shared provider infrastructure. Private is cloud-style for one org. Hybrid connects on-prem with public cloud.

Public   — default for learning
Private  — dedicated / on-prem style
Hybrid   — link both when required

Regions & resilience

Region

A geographic area with provider data centers. Choose near users and for legal/data-residency needs.

# Pick once for a first project
us-east-1 / eastus / us-central1  (examples)
Keep resources in one region to start

Availability zone (AZ)

An isolated location inside a region. Spreading critical pieces across AZs improves resilience to local failures.

# Pattern
App replicas in AZ-a and AZ-b
Same region, separate failure domains

Latency

Round-trip delay between users and your resources. Distant regions add lag for interactive apps.

# Rule of thumb
Users in Europe → prefer an EU region
Batch jobs care less than video calls

High availability idea

Design so one instance or AZ failure does not take the whole service down—replicas, health checks, and multi-AZ when needed.

# Minimal HA sketch
2+ app instances
Load balancer health checks
Managed DB with standby (when offered)

Backups vs HA

High availability keeps a service running through failures. Backups let you restore data after corruption, deletion, or ransomware.

# Both matter
HA → stay online
Backups → recover yesterday's good data

Compute & storage

Virtual machine / instance

A rented server with chosen CPU, memory, disk, and image (OS). You start, stop, and resize within account limits.

# Lifecycle
Create → start → use → stop/terminate
Stopping often still bills for disks

Image / AMI / machine image

A template for the VM's OS and sometimes preinstalled software. Start from a trusted provider or hardened image.

# Practice
Official Ubuntu/Windows images for labs
Avoid random public images for secrets

Object storage

Stores files as objects (blobs) addressed by key—great for backups, media, and static website assets.

# Typical uses
Static site HTML/CSS/JS
Backup archives
User uploads

Block storage

Disk volumes attached to VMs for databases and file systems that need low-latency block I/O.

# Pattern
VM root volume + extra data volume
Snapshot volumes for backup points

File storage

Shared network file systems (NFS-style) when multiple compute instances need a common folder tree.

# When it fits
Shared content for several VMs
Lift-and-shift apps expecting a filesystem

Managed database

Provider-operated database service (patching, backups, failover options) versus installing a DB yourself on a VM.

# Trade-off
Managed: less ops, less deep control
Self-managed on VM: full control, more work

Networking & identity

VPC / virtual network

Your private network space in the cloud: subnets, routes, and isolation from other customers' networks.

# Starter layout
One VPC
Public subnet (optional load balancer)
Private subnet for app/DB

Subnet

A slice of the VPC address space, often tied to an availability zone and a route table.

10.0.1.0/24  public-ish
10.0.2.0/24  private
# Exact design varies by provider wizard

Security group / firewall rules

Stateful allow rules for traffic to/from instances. Default-deny inbound is a common safe starting point.

# Example intent (not a vendor CLI)
Allow 443 from internet → web tier
Allow app port only from web tier → app
Deny all else inbound

IAM user / principal

An identity that can sign in or call APIs—human users, service accounts, or roles assumed temporarily.

# Prefer
Named users or SSO for people
Roles for apps
No long-lived keys in code

Policy & least privilege

Permissions documents that say who can do what on which resources. Grant the minimum needed.

# Habit
Read-only for explorers
Separate deploy role for CI
Review unused permissions

Access keys caution

Long-lived keys are easy to leak in git and screenshots. Prefer short-lived credentials and roles when possible.

# Never
git add secrets.env
# Rotate and delete leaked keys immediately

Cost & security

Pay-as-you-go

Most resources bill by time, size, or data moved. Stopping compute helps; idle disks and IPs can still cost money.

# Cost killers for beginners
Forgotten VMs left on
Large unused disks
Public data egress

Free tier

Limited free usage for new accounts or always-free products. Track end dates and quotas so you are not surprised.

# Checklist
Know free-tier expiry
Set a billing alert
Delete lab resources when done

Billing alerts

Budget thresholds that email or notify you when spend crosses a limit you choose.

# First week setup
Alert at $5 / $10 / $25
Review the bill daily while learning

Shared responsibility

The provider secures the cloud (facilities, hardware, base services). You secure what you put in it (accounts, data, configs, apps).

Provider: data centers, hypervisor, core networking
You: IAM, OS patches (IaaS), encryption choices, app code

Public exposure check

Before demos, confirm storage buckets, databases, and admin ports are not open to the whole internet by accident.

# Quick review
Who can reach port 22/3389?
Is the bucket public?
Are DB ports public?

Operations

Tags / labels

Key-value metadata on resources for cost tracking, ownership, and cleanup (project=lab, owner=you).

project=learning
env=dev
owner=alex

Monitoring & metrics

Numeric signals such as CPU, memory, latency, and error rate that show health over time.

# Starter signals
CPU high for hours?
5xx errors rising?
Disk nearly full?

Logs

Timestamped event records from apps, load balancers, and cloud APIs. Essential for debugging and audits.

# Habit
Centralize important logs
Don't log secrets/passwords
Retain enough to debug last week's issue

Alerts

Notifications when a metric or log pattern crosses a threshold you define—wake people only for actionable issues.

# Example intents
Bill > budget
Instance down
Error rate spike

Static site hosting

Serve HTML/CSS/JS from object storage or a simple web host—often the easiest first cloud deploy.

# Flow
Build files → upload to bucket/host
Enable static website or CDN
Point DNS when ready

Cleanup habit

Delete or stop lab resources when finished. Orphaned disks, snapshots, and load balancers keep charging.

# End-of-lab ritual
Stop/terminate VMs
Delete unused disks & IPs
Confirm bill trend down