Cloud Computing: From Room-Sized Computers to AWS

The 10 AM Problem

Every Indian student who has tried to book a Tatkal train ticket knows a strange fact: the IRCTC website behaves perfectly all day, and then, for a few minutes right at 10 AM (or 11 AM for non-AC classes), it slows to a crawl or refuses to load at all. The same thing happens to e-commerce sites during a big festival sale, and to streaming apps during a high-profile cricket match when millions of people open the app in the same ten-minute window. Nothing is "broken" in the ordinary sense — the code works fine at 10:05 AM. The problem is that a huge number of people are asking the same computer system to do work at the exact same moment, and the system was not built to handle that many requests at once.

This single, very ordinary annoyance is actually the best entry point into cloud computing, because it exposes the real engineering question this chapter answers: how much computer should an organisation own? Too little, and it collapses during a rush. Too much, and it wastes money on machines that sit idle most of the day. Cloud computing is not a buzzword for "stuff on the internet" — it is a specific, well-defined answer to this exact problem, built up over seventy years of computing history. To understand why it works, we need to see what came before it.

Room-Sized Computers: Computing Before "The Cloud"

In 1945, the University of Pennsylvania completed a computer called ENIAC (Electronic Numerical Integrator and Computer). ENIAC filled a room roughly the size of a school basketball court, weighed close to 27 tonnes, and used nearly 18,000 vacuum tubes to perform calculations that a modern microcontroller costing a few hundred rupees could do in a fraction of a second. Vacuum tubes generated enormous heat and failed constantly, so a large part of the daily work of running ENIAC was simply finding and replacing burnt-out tubes.

By the 1960s, machines like IBM's System/360 family shrank things from "room of tubes" to "room of cabinets," but the basic arrangement of computing did not change: a computer was an enormous, expensive, centrally located machine, usually owned by a university, government department, or large corporation. A student or junior engineer did not sit in front of it. Instead, you wrote your program on a stack of punched cards, handed the stack to an operator, and came back later — sometimes the next day — to collect a printout telling you whether your program ran correctly or crashed on line 40. Computing time on the machine was so scarce and expensive that it had to be scheduled and rationed like a costly shared resource, which is exactly the constraint that produced the next big idea.

Time-Sharing: The First "Cloud" Idea

If a computer costs as much as a building and only one person's program can run on it at a time, most of that expensive machine sits idle while a human reads the printout, thinks, and writes the next batch of cards. In 1961, researchers at MIT built the Compatible Time-Sharing System (CTSS), which let several people use the same physical computer at once by typing at separate terminals connected to it. The computer did not truly run every user's program simultaneously — it rapidly switched between users, giving each one a tiny slice of processing time, many times per second, so quickly that each person felt as though they had the machine to themselves.

This is the first appearance of an idea that is now central to cloud computing: instead of giving each user a whole physical machine, give many users the illusion of having their own machine, while secretly sharing one real machine underneath. Time-sharing made computing dramatically cheaper per person, because the expensive hardware was kept busy almost all the time instead of sitting idle between one person's typing pauses. Everything you will learn in this chapter about cloud data centers is, at its core, this same trick applied at a much larger scale, using much better technology.

A Quick Timeline

Before going further, it helps to see the whole arc in one picture — four eras, each solving the limitation of the one before it.

So What Actually Is "The Cloud"?

The word "cloud" is unfortunately vague in everyday speech — people say a photo is "in the cloud" the way they might say a spell was "in the air." But cloud computing has a precise technical meaning. The US National Institute of Standards and Technology (NIST) defines it using five essential characteristics, and CBSE's computer science curriculum leans on the same definition, so it is worth learning precisely:

• On-demand self-service: you can get a new server running in minutes by clicking a button or running a command, without emailing anyone or waiting for a technician.
• Broad network access: the resources are reachable over the internet from a laptop, a phone, or another server, using standard protocols.
• Resource pooling: the provider's physical hardware — CPUs, RAM, storage, network — is shared across many different customers, who never even find out which physical machine they are actually using.
• Rapid elasticity: the amount of computing you are using can grow or shrink automatically as demand changes, in minutes, not weeks.
• Measured service: everything is metered, like an electricity bill — you pay for the CPU-hours, gigabytes stored, and data transferred that you actually used.

