It’s sometimes the case that you’d like to wrap your Amazon EC2 instances, and perhaps some EFS file stores, up in a nice private environment, as if you had your own little data center. You’d have your own network segments, with perhaps a DMZ or a NAT gateway. You’d be able to define ingress and egress rules for each segment.
AWS bundles those capabilities up in their Virtual Private Cloud (VPC) service.
Configuring a VPC isn’t particularly intuitive; it took a couple of us who already have AWS experience a few hours to work through the options.
The process distilled below outlines two of the most common scenarios:
The steps below can all be scripted and done from a command line, but I’m going to walk you through them using the AWS web console.
Regardless of which scenario appeals to you, you first need to choose an IPv4 address block for your VPC. You can use any RFC 1918 address you’d like, taking a couple things into consideration:
Make the block big enough to expand. Once you’ve allocated a CIDR block to a VPC, you can’t expand it. There’s no reason to use a /16 block if you’re only going to run a few VMs, but it’s wise to think ahead for future expansion.
Avoid any address overlap with your other networks, including your home LAN (and those of any collaborators). You may end up with a VPN at some point. If so, you’ll want discreet address blocks to facilitate easy routing.
Also, decide before you begin whether or not you want IPv6 addressing as part of your setup. I’m a big fan of IPv6, but I’ll be the first to admit that it complicates routing and firewall rules.
Both of the two scenarios outlined start with the same step:
Task: Create a VPC
At this point, you need to answer a couple questions.
One of your subnets needs a direct route to the Internet, but not all of them do. Others can be put behind a NAT gateway.
Task: Create Subnet
Optionally, you can modify the subnet to auto-assign public IPv4 addresses.
Task: Create Internet Gateway
Task: Edit Route Tables
From there, you can proceed to creating EC2 or EFS instances that will reside in your new VPC/Subnet. At least one of your EC2 instances will need an Amazon-issued public address in order for you to be able to log into any of them; in this scenario, however, probably all of them will benefit from public addresses.
The AWS VPC-NAT instructions are tremendously helpful for understanding what’s going on here.
First off, you’ll need to break your VPC CIDR into at least two subnets. At least one you’ll want to designate as “public” and at least one as “private.” Don’t stress over those designations; they have more to do with routing than address space.
The instructions below capture the simplest case, with only two subnets.
Task: Create “public” subnet
Optionally, you can configure the public subnet to auto-assign public IPv4 addresses. Instructions can be found earlier in this document.
Task: Create Internet Gateway
Task: Create Internet Route
Task: Create Elastic IP
Task: Create “private” subnet
Task: Create NAT Gateway
Note Under the hood, a NAT gateway is special-use virtual machine. The process to create it may take several minutes.
At this point, you may have to wait a while if your NAT Gateway has not yet been created and brought online.
Task: Create NAT Route
You’ll want to create at least one EC2 instance in the public subnet, and assign it a public IPv4 address, so you can SSH into that host and, from there, into the private subnet.
The default rules will allow your “DMZ” hosts full access to the VMs in the “private” subnet. You can edit the subnet’s ingress and egress rules if that’s not what you want.
Note that an AWS NAT gateway cannot be configured for functions like port forwarding or VPN termination. You’ll need to configure your own NAT host if you need those functions.