What no one tells you when you start your cloud journey
Long before the focus on AI we used to talk about our AWS cloud journeys. These conversations were about what we were learning on AWS at the time, the resources we consulted in this learning, the certifications we got, and hopefully the cool cloud jobs we got as a consequence of all this dedication.
Long before the focus on AI we used to talk about our AWS cloud journeys. These conversations were about what we were learning on AWS at the time, the resources we consulted during this learning, the certifications we got, and hopefully the cool cloud jobs we got as a result of all this dedication.
My journey started in much the same way and I'm grateful that I ended up with the cool cloud job as was always the hope when putting in all the work. However, in an industry where it's always about appearing to be the smartest it took a while to be comfortable to talk about the struggles associated with the learning. In the rush to project success the struggle stories tend to be left out.
The cloud is a completely new world if your background is non-tech, it's also a whole new world depending on what parts of tech form your background. For me with a background largely in software development, working at big institutions, there was always a team that took care of the bits that weren't core to my role. Databases weren't core to my role so another team took care of that, so was computer networking, security, and on the list goes.
The cloud brings all these bits together and suddenly it's important to understand at least the basics of each of them. Networking was that whole new world for me, VPCs, subnets, ACLs, what are we even talking about!
Fast forward and it's 2026 and I've decided to go back to school to pursue a bucket list item that's long outstanding, and as part of my degree I'm diving deep into networking - and finally so much clicks!
So here I am, writing this love letter to you if you're reading this, to say that even though we're all about AI nowadays understanding the basics of cloud remains relevant.
In this post I detail what's finally clicking for me now that I'm going back to basics! I'll focus on what I'm learning right now specifically in my networking class. Read until the end where I share resources to help you learn the basics as well.
The cloud is networking
Nobody told me this when I started my cloud journey and maybe they didn't have to; the cloud is just someone else's network. What I always liked about pursuing cloud certifications was that the study material introduced you to this concept by "teaching" cloud from end-to-end, touching on topics ranging from databases, security, storage, compute, and more.
Every VPC you create, every subnet you define, every route table you configure, none of these were born in the cloud. They're all digitised versions of physical networking concepts that have existed for decades. The cloud didn't replace networking, it only abstracted it. When I started studying computer networking, the fundamentals which are the physical layer stuff, thinking back to my early days of learning the cloud, all the fundamentals suddenly had context.
Here are just some of my aha moments so far
Routers aren't just icons on a diagram
In my networking studies, I'm learning that a router's job is simple; look at an IP address, consult a routing table, forward the packet toward the right network. That's it! And oh, routers operate on the Networking layer (layer 3) of the OSI Model .
Then I looked at my AWS route tables, the ones I'd been creating almost mechanically after I got over being overwhelmed by them, and realised how it's the exact same thing. A route table attached to a subnet is what tells a router where to send traffic. When I add a rule that says
0.0.0.0/0 → Internet Gateway, I'm telling a virtual router: "anything that isn't local? Send it to the internet."The cloud didn't invent routing, it just turned what usually gets configured in a rack into configuration with a few lines in the AWS console or in your favorite infrastructure-as-code.
A NAT Gateway is like your home router
Every time you set up a NAT Gateway in a private subnet, you're implementing the same concept your home router uses by letting multiple private devices share one public IP address. The ISP gives your home one public IP address; your router NATs all your devices behind it. AWS does the identical thing, just at scale.
Understanding NAT as a concept instead of just an AWS service will stop you from googling "when do I need a NAT Gateway", you'll just know!
Subnets are VLANs by another name
In physical networking, a switch creates separate collision domains per port . However, to separate broadcast domains, to truly isolate groups of devices, you need VLANs.
In AWS, subnets serve the same purpose as VLANs. A public subnet and a private subnet on the same VPC are logically separated networks sharing the same physical infrastructure , just like VLANs on a managed switch. So you have different ports and different rules but the same hardware underneath.
The Internet Gateway is your Demarc
In physical networking, there's a concept called the demarcation point which is the exact boundary where the service provider's responsibility ends and yours begins. It's essentially a handoff point.
The Internet Gateway in AWS? Same thing. It's the boundary between your virtual private network and the public internet. It doesn't route nor does it filter traffic. It just connects two worlds. An understanding of demarcs will make the Internet Gateway less mysterious.
Security Groups are firewalls
Security groups are firewalls instead of cloud-native security constructs. They inspect traffic and allow or deny it based on defined rules. This is the same thing a physical firewall appliance does in a rack in a data centre.
Gaining an understanding of ACLs (Access Control Lists) on physical routers makes AWS Network ACLs and Security Groups feel intuitive.
What changes when you understand the foundations
When you are only starting out and don't have an understanding of the basics you tend to go more for following tutorials to do your setup instead of first stepping back to figure out what needs to talk to what before you do your provisioning.
Gaining the understanding lets you ask better questions instead of configuring by imitation, so you end up designing and building with more intention.
What's also great about learning the basics is the confidence you gain. When you understand what's happening under the abstraction, you stop being afraid of breaking things.
Here's my challenge to you
If you work with cloud infrastructure, whether it's AWS or any other, and you've never studied basic networking, I encourage you to go back to these basics. The moment these concepts click into place, the cloud transforms from a collection of services into a coherent system you can reason about.
You don't need a degree and you don't need to buy a Cisco router, all you need to do is to learn:
- What a router does (Layer 3, IP-based forwarding)
- What a switch does (Layer 2, MAC-based forwarding, collision/broadcast domains)
- How NAT works
- What VLANs are and why they exist
- The basics of the OSI model
- and more :)
That's it. That foundation will make everything else — every cloud service, every architecture diagram, every networking error you might encounter, make sense like never before.
References
- Collision domain in computer networking
- Open Systems Interconnection Model OSI
- AWS Documentation Amazon VPC
What new things are you learning in the world of cloud, let me know in the comments below.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article