This week marked the beginning of something powerful.
Every year when we launch the 12-Week AWS Workshop Challenge, I feel the same mix of excitement, responsibility, and curiosity, because no two cohorts are ever the same. And this year's Week 1 reminded me exactly why I love building cloud communities.
As the organizer of this challenge, I usually watch from the sidelines, answering questions, troubleshooting issues, and celebrating wins. But this year, I decided to participate alongside everyone. And honestly? But Week 1 reminded me why revisiting the basics is never a waste of time.
- What Exactly Is Cloud Computing?
Could we forget the textbook definitions for a moment? You know, the ones that say "cloud computing is the on-demand delivery of IT resources via the internet with pay-as-you-go pricing." Cool. Very helpful. Totally clear.
Here's what I think cloud computing is:
Think about electricity. A hundred years ago, if you wanted power, you bought a generator. You maintained it, fueled it, and dealt with breakdowns. Expensive. Complicated. A full-time job. Then the grid happened. Now you plug in and pay for what you use. Someone else handles generation, distribution, and maintenance. You get power on demand.
That's cloud.
Instead of buying servers, building data centers, and hiring teams to maintain hardware, you rent compute, storage, and services from AWS. You pay for what you use. They handle the infrastructure. You focus on building.
Simple concept. Massive implications.
There are three ways to deploy: private, public, and hybrid.
Private cloud is when you build your own cloud infrastructure. Full control, but you're handling everything: hardware, maintenance, and scaling. Banks and government agencies do this when they can't risk putting data anywhere else. (Or when they just really love spending money on infrastructure :).)
Public cloud is AWS, Azure, and GCP. Someone else owns the infrastructure. You rent resources. It's cheaper, scales instantly, and you're not maintaining physical servers at 3 AM. This is what most companies use.
Hybrid cloud is both. Keep sensitive data on-premise; use the public cloud for everything else. It's complicated to manage, but sometimes compliance or security requirements force your hand. Also great for when your CTO wants "the best of both worlds" without considering the operational nightmare. You can read more on the benefits of the latest collaboration between AWS and Google on multicloud networking.
Most real-world systems I've worked on end up hybrid, even if they don't start that way. Legacy systems don't migrate overnight, no matter what your vendor promised in that sales pitch.
- Service Models: Who Manages What?
Here's where people get confused. IaaS, PaaS, and SaaS: what's the actual difference? And why do we have so many acronyms?
Let me break it down with pizza. Yes, pizza. Stay with me. :)
On-premise infrastructure is making pizza from scratch. You buy flour, yeast, tomatoes, and cheese. You mix, knead, bake, and clean up. Total control. Total responsibility. Total exhaustion. This is traditional IT; you own and manage everything, including the 2 AM calls when something breaks.
IaaS (Infrastructure as a Service) is "take and bake" pizza. Someone gives you a ready pizza; you bake it yourself. AWS gives you servers; you install the OS, deploy your applications, and manage everything on top. Examples: EC2, S3. You still do a lot of work, but at least you're not building the data center.
PaaS (Platform as a Service) is pizza delivery. They make it, bake it, and bring it to your door. You just eat. You write code and deploy it. AWS handles the servers, scaling, and patching. Examples: Elastic Beanstalk, RDS. Perfect for when you want to build apps, not babysit infrastructure.
SaaS (Software as a Service) is dining out. They make it, serve it, and clean up. You just show up and use it. Examples: Gmail, Salesforce, Netflix. Zero maintenance on your end. Just pay the subscription and complain when it's down.
Most applications you use daily are SaaS. Most things you'll build in this challenge will be IaaS or PaaS. Choose wisely based on how much you enjoy being woken up at night.
- AWS Global Infrastructure
When people say "the cloud," they make it sound like data just floats around somewhere. Here's what's actually happening:
Availability Zones are clusters of data centers. Each isolated, separate power, networking, everything. If one fails, others keep running.
Regions are geographical locations with multiple AZs. "US East" is a region. "Cape Town" is a region. Completely independent.
Edge locations cache content close to users. Your Netflix stream? Coming from an edge location near you, not Virginia.
Multi-AZ isn't a checkbox. It's thinking through what happens when things fail. Because they will. :)
I know you already have a lot of what-ifs, but calm down, IAM is here :)
IAM: Where Security Actually Lives
Identity and Access Management is not sexy. It's also the most important thing you'll set up.
Never use your root account for daily work. I don't care how convenient it is. Just create an IAM user with admin permissions. Enable multi-factor authentication. Lock that root account away and pretend it doesn't exist.
Why? Because if someone gets your root credentials, they own everything. Your entire AWS environment. Every resource. Every service. Every bit of data. And yes, they can spin up a million EC2 instances just for fun while you're sleeping. Your bill will be legendary. You will smell bankruptcy
Users are people or applications that need access.
Groups are collections of users with similar permissions (developers, admins, etc.)
Roles are temporary credentials that services or users can assume
Policies define what actions are allowed or denied. They're written in JSON, and they follow a simple rule: explicit deny always wins. If something is denied anywhere, it's denied everywhere. No exceptions, no arguments, and no "but I really need this to work right now."
I've seen production systems get compromised because someone gave overly broad permissions "just to get it working." Spoiler alert: it's never worth it. Start with least privilege. Add permissions as needed. Never the other way around. Your future self (and your security team) will thank you.
What 5 Years Taught Me
You can follow best practices without understanding why they exist. Then you hit an edge case, and that lack of understanding bites you.
The Well-Architected Framework shows the ideal. Real projects force trade-offs—security vs. convenience, reliability vs. cost. Your job? Knowing which corners you can cut and which will haunt you.
Fundamentals aren't boring theory. They're your foundation for making smart decisions under pressure.
Check out 12wwchallenge.wicafrica.org for the challenge and join our community
See you next week
Miss Cloud
Top comments (0)