East/west security & Transit Gateway

Question

Customer has implemented TGW and initially had very limited east/west routing in place (just service account, DX , etc). They are now increasingly needing to implement connectivity between VPCs and due to the large number of AWS accounts involved don't want to use VPC peering.

They are considering opening up the routing to allow all the accounts to route to each other but then need a way of securing access for some of them. The TGW ENI's all terminate in dedicated subnets in each account and one option they are wondering about is to use NACLs in each of these subnets to control access to/from the transit gateway and other accounts.

Does this sound like a workable solution or is there an alternative/best practice option for doing this?

Thanks

Accepted Answer

Your architecture is a good approach. Customers can enable fully meshed routing to the TGW, and then use the NACLs on the subnet where the ENI lives to limit what can access that VPC, assuming as you say, dedicated subnets for the TGW ENI.

You can also use the other option of adding an intermediate security (also know as inspection or appliances) VPC to inspect traffic.

A third option might be to have a look at what firewall manager can do for you, to centrally configure security groups. The only hesitation i have there is that you then end up shifting all your SG configuration centrally, and that in turn may not suit development environments.

Certainly, your suggestion is definitely a manageable one, but i would encourage the customer to be clear about IP CIDR range allocation, and not make life hard for themselves. There are limits to entries in NACLs and you don't want to get to the point where you have to permit/deny many ranges....ideally if its a bank, maybe they could align their ranges with either security level, or business unit, and put the high level control in that way!

East/west security & Transit Gateway

Contenido relevante