Put together, cloud computing is: renting metered, elastic access to pooled computing resources owned by someone else, provisioned on demand over a network. Amazon Web Services (AWS) — launched by Amazon starting with its Simple Storage Service (S3) and Elastic Compute Cloud (EC2) in 2006 — was one of the first companies to sell exactly this. Microsoft Azure and Google Cloud Platform followed with similar offerings a few years later. All three now operate data centers physically located within India to serve Indian customers with lower delay.

The Trick That Makes It Work: Virtualization

Here is the obvious objection to cloud computing: if AWS has a physical warehouse full of real computers, and thousands of different customers want to rent computing power from it, how does AWS give each customer their "own" server without literally buying a separate physical machine for every single customer on Earth? The answer is the same trick time-sharing used, refined into a formal technology called virtualization.

Think of a large apartment building. The building itself has one electricity connection, one water supply, and one physical structure, but it is divided into many independent flats, each with its own locked door, its own rooms, and its own electricity meter. Residents of one flat cannot walk into another flat's rooms, and each flat is billed separately for what it uses, even though all of them ultimately draw from the same building infrastructure.

A physical server in a data center works the same way. A special piece of software called a hypervisor runs directly on the physical machine (called the host) and divides its CPU cores, RAM, and storage into several isolated slices. Each slice behaves, from the inside, exactly like a complete, separate computer with its own operating system — this is called a virtual machine, or VM (also the guest). A single physical server with, say, 64 CPU cores and 256 GB of RAM might be divided by the hypervisor into 16 virtual machines, each believing it has 4 cores and 16 GB of RAM to itself, unaware that fifteen other "computers" are running alongside it on the same physical box. If one customer's VM crashes or gets attacked by malware, the hypervisor keeps it isolated so the other fifteen VMs on the same physical machine are unaffected — the same way a fire in one flat should not (in a properly built apartment) spread instantly into the next one.

Virtualization is what lets a single AWS data center rent out capacity to thousands of unrelated customers simultaneously, billing each one only for the slice they actually used, and reassigning that slice to a different customer the moment the first one is done with it.

Why Elasticity Changes the Economics

Now we can return to the Tatkal problem with real numbers and see exactly why renting elastic capacity beats owning fixed capacity. The figures below are simplified, invented numbers chosen to make the arithmetic clean — not actual AWS prices — but the pattern they illustrate is exactly why cloud computing exists.

Suppose a ticket-booking website normally needs 10 servers to handle everyday traffic, all day, every day. But for two hours each day — during a rush like Tatkal booking — traffic jumps so much that it needs 100 servers to avoid crashing.

Option A — Buy your own servers. To survive the rush without crashing, the company must own 100 physical servers, even though 90 of them sit almost completely idle for 22 hours out of every 24. If each server costs roughly ₹80,000 to buy, the upfront hardware bill alone is:

100 servers × ₹80,000 = ₹80,00,000 (₹80 lakh)

and that is before paying for electricity, air conditioning, a secure server room, and staff to maintain machines that are mostly switched on for nothing.

Option B — Rent elastic capacity from a cloud provider. Suppose renting one server costs ₹10 per hour, billed only for the hours it is actually switched on. The company keeps 10 servers running all 24 hours for ordinary traffic, and asks the cloud provider to add 90 more servers only during the 2-hour rush each day:

Base load:  10 servers × 24 hours × ₹10/hr = ₹2,400 per day
Rush load:  90 servers ×  2 hours × ₹10/hr = ₹1,800 per day
                                     Total   = ₹4,200 per day

Over a 30-day month, that is ₹4,200 × 30 = ₹1,26,000 — a running cost, not a one-time purchase, and dramatically smaller than the ₹80 lakh upfront cost of owning enough hardware to survive the same rush. The company never pays for the 90 extra servers during the 22 quiet hours, because in the cloud model those servers do not "belong" to them at all outside the two hours they are switched on — the same physical machines are instantly rented out to some other customer the moment this company's rush ends. This is rapid elasticity from the NIST definition, made concrete: capacity that grows and shrinks with demand, billed only for what is actually used. This is also precisely why platforms like large e-commerce sites during festival flash sales, or streaming apps during a widely watched cricket match, can absorb a sudden burst of extra visitors without needing to own that much hardware permanently.

It is worth being honest about the limits of this argument, though: elasticity saves money specifically when demand is spiky and unpredictable. A company with perfectly steady, predictable traffic all year round sometimes finds that owning hardware outright, or committing to a long-term reserved cloud contract at a discounted rate, actually costs less over several years than paying full on-demand cloud prices continuously. Cloud computing is not "always cheaper" — it is a tool that is extremely good at converting a large, risky upfront cost into a smaller, flexible ongoing one.

