What Is the Cloud

The cloud is an apartment building. A company that needed its own server used to buy a computer, plug it in, and find a room with cool air and a backup generator. Renting a slice of someone else's computer over the internet works the same way as renting an apartment — the landlord owns the building, fixes the plumbing, pays the property tax, and you walk in with a suitcase and start living. You do not own the bricks. You pay by the night.

The building did not exist before 2006. Amazon ran a giant retail website that spiked every Christmas and sat half-idle the rest of the year, so they had warehouses of servers sitting cold. Andy Jassy ran a small team inside Amazon that asked a strange question — what if a stranger could rent one of those idle servers by the hour? They built a service called Elastic Compute Cloud, shortened to EC2, and launched it in August 2006. Anybody with a credit card could spin up a Linux machine in minutes and pay by the hour, the same way a hotel charges by the night. The first customers were tiny startups that could not afford a real server room. Within a few years the same service was running Netflix, Airbnb, and the CIA.

The apartment-building idea spread fast. Microsoft opened Azure in 2010. Google opened the Google Cloud Platform in 2011 after years of running its own internal version. Today those three — AWS, Azure, and GCP — own most of the rented-server market, with Oracle, IBM, and DigitalOcean renting out the smaller buildings on the same street. The shape is the same everywhere. You pick a building, you pick an apartment, you swipe a card, you move in.

A building is in a city, and every cloud is in a place. The cloud companies call those places regions, and they name them after the city the data center sits in — us-east-1 in Virginia, eu-west-1 in Ireland, ap-northeast-1 in Tokyo. A region is a building, or really a cluster of nearby buildings the company built together so they can keep working even if one of them catches fire. Inside a region a single rented machine is called an instance. An instance is an apartment — your own front door, your own four walls, your own electricity meter — even though the building behind the wall is shared with thousands of other tenants.

The smallest model that captures this in Rust is two structs. A Region has a name and a list of Instance values. An Instance has an id, a size, and a status.

#[derive(Copy, Clone)]
enum Kind {
    Small,
    Medium,
    Large,
}

#[derive(Copy, Clone)]
enum Status {
    Running,
    Stopped,
}

struct Instance {
    id: &'static str,
    kind: Kind,
    status: Status,
}

struct Region {
    name: &'static str,
    instances: Vec<Instance>,
}

Each piece is the same pattern as the apartment. Region is the building. Instance is the apartment. Kind says how big the apartment is — a studio, a one-bedroom, a penthouse — and Status says whether the lights are on. Using an enum for Kind and Status is the same move the Tic Tac Toe lesson made for Cell and Status. The compiler refuses to let a stray string like "runnning" (with three n's) ever sit in a status field, because the type only accepts the two variants the program knows about.

Build the toy cloud with two regions and a handful of instances each.

fn build_cloud() -> Vec<Region> {
    vec![
        Region {
            name: "us-east-1",
            instances: vec![
                Instance {
                    id: "i-01",
                    kind: Kind::Small,
                    status: Status::Running,
                },
                Instance {
                    id: "i-02",
                    kind: Kind::Medium,
                    status: Status::Running,
                },
                Instance {
                    id: "i-03",
                    kind: Kind::Large,
                    status: Status::Stopped,
                },
            ],
        },
        Region {
            name: "eu-west-1",
            instances: vec![
                Instance {
                    id: "i-04",
                    kind: Kind::Small,
                    status: Status::Running,
                },
                Instance {
                    id: "i-05",
                    kind: Kind::Large,
                    status: Status::Running,
                },
            ],
        },
    ]
}

The data here is hardcoded so the binary is deterministic, but the shape is the shape a real cloud API would hand back. Ask AWS for the list of instances in us-east-1 and you get a list that looks like this, only longer. The fact that one of the instances is Stopped is on purpose. In a real apartment building some apartments sit empty between tenants — the landlord still owns them, the rent is paused, the lights are off, and the machine can be flipped back on without rebuilding the room.

Now walk the cloud and print it.

fn kind_label(k: Kind) -> &'static str {
    match k {
        Kind::Small => "small",
        Kind::Medium => "medium",
        Kind::Large => "large",
    }
}

