Cloud & Infrastructure

1. What Is "The Cloud"?

Strip away all the marketing, and "the cloud" is just other people's computers that you rent. That's it. When you deploy your app to AWS, your code runs on a physical server sitting in a warehouse (called a data center) owned by Amazon. You don't buy the server. You don't maintain the server. You pay for how much you use.

What Does a Data Center Actually Look Like?

A data center is a massive building full of racks of servers, connected by fiber optic cables, cooled by industrial HVAC systems, and backed by redundant power supplies (including diesel generators for when the grid fails). AWS alone operates 100+ data centers worldwide. Each one looks like this:

  DATA CENTER
  +-------------------------------------------------+
  |                                                 |
  |   +-------+  +-------+  +-------+  +-------+   |
  |   | Rack  |  | Rack  |  | Rack  |  | Rack  |   |
  |   |Server1|  |Server1|  |Server1|  |Server1|   |
  |   |Server2|  |Server2|  |Server2|  |Server2|   |
  |   |Server3|  |Server3|  |Server3|  |Server3|   |
  |   |  ...  |  |  ...  |  |  ...  |  |  ...  |   |
  |   +---+---+  +---+---+  +---+---+  +---+---+   |
  |       |          |          |          |        |
  |   +---+----------+----------+----------+---+    |
  |   |         Network Switch Layer           |    |
  |   +---+------------------------------------+    |
  |       |                                         |
  |   +---+---+   +----------+   +-----------+     |
  |   |Router |   |  Cooling |   |  Backup   |     |
  |   |to ISP |   |  System  |   |  Power    |     |
  |   +-------+   +----------+   +-----------+     |
  |                                                 |
  +-------------------------------------------------+
        |
  To the internet (your users)

Why the Cloud Exists

Before the cloud, if you wanted to launch a web app, you had to:

• Buy physical servers -- $5,000-$50,000 per machine, weeks of lead time
• Rent rack space in a data center (or build your own)
• Hire sysadmins to maintain hardware, replace failed disks, patch OSes
• Guess your capacity -- buy too few servers and you crash on launch day, buy too many and you waste money
• Handle disasters -- what happens when a server catches fire? When the building floods?

The cloud eliminates all of this. You click a button (or run a command), and a virtual server appears in seconds. Need 10 more? Click 10 more times. Traffic drops? Turn them off and stop paying. This is elastic computing, and it changed how software is built.

2. Cloud Providers (AWS, GCP, Azure)

Three companies dominate cloud computing: AWS (Amazon), Azure (Microsoft), and GCP (Google). Together they hold about 65% of the market. There are also strong alternatives: DigitalOcean, Linode (now Akamai), Hetzner, Vultr, and Cloudflare.

The Big Three Compared

Service Name Rosetta Stone

Every provider has the same core services -- they just give them different names. Here's how to translate:

3. Core Cloud Services

Every cloud provider offers hundreds of services, but you only need to understand about 5-6 core ones to be productive. Everything else is built on top of these fundamentals.

Compute (EC2 / VMs)

A virtual machine in the cloud. You choose the CPU, RAM, and disk size. You get root access. It's like having a remote computer you can SSH into. This is the most fundamental cloud service -- everything else can theoretically run on a VM.

# Launch an EC2 instance (AWS CLI)
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0

# SSH into it
ssh -i my-key-pair.pem ec2-user@54.123.45.67

# Common instance types (AWS):
# t3.micro  -- 2 vCPU,  1 GB RAM  -- free tier, dev/test
# t3.medium -- 2 vCPU,  4 GB RAM  -- small apps
# m6i.large -- 2 vCPU,  8 GB RAM  -- general purpose
# c6i.large -- 2 vCPU,  4 GB RAM  -- CPU-intensive (compute-optimized)
# r6i.large -- 2 vCPU, 16 GB RAM  -- memory-intensive (databases, caching)

Storage (S3 / Blob)

Object storage for files of any size -- images, videos, backups, logs, static websites. You upload objects into "buckets" (containers). Each object gets a unique key (like a file path). S3 has 99.999999999% (eleven 9s) durability -- meaning if you store 10 million objects, you might lose 1 every 10,000 years.