Three Ways to Rent: IaaS, PaaS, SaaS

Cloud providers do not sell only one kind of product — they sell computing at different levels of "how much is already set up for you," commonly described using a housing analogy.

• IaaS (Infrastructure as a Service): like renting empty land with electricity and water connections already laid — you get raw virtual machines, storage, and networking, but you install and manage your own operating system, security patches, and software. AWS EC2 and Amazon S3 are IaaS products.
• PaaS (Platform as a Service): like renting a flat with the walls, plumbing, and electrical wiring already done — the provider manages the operating system, runtime, and patching, and you just deploy your application code on top. AWS Elastic Beanstalk and Google App Engine are PaaS products.
• SaaS (Software as a Service): like renting a fully furnished serviced apartment — you don't manage any infrastructure at all, you simply use a finished application through a browser. Gmail, Google Docs, and Zoom are SaaS products; you never think about which server or operating system they run on.

Each layer trades control for convenience: IaaS gives you the most flexibility and the most responsibility; SaaS gives you the least control but requires the least effort. A CBSE exam answer distinguishing these three should mention exactly this trade-off, not just list the three letters.

Inside AWS: Regions, Availability Zones, and Why Location Matters

AWS does not operate one giant data center for the whole planet — it operates dozens of geographically separate clusters of data centers called regions, each identified by a code. Mumbai, for instance, is the region ap-south-1, which AWS opened in 2016 specifically to serve customers in India with lower network delay (latency) than routing every request to a data center in, say, Singapore or Ireland.

Latency matters because data still has to travel at a finite speed through physical fibre-optic cables. A request from a student in Bengaluru to a server in Mumbai might take on the order of 20-30 milliseconds round trip; the same request to a server on another continent could take well over 200 milliseconds. That difference is invisible for loading a static webpage once, but it matters enormously for anything interactive — video calls, multiplayer games, or high-frequency financial trading — where delays compound with every back-and-forth exchange.

Within a single region, AWS further splits its data centers into multiple Availability Zones — physically separate buildings, often several kilometres apart, each with independent power and cooling. An application can be deployed across two or three Availability Zones in the same region so that if a fire, flood, or power failure takes down one building entirely, the application keeps running from the others. This is a direct, modern descendant of the same reliability instinct that made engineers keep spare vacuum tubes on hand for ENIAC — except now entire buildings are the "spare part."

How a Request Actually Gets Handled

Owning many virtual servers only helps if incoming requests are actually spread across them evenly. If every user's request always went to the same one server while 99 others sat idle, elasticity would be useless. The component that solves this is called a load balancer — a piece of software (or dedicated hardware) that sits in front of a group of servers and decides, for every incoming request, which server should handle it.

One of the simplest load-balancing strategies is called round robin: send the first request to server 1, the second request to server 2, the third to server 3, and after reaching the last server, wrap back around to server 1 again. Here is round robin as actual, runnable Python:

def round_robin(requests, servers):
    assignments = []
    for i, req in enumerate(requests):
        server = servers[i % len(servers)]
        assignments.append((req, server))
    return assignments

requests = ["R1", "R2", "R3", "R4", "R5"]
servers  = ["S1", "S2", "S3"]
print(round_robin(requests, servers))

Trace through it by hand, the way you would for a CBSE program-tracing question. There are 3 servers, so i % len(servers) is i % 3:

• i=0: "R1" → 0 % 3 = 0 → servers[0] = "S1"
• i=1: "R2" → 1 % 3 = 1 → servers[1] = "S2"
• i=2: "R3" → 2 % 3 = 2 → servers[2] = "S3"
• i=3: "R4" → 3 % 3 = 0 → servers[0] = "S1" (wraps back around)
• i=4: "R5" → 4 % 3 = 1 → servers[1] = "S2"

So the output is exactly:

[('R1', 'S1'), ('R2', 'S2'), ('R3', 'S3'), ('R4', 'S1'), ('R5', 'S2')]

Notice that S1 and S2 each received two requests while S3 received only one, out of five total — with more requests, the modulo (remainder) arithmetic keeps distributing them as evenly as the number of servers allows, which is exactly why the % operator is the right tool here.

