What is cloud computing? Renting infrastructure instead of owning it

Before cloud computing existed as an option, running a website or backend meant owning or renting physical servers — buying hardware, installing it in a data center (or your own building), configuring the operating system, and keeping it running yourself. Wanting more capacity meant a real, slow chain of events: order new hardware, wait for it to ship, physically install it, configure it — often weeks between "we need more capacity" and actually having it.

This model has a name: on-premises ("on-prem") infrastructure. It's not extinct — some organizations still run their own data centers, for reasons ranging from regulatory requirements to genuinely predictable, massive, steady-state workloads where owning hardware outright is cheaper long-term. But for most software teams today, it's the exception, not the default.

Cloud computing means renting infrastructure — servers, storage, networking, databases — from a provider (AWS, Google Cloud, Microsoft Azure, and others) who owns and operates the actual physical hardware in their own data centers, and gives you on-demand access to slices of it through an API or web console. Instead of buying a server, you request one, and it exists — usually within seconds to minutes, not weeks.

Buying physical servers is a capital expense (capex) — a large upfront cost for something you now own, whether you fully use it or not. Renting cloud infrastructure is an operating expense (opex) — an ongoing cost that scales with actual usage, with no large upfront purchase. This distinction sounds like an accounting detail, but it has real practical consequences: a startup testing an idea can run real infrastructure for a few dollars a month instead of needing capital to buy servers before knowing if the idea works at all, and a company with unpredictable, spiky traffic pays for capacity roughly matching what it actually uses, rather than owning enough hardware to handle its worst-case peak load sitting mostly idle the rest of the time.

Elasticity — the ability to scale capacity up or down automatically, in near-real-time, in response to actual demand — is the cloud's defining technical advantage over owned hardware, not just a nice-to-have. A physical server you own has a fixed capacity; adding more means going through the whole slow procurement cycle described above, and removing capacity you no longer need doesn't get your money back at all. Cloud infrastructure can be requested, used for an hour, and released — paying only for that hour — a capability that's not a matter of degree but a genuinely different kind of infrastructure, one this domain's auto-scaling lesson later builds on directly.

A common joke about "the cloud" is that it's just "someone else's computer" — which is technically true and also somewhat misses the point. Yes, physically, your code runs on hardware AWS (or another provider) owns, in a building you'll never see. What the joke undersells: the actual product isn't just borrowed hardware, it's the entire layer of managed services built on top of it — a database you don't have to patch yourself, a load balancer you don't have to configure a kernel's networking stack for, a storage system engineered for a level of durability a single team would struggle to replicate. The rest of this domain is largely about that layer, not the raw rented hardware underneath it.

Cloud providers don't take over everything — there's a clear (if sometimes underappreciated) split known as the shared responsibility model. The provider is responsible for the security and reliability of the cloud — physical data center security, the underlying hardware, the isolation between different customers' resources. You remain responsible for security and configuration in the cloud — how you configure access controls, whether your data is encrypted, whether your application code has vulnerabilities. A famous, expensive class of real-world incidents comes from exactly this gap: a misconfigured, publicly-readable storage bucket is not the cloud provider's failure — the provider correctly built a bucket that can be private; leaving it public was a configuration choice on the customer's side of the line.

Everything else in this domain builds on the shift described here — infrastructure as code (declaring these rented resources instead of clicking through a console by hand), compute options, storage types, networking, and the operational patterns (queues, auto-scaling, observability, cost control) that come with running real systems on rented infrastructure. Once these fundamentals are solid, the dedicated AWS domain goes deep on one specific provider's actual services, console, and CLI — the practical, hands-on layer this domain deliberately keeps provider-agnostic.