Let’s dig into VPCs or Virtual Private Clouds. Essentially a VPC is a logical boundary, or essentially an encapsulated environment with no default ingress or egress. The thing with cloud is it’s so very network dependent but in AWS cloud everything is defaulted to no access. That’s why we use security groups, NATs, and Internet Gateways (IGWs). VPCs are the construct of how we draw a demarcation around services in a shared resource model. A VPC is a /28 to /16 netmask CiDR block at its core.

Ok that’s a lot of words so how does this look, well when you initially sign up for AWS and log in you are given a default VPC. This is great but not the best to use for building out your actual workloads. Therefor you will want to build a VPC but is just one VPC the answer? Well it depends on your needs and your architecture.

As I mentioned before a VPC is a set of IP addresses in a CiDR block, it is important when designing your VPC to ensure you have enough IP addresses to perform all of the functions that you are planning. Therefor you start with a /16 which gives you 254 /24 subnets. The best practice guidance is to use private IP space to create your VPC, as specified in RFC 1918.

10.0.0.0 – 10.255.255.255 (10/8 prefix)

172.16.0.0 – 172.31.255.255 (172.16/12 prefix)

192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

As mentioned this block of addresses will be carved into subnets with 5 IPs reserved for management activities (the first 4 and last 1 in the range).

x.x.x.0: Network address.

x.x.x.1: Reserved by AWS for the VPC router.

x.x.x.2: Reserved by AWS. The IP address of the DNS server is always the base of the VPC network range plus two; however, we also reserve the base of each subnet range plus two. For more information, seeAmazon DNS Server.

x.x.x.3: Reserved by AWS for future use.

x.x.x.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.

Subnets are restricted to a VPC and cannot span across VPCs. We can however create peering points between VPCs, and have a single VPC that peers to two VPCs that contain the same subnet, this could be useful in deployments where we want to reuse the same IPs for Test&Dev/Prod or Blue/Green. There are other variations of how and why to peer VPCs but let’s set that aside for a future post and just get our first VPC stood up.

We can do a custom build, but the AWS console has a sweet little VPC wizard we can use. Let’s use the Wizard cause why not.  So as you can see you have 4 options. We are going to select Option 2: a VPC with one public and one private subnet.

We select which AZs we want each of the subnets to sit in and determine if we want a NAT, in this case I am choosing a NAT gateway instead of a NAT instance. There are several reasons to choose one over another, one of the main differences is a NAT gateway will auto-scale whereas a NAT instance requires a script for failover. Compare your options here.

By using the VPC wizard once it’s completed it’s set up our public subnet is also assigned an internet gateway. This means we now have external connectivity to our public subnet.
With that same setup the Private subnet is behind the NAT. We are ready to start building out our EC2 instances.

I highly recommend this video to understand VPC networking even further.

Next up we will discuss storage options in AWS. Feedback on if any of this is useful is helpful for me to make sure I am writing to the correct audience.