Round robin distributes load, but it does not by itself decide how many servers should exist in the first place — that is the job of an auto-scaling system, which watches a metric like average CPU usage across all current servers and adds or removes servers automatically:

def autoscale(current_servers, avg_cpu_percent):
    if avg_cpu_percent > 70 and current_servers < 500:
        return current_servers + 10   # scale out: add capacity
    elif avg_cpu_percent < 20 and current_servers > 10:
        return current_servers - 10   # scale in: remove capacity
    return current_servers            # no change needed

Trace it: if current_servers = 10 and avg_cpu_percent = 85, the first condition checks 85 > 70 (true) and 10 < 500 (true), so the function returns 10 + 10 = 20. A few minutes later, if traffic falls and avg_cpu_percent drops to 15 while current_servers = 20, the second condition checks 15 < 20 (true) and 20 > 10 (true), so it returns 20 - 10 = 10 — the fleet shrinks back down automatically once the rush passes. AWS's real Auto Scaling service works on this same principle, just with far more sophisticated metrics and safety limits than this simplified sketch.

The diagram below shows how these two pieces fit together for a single incoming wave of user requests.

Common Misconception: "Cloud" Just Means "The Internet"

A very common mix-up — one worth correcting explicitly before an exam — is treating "cloud computing" and "the internet" as basically the same thing, or believing that data "in the cloud" floats somewhere without a physical location. Neither is true. The internet is the network of cables and routers that carries data between machines; cloud computing is a specific business and technical model for renting metered, elastic computing resources over that network. A static personal website hosted on a single server that someone bought once and never resizes is "on the internet" but is not really an example of cloud computing in the elastic, on-demand sense — there is no auto-scaling, no pay-per-use metering, no resource pooling. Conversely, every byte stored "in the cloud" sits on a real hard drive or SSD, inside a real server, inside a real building with an actual street address, real security guards, and real diesel backup generators — Amazon's Mumbai region is a real cluster of buildings in Maharashtra, not a metaphorical cloud in the sky. When you understand virtualization, regions, and elasticity, you can explain precisely how "the cloud" differs from just "a website" — and that precision is exactly what separates a strong CBSE answer from a vague one.

Check Your Understanding

1. Explain, using the apartment-building analogy, what a hypervisor does and why a virtual machine on a shared physical server does not need to know that other virtual machines exist on the same hardware.
2. A company runs 8 servers all day for normal traffic, and needs 40 more servers only during a 3-hour evening rush. If renting one server costs ₹12/hour, calculate the total daily cloud cost (base load for 24 hours plus rush load for 3 hours), and compare it briefly to the idea of buying all 48 servers outright.
3. Trace round_robin(["A","B","C","D","E","F"], ["X","Y"]) by hand and write down the exact list of tuples it returns.
4. Using the autoscale function from this chapter, what value is returned when current_servers = 500 and avg_cpu_percent = 90? Explain why the 500-server ceiling matters in a real system.
5. Name the five NIST characteristics of cloud computing, and give one everyday example (Indian, if possible) that demonstrates "rapid elasticity" specifically.
6. A classmate says, "Our school's Wi-Fi router that serves everyone in the building is basically cloud computing, since many people share it." Explain what is missing from the router example for it to genuinely count as cloud computing.

Summary

Cloud computing did not appear out of nowhere — it is the modern, fully automated descendant of time-sharing, the 1961 idea of letting many users share one expensive machine by rapidly switching between them. What changed since then is scale and automation: virtualization lets a hypervisor slice a single physical server into many isolated virtual machines, the way a building is divided into flats; providers like AWS, Azure, and Google Cloud rent these virtual machines to anyone, metered by the hour or even the second; and services like load balancers and auto-scaling systems automatically spread requests across servers and add or remove capacity as demand rises and falls, without a human deciding in real time. This combination — on-demand access, pooled hardware, rapid elasticity, and measured billing, the five NIST characteristics — is what lets a ticket-booking site, an e-commerce app during a festival sale, or a streaming platform during a big match absorb a massive, short-lived spike in traffic without owning enough hardware to handle that spike every single day of the year. IaaS, PaaS, and SaaS describe how much of that underlying machinery a customer wants to manage themselves versus leave entirely to the provider, and AWS's regions and Availability Zones show how the same elasticity idea is combined with physical geography to keep applications both fast and resilient to real-world failures.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where cloud computing: from room-sized computers to aws is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting cloud computing: from room-sized computers to aws to at least 3 other topics you have studied.