🧩 Cloud Services for Web Apps

The Anatomy of a Web App

When a user visits your site, a surprising number of services cooperate in the few hundred milliseconds before the page appears. Think of building a web app in the cloud like running a restaurant. You could own the building, buy every appliance, and hire every specialist — but you'd spend all your energy on plumbing instead of food. Instead, you rent a fully-equipped space and buy specialized services, so you can focus on your actual product.

Almost every web application, regardless of provider, is assembled from the same seven categories of service:

Compute: Running Your Code

Compute is where your Node.js server, your API, your rendering logic actually runs. You have four broad choices, from most control to least effort. The right one depends on how much of the machine you want to manage.

Containers & serverless in practice

For most full-stack apps today, a managed container platform hits the sweet spot: you package your app once with Docker and the platform runs, scales, and heals it. Here's a Node app deployed to Google Cloud Run — the same idea works on AWS App Runner or Azure Container Apps.

# 1. Build and push your container image
gcloud builds submit --tag gcr.io/PROJECT_ID/web-app

# 2. Deploy it — scales to zero when idle, up on demand
gcloud run deploy web-app \
  --image gcr.io/PROJECT_ID/web-app \
  --platform managed \
  --region us-central1 \
  --memory 512Mi \
  --min-instances 0 \
  --max-instances 10 \
  --allow-unauthenticated

The matching Dockerfile is small and standard:

# Dockerfile for a Node web app
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev      # reproducible, production-only install
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

For truly spiky or event-driven work — a webhook handler, an image resizer, a scheduled cleanup — serverless functions shine because they cost nothing when idle:

// AWS Lambda handler — invoked per request, scales automatically
exports.handler = async (event) => {
  const body = JSON.parse(event.body || "{}");
  const name = body.name || "World";

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

Managed Databases

You could install PostgreSQL on a VM and manage it yourself — but then you own backups, security patches, replication, failover, and the 2 a.m. page when the disk fills up. A managed database hands all of that to the provider. You get a connection string; they keep it alive.

Managed databases give you production-grade reliability out of the box: multi-AZ replication (a standby in another data center takes over if the primary fails), automated backups with point-in-time recovery, and read replicas to spread heavy read traffic.

Object Storage

Where do user-uploaded profile photos, PDFs, video, and your app's build artifacts go? Not on your app server's disk — that disk vanishes when the instance restarts, and it doesn't scale. The answer is object storage: effectively infinite, cheap, durable buckets of files, each addressable by a URL.

• Durability — providers replicate objects across facilities, quoting eleven nines (99.999999999%) of durability. Files effectively don't get lost.
• Scalability — store one file or one billion; the service doesn't care.
• Cheap — pennies per gigabyte per month, with even cheaper "cold" tiers for archives.
• Web-native — serve files directly, or better, put a CDN in front.

CDN, DNS & Load Balancer: Getting the Request There

These three services form the front door of your application. Together they turn a typed URL into a fast, reliable response.

DNS — the address book

When someone types yourapp.com, DNS (Route 53, Azure DNS, Cloud DNS) translates that name into an IP address — the internet's phone book. It also lets you route traffic geographically or fail over to a backup region.

CDN — the local warehouse

A CDN (CloudFront, Front Door, Cloud CDN) caches copies of your static content — HTML, CSS, JS bundles, images — at edge locations around the world. A user in Tokyo is served from a Tokyo edge instead of waiting for a round-trip to Virginia. This is the single biggest, cheapest performance win most sites can make.

Load balancer — the host at the door

A load balancer sits in front of multiple app instances and distributes incoming requests among them. If one instance dies, the balancer stops sending it traffic; when you add instances, it starts using them. It's what makes horizontal scaling and zero-downtime deploys possible.

Secrets Management

Your app needs database passwords, third-party API keys, signing tokens. Where do they go? Never in your source code, and never committed to Git. The professional answer is a managed secrets service (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) that stores credentials encrypted and hands them to your app at runtime.

// Fetch a secret at runtime instead of hard-coding it.
// The app authenticates via its cloud role — no key needed in code.
import { SecretsManagerClient, GetSecretValueCommand }
  from "@aws-sdk/client-secrets-manager";

const client = new SecretsManagerClient({ region: "us-east-1" });

async function getDbPassword() {
  const res = await client.send(
    new GetSecretValueCommand({ SecretId: "prod/db/password" })
  );
  return JSON.parse(res.SecretString).password;
}

A Reference Architecture

Let's assemble everything into one coherent picture — a typical production web application. Trace a request from the top and you'll see all seven services doing their jobs.

Notice the shape: static content (the React build, images) is served straight from object storage through the CDN, never touching your compute. Only dynamic requests (API calls) pass the load balancer to your compute layer, which reads and writes the database, caches hot data in Redis, stores uploads in object storage, and pulls credentials from the secrets manager. This separation is what lets a small app scale to millions of users without re-architecting.

Practice & Quiz

Best Practices & Pitfalls

✅ Do

• Serve static assets from object storage through a CDN, not from your app server
• Use a managed database so backups, patching, and failover are handled for you
• Store uploads in object storage, ideally via presigned URLs
• Pull secrets from a secrets manager in production; use .env locally
• Put a load balancer in front of compute so you can scale and deploy without downtime

❌ Don't

• Write uploaded files to a server's local disk — it's ephemeral and unshared
• Commit API keys or passwords to Git, ever
• Run your own database on a VM unless you truly need that control
• Forget cold starts when choosing serverless for latency-critical paths

Summary

📚 Additional Resources

• AWS — Web application reference architectures
• Google Cloud — Web serving architecture overview
• Azure — Basic web application architecture
• The Twelve-Factor App methodology

🚀 What's Next?

You now know what services a web app uses. The next lesson tackles the question that follows every architecture decision: how do you keep the bill under control? Next up is Cost Optimization Strategies.