Tech & AI, Explained

what-is-the-cloud

13 min read

What is “the cloud”?

Status: 🟩 COMPLETE (🟦 LIVING — the providers and their services change frequently) Last updated: 2026-06-19 Plain-English tagline: “The cloud” is other people’s computers, rented by the minute, in giant air-conditioned warehouses called data centers. Three companies (AWS, Google Cloud, Azure) dominate; many smaller players exist; managed services like Vercel + Supabase sit on top of them.

In plain English

The phrase “the cloud” is a great brand and a terrible technical term. It evokes vague fluffiness; the reality is concrete. The cloud is:

  • Big buildings (data centers) full of computers, in many locations around the world
  • Owned by companies that rent out access to those computers
  • Configured so you can spin up a computer, use it, and shut it down — billed by the hour or even by the second
  • Plus a vast catalog of MANAGED SERVICES built on top (databases, file storage, AI, message queues, etc.) so you rarely manage raw machines anymore

The “big three” cloud providers in 2026:

ProviderOwnerNotes
AWS (Amazon Web Services)AmazonThe oldest, largest, most feature-rich; powers ~30% of internet
Google Cloud (GCP)GoogleStrong in AI/ML, data; smaller market share
Microsoft AzureMicrosoftEnterprise-heavy; strong .NET + Office integration

Beyond the big three:

  • Cloudflare — increasingly a full cloud (Workers + R2 + D1)
  • Vercel — Next.js-focused (built ON TOP of AWS)
  • Supabase — Postgres + auth (built on AWS too)
  • Fly.io, Render, Railway — smaller, simpler PaaS alternatives
  • DigitalOcean, Linode, Hetzner — cheaper VPS-style hosting
  • Oracle Cloud, IBM Cloud, Alibaba Cloud — significant in specific markets

For Bible Quest-style projects: George doesn’t directly touch AWS, GCP, or Azure. Vercel + Supabase + Cloudflare cover everything — but ALL THREE are themselves built on the bigger providers. The cloud is below your awareness when using these managed services; only resurfaces when you outgrow them.

For practical hosting, see What is hosting?. This entry is the BIG PICTURE — what “the cloud” is as a concept and an industry.

Why it matters

Three reasons even a non-coder benefits from understanding the cloud:

  1. Almost every modern app runs on it. Your bank, your email, your photos, your Bible Quest — all “in the cloud.” Knowing what that means demystifies a huge chunk of how the world works.

  2. The pricing model affects everything. Cloud bills are by-usage. A misconfigured loop can cost thousands of dollars in a weekend. Understanding the model prevents surprises.

  3. The “shapes” of cloud services explain Vercel / Supabase. Once you know what S3, EC2, RDS, Lambda are, the smaller services become obvious — they’re packaged versions of the underlying pieces.

The trade-off: the full cloud is overwhelming. AWS alone has 200+ services. This entry covers the conceptual map; for any specific service, dive deeper when you need to.

The cloud’s three service models

The classic IaaS / PaaS / SaaS framework. It’s useful even though the lines blur in practice.

1. IaaS — Infrastructure as a Service

You rent VIRTUAL COMPUTERS. You install the OS (or pick a pre-configured image), set up everything yourself, manage security patches, scale up or down by adding/removing VMs.

Examples:

  • AWS EC2 — virtual machines
  • Google Compute Engine
  • Azure Virtual Machines
  • DigitalOcean Droplets
  • Linode

Use cases: workloads that don’t fit serverless (long-running processes, big GPU jobs, custom OS configs).

2. PaaS — Platform as a Service

You give the platform your code. The platform runs it. You don’t manage the OS, web server, scaling. Pick a runtime (Node, Python, etc.), upload code, point a domain at it, done.

Examples:

  • Heroku (the original PaaS)
  • AWS Elastic Beanstalk
  • Render, Railway, Fly.io
  • Vercel, Netlify, Cloudflare Pages (PaaS-adjacent for static + serverless)

Use cases: web apps, APIs, anything that’s “an app you push and the platform runs.”

3. SaaS — Software as a Service