# Upload a file to S3
aws s3 cp ./backup.tar.gz s3://my-bucket/backups/backup-2024-01-15.tar.gz

# List bucket contents
aws s3 ls s3://my-bucket/backups/

# Download a file
aws s3 cp s3://my-bucket/backups/backup-2024-01-15.tar.gz ./

# Sync a directory (like rsync)
aws s3 sync ./dist s3://my-website-bucket/ --delete

Databases (RDS)

Managed database services. You pick the engine (PostgreSQL, MySQL, etc.) and the instance size. The cloud provider handles backups, patching, replication, and failover. You just connect and run queries.

# What "managed" means -- the provider handles:
# - Automated daily backups (point-in-time recovery)
# - OS and database engine patching
# - Multi-AZ failover (automatic switch to standby if primary dies)
# - Read replicas (for scaling reads)
# - Monitoring and alerts
# - Storage auto-scaling

# You handle:
# - Schema design
# - Query optimization
# - Application-level connection pooling
# - Access control (who can connect)

Networking (VPC)

A Virtual Private Cloud is your own private network in the cloud. It's like having your own isolated section of the data center. You control which resources can talk to each other, which can access the internet, and which ports are open.

  YOUR VPC (10.0.0.0/16)
  +---------------------------------------------------+
  |                                                   |
  |  Public Subnet (10.0.1.0/24)                      |
  |  +---------------------------------------------+  |
  |  | Load Balancer  --->  Web Server (EC2)        |  |
  |  +---------------------------------------------+  |
  |         |                                         |
  |  Private Subnet (10.0.2.0/24)                     |
  |  +---------------------------------------------+  |
  |  | App Server (EC2)  --->  Database (RDS)       |  |
  |  +---------------------------------------------+  |
  |                                                   |
  +---------------------------------------------------+
        |
   Internet Gateway (only public subnet has access)

CDN (CloudFront / Cloud CDN)

A Content Delivery Network caches your content at edge locations around the world. When a user in Tokyo requests your image, they get it from a server in Tokyo instead of your origin server in Virginia. This reduces latency from ~200ms to ~20ms. More on this in Section 9.

4. IaaS vs PaaS vs SaaS vs FaaS

These acronyms describe how much the provider manages for you. Think of it as a spectrum from "you manage everything" to "you manage nothing".

  What YOU manage vs what the PROVIDER manages:

  On-Premise   IaaS         PaaS         FaaS         SaaS
  (you own     (rent        (rent        (rent        (rent
   everything)  hardware)    platform)    functions)   software)

  +----------+ +----------+ +----------+ +----------+ +----------+
  |   App    | |   App    | |   App    | | Function | |          |
  +----------+ +----------+ +----------+ +----------+ |          |
  | Runtime  | | Runtime  | |##########| |##########| |          |
  +----------+ +----------+ +----------+ +----------+ |  Gmail   |
  |    OS    | |    OS    | |##########| |##########| |  Slack   |
  +----------+ +----------+ +----------+ +----------+ | Shopify  |
  |   Disk   | |##########| |##########| |##########| |          |
  +----------+ +----------+ +----------+ +----------+ |          |
  | Network  | |##########| |##########| |##########| |          |
  +----------+ +----------+ +----------+ +----------+ +----------+

  [  = You manage ]     [## = Provider manages ]

IaaS -- Infrastructure as a Service

You rent the hardware (virtual machines, networking, storage). You install and manage everything on top: the OS, runtime, app, security patches.

Examples: AWS EC2, GCP Compute Engine, DigitalOcean Droplets, Hetzner Cloud

Use when: You need full control. Custom OS configurations. Running software that doesn't fit into platform constraints. You have the ops expertise to manage it.

# You spin up a VM, then you're responsible for everything:
ssh root@your-server
apt update && apt upgrade              # You patch the OS
apt install nodejs nginx postgresql    # You install dependencies
git clone your-repo && npm install     # You deploy your code
systemctl enable nginx                 # You configure the web server
certbot --nginx                        # You manage SSL certificates
# ...and you set up monitoring, backups, firewalls, log rotation

PaaS -- Platform as a Service

You give the provider your code, and they handle the rest -- servers, OS, runtime, scaling, SSL, deployments. You just git push.

Examples: Heroku, Vercel, Netlify, Railway, Render, Fly.io, Google App Engine

Use when: You want to ship fast without managing infrastructure. Small teams. Prototypes. Apps that fit standard patterns.

# Heroku: deploy a Node.js app
git push heroku main
# That's it. Heroku detects Node.js, installs dependencies,
# starts your server, gives you a URL, handles SSL, and scales.

# Vercel: deploy a Next.js app
vercel --prod
# Builds, deploys to edge network, SSL, custom domain, done.

# Railway: deploy anything with a Dockerfile
railway up
# Detects Dockerfile, builds, deploys, gives you a URL.

SaaS -- Software as a Service

You don't manage anything. You just use the software through a browser or API. The provider handles everything -- infrastructure, updates, security, availability.

Examples: Gmail, Slack, Shopify, GitHub, Notion, Stripe, Twilio

Use when: The software does what you need out of the box. You're a user, not a builder (for that specific function).

FaaS -- Functions as a Service

You write individual functions. The provider runs them when triggered (HTTP request, file upload, timer, queue message). No servers to manage. You pay per execution, not per hour. More on this in Section 5.

Examples: AWS Lambda, Google Cloud Functions, Cloudflare Workers, Azure Functions

5. Serverless

Serverless is the most misnamed concept in computing. There are servers -- you just don't think about them. You write a function, upload it, and the cloud provider runs it whenever it's triggered. You don't provision VMs, you don't manage scaling, you don't patch anything. You pay only when your code actually runs.

AWS Lambda Example

// handler.js -- an AWS Lambda function
// This function runs when triggered (HTTP request, S3 upload, etc.)

exports.handler = async (event) => {
  // event contains the trigger data (request body, S3 event, etc.)
  const name = event.queryStringParameters?.name || "World";

  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: `Hello, ${name}!`,
      timestamp: new Date().toISOString(),
    }),
  };
};

