How to Learn Cloud Computing From Scratch in 2026

It was 11pm on a Tuesday and I was reading my fifteenth article comparing AWS to Azure. My eyes were glazing over. I had three browser tabs open with pricing calculators, two with market share charts, and one with a Reddit thread where strangers were yelling at each other about serverless.

I had been “learning cloud” for two weeks. I had not launched a single resource.

Then my coworker Dave — the kind of guy who learns things by setting them on fire — told me to just create an AWS account and break stuff. So I did. I launched an EC2 instance that same night. Couldn’t SSH into it. Spent an hour staring at security group rules, trying to figure out why port 22 was acting like a locked door. By midnight, I had it working. And I’d learned more about networking in that frustrating, coffee-fueled hour than in two weeks of comparison articles.

That’s basically the whole article summed up. You learn cloud by doing cloud.

Everything else is just you, stalling, at 11pm, reading pricing calculators.

What you actually need before touching a console

Not much. But skip this and every error message will feel like it’s written in a foreign language.

Some networking. What’s an IP address. What’s a subnet. How DNS works. What a port is. I’m not talking CCNA-level knowledge — just enough that when a security group blocks your traffic, you have a fighting chance of understanding why. I spent two evenings watching Professor Messer’s free Network+ videos. That was enough. Two evenings.

I know networking sounds like the boring vegetables you have to eat before dessert. It kind of is. But it’s also the thing that turns “why the hell isn’t this working” into “ah, port 443 isn’t open.” That shift is worth the boredom.

Basic Linux command line. Most cloud stuff runs on Linux. You need ls, cd, grep, ssh, chmod to feel natural. Not expert-level. Just… not panicky. If you’re on Windows, install WSL. Ten minutes and you have a real terminal.

A rough idea of VMs and containers. A VM is a full simulated computer. A container is a lightweight isolated box. Docker packages apps into containers. That’s it. Don’t go deep yet. You’ll go deep later when you actually need to, and it’ll make way more sense then.

Three things. That’s the list. I spent a month trying to understand all of cloud theory before touching a console, and all it got me was a very organized bookmark folder and zero practical skills.

Pick one and stop agonizing

AWS, Azure, or GCP. The eternal debate. I’ve seen people spend longer choosing a cloud provider than actually learning one.

Here’s what I wish someone had shouted at me: they all do the same stuff at the foundation level. Compute, storage, networking, databases, identity management. If you learn AWS deeply, switching to Azure takes weeks. Not months. Weeks. The concepts transfer.

If you have no strong preference: go with AWS. Biggest market share, most tutorials, most job postings. Path of least friction. If your company uses Azure, or you’re into data and ML where GCP shines, go with that. Just pick one. The worst possible outcome is spending a month bouncing between all three and learning none.

Create a free tier account. And before you do a single other thing, set a billing alarm at $5.

I need to tell you about billing because I keep watching people get burned. My friend left a NAT gateway running over a weekend. $47 on his credit card Monday morning. He stared at the email like it was a parking ticket. It’s not catastrophic money, but for a beginner who’s just trying to learn, it’s enough to make you close the tab and never come back. The free tier is generous, but it has invisible edges. Set the alarm.

Then, roughly in order:

1. Launch an EC2 instance. SSH into it. Install nginx. See a webpage. Feel a small rush of accomplishment.
2. Put a static website on S3. Make it publicly accessible.
3. Create an RDS database. Connect to it from your EC2 instance.
4. Write a Lambda function. Trigger it from API Gateway. Watch it actually respond.
5. Set up IAM users. Give them different permissions. Try to do something forbidden. See it fail.

Don’t follow tutorials robotically. Change a setting. Remove a security group rule. See what breaks. That’s where the actual learning lives.

OK so about projects

I need to be honest about something first. I tell everyone to build projects. It’s the right advice. But when I started, I didn’t do that. I watched forty hours of Kubernetes tutorials on YouTube, felt great about myself, and then tried to actually deploy something and realized I couldn’t. The tutorial knowledge evaporated the second I had to make a real decision without someone holding my hand.

It’s like watching someone cook on YouTube and then trying to make a soufflé. The confidence is there. The soufflé is not.

Projects force you to connect the dots in a way that tutorials never do. A tutorial teaches you “here’s how S3 works.” A project teaches you “here’s how S3 works when CloudFront is caching stale files and your IAM policy is slightly wrong and CORS is rejecting everything and you’ve been debugging for two hours and you just want dinner.”

Three projects that taught me a lot:

A portfolio site with CI/CD. S3 for hosting, CloudFront in front, a domain wired up. Push to GitHub, it auto-deploys. Touches storage, networking, caching, automation. Took me longer than I’d like to admit. But when that first auto-deploy worked, I actually pumped my fist. At my desk. Alone. No regrets.

A serverless API. Lambda behind API Gateway, talking to DynamoDB. Process some data, return JSON. This is where event-driven architecture stopped being a buzzword and started being something I could actually build.

A monitoring setup. CloudWatch dashboards and SNS alerts on a running app. This is the boring stuff that separates “I deployed something” from “I could run something in production without it catching fire at 3am.”

Put them on GitHub. Write READMEs. Hiring managers — I say this as someone who’s reviewed hundreds of resumes — care more about a real project with messy code than a certification badge with nothing behind it. I know people disagree with me on that. That’s OK.

Specialize later (I mean it)

Once you’ve built a few things, pick a direction:

• DevOps — Terraform, CI/CD pipelines, Kubernetes if you’re feeling brave
• Data engineering — data lakes, ETL, Redshift or BigQuery
• Cloud security — IAM deep dives, encryption, compliance

I was dead set on data engineering for months. Read articles about it. Planned a career path. Then I actually spent a month doing it and discovered I found DevOps way more interesting. All that planning, out the window. Which is exactly why you should explore before committing. Your future self will have different opinions than your current self. Trust the process.

The same mistakes, over and over

The tutorial trap. I already told you about my Kubernetes saga. Forty hours of watching, zero hours of doing. If you haven’t opened a console this week, you’re not learning cloud. You’re watching someone else learn cloud. I know the difference is hard to feel in the moment. It’s real though.

Forgetting about money. That billing alarm. I’ve mentioned it three times now. I’ll mention it again before this article is over, probably. The free tier has limits that aren’t always obvious. A forgotten instance here, a data transfer overage there.

Skipping networking. I said this already. I’m saying it again. I’ve watched too many people spend three days fighting security groups because they never learned what a subnet mask does. It’s boring. It’s not optional.

Certifying before building. Certs are useful — they structure your learning and give recruiters something to scan for. But a cert without hands-on experience is trivia. Build first. Cert around month four or five. The exam will be easier because you’ll have context, and a GitHub with real projects will impress people more than a badge anyway.

Someone always asks: do I need to know how to code? Not to start. Networking, storage, compute, IAM — no programming needed. But once you start writing Lambda functions or Infrastructure as Code, basic Python or Bash becomes necessary. Learn it when you need it, not as a prerequisite. It sticks better with a real reason.

I think that covers it. Probably forgot something. That’s fine.

Want to start building? Start learning today →