What you'll learn
Quick Answer
Cloud providers rent computing, storage and services on demand. IaaS gives you a machine to manage, PaaS gives you a place to deploy code, SaaS gives you finished software. The real shift is paying for what you use instead of buying capacity in advance.
What actually changed
Before cloud hosting, launching a service meant estimating peak demand, buying servers for it, waiting weeks for delivery, and installing them in a data centre. Get the estimate wrong upwards and you paid for idle hardware. Get it wrong downwards and you were down during your biggest moment.
The cloud converts that capital expense into an operating expense, and a weeks-long procurement into an API call. You can have twenty servers for the four hours of a sale and none afterwards.
Three consequences matter more than the technology:
- Experiments become cheap. Trying an idea costs a few rupees rather than a purchase decision.
- Failure is survivable. Wrongly sized infrastructure is switched off rather than written off.
- Small teams get large capabilities. Two students can use the same managed database and CDN as a large company.
IaaS, PaaS, SaaS — by how much you manage
The standard three-way split, and the useful way to read it is as a ladder of responsibility.
IaaS — Infrastructure as a Service. You rent a virtual machine. You choose the operating system, install everything, patch it, secure it, and configure the web server. Maximum control, maximum work. Examples: EC2, Compute Engine, a DigitalOcean droplet.
PaaS — Platform as a Service. You push code; the platform runs it. No operating system to patch, no web server to configure. Less control — you work within what the platform supports. Examples: App Engine, Heroku, Render.
SaaS — Software as a Service. Finished software you use. Gmail, Figma, Salesforce. You manage nothing but your data.
The pizza analogy is genuinely the clearest: IaaS is a kitchen you rent, PaaS is a delivered base you top yourself, SaaS is eating at a restaurant.
Most real systems mix them — a PaaS-hosted application, a managed database, and SaaS for email delivery.
The service categories that matter
Providers list hundreds of services. Nearly all real architectures use a handful:
- Compute — virtual machines, containers or functions. Where your code runs.
- Storage — object storage for files (images, backups, uploads), block storage for disks attached to machines.
- Database — managed SQL and NoSQL, where the provider handles backups, patching and replication.
- Networking — private networks, load balancers, DNS, CDN.
- Identity — who can do what. Consistently underestimated and consistently the cause of breaches.
The single most valuable category for a small team is managed databases. Running your own database means backups you must test, failover you must configure, and patching you must schedule. Paying someone to do it correctly is usually the best money you will spend.
The costs that surprise people
Pay-per-use cuts both ways, and cloud bills catch out students and companies alike.
- Egress charges. Data into a provider is usually free; data out costs money. A site serving large files can find bandwidth is the dominant line item.
- Idle resources. A virtual machine left running costs the same whether or not anyone uses it. Forgotten test environments are the classic surprise.
- Attached storage and IP addresses persist. Deleting a machine may leave its disk and its reserved address, still billing.
- Free tiers expire. Most are twelve months. The bill starts arriving quietly in month thirteen.
Set a billing alert on day one. Not a limit — providers rarely stop service automatically — but an alert. Every experienced engineer has a story about a resource left running, and for a student an unexpected bill is a genuine problem rather than an annoyance.
Where to start as a student
The temptation is to learn a provider's whole catalogue. Do not. Learn the concepts, then one provider well enough to deploy something.
A sensible first project: deploy an application with a database, a domain and HTTPS, and understand every piece. That teaches more than a certification path, and it gives you something to discuss.
Start with a PaaS rather than raw virtual machines. Managing your own server teaches useful things eventually; it also means you spend your first week on firewalls instead of on your app. See deploying your project for free.
The vocabulary matters for interviews even if you have not used it in production. Understanding what a load balancer, a managed database and object storage are, and when each is appropriate, is most of what a fresher is expected to know — see AWS basics for students.
And keep the fundamentals in view: the cloud runs on the same networking and the same Linux you already know. It is not a separate discipline, it is a delivery model.