// Deploy with AWS CLI:
// aws lambda create-function \
//   --function-name hello \
//   --runtime nodejs20.x \
//   --handler handler.handler \
//   --zip-file fileb://function.zip \
//   --role arn:aws:iam::123456789:role/lambda-role

Cloudflare Workers Example

// worker.js -- runs at the edge (200+ locations worldwide)
// Response time: ~10ms because it runs near the user

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/hello") {
      return new Response(JSON.stringify({ message: "Hello from the edge!" }), {
        headers: { "Content-Type": "application/json" },
      });
    }

    return new Response("Not Found", { status: 404 });
  },
};

// Deploy: wrangler deploy

Cold Starts -- The Serverless Tax

When a serverless function hasn't been called recently, the provider needs to spin up a new execution environment (load your code, initialize the runtime, run your initialization code). This is called a cold start, and it adds latency to the first request.

When to Use Serverless (and When NOT To)

6. CI/CD (Continuous Integration & Deployment)

CI/CD automates the process of testing, building, and deploying your code. Without it, deployments are manual, error-prone, and scary. With it, you push code to Git and it automatically gets tested and deployed. This is how professional teams ship software.

  Developer pushes code to GitHub
       |
       v
  +--------------------+
  |  CI Pipeline Runs  |  (automated)
  |  - Install deps    |
  |  - Lint code       |
  |  - Run tests       |
  |  - Build project   |
  +---------+----------+
            |
       Tests pass?
       /         \
     YES          NO
      |            |
      v            v
  +--------+   +----------+
  | Deploy |   | Notify   |
  | to     |   | developer|
  | prod   |   | (fix it) |
  +--------+   +----------+

GitHub Actions -- The Most Common CI/CD Tool

GitHub Actions runs workflows defined in YAML files inside your repo (.github/workflows/). Workflows are triggered by events (push, pull request, schedule, manual). Each workflow has jobs, and each job has steps.

# .github/workflows/ci.yml
name: CI/CD Pipeline

# When to run
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest      # GitHub provides the VM

    steps:
      # 1. Check out your code
      - uses: actions/checkout@v4

      # 2. Set up Node.js
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'           # Cache node_modules between runs

      # 3. Install dependencies
      - run: npm ci

      # 4. Lint
      - run: npm run lint

      # 5. Run tests
      - run: npm test

      # 6. Build
      - run: npm run build

  deploy:
    needs: test                  # Only runs if "test" job passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'  # Only deploy from main branch

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci
      - run: npm run build

      # Deploy to your hosting provider
      - name: Deploy to production
        run: |
          npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