You don’t run code at all. You USE a finished application. Google Workspace, Salesforce, Stripe (from the user’s perspective), Notion — all SaaS.

The line between SaaS and “the rest of the cloud” is fuzzy. SaaS = end-user software hosted on the cloud.

There’s also:

Serverless / FaaS — Functions as a Service

Smaller than PaaS. You upload INDIVIDUAL FUNCTIONS, not whole apps. Each function runs in response to a specific event (HTTP request, schedule, queue message). You pay per execution.

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

See Serverless functions for the deep dive.

Backend-as-a-Service (BaaS)

Packaged backend services so you don’t write one. Auth + database + storage + APIs in one bundle. Supabase, Firebase, AWS Amplify are the modern examples.

The HIERARCHY:

SaaS (end-user apps)
  ↓ built on top of
PaaS / BaaS (whole-app and packaged-backend hosting)
  ↓ built on top of
IaaS (raw VMs and managed services like S3, RDS)
  ↓ built on top of
Physical infrastructure (data centers, fiber, electricity)

Each layer abstracts the one below. You usually pick the HIGHEST layer that fits your needs (least work, fewest knobs).

The big three’s service categories

A simplified map of what each major cloud provides. Categories are universal; service names differ.

Compute

Virtual machines, containers, serverless functions, batch processing.

  • AWS: EC2, ECS, EKS, Lambda, Batch
  • GCP: Compute Engine, GKE, Cloud Functions, Cloud Run
  • Azure: Virtual Machines, AKS, Functions

Storage

Object storage (files), block storage (disks), file storage (NFS), archival.

  • AWS: S3 (object), EBS (block), EFS (file), Glacier (archive)
  • GCP: Cloud Storage, Persistent Disk, Filestore
  • Azure: Blob Storage, Disk Storage, Files

Database

Managed databases — relational, NoSQL, in-memory caches, data warehouses.

  • AWS: RDS (Postgres/MySQL), DynamoDB (NoSQL), ElastiCache (Redis), Redshift (warehouse)
  • GCP: Cloud SQL, Firestore, Memorystore, BigQuery
  • Azure: SQL Database, Cosmos DB, Cache, Synapse

Networking

DNS, load balancers, CDNs, VPNs, firewalls.

  • AWS: Route 53, ELB, CloudFront, VPN, WAF
  • GCP: Cloud DNS, Load Balancing, Cloud CDN
  • Azure: DNS, Load Balancer, CDN, VPN Gateway

Auth + Identity

User management, SSO, secrets.

  • AWS: Cognito, IAM, Secrets Manager
  • GCP: Identity Platform, IAM, Secret Manager
  • Azure: Active Directory, Key Vault

AI / ML

Trained models as APIs, GPU compute, fine-tuning.

  • AWS: Bedrock (foundation models), SageMaker
  • GCP: Vertex AI, Gemini API
  • Azure: OpenAI Service, ML Studio

Messaging / Queues

Event buses, message queues, pub/sub.

  • AWS: SQS, SNS, EventBridge, Kinesis
  • GCP: Pub/Sub, Cloud Tasks
  • Azure: Service Bus, Event Grid

Most projects use a tiny fraction of these. The catalog exists to cover every possible workload.

How pricing typically works

Cloud is mostly PAY-PER-USE. A few patterns:

  • Compute — per second / per minute of running time × resource size
  • Storage — per GB-month × storage class (hot vs cold)
  • Bandwidth (egress) — per GB of data leaving the cloud
  • Requests — per million API calls
  • Database — combination of compute + storage + I/O

The notorious cost categories:

  • Egress bandwidth — surprisingly expensive. Cloudflare R2 famously charges 90/TB).
  • Cross-region transfer — even MORE expensive within the same cloud.
  • Idle resources — a forgotten EC2 instance costs the same whether you use it or not.
  • Misconfigured infinite loops — a Lambda that calls itself can rack up thousands of dollars in hours.

Free tiers exist for almost everything:

  • AWS: 12-month free tier + ongoing always-free for small usage
  • GCP: $300 credit + free tier
  • Azure: $200 credit + free tier
  • Vercel, Netlify, Supabase, Cloudflare: generous free tiers for small projects

