AWS VPC networking in plain English (1)

Just enough networking for backend engineers who develop services on AWS

(this is a modified version of article that I published on my LinkedIn articles last year)

When I work with software engineers who are new to cloud environment, I found that everyone loves how the cloud infrastructure has empowered us to accomplish our work, but there is one topic that seems to be unfamiliar to us, and that is networking (topology and security design). “VPC, Internet gateway, public subnet, private subnet, route table…”, a lot of terms and most of them sound a bit unfamiliar and even intimidating.

But the reality is that AWS networking does not need to be an intimidating topic for a regular software engineer. In this post, I’d try to use a daily life analogy to explain some of the basic topics in AWS networking (please give me an upvote below 👇 if the analogy is clear and easy enough to understand 😄)

Why networking design often happens inside backend team

There are two reasons why discussions of networking happen in a software development team building micro-services on AWS:

1. “you build it, you run it”, micro-service oriented software architecture requires small team owns the develop, deploy and operate an independent (micro-)service, and networking topology and network security decision have to be considered by the micro-service development team;

2. Infrastructure as code, especially the ownership transition to developer through tools like sls and AWS CDK as we discussed in a previous post, made the development team own the infrastructure design, and networking is part of the infrastructure design

A VPC is not too different from a parking lot, and here is the analogy

Here I wanted to use our daily driving as the metaphor to talk about VPC, IGW, Subnets and Route table.

1. We probably all had experience on parking in a large gated parking lot with fence around it, I guess. -- we can imagine that VPC (Virtual Private Cloud) is a big gated parking lot with fence around it;

2. then that parking lot has one gate for cars coming in and out of it -- that gate is IGW, Internet Gateway;

3. within this big parking lot, there could be multiple well planned and relatively separated area (and these areas are typically used for different purposes) -- we can think of subnets as these separated areas;

4. In that parking lot, in the entrance/exit of each the above separated areas, there exist route signs like "<==Exit", "Long-term Parking ==>" -- we can think of route table as these route signs for a driver getting out of that separated area to follow (therefore, route-table is a per subnet concept though multiple subnets can share a route table)

I am not a good sketcher, but I am bold enough to draw one and attach here for this article below:

How would backend engineer own the Infrastructure as code (and the design of networking) in cloud era?

(I argued that software engineers will own infrastructure as code in my previous post, and that’s why a small and nimble team of software engineers will discuss networking topics in my mind, so I write a simple piece of code in this section)

Here I use ~20 line AWS CDK code to codify and built the VPC corresponding the above parking lot sketch, which is what roughly a lot of simple production VPCs really are.

import * as cdk from '@aws-cdk/core';
import * as ec2 from '@aws-cdk/aws-ec2'


export class ParkinglotNVpcStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);


    // The code that defines your stack goes here
    const vpc = new ec2.Vpc(this, 'ParkingLot', {
      cidr: '10.1.0.0/16',
      subnetConfiguration: [{
          cidrMask: 24,
          name: 'public subnet',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'private subnet',
          subnetType: ec2.SubnetType.ISOLATED,
        },
      ],
    });
 } 
}

(If you want to play with this piece of simple CDK code, here is the git repo)

Next, what would you think of security group and network ACL? Let’s talk about it next time, stay tuned…