Understanding Cloud Networking: VPCs
If you needed to understand some fundamentals about cloud networking.
This series of posts serves as a primer for anyone who hears an infrastructure engineer talk about networking or you’re someone who wants to learn about cloud networking. It’s not a deep dive but rather a walk through on what different terms mean and how they apply in different use cases.
So, we’ll be talking about:
Virtual Private Clouds
Subnets
IP addressing
Route tables
Let’s Start Here
For today, we’re dealing with VPCs.
First, we need distinguish the difference between a public cloud and private cloud.
A public cloud is shared cloud infrastructure. It’s shared cloud services that are available to anyone who wants to use it over the public internet by a cloud provider.
There are many well-known public cloud providers like AWS, Google Cloud, Microsoft Azure, DigitalOcean, Linode and Heroku. (Of course there are many more).
Each of them provide different services according to your needs.
How you keep those services isolated for your own separate use from other users in those provider’s network is by provisioning a virtual private cloud.
In the picture above, you have the AWS’ network that is available to all customers. You can provision resources like EC2 instances, S3 buckets, all of that and anyone can have access to it.
Now, in order to safe guard the resources you provision so that they can only be accessed by you only, you set up a VPC.
A little definition: a VPC or a virtual private cloud is an isolated private network within a public cloud.
In an analogy, there’s a big piece of land (AWS network) with all kinds of resources available (EC2 instances, EBS volumes, S3, etc) and you ask the owner to section off a small piece of their land (a VPC) so that you can limit access to the resources you provision.
Now For The Good Stuff
So what you see now is a situation where we have 4 customers each with their own VPC and each customer can access services in whichever way they prefer.
Typically, when you create a VPC, you have to define a CIDR block.
According to AWS:
A CIDR block is a collection of IP addresses that share the same network prefix and number of bits. A large block consists of more IP addresses and a small suffix.
If you want a deep dive into CIDR notation, subnets and IP addressing, have a look at this blog.
Any way, when you define a CIDR block, you have to choose a network prefix (for example, 172.18.0.0) alongside a suffix (for example, 16).
So you’d have something like 172.18.0.0/16 as your chosen CIDR block for your VPC. The suffix here also determines how many usable hosts per subnet are available for you.
Since I chose 16 here that means there are ~65k usable hosts per subnet.
You can use a subnet calculator to see how many usable hosts are available to you.
So, all the resources that you provision will be assigned an IP address under the 172.18.0.0/16 CIDR block (to a specific subnet that you choose) and that’s how your resources will be allocated only to you and the users you allow.
To End Off
This was very short but hopefully you now have an understanding about what a VPC is and what it does.
In the next few posts, we’ll be continuing on putting together the knowledge we have on VPCs to understand the layers below like subnets, IP addresses and route tables to make sense of how data flows through a network you provision.
Side note: there could be little bits and pieces that don’t connect in this article so don’t hesitate to ask me a question about it.