A Real-World Workflow: Docker Build + Deploy

# .github/workflows/deploy.yml
name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # Log into Docker Hub (or ECR, GHCR)
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      # Build and push Docker image
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: myuser/myapp:latest,myuser/myapp:${{ github.sha }}

      # Deploy to server via SSH
      - name: Deploy
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull myuser/myapp:latest
            docker stop myapp || true
            docker rm myapp || true
            docker run -d --name myapp \
              -p 80:3000 \
              --env-file /home/deploy/.env \
              myuser/myapp:latest

7. Infrastructure as Code

Infrastructure as Code (IaC) means defining your cloud resources in code files instead of clicking through a web console. Your servers, databases, networks, DNS records -- all described in text files that live in Git. This makes infrastructure reproducible, reviewable, and version-controlled.

Declarative vs Imperative

# IMPERATIVE (scripts): "Here are the steps to get there"
# Like giving someone turn-by-turn directions
aws ec2 create-security-group --group-name web-sg --description "Web SG"
aws ec2 authorize-security-group-ingress --group-name web-sg --port 80 --cidr 0.0.0.0/0
aws ec2 run-instances --instance-type t3.micro --security-groups web-sg
# Problem: run it twice and you get TWO servers. Not idempotent.

# DECLARATIVE (Terraform/CloudFormation): "Here's what I want to exist"
# Like showing someone a photo of where you want to go
resource "aws_instance" "web" {
  instance_type = "t3.micro"
  ami           = "ami-0c55b159cbfafe1f0"
}
# Run it twice and Terraform says "already exists, nothing to do."
# Change instance_type and Terraform updates only what changed.

Terraform -- The Most Popular IaC Tool

Terraform by HashiCorp works with every cloud provider (and many other services like GitHub, Cloudflare, Datadog). You write .tf files using HCL (HashiCorp Configuration Language), then Terraform figures out what needs to be created, updated, or destroyed.

# main.tf -- Define your infrastructure

# Tell Terraform which providers to use
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure the AWS provider
provider "aws" {
  region = "us-east-1"
}

# Create a VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "my-app-vpc"
  }
}

# Create a public subnet
resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "public-subnet"
  }
}

# Create an EC2 instance
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type     # Variable -- configurable
  subnet_id     = aws_subnet.public.id  # Reference another resource

  tags = {
    Name        = "web-server"
    Environment = var.environment
  }
}

# Create an RDS database
resource "aws_db_instance" "postgres" {
  engine            = "postgres"
  engine_version    = "16"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  db_name           = "myapp"
  username          = "appuser"
  password          = var.db_password  # From variable (never hardcode)

  skip_final_snapshot = true  # For dev environments
}

# variables.tf -- Define configurable values
variable "instance_type" {
  description = "EC2 instance type"
  default     = "t3.micro"
}

variable "environment" {
  description = "Environment name"
  default     = "development"
}

variable "db_password" {
  description = "Database password"
  sensitive   = true  # Won't show in logs/output
}

Terraform Workflow

# 1. Initialize (download provider plugins)
terraform init

# 2. Plan (preview what will change -- ALWAYS do this)
terraform plan
# Output:
# + aws_instance.web will be created
# + aws_db_instance.postgres will be created
# Plan: 2 to add, 0 to change, 0 to destroy.

# 3. Apply (create/update resources)
terraform apply
# Type "yes" to confirm (or use -auto-approve in CI)

# 4. Destroy (tear down everything -- careful!)
terraform destroy

8. Load Balancers

