Infrastructure as Code

Building a not production ready VPC with Terraform

By Joe Ritchey Updated Sun 27 December 2020
Terraform IaC AWS VPC development cloud cost NAT Gateway CI/CD

I often see a lot of posts about building the production ready cloud VPC and notabley this is worth all of the buzz. Produciton is where the money is made. On the other hand development (or staging, or test, or expermients, whatever you want to call it), that is where a lot of the magic happens.

I'm going to use Terraform as my tool of choice to manage standing up and tearing down the infrastructure. Terraform is a tool for provisioning infrastructure through code. (https://www.terraform.io/intro/index.html) Tearing things down when they are not in use is one of the keys to saving money in AWS. I'm going to focus on the VPC networking side because this seemed to be where a lot of confusion exists. There is also an opportunity for savings, (or cost overruns depending on how you look at it). Since I am going to be focusing on a development environment, I am going to make a few assumptions from the start:

  • Everything in this environment can be deleted and recreated at any time.
  • High availability, high reliability is not a concern.
  • Still adhere to best security practices, like not making databases publicly accessible.

What we are going to setup

  • A new VPC with a CIDR range of 172.16.0.0/24
  • Four subnets total
    • Two public subnets in us-east-1a and us-east-1b
    • Two private subnets in us-east-1a and us-east-1b
  • A Internet Gateway attached as the default route (0.0.0.0/0)
  • VPC endpoints for s3, dynamodb (this are the only gateway endpoints available at the time of this writing)

For simplecity sake in this demo, I'm going to use the AWS NAT Gateway vs running an EC2 instance. I'm setting the default to not build a NAT Gateway (cause that shiz cost money!)

Oh, and let's not forget tags, tags, tags! Cloud tracking and managing projects are all about the tags. Tagging all day every day.

I am going to start this by using just AWS resources from the Terraform AWS provider and not a module. Once you do get comfortable with Terraform and modules I would suggest looking at the Terraform AWS module https://github.com/terraform-aws-modules/terraform-aws-vpc

Why 4 subnets? Subnets do not cost anything to have and if you want to run RDS you need two subnets. First of course is the VPC. We will need the VPC ID when all of the other resources are built. Subnets Here is what I worked out for 4 subnets in a /24 CIDR range 172.16.0.0 - 172.16.0.255

  • 172.16.0.0 - 172.16.0.63/26 -> 172.16.0.1 - 172.16.0.62
  • 172.16.0.64 - 172.16.0.127/26 -> 172.16.0.65 - 172.16.0.126
  • 172.16.0.128 - 172.16.0.191/26 -> 172.16.0.129 - 172.16.0.190
  • 172.16.0.192 - 172.16.0.255/26 -> 172.16.0.193 - 172.16.0.254

For the non-subnet hackers. I'm pretty sure I could just hear a collective, "What the literal f@@@, is this sh@@" To say it simpley I've broken up the range of IP addresses (ipv4 addresses if you want me to be technical), into 4 equal segments. Now I am not briliant enough to just say split a huge range of IP addresses into equal groups in my head. I have had a little help from my friends: http://www.subnet-calculator.com/.

Then there are the VPC endpoints. I've always found the VPC endpoint a little more difficult to explain. The endpoints are more difficult to come up with a ananolgy to a data center. A S3 VPC endpoint routes requests to the AWS S3 service without going through a Internet Gateway. This mean requests from say your EC2 instances to S3, will have the private IP address show up as the origin of the request. Without a S3 VPC endpoint this request would either be from the NAT Gateway or the Public IP address attached to your instance.