Browse the Repo

file-type-icon.circleci
file-type-iconexamples
file-type-iconmodules
file-type-icon_docs
file-type-iconnetwork-acl-inbound
file-type-iconnetwork-acl-outbound
file-type-iconvpc-app-network-acls
file-type-iconvpc-app
file-type-iconREADME.md
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf
file-type-iconvpc-dns-forwarder-rules
file-type-iconvpc-dns-forwarder
file-type-iconvpc-flow-logs
file-type-iconvpc-interface-endpoint
file-type-iconvpc-mgmt-network-acls
file-type-iconvpc-mgmt
file-type-iconvpc-peering-cross-accounts-accepter
file-type-iconvpc-peering-cross-accounts-requester
file-type-iconvpc-peering-external
file-type-iconvpc-peering
file-type-icontest
file-type-icon.gitignore
file-type-icon.pre-commit-config.yaml
file-type-iconCODEOWNERS
file-type-iconLICENSE.txt
file-type-iconREADME.md
file-type-iconterraform-cloud-enterprise-private-module-...

Browse the Repo

file-type-icon.circleci
file-type-iconexamples
file-type-iconmodules
file-type-icon_docs
file-type-iconnetwork-acl-inbound
file-type-iconnetwork-acl-outbound
file-type-iconvpc-app-network-acls
file-type-iconvpc-app
file-type-iconREADME.md
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf
file-type-iconvpc-dns-forwarder-rules
file-type-iconvpc-dns-forwarder
file-type-iconvpc-flow-logs
file-type-iconvpc-interface-endpoint
file-type-iconvpc-mgmt-network-acls
file-type-iconvpc-mgmt
file-type-iconvpc-peering-cross-accounts-accepter
file-type-iconvpc-peering-cross-accounts-requester
file-type-iconvpc-peering-external
file-type-iconvpc-peering
file-type-icontest
file-type-icon.gitignore
file-type-icon.pre-commit-config.yaml
file-type-iconCODEOWNERS
file-type-iconLICENSE.txt
file-type-iconREADME.md
file-type-iconterraform-cloud-enterprise-private-module-...
Virtual Private Cloud (VPC)

Virtual Private Cloud (VPC)

Create a Virtual Private Cloud (VPC). Includes multiple subnet tiers, NACLs, NAT gateways, Internet Gateways, and VPC peering.

Code Preview

Preview the Code

mobile file icon

README.md

down

VPC-App Terraform Module

This Terraform Module launches a single VPC meant to house applications. By contrast, DevOps-related services such as Jenkins or InfluxDB should be in a "mgmt" VPC. (See the vpc-mgmt module.)

How do you use this module?

Check out the examples folder.

What's a VPC?

A VPC or Virtual Private Cloud is a logically isolated section of your AWS cloud. Each VPC defines a virtual network within which you run your AWS resources, as well as rules for what can go in and out of that network. This includes subnets, route tables that tell those subnets how to route inbound and outbound traffic, security groups, access controls lists for the network (NACLs), and any other network components such as VPN connections.

Three Subnet Tiers

This VPC defines three "tiers" of subnets:

  • Public Subnets: Resources in these subnets are directly addressable from the Internet. Only public-facing resources (typically just load balancers) should be put here.
  • Private/App Subnets: Resources in these subnets are NOT directly addressable from the Internet but they can make outbound connections to the Internet through a NAT Gateway. You can connect to the resources in this subnet only from resources within the VPC, so you should put your app servers here and allow the load balancers in the Public Subnet to route traffic to them.
  • Private/Persistence Subnets: Resources in these subnets are neither directly addressable from the Internet nor able to make outbound Internet connections. You can connect to the resources in this subnet only from within the VPC, so you should put your databases, cache servers, and other stateful resources here and allow your apps to talk to them.

VPC Architecture

The three-tier VPC is inspired by the VPC Architecture described by Ben Whaley in his blog post A Reference VPC Architecture. That blog post proposed the following VPC structure:

VPC Diagram

To summarize:

  • Each environment (prod, stage, etc.) is represented by a separate VPC.
  • Each VPC has three "tiers" of subnets to allow AWS resources to be publicly addressable, addressable only from the public tier, or only from the private/app tier.
  • In a given subnet tier, there are usually three or four actual subnets, one for each Availability Zone.
  • Therefore, if we created a single VPC in the us-west-2 region, which has Availability Zones us-west-2a,us-west-2b, and us-west-2c, each subnet tier would have three subnets (one per Availability Zone) for a total of 9 subnets in all.
  • The only way to reach this VPC is from the public Internet via a publicly exposed sevice, or via the mgmt VPC, which uses VPC Peering to make this VPC accessible from the mgmt VPC.
  • Philosophically, everything in a VPC should be isolated from all resources in any other VPC. In particular, we want to ensure that our stage environment is completely independent from prod. This architecture helps to reinforce that.

Throughout our diagrams and examples we recommend a /16 CIDR range for VPCs. The reason for this is that a /16 makes CIDR math quite straightforward. If using the 10.0.0.0/8 RFC1918 address space, this allows for 256 VPCs (10.0.0.0/16-10.255.255.255/16) with 65,534 IP addresses per VPC. This should be sufficient for nearly all use-cases, and is consistent with many examples and existing documentation found elsewhere.

Gotchas

  • If the num_availability_zones variable in the mgmt VPC and the num_availability_zones variable in the app VPC don't match, there are problems with the routes that are created between the two VPCs as part of setting up VPC Peering. If your use case requires different numbers of Availability Zones for each of these VPCs, please let us know and we'll investigate further!

Other VPC Core Concepts

Learn about Other VPC Core Concepts like subnets, NAT Gateways, and VPC Endpoints.

Questions? Ask away.

We're here to talk about our services, answer any questions, give advice, or just to chat.

Ready to hand off the Gruntwork?