A load balancer sits in front of multiple servers and distributes incoming requests across them. Without one, a single server handles all traffic and becomes a bottleneck (and a single point of failure). With one, you can scale to any number of servers and survive individual server failures.

  Without Load Balancer:                With Load Balancer:

  Users ---> [Server]                   Users ---> [Load Balancer]
             (single point                         /     |      \
              of failure)                      [Srv 1] [Srv 2] [Srv 3]
                                               (any server can die,
                                                users don't notice)

Layer 4 vs Layer 7 Load Balancers

Load balancers operate at different layers of the networking stack, which determines what information they can see and use for routing decisions.

# With a Layer 7 load balancer, you can route based on URL path:
#
# /api/*        --> API servers (backend cluster)
# /images/*     --> Image processing servers
# /admin/*      --> Admin dashboard servers
# /*            --> Frontend servers
#
# Or route based on hostname:
#
# api.example.com    --> API cluster
# www.example.com    --> Web frontend cluster
# admin.example.com  --> Admin cluster
#
# This is impossible with Layer 4 -- it can't see the URL or hostname.

Load Balancing Algorithms

# How the load balancer decides which server gets the next request:

# 1. ROUND ROBIN (simplest, most common)
# Request 1 -> Server A
# Request 2 -> Server B
# Request 3 -> Server C
# Request 4 -> Server A (back to start)
# Good for: servers with equal capacity

# 2. WEIGHTED ROUND ROBIN
# Server A (weight 3): gets 3 out of every 6 requests
# Server B (weight 2): gets 2 out of every 6 requests
# Server C (weight 1): gets 1 out of every 6 requests
# Good for: servers with different capacities

# 3. LEAST CONNECTIONS
# Send to the server with the fewest active connections
# Good for: requests that take variable time (some fast, some slow)

# 4. IP HASH
# Hash the client's IP to consistently route to the same server
# Good for: session stickiness without cookies
# Problem: if a server dies, all its clients get reassigned

# 5. LEAST RESPONSE TIME
# Send to the server that's responding fastest right now
# Good for: maximizing performance when servers have varying load

Health Checks

The load balancer regularly pings your servers to check if they're alive. If a server stops responding, the load balancer stops sending traffic to it. When it recovers, traffic resumes.

# Health check configuration (AWS ALB example):
#
# Protocol:      HTTP
# Path:          /health
# Port:          3000
# Interval:      30 seconds (check every 30s)
# Timeout:       5 seconds (wait 5s for response)
# Healthy:       3 consecutive successes = server is healthy
# Unhealthy:     2 consecutive failures = server is unhealthy

# Your app needs a health endpoint:
app.get("/health", (req, res) => {
  // Check dependencies
  const dbHealthy = await checkDatabase();
  const cacheHealthy = await checkRedis();

  if (dbHealthy && cacheHealthy) {
    res.status(200).json({ status: "ok" });
  } else {
    res.status(503).json({ status: "unhealthy", db: dbHealthy, cache: cacheHealthy });
  }
});

9. CDNs (Content Delivery Networks)

A CDN caches copies of your content at servers spread across the globe (called edge nodes or PoPs -- Points of Presence). When a user requests your image, JavaScript file, or API response, they get it from the nearest edge node instead of your origin server thousands of miles away.

  Without CDN:                          With CDN:

  User in Tokyo                         User in Tokyo
       |                                     |
       | 200ms round trip                    | 10ms round trip
       |                                     |
       v                                     v
  Server in Virginia                    Edge node in Tokyo
                                             |
                                        (cache miss? fetch from origin)
                                             |
                                             v
                                        Server in Virginia

What Should You Put Behind a CDN?

Cache-Control Headers

# You control CDN caching through HTTP headers:

# Cache for 1 year (static assets with hashed filenames)
Cache-Control: public, max-age=31536000, immutable
# "public" = CDN can cache it
# "immutable" = don't even check for updates (filename changes instead)

# Cache for 5 minutes, revalidate after
Cache-Control: public, max-age=300, stale-while-revalidate=60
# Serve cached copy for 300s. After that, serve stale for 60s
# while fetching fresh copy in background.

# Don't cache (user-specific data)
Cache-Control: private, no-store
# "private" = only browser can cache, not CDN
# "no-store" = don't cache at all

# Cache but always revalidate (HTML pages)
Cache-Control: public, no-cache
# "no-cache" doesn't mean "don't cache" -- it means
# "cache it, but check with origin before using it" (via ETag/If-Modified-Since)

Major CDN Providers

10. Object Storage

Object storage is a flat storage system where every item (called an "object") gets a unique key. Unlike a filesystem with directories and nested folders, object storage is a giant key-value store. The key looks like a path (images/avatars/user-123.jpg), but there's no actual directory structure -- it's just a string.

S3 -- The Standard

# AWS S3 CLI basics

# Create a bucket
aws s3 mb s3://my-app-uploads-prod

# Upload a file
aws s3 cp ./photo.jpg s3://my-app-uploads-prod/avatars/user-123.jpg

# Download a file
aws s3 cp s3://my-app-uploads-prod/avatars/user-123.jpg ./downloaded.jpg

# List objects
aws s3 ls s3://my-app-uploads-prod/avatars/

# Delete an object
aws s3 rm s3://my-app-uploads-prod/avatars/user-123.jpg

# Sync a directory
aws s3 sync ./uploads s3://my-app-uploads-prod/ --delete

Uploading from Your App

// Node.js: Upload to S3 using AWS SDK v3
const { S3Client, PutObjectCommand, GetObjectCommand } = require("@aws-sdk/client-s3");
const { getSignedUrl } = require("@aws-sdk/s3-request-presigner");

const s3 = new S3Client({ region: "us-east-1" });

// Direct upload from your server
async function uploadFile(buffer, key, contentType) {
  await s3.send(new PutObjectCommand({
    Bucket: "my-app-uploads-prod",
    Key: key,                        // e.g., "avatars/user-123.jpg"
    Body: buffer,                    // File contents as Buffer
    ContentType: contentType,        // e.g., "image/jpeg"
  }));

  return `https://my-app-uploads-prod.s3.amazonaws.com/${key}`;
}

// Express route: handle file upload
app.post("/api/upload", upload.single("file"), async (req, res) => {
  const key = `uploads/${Date.now()}-${req.file.originalname}`;
  const url = await uploadFile(req.file.buffer, key, req.file.mimetype);
  res.json({ url });
});

Presigned URLs -- The Production Pattern

Instead of uploading files through your server (which uses your bandwidth and CPU), generate a presigned URL that lets the client upload directly to S3. Your server never touches the file.

// Step 1: Client requests an upload URL from your API
// Step 2: Your API generates a presigned S3 URL
// Step 3: Client uploads directly to S3 using that URL
// Step 4: Client tells your API the upload is done

// Server: generate presigned upload URL
app.post("/api/upload-url", async (req, res) => {
  const { filename, contentType } = req.body;
  const key = `uploads/${req.user.id}/${Date.now()}-${filename}`;

  const command = new PutObjectCommand({
    Bucket: "my-app-uploads-prod",
    Key: key,
    ContentType: contentType,
  });

  // URL is valid for 15 minutes
  const uploadUrl = await getSignedUrl(s3, command, { expiresIn: 900 });

  res.json({ uploadUrl, key });
});

// Client: upload directly to S3
const { uploadUrl } = await fetch("/api/upload-url", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ filename: "photo.jpg", contentType: "image/jpeg" }),
}).then(r => r.json());