For Bible Quest-scale projects: $0/month is realistic on managed services. The bills appear at scale.

A concrete example: where Bible Quest actually runs

Tracing the real infrastructure:

User in Sydney visits stmarkbible.com
  ↓ DNS lookup (Vercel-managed)
  ↓
Vercel Edge Network (runs on Cloudflare + AWS edge POPs globally)
  ↓ routes to nearest edge
  ↓
Vercel Function in syd1 (Sydney) — runs Next.js server code
  Vercel Functions are built on AWS Lambda
  ↓ database query
  ↓
Supabase Postgres in Sydney
  Supabase Postgres runs on AWS RDS (or equivalent)
  ↓ data returned
  ↓
Function returns HTML
  ↓
User's browser renders

NONE of this is George’s code touching AWS directly. The stack is:

  • Vercel handles the function execution (AWS underneath)
  • Supabase handles the database (AWS underneath)
  • Cloudflare handles parts of the edge network

When people say “Bible Quest is in the cloud,” THIS is what they mean. Multiple managed services, each abstracting a piece of AWS or its equivalents.

For most modern webapps: the actual cloud provider is invisible. You pick managed services; they pick their cloud(s) underneath.

When to use the cloud directly vs. managed services

A real decision point as projects grow:

Stay on managed (Vercel + Supabase) when:

  • The project fits the “modern webapp” pattern
  • Free / low tiers cover your needs
  • You want fastest path from idea to live
  • You don’t want to manage infrastructure
  • Your scale is small-to-medium

Move toward raw cloud (AWS / GCP / Azure) when:

  • You’re hitting cost ceilings of managed services
  • You need fine-grained control (specific compute types, custom networking)
  • You have specialized workloads (huge data processing, ML training)
  • Compliance / data residency requires specific control
  • You have a dedicated platform team

For Bible Quest-scale work: stay on managed. The “cloud directly” path is heavyweight; usually only justified above 10x the current scale.

Cloud regions and availability zones

The cloud is geographically distributed. Each provider has:

  • Regions — geographic clusters (US East, Europe West, Sydney, Tokyo, São Paulo, etc.)
  • Availability Zones (AZs) — distinct data centers within a region, isolated from each other

The pattern: a single AZ can fail (power outage, cooling issue). A whole region rarely fails (but has). To achieve high availability:

  • Deploy in MULTIPLE AZs within one region (cheap, easy)
  • Replicate across MULTIPLE regions (expensive, complex)

For small projects: pick one region close to your users and your database. Don’t over-engineer.

For Bible Quest: Vercel functions in syd1 (Sydney), Supabase database in Sydney. Single region. Fine for the scale.

See Regions & edge for the practical view.

