NatGateway Config for Public Subnet Control to Allow NACL Controls

[moofish32]

While editing for #740 I realized that we will in fact have to bring this property back.

Many teams that use a NAT GW are required to control traffic with a Network Access Control List (NACL). So typically there is a group of subnets for truly public inbound traffic where the sole control is security groups. Then you have an egress subnet (also public) that has a NACL associated. The NACL is typically used to block outbound traffic to port 22, restrict 53 for DNS or block if R53 only, block NTP if using AWS provided, allow outbound ports for security utilities to approved IP lists. If this control is placed on public subnet obvious problems would occur.

The current design will allocate the NAT GW's in the first Public Subnet for that zone.

Another option would be create another subnet type for NAT'd traffic. This would avoid introducing another parameter.

[rix0rrr]

Am I understanding correctly that the issue is that we want to have the ability to have a public subnet with a network ACL and one without in the same VPC?

And we'd make the distinction using a CIDR-based rule?

[moofish32]

@rix0rrr in the picture the issue is the red box and the NAT GW. Our design today will put NAT GW in the first public subnets received in the createSubnets loop. If those NAT GW go into the Public ingress Subnets then then the NACL on the Public egress Subnet is entirely useless. So the feature request is to be able to assign the NAT GW to a specific set of Public Subnets. I thought of a few hows:

1. Add natGatway property back to subnet configurations
2. Add a subnet type for NAT Subnet
3. Add VPC level property that says natGateway: VpcPlacementStrategy using the by name configuration

The second option has the unfortunate ripple into VpcNetowrkRef, so I'm not sure we want that.

Did this clear up your questions?

[rix0rrr]

Somewhat. My next question is, how are you making a distinction between ingress and egress public subnets right now? If the answer is, you just have two public subnets in your config, that's great that that works already!

Then I think my preference would be just another placement strategy for the NAT gateways.

(Which we might need to rename to SubnetSelectionStrategy, btw)

[moofish32]

The distinction is by name right now. CloudFormation makes a Public subnet that has a NAT in it and name/tag Egress. The problem is I can't control which subnet gets the NAT today (unless I trust ordering and that has other implications). So when I go back to put the NACL on a subnet how do I choose the right one? If i go by name I can't ensure the NAT is in the right spot.