// Upload file directly to S3 (bypasses your server entirely)
await fetch(uploadUrl, {
  method: "PUT",
  headers: { "Content-Type": "image/jpeg" },
  body: fileBlob,  // The actual file
});

S3-Compatible Alternatives

11. Managed Databases

A managed database is a database where the cloud provider handles all the operational work -- backups, patching, replication, failover, monitoring, scaling. You just connect and run queries. The alternative is running your own database on a VM (or bare metal), which means you're responsible for everything.

Managed vs Self-Hosted

Popular Managed Database Services

Traditional Cloud (AWS, GCP, Azure)

Modern Database Platforms

Connection Strings

# Every managed database gives you a connection string. Format:
# protocol://username:password@host:port/database?options

# PostgreSQL (RDS, Neon, Supabase)
postgresql://appuser:secret@db.abc123.us-east-1.rds.amazonaws.com:5432/myapp?sslmode=require

# MySQL (PlanetScale)
mysql://username:password@aws.connect.psdb.cloud/mydb?ssl={"rejectUnauthorized":true}

# Redis (Upstash)
rediss://default:token@usw1-capable-toucan-12345.upstash.io:6379

# ALWAYS:
# - Use SSL/TLS (sslmode=require or ?ssl=true)
# - Store connection strings in environment variables, NEVER in code
# - Use connection pooling (PgBouncer, Prisma pool, etc.)
# - Restrict access to your VPC / allowed IP addresses

