Cloud Fundamentals
Beginner 12 min read Cloud Fundamentals

Cloud Computing Fundamentals

Cloud computing is on-demand access to compute, storage and network resources over the internet. Learn the service models (IaaS/PaaS/SaaS), the shared responsibility model, and why the CAPEX to OPEX shift changed how teams run software.

IaaSPaaSSaaSshared responsibilityCAPEXOPEXon-demandelasticityNIST SP 800-145
Introduction

What is this?

Cloud computing is the delivery of computing resources — servers, storage, databases, networking, software — on demand over the internet with pay-as-you-go pricing. Instead of buying hardware months in advance, you provision exactly what you need when you need it. NIST SP 800-145 defines the five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.

Motivation

Why do you need it?

  • Almost every DevOps workflow you will run targets a cloud provider, so the mental model matters before any console or CLI.
  • The shared responsibility model decides who patches what — a question that shows up in every incident and every audit.
  • Choosing IaaS, PaaS or SaaS changes how much infrastructure code your team owns.
  • The CAPEX to OPEX shift drives budget conversations, right-sizing decisions and FinOps practices.
  • Cloud abstractions (VPCs, object storage, serverless) map one-to-one onto the modules in this track.
Think about it

Mental model

Imagine

The electricity grid

Think of

Cloud computing

You do not build a power plant for your office; you pay the utility for exactly the kilowatt-hours you use, and capacity is there on demand. Cloud works the same way for servers, storage and databases — pay for what you consume, scale when you need to, and leave the power plant (data centers) to the provider.

Mechanics

How it works

  • A provider like AWS, Azure or Google Cloud builds and operates massive data centers with pooled compute, storage and network capacity.
  • You request resources through a self-service control plane — a web console, CLI or API — and the provider provisions them in seconds.
  • Billing is metered per unit consumed (instance-hours, GB stored, requests, data transferred) rather than a fixed capital purchase.
  • Elasticity lets the platform add or remove capacity automatically to match demand, from a single VM to thousands of servers.
  • The provider exposes guarantees (availability, durability, SLAs) and you remain responsible for everything above the abstraction you chose.

How a cloud resource is provisioned and consumed.

You request a resource
Control plane
Resource pool
Provisioned
Metering
You manage what you own
Reference

Key commands

curl -s http://169.254.169.254/latest/meta-data/instance-type

Ask the instance metadata service what VM size you are running on.

env

List environment variables injected into the instance at boot.

date -u

Show UTC time — cloud logs and billing are recorded in UTC.

uname -a

Print the kernel and architecture of the running OS.

free -m

Show memory usage in MB — the first place to look when sizing an instance.

Hands-on

Examples

Discover an instance through the cloud metadata service

Discover an instance through the cloud metadata service
$ curl -s http://169.254.169.254/latest/meta-data/instance-type
t3.micro
 
$ curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1a
 
$ curl -s http://169.254.169.254/latest/meta-data/local-ipv4
10.0.1.42

Every cloud instance exposes its own facts through a link-local metadata service at 169.254.169.254 — no credentials needed. It is how an instance learns its type, zone and IP. You can query it from any machine that runs in AWS, and it is the canonical trick for discovering the environment a piece of software is running in.

Real world

In production

  • Deploy pipelines provision ephemeral build machines on demand and tear them down after every run.
  • Autoscaling groups add capacity when CPU or request latency crosses a threshold and remove it when load drops.
  • Multi-account or multi-project structures isolate teams, environments and blast radius.
  • Cloud provider regions and availability zones define where your latency-sensitive traffic lives.
Guidelines

Best practices

  • Start with PaaS or serverless when a service fits — you carry less operational burden than IaaS.
  • Prefer infrastructure as code (Terraform, CloudFormation) over clicking in the console so environments are reproducible.
  • Use tags and labels on every resource from day one so cost and ownership are attributable later.
  • Keep credentials out of source code and use instance roles or workload identity instead.
Watch out

Common mistakes

  • Assuming the provider patches your OS just because it is in the cloud — under IaaS that is still your job.
  • Clicking through consoles manually and losing the ability to rebuild environments from code.
  • Forgetting that network egress is billed, which can dwarf compute spend for data-heavy workloads.
  • Treating cloud SLAs as uptime guarantees for your application — the provider only covers the layer they own.
Root cause analysis

Common issues

Error
curl: Connection timed out to 169.254.169.254
Root cause

The host is not a cloud instance, or the metadata service is disabled or IMDSv2-only.

Fix

Run on an actual cloud VM, or use IMDSv2 (request a session token first) if the provider requires it.

Error
Resource limit exceeded when provisioning instances
Root cause

The account has a service quota (for example 5 VPCs or 20 instances per region by default).

Fix

Open a quota increase request in the provider console, or reuse idle resources before creating more.

Error
Billing spike after a weekend load test
Root cause

Resources left running with no schedule or scale-in policy.

Fix

Set autoscaling min to 0 for dev, enforce tagging, and schedule shutdowns outside business hours.

When things break

Debugging tips

  • Reproduce failures from a clean, scripted environment instead of debugging a manually-mutated one.
  • Check the metadata service before assuming you know which zone, size or account you are in.
  • Use the cloud provider's status page to separate a provider incident from your own config error.
  • Capture timestamps in UTC so logs from multiple instances and services line up.
Interviews

Interview checkpoint

Practice

Hands-on lab

Explore an Instance Like a Cloud Server
20 min · beginner
In progress
Objectives
  • Identify who you are, on what host, and what OS runs
  • Inspect environment variables and system resources
  • Create and verify a configuration file the way provisioning scripts do
  • Practice reading process and disk information

Explore an Instance Like a Cloud Server

20 min · beginner

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which service model gives you a fully managed application platform where you only manage your application and data?

2

Under the shared responsibility model with an IaaS virtual machine, who is responsible for patching the operating system?

3

One of the main financial benefits of cloud computing is converting large up-front capital purchases into variable operating expenses.

Quick reference

Cheat sheet

The five essential characteristics (NIST)
On-demand self-serviceProvision without human interaction, via API/CLI
Broad network accessServices reachable over the internet from anywhere
Resource poolingShared multi-tenant capacity the provider assigns
Rapid elasticityScale up and out quickly, and back down
Measured serviceMetered usage that is billed and reported
Service models at a glance
IaaSVMs, storage, network — you manage the OS and above
PaaSManaged runtime, DBs and app hosting
SaaSReady-made software, vendor runs everything
Shared responsibilityProvider = security of the cloud; you = security in the cloud
Go deeper

Official documentation

AWS: What Is Cloud Computing?
docs
Microsoft: Cloud Computing Dictionary
docs
Google Cloud: What Is Cloud Computing?
docs
NIST SP 800-145: Definition of Cloud Computing
spec
AWS Shared Responsibility Model
docs