fn status_label(s: Status) -> &'static str {
    match s {
        Status::Running => "running",
        Status::Stopped => "stopped",
    }
}

fn print_inventory(cloud: &[Region]) {
    println!("--- cloud inventory ---");
    for region in cloud {
        println!("region: {}", region.name);
        for inst in &region.instances {
            println!(
                "  {}  kind={:<6}  status={}",
                inst.id,
                kind_label(inst.kind),
                status_label(inst.status),
            );
        }
    }
    println!();
}

fn print_summary(cloud: &[Region]) {
    println!("--- summary ---");
    let mut total = 0;
    let mut running = 0;
    for region in cloud {
        let region_total = region.instances.len();
        let region_running = region
            .instances
            .iter()
            .filter(|i| matches!(i.status, Status::Running))
            .count();
        println!(
            "{}: {} instances, {} running",
            region.name, region_total, region_running,
        );
        total += region_total;
        running += region_running;
    }
    println!("global: {} instances, {} running", total, running);
}

The print_inventory function is the same pattern a cloud console uses. Loop the regions, loop the instances inside each region, format the line so the eye can scan it. The print_summary function does the second thing every console does — count what is running and what is paused, region by region and across the whole fleet. Counting only the running instances is how the bill gets computed in real life. A stopped apartment does not pay rent for the room itself, only for the closet that holds your furniture.

--- cloud inventory ---
region: us-east-1
  i-01  kind=small   status=running
  i-02  kind=medium  status=running
  i-03  kind=large   status=stopped
region: eu-west-1
  i-04  kind=small   status=running
  i-05  kind=large   status=running

--- summary ---
us-east-1: 3 instances, 2 running
eu-west-1: 2 instances, 2 running
global: 5 instances, 4 running

Read the output top to bottom. The inventory section lists each region with its instances indented below, the way a sysadmin would scan a fleet on the morning of a deploy. The summary at the bottom counts 3 instances in us-east-1 with 2 running, 2 instances in eu-west-1 with both running, and a global total of 5 instances with 4 running. The one instance in i-03 that is Stopped is the only thing keeping the global count below 5 running.

A question worth asking — why split the cloud into regions at all, why not have one giant building? The reason is the same reason apartment buildings are not stacked into a single one-mile tower. Earthquakes, fires, undersea cables that get cut by anchors, governments that block traffic to certain countries. If your whole company lives in one building and a backhoe slices the fiber, your company is offline until the cable is spliced back together. Splitting across regions means the lights in Ireland stay on when Virginia goes dark.

The apartment metaphor stretches one more way. A bare apartment with empty rooms is what AWS calls Infrastructure as a Service, or IaaS — EC2 hands you a Linux machine and a network port, and what runs inside is your problem. A furnished apartment with the stove already hooked up is Platform as a Service, or PaaS — services like Heroku or AWS Elastic Beanstalk give you a place to drop your code without managing the server. A full hotel suite where the front desk takes your laundry is Software as a Service, or SaaS — Gmail, Notion, Salesforce, the apps a user opens in a browser without ever knowing or caring what runs underneath. The same three letters, IaaS, PaaS, SaaS, stack from raw rooms at the bottom to room service at the top.

Every layer carries a quiet contract called the shared responsibility model. The landlord is responsible for the building — the roof, the walls, the water heater, the lock on the front door. The tenant is responsible for what they bring inside — their laptop, the lock on their bedroom door, the food in their fridge. AWS publishes this split as a poster on their website. They handle the physical disks, the network cables, the cooling, the patches on the hypervisor underneath your instance. You handle the operating system patches, the firewall rules, the database backups, the passwords your application stores. Confusing those two columns is the single most common way a cloud account gets breached.

The thing this rented-apartment model cannot do on its own is run code without a long-lived machine waiting for a request. Spinning up an EC2 instance to handle one HTTP call is like signing a year-long lease to use the kitchen for ten minutes. The next bottleneck is paying only for the seconds your code runs, which is the problem AWS Lambda was built to solve, and which the rest of this section unpacks one service at a time.