12. Cloud Costs & Avoiding Bill Shock

Cloud billing is designed to be complex. Every service has its own pricing model with multiple dimensions (compute, storage, network, requests, data transfer). People routinely wake up to unexpected $500 bills from leaving a test cluster running or misconfiguring auto-scaling. Understanding cloud costs is a survival skill.

How Cloud Billing Works

# Cloud costs have multiple dimensions. Here's a typical web app:

# 1. COMPUTE (EC2 / VMs)
#    Billed per second (or hour) the instance is running
#    t3.micro: ~$0.0104/hour = ~$7.50/month (running 24/7)
#    t3.medium: ~$0.0416/hour = ~$30/month
#    GOTCHA: Instances bill even when idle. Stop/terminate when not needed.

# 2. STORAGE (EBS / disks attached to VMs)
#    Billed per GB per month
#    gp3 (SSD): $0.08/GB/month. 100GB = $8/month
#    GOTCHA: Volumes persist after instance termination. Delete them manually.

# 3. DATA TRANSFER (bandwidth)
#    Inbound: FREE (data going INTO AWS)
#    Outbound: $0.09/GB (data leaving AWS to the internet)
#    Between AZs: $0.01/GB (data between availability zones)
#    GOTCHA: This is the hidden killer. Serving 10TB/month = $900.

# 4. OBJECT STORAGE (S3)
#    Storage: $0.023/GB/month
#    Requests: $0.0004 per 1,000 GET requests
#    Egress: $0.09/GB (same as data transfer)
#    GOTCHA: Millions of tiny objects = expensive from requests, not storage.

# 5. DATABASE (RDS)
#    Instance: $15-$500+/month depending on size
#    Storage: $0.115/GB/month (gp3)
#    Backups: Free up to 100% of DB storage, then $0.095/GB
#    GOTCHA: Multi-AZ doubles the instance cost.

Free Tier Gotchas

Cost Optimization Tips

# 1. RIGHT-SIZE YOUR INSTANCES
# Most instances are over-provisioned. Monitor CPU/RAM usage.
# If your t3.medium (4GB RAM) never uses more than 1.5GB,
# switch to t3.small (2GB RAM) and save 50%.

# 2. USE RESERVED INSTANCES OR SAVINGS PLANS
# Commit to 1 or 3 years of usage for 30-60% discount.
# Only for stable, predictable workloads.
# AWS: Reserved Instances or Savings Plans
# GCP: Committed Use Discounts

# 3. USE SPOT INSTANCES FOR FAULT-TOLERANT WORK
# Spot/Preemptible VMs cost 60-90% less than on-demand.
# AWS can reclaim them with 2 minutes notice.
# Good for: batch processing, CI/CD runners, data pipelines
# Bad for: web servers, databases, anything stateful

# 4. PUT A CDN IN FRONT OF EVERYTHING
# Reduce origin data transfer (the expensive part)
# Cloudflare free tier = $0 for unlimited bandwidth
# That $900/month S3 egress bill becomes $50/month with a CDN.

# 5. USE S3 STORAGE CLASSES
# S3 Standard:              $0.023/GB  (frequently accessed)
# S3 Infrequent Access:     $0.0125/GB (accessed once a month)
# S3 Glacier Instant:       $0.004/GB  (archival, rare access)
# S3 Glacier Deep Archive:  $0.00099/GB (accessed once a year)
# Set up lifecycle policies to automatically move old data to cheaper tiers.

# 6. USE SERVERLESS FOR VARIABLE WORKLOADS
# A t3.small running 24/7 costs ~$15/month even when idle.
# Lambda costs $0 when not running.
# For APIs with <100K requests/month, serverless is nearly free.

# 7. AVOID NAT GATEWAYS IF POSSIBLE
# $32/month + data transfer for a NAT Gateway.
# Alternatives: VPC endpoints for AWS services ($0),
# or put your resources in public subnets with security groups.

# 8. SCHEDULE NON-PRODUCTION RESOURCES
# Dev/staging environments don't need to run 24/7.
# Run them 10 hours/day, 5 days/week = 70% cost reduction.
# Use AWS Instance Scheduler or a simple cron + Lambda.

Monthly Cost Estimates for Common Setups