Common gotchas

  • Cloud bills can spike unexpectedly. A misconfigured cron job, a runaway script, an infinite recursion, a viral moment + uncapped bandwidth. Always set BUDGET ALERTS in your cloud account.

  • “Free tier” doesn’t mean unlimited. Each free tier has limits (usually generous for personal use; trivially exceeded by production traffic). Read the fine print.

  • Egress is expensive. Pulling 1 TB OUT of AWS S3 costs ~$90. The same TB INTO S3 is free. Plan around this for data-heavy workloads.

  • Reserved instances + savings plans exist. Committing to 1-3 years upfront cuts compute costs by 30-70%. Only relevant if you’re on raw EC2/RDS at scale.

  • Don’t leave instances running. A t3.medium EC2 running 24/7 idle costs ~$30/month. Easy to forget; cumulative.

  • Cross-region traffic is the silent killer. Two services in different regions chatting heavily can rack up huge bandwidth bills.

  • AWS console is famously hostile to newcomers. 200+ services, complex permissions, dense pricing. Most users start with managed wrappers (Vercel, Supabase) precisely to avoid it.

  • IAM (Identity and Access Management) is its own discipline. AWS IAM has hundreds of permissions; getting it wrong = security holes. Managed services hide this from you.

  • Vendor lock-in is real, mostly via APIs. Code using AWS Lambda’s API doesn’t run on GCP Functions without modification. Use abstractions (Serverless Framework, SST) if portability matters.

  • Some “cloud-native” features are deeply provider-specific. AWS DynamoDB, GCP BigQuery, Azure Cosmos — no exact equivalents elsewhere. Adopting them locks you in.

  • The Big Three’s free credit programs are generous. $200-300 of free credit when you sign up. Enough to experiment freely.

  • Egress to the public internet (free tier for users hitting your site) is included; instance-to-instance egress within a region is too. It’s cross-region and cross-cloud where bandwidth costs add up.

  • Cloud SLAs (Service Level Agreements) sound impressive but are limited. “99.99% uptime” means ~52 minutes of allowed downtime per year. SLAs are about credits/refunds, not preventing outages.

  • The cloud has down days. AWS US-East-1 has had multi-hour outages. Major news; small impact on individual sites if you’re not deployed there.

  • Most outages are within ONE region. Multi-region deployment protects against this; almost no one does it for small projects.

  • CloudFormation / Terraform / Pulumi describe infrastructure as code. Define your cloud setup in YAML/HCL/code; check into git; deploy reproducibly. Important at scale; overkill for small projects.

  • “Lift and shift” rarely makes sense. Moving an on-prem app to the cloud as-is misses most cloud benefits. “Re-architect for the cloud” produces the wins.

  • The cloud is mostly LINUX. All major clouds offer Windows VMs (more expensive). Most workloads run on Linux.

  • Data sovereignty / compliance matters. GDPR requires EU data in EU regions. HIPAA has US-specific requirements. CCPA, Australian Privacy Act, etc. Cloud providers all have compliance certifications; matching them to your needs is its own task.

  • A “managed” service is still your responsibility for data. AWS RDS manages the database server; you’re responsible for your data, backups, schema, access patterns. The shared responsibility model varies per service.

  • Cloudflare’s “no egress fees” is a competitive disruption. Pushing other clouds toward more transparent / lower egress pricing.

  • Status pages. Bookmark them: status.aws.amazon.com, status.cloud.google.com, status.azure.com, vercel-status.com, status.supabase.com. When your app misbehaves, check these BEFORE assuming it’s your code.

  • “The cloud” doesn’t mean “the internet.” Many corporate “cloud” deployments are private clouds (on-prem virtualization with cloud-like APIs). Same patterns, different ownership.

  • Serverless billing has minimum execution times. A 50ms function might be billed for 100ms minimum. Adds up at high volume.

  • Some clouds charge for IDLE compute even on serverless. Vercel’s Fluid Compute and Cloudflare Workers bill mostly for active CPU time; AWS Lambda bills for wall-clock duration. Different models, different optimization paths.

  • Multi-cloud is harder than single-cloud. Companies that “go multi-cloud” often regret the operational overhead. For small projects, pick one and stay.

  • The cloud is mostly RELIABLE but never PERFECT. Plan for outages. Implement retries with exponential backoff. Cache aggressively at the edge.

  • AI agents like Claude Code can interact with cloud APIs directly. Be cautious — granting an agent AWS credentials can lead to expensive mistakes. Use scoped IAM roles + spending caps.

  • The cloud generates enormous amounts of telemetry. Most users never look at it. When debugging hard problems, CloudWatch / Stackdriver / Application Insights have answers.

  • Hosting costs ARE part of your business. As traffic scales, infrastructure cost matters. But for the first few years of a project, infrastructure is rarely the bottleneck.

When to learn cloud directly

For most webapp developers, you can ignore the underlying clouds for years. You’ll touch them when:

  • A managed service hits a wall and you need control
  • You join a team that uses AWS / GCP / Azure directly
  • You’re building specialized workloads (ML, data engineering, IoT)
  • You’re starting a company at meaningful scale

Where to start when you do:

  • AWS: the Solutions Architect Associate cert is a solid overview path
  • GCP: Associate Cloud Engineer cert
  • Azure: AZ-900 (Fundamentals) then AZ-104 (Administrator)

The certifications aren’t required but the curriculums are well-designed introductions.

See also

Sources

Graph View

Backlinks