Skip to main content
Service Catalog Version 0.78.1

VPC

View SourceFiltered Release Notes

Overview​

This service contains code to deploy a Virtual Private Cloud (VPC) on AWS that can be used for either production or non-production workloads.

VPC architectureVPC architecture

Features​

  • The VPC itself.
  • Subnets, which are isolated subdivisions within the VPC. There are 3 "tiers" of subnets: public, private app, and private persistence.
  • Route tables, which provide routing rules for the subnets.
  • Internet Gateways to route traffic to the public Internet from public subnets.
  • NATs to route traffic to the public Internet from private subnets.
  • Optionally, VPC peering to a management VPC
  • Optionally, DNS forwarding for a management VPC
  • Optionally, tags for an EKS cluster

Learn​

note

This repo is a part of the Gruntwork Service Catalog, a collection of reusable, battle-tested, production ready infrastructure code. If you’ve never used the Service Catalog before, make sure to read How to use the Gruntwork Service Catalog!

Under the hood, this is all implemented using Terraform modules from the Gruntwork terraform-aws-vpc repo. If you don’t have access to this repo, email support@gruntwork.io.

Core concepts​

To understand core concepts like what’s a VPC, how subnets are configured, how network ACLs work, and more, see the documentation in the terraform-aws-vpc repo.

Repo organization​

  • modules: The main implementation code for this repo, broken down into multiple standalone, orthogonal submodules.
  • examples: This folder contains working examples of how to use the submodules.
  • test: Automated tests for the modules and examples.

Deploy​

Non-production deployment (quick start for learning)​

If you just want to try this repo out for experimenting and learning, check out the following resources:

  • examples/for-learning-and-testing folder: The examples/for-learning-and-testing folder contains standalone sample code optimized for learning, experimenting, and testing (but not direct production usage).

Production deployment​

If you want to deploy this repo in production, check out the following resources:

Reference​

  • associate_default_nacl_to_subnets — If true, will associate the default NACL to the public, private, and persistence subnets created by this module. Only used if apply_default_nacl_rules is true. Note that this does not guarantee that the subnets are associated with the default NACL. Subnets can only be associated with a single NACL. The default NACL association will be dropped if the subnets are associated with a custom NACL later.
  • availability_zone_exclude_names — Specific Availability Zones in which subnets SHOULD NOT be created. Useful for when features / support is missing from a given AZ.
  • aws_region — The AWS region in which all resources will be created
  • cidr_block — The IP address range of the VPC in CIDR notation. A prefix of /18 is recommended. Do not use a prefix higher than /27. Examples include '10.100.0.0/18', '10.200.0.0/18', etc.
  • create_dns_forwarder — Whether or not to create DNS forwarders from the Mgmt VPC to the App VPC to resolve private Route 53 endpoints. This is most useful when you want to keep your EKS Kubernetes API endpoint private to the VPC, but want to access it from the Mgmt VPC (where your VPN/Bastion servers are).
  • create_flow_logs — If you set this variable to false, this module will not create VPC Flow Logs resources. This is used as a workaround because Terraform does not allow you to use the 'count' parameter on modules. By using this parameter, you can optionally create or not create the resources within this module.
  • create_igw — Whether the VPC will create an Internet Gateway. There are use cases when the VPC is desired to not be routable from the internet, and hence, they should not have an Internet Gateway. For example, when it is desired that public subnets exist but they are not directly public facing, since they can be routed from other VPC hosting the IGW.
  • create_network_acls — If set to false, this module will NOT create Network ACLs. This is useful if you don't want to use Network ACLs or you want to provide your own Network ACLs outside of this module.
  • create_public_subnet_nacls — If set to false, this module will NOT create the NACLs for the public subnet tier. This is useful for VPCs that only need private subnets.
  • create_public_subnets — If set to false, this module will NOT create the public subnet tier. This is useful for VPCs that only need private subnets. Note that setting this to false also means the module will NOT create an Internet Gateway or the NAT gateways, so if you want any public Internet access in the VPC (even outbound access—e.g., to run apt get), you'll need to provide it yourself via some other mechanism (e.g., via VPC peering, a Transit Gateway, Direct Connect, etc).
  • custom_tags — A map of tags to apply to the VPC, Subnets, Route Tables, Internet Gateway, default security group, and default NACLs. The key is the tag name and the value is the tag value. Note that the tag 'Name' is automatically added by this module but may be optionally overwritten by this variable.
  • flow_log_cloudwatch_iam_role_name — The name to use for the flow log IAM role. This can be useful if you provision the VPC without admin privileges which needs setting IAM:PassRole on deployment role. When null, a default name based on the VPC name will be chosen.
  • flow_log_cloudwatch_log_group_name — The name to use for the CloudWatch Log group used for storing flow log. When null, a default name based on the VPC name will be chosen.
  • kms_key_arn — The ARN of a KMS key to use for encrypting VPC the flow log. A new KMS key will be created if this is not supplied.
  • kms_key_deletion_window_in_days — The number of days to retain this KMS Key (a Customer Master Key) after it has been marked for deletion. Setting to null defaults to the provider default, which is the maximum possible value (30 days).
  • kms_key_user_iam_arns — VPC Flow Logs will be encrypted with a KMS Key (a Customer Master Key). The IAM Users specified in this list will have access to this key.
  • nat_gateway_custom_tags — A map of tags to apply to the NAT gateways, on top of the custom_tags. The key is the tag name and the value is the tag value. Note that tags defined here will override tags defined as custom_tags in case of conflict.
  • num_availability_zones — How many AWS Availability Zones (AZs) to use. One subnet of each type (public, private app) will be created in each AZ. Note that this must be less than or equal to the total number of AZs in a region. A value of null means all AZs should be used. For example, if you specify 3 in a region with 5 AZs, subnets will be created in just 3 AZs instead of all 5. Defaults to all AZs in a region.
  • num_nat_gateways — The number of NAT Gateways to launch for this VPC. For production VPCs, a NAT Gateway should be placed in each Availability Zone (so likely 3 total), whereas for non-prod VPCs, just one Availability Zone (and hence 1 NAT Gateway) will suffice.
  • origin_vpc_id — The ID of the origin VPC to use when creating peering connections and DNS forwarding.
  • origin_vpc_name — The name of the origin VPC to use when creating peering connections and DNS forwarding.
  • origin_vpc_public_subnet_ids — The public subnets in the origin VPC to use when creating route53 resolvers. These are public subnets due to network ACLs restrictions. Although the forwarder is addressable publicly, access is blocked by security groups.
  • persistence_propagating_vgws — A list of Virtual Private Gateways that will propagate routes to persistence subnets. All routes from VPN connections that use Virtual Private Gateways listed here will appear in route tables of persistence subnets. If left empty, no routes will be propagated.
  • persistence_subnet_bits — Takes the CIDR prefix and adds these many bits to it for calculating subnet ranges. MAKE SURE if you change this you also change the CIDR spacing or you may hit errors. See cidrsubnet interpolation in terraform config for more information.
  • private_app_allow_inbound_ports_from_cidr — A map of unique names to client IP CIDR block and inbound ports that should be exposed in the private app subnet tier nACLs. This is useful when exposing your service on a privileged port with an NLB, where the address isn't translated.
  • private_app_allow_outbound_ports_to_destination_cidr — A map of unique names to destination IP CIDR block and outbound ports that should be allowed in the private app subnet tier nACLs. This is useful when allowing your VPC specific outbound communication to defined CIDR blocks(known networks)
  • private_app_subnet_cidr_blocks — A map listing the specific CIDR blocks desired for each private-app subnet. The key must be in the form AZ-0, AZ-1, ... AZ-n where n is the number of Availability Zones. If left blank, we will compute a reasonable CIDR block for each subnet.
  • private_persistence_subnet_cidr_blocks — A map listing the specific CIDR blocks desired for each private-persistence subnet. The key must be in the form AZ-0, AZ-1, ... AZ-n where n is the number of Availability Zones. If left blank, we will compute a reasonable CIDR block for each subnet.
  • private_propagating_vgws — A list of Virtual Private Gateways that will propagate routes to private subnets. All routes from VPN connections that use Virtual Private Gateways listed here will appear in route tables of private subnets. If left empty, no routes will be propagated.
  • private_subnet_bits — Takes the CIDR prefix and adds these many bits to it for calculating subnet ranges. MAKE SURE if you change this you also change the CIDR spacing or you may hit errors. See cidrsubnet interpolation in terraform config for more information.
  • public_propagating_vgws — A list of Virtual Private Gateways that will propagate routes to public subnets. All routes from VPN connections that use Virtual Private Gateways listed here will appear in route tables of public subnets. If left empty, no routes will be propagated.
  • public_subnet_bits — Takes the CIDR prefix and adds these many bits to it for calculating subnet ranges. MAKE SURE if you change this you also change the CIDR spacing or you may hit errors. See cidrsubnet interpolation in terraform config for more information.
  • public_subnet_cidr_blocks — A map listing the specific CIDR blocks desired for each public subnet. The key must be in the form AZ-0, AZ-1, ... AZ-n where n is the number of Availability Zones. If left blank, we will compute a reasonable CIDR block for each subnet.
  • public_subnet_custom_tags — A map of tags to apply to the public Subnet, on top of the custom_tags. The key is the tag name and the value is the tag value. Note that tags defined here will override tags defined as custom_tags in case of conflict.
  • security_group_tags — A map of tags to apply to the default Security Group, on top of the custom_tags. The key is the tag name and the value is the tag value. Note that tags defined here will override tags defined as custom_tags in case of conflict.
  • subnet_spacing — The amount of spacing between the different subnet types
  • tag_for_use_with_eks — The VPC resources need special tags for discoverability by Kubernetes to use with certain features, like deploying ALBs.
  • tenancy — The allowed tenancy of instances launched into the selected VPC. Must be one of: default, dedicated, or host.
  • vpc_custom_tags — A map of tags to apply just to the VPC itself, but not any of the other resources. The key is the tag name and the value is the tag value. Note that tags defined here will override tags defined as custom_tags in case of conflict.
  • vpc_name — Name of the VPC. Examples include 'prod', 'dev', 'mgmt', etc.