What Is Cloud Computing
The shift from buying and running your own servers to renting compute, storage, and services on demand from a provider like AWS.
Want a visual for this topic?
Generate a diagram tailored to What Is Cloud Computing — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain cloud computing in one sentence to a non-technical person
- •Distinguish IaaS, PaaS, and SaaS with a real AWS example of each
- •Distinguish public, private, and hybrid cloud deployment models
- •Explain why 'pay for what you use' changes how companies plan capacity
What is it?
Cloud computing is renting computing resources — servers, storage, databases, networking, software — from a provider over the internet, paying only for what you use, instead of buying and running physical hardware yourself. AWS (Amazon Web Services) is the largest cloud provider: instead of buying a physical server and installing it in a data center you manage, you click a few buttons (or make an API call) and get a virtual server running in minutes, billed by the second or hour.
Why it exists
Before the cloud, running an application meant buying physical servers, provisioning them in a data center you owned or leased, and over-provisioning for your busiest expected day — because if you under-provisioned and got a traffic spike, your site went down, and if you needed more capacity you had to buy and physically install more hardware, which took weeks. Most of that hardware then sat idle most of the time. Amazon built AWS in the mid-2000s out of the infrastructure it had already built to handle its own retail traffic spikes (like Black Friday), and realized other companies would pay to rent that same elastic infrastructure instead of building their own.
Problem it solves
It solves the capacity-planning problem (guessing how much hardware you'll need months in advance, then living with that guess), the upfront-capital problem (buying servers is a large cash outlay before you've earned a dollar of revenue), the operational problem (someone has to rack servers, replace failed disks, patch firmware), and the global-reach problem (setting up your own data center in another country to serve users there is a multi-year undertaking; renting AWS capacity in that region takes minutes).
Intuition
Think of the difference between owning a car and using a taxi/rideshare. Owning a car means a large upfront cost, you're responsible for maintenance and insurance, and if you don't drive much most days it sits idle in a driveway — but it's yours to modify however you like. A taxi means no upfront cost, you pay only for the ride you take, someone else handles maintenance, and you can summon exactly the capacity you need (a small car, a van) for that specific trip. Cloud computing is choosing taxis (rented, elastic, pay-per-use) over owning a fleet of cars (physical servers) that mostly sit idle.
Analogy
A shared commercial kitchen you rent by the hour is a good analogy for cloud compute: you don't own the ovens or buy the building, you show up, use exactly the equipment you need for exactly as long as you need it, and pay only for that usage — versus building your own restaurant kitchen (a huge upfront investment) that then sits unused outside business hours.
Technical explanation
AWS achieves elasticity through virtualization: physical servers in AWS data centers run a hypervisor (AWS's own Nitro hypervisor for modern instance types) that slices one physical machine into many isolated virtual machines, each of which can be assigned to a different customer with strong isolation between them. When you 'launch an EC2 instance,' you're not getting a dedicated physical server — you're getting a slice of a physical server's CPU, RAM, and network capacity, allocated to you in seconds because the hypervisor is already running and just needs to spin up a new virtual machine, not rack new hardware.
Architecture
AWS's global infrastructure is organized in a hierarchy: the AWS Cloud contains many geographic Regions (e.g. us-east-1 in Virginia, ap-south-1 in Mumbai); each Region contains multiple isolated Availability Zones (physically separate data centers within that region, connected by low-latency links); each Availability Zone contains multiple physical data centers running the actual servers. When you launch a resource, you choose a Region (and often an Availability Zone) — this determines where in the world your data physically lives and how far it is from your users.
Workflow
A typical workflow: 1) You sign up for an AWS account. 2) You choose a Region close to your users. 3) You use the AWS Console, CLI, or Infrastructure-as-Code (CloudFormation/Terraform) to request resources — e.g. 'launch a t3.micro EC2 instance.' 4) AWS's control plane finds capacity on one of its physical hosts in that Region/AZ and boots your virtual machine, typically within seconds to a couple of minutes. 5) You're billed per-second/per-hour for exactly the time that resource exists, and you can terminate it the moment you no longer need it, stopping the billing immediately.
Example
A startup building a photo-sharing app doesn't buy servers. On day one they launch 2 small EC2 instances and an S3 bucket for photo storage — total cost maybe $20/month. When the app goes viral and traffic grows 100x in a week, they configure Auto Scaling to launch more EC2 instances automatically as load increases, and S3 scales storage capacity transparently with no action needed. If the app fails and shuts down six months later, they terminate everything and stop paying immediately — no physical servers to sell off or write off as a loss, unlike a company that had bought hardware upfront.
Real-world usage
Netflix runs almost its entire streaming service on AWS rather than owning data centers, specifically citing the ability to scale compute up for peak viewing hours and down overnight, and to expand into new countries without building physical infrastructure there. Airbnb, a company with famously spiky demand around holidays and events, similarly relies on AWS's elasticity rather than provisioning for their absolute peak load year-round.
Trade-offs
The core tradeoff is capital expenditure (CapEx) versus operating expenditure (OpEx), and control versus convenience. Owning hardware means a large upfront cost but full control and, at very large steady-state scale, potentially lower long-term cost; renting from AWS means no upfront cost, elastic capacity, and less operational burden, but ongoing per-use costs that can be higher than owned hardware at massive constant scale, and less low-level control (you can't walk into the data center and swap a disk yourself).
Visual explanation
Picture a spectrum from left to right: 'On-Premises' (you own everything — building, servers, OS, your app) → 'IaaS' (Infrastructure as a Service — AWS owns the building/servers/virtualization, you manage the OS upward: EC2) → 'PaaS' (Platform as a Service — AWS also manages the OS and runtime, you just deploy code: Elastic Beanstalk, Lambda) → 'SaaS' (Software as a Service — you just use a finished application over the browser: Gmail, Salesforce). As you move right, you manage less and AWS manages more, in exchange for less control.
Advantages
- —
No large upfront capital expenditure — you pay operating expenses as you go instead of buying hardware before you've earned revenue
- —
Elastic capacity — scale up in minutes for a traffic spike, scale down immediately after, paying only for what you actually used
- —
Global reach in minutes — deploy into a new geographic region without building a physical data center there
- —
AWS handles the undifferentiated heavy lifting — power, cooling, physical security, hardware failure replacement — so your team focuses on your application, not server racks
Disadvantages
- —
Ongoing operating cost can exceed owned-hardware cost at very large, predictable, steady-state scale — some large companies eventually repatriate stable workloads to owned hardware to save money
- —
Vendor lock-in risk — deep use of AWS-specific services (DynamoDB, Lambda-specific patterns) makes migrating to another provider or back on-premises expensive later
- —
Shared responsibility means you're still responsible for security misconfigurations (e.g. an open S3 bucket) — 'the cloud is secure' does not mean 'your usage of the cloud is automatically secure'
- —
Costs can spiral if usage isn't monitored — unlike owned hardware with a fixed known cost, a runaway or misconfigured cloud resource keeps generating bills until someone notices
Common mistakes
- —
Assuming 'we're on the cloud' automatically means secure, backed-up, and highly available — AWS provides the tools, but you must configure them correctly (the Shared Responsibility Model: AWS secures the cloud infrastructure, you secure what you put in it)
- —
Choosing IaaS (EC2, self-managed) by default when PaaS/serverless (Lambda, managed databases) would mean far less operational work for a team without deep infrastructure expertise
- —
Not setting a Region close to your actual users, adding unnecessary latency to every request
- —
Leaving unused resources running (a forgotten EC2 instance, an unattached EBS volume) — since billing is usage-based, idle-but-running resources still cost money every hour
In the AWS Console
- 1
aws.amazon.com → Create an AWS Account
Sign up with an email, set a root account password, and add a payment method.
The root account has unrestricted access to everything — create an IAM admin user for daily use instead of using root, covered in the IAM Fundamentals topic.
- 2
AWS Console → top-right Region selector
Choose the Region closest to your users (e.g. Mumbai = ap-south-1, N. Virginia = us-east-1).
Almost every resource you create is Region-scoped — picking the wrong Region is a common beginner confusion when a resource 'disappears.'
- 3
AWS Console → search bar
Type a service name (e.g. 'EC2') to jump directly to that service's console instead of hunting through menus.
The search bar is the fastest way to navigate as the number of AWS services grows into the hundreds.
- 4
AWS Console → Billing and Cost Management → Budgets
Set up a monthly budget alert (e.g. $10) so you get an email if spending exceeds your expectation.
Do this before creating any resources — it's the single most common piece of advice for anyone new to AWS to avoid a surprise bill.
🎤 Interview questions
Explain cloud computing to someone with no technical background. (Listen for: renting computing resources on demand instead of owning hardware, pay for what you use.)
What's the difference between IaaS, PaaS, and SaaS? Give an AWS example of each. (Listen for: IaaS=EC2 you manage the OS, PaaS=Elastic Beanstalk/Lambda AWS manages more, SaaS=a finished hosted application.)
Why would a company choose to rent cloud capacity instead of buying its own servers? (Listen for: no upfront capital cost, elastic scaling, no data center operations burden — plus tradeoffs at very large steady-state scale.)
What is the AWS Shared Responsibility Model? (Listen for: AWS secures the underlying cloud infrastructure; the customer is responsible for securing what they configure and put in it.)
📂 Subtopics
Service Models: IaaS, PaaS, SaaS
The three layers of 'how much AWS manages for you' — from raw virtual machines to a fully finished application.
~12 min
Deployment Models: Public, Private, Hybrid
Where the physical infrastructure lives and who else shares it — public cloud, a private cloud, or a mix of both.
~10 min