Originally from finos/terraform-aws-cfi-eks#7 (comment)

Broadly speaking, we think, define VPC as a mod with all the features one'd want, with switches in the resources for count so that if var true then deploy element else don't. This provides flexibility for members deploying a VPC but who dont want routing and subnets with it for instance. Example

resource "aws_subnet" "main" {
  count = var.add_subnets == true ? var.num_subnets : 0
...

etc.

In my VPC, I have:

aws_default_security_group
aws_security_group
aws_network_acl

aws_eip
aws_internet_gateway
aws_nat_gateway
aws_route
aws_route_table
aws_route_table_association

aws_subnet
aws_vpc
aws_vpc_endpoint
aws_vpc_endpoint_route_table_association

split into security, routing and core. We would need to associate groups of resources to need so eg no point having a switch allowing a user to not have an endpoint resource, but still have an endpoint route table association.

We should then excise as needed to create separate compliant child mods for these as well (eg a subnet mod) for max flex.

I think also SSH key and VPC peering mods.

Originally posted by @ml4 in finos/terraform-aws-cfi-eks#7 (comment)