When building a hub and spoke topology with an inspection VPC using firewall appliances, why use a transit gateway to connect VPCs over deploying gateway load balancer endpoints in every VPC ?

Question

Hi AWS networking experts !

Im trying to weight the pros and cons of using a transit gateway to connect several application VPCs with an inspection VPC over using gateway load balancer endpoints  in each app VPC to reach the appliance based firewalls in the inspection VPC.   Goal is to inspect both egress traffic and vpc-to-vpc traffic.   The two architectures are often mentioned in documentation, and for example see https://aws.amazon.com/blogs/publicsector/implementing-third-party-firewall-appliances-aws-comparing-two-methods/
where the transit gateway is used with a single GWLB endpoint in the inspection VPC while we could have deployed GWLB endpoints in each VPC instead and no transit gateway.

Does it only boils down to endpoint costs or am I missing something ?   Data processing looks cheaper with distributed endpoints over TGW endpoints so what functionality am I missing here ?

thanks !

Accepted Answer

It boils down to design and what you want to inspection.. Central E/INGRESS inspection works fine as you can route traffic from the IGW to the GWLB endpoint and control this all via subnets and route tables in the VPC.

For VPC to VPC inspection you then face challanges as gateway LB endpoints will return the traffic back to the orginating subnet via the EndPoint in the VPC. Then you would need to be able to get that traffic from VPC a to VPC b AFTER inspection, but theres no Elastic Interface on a specific subnet to control how the VPCs route traffic to each other like you have with TGW. You cant use VPC Peering correctly because of this and TGW is a PreReq!

If you want traffic to be inspected when it leaves VPC 1 to VPC 2 then you will need to use Transit gateway to route traffic from VPC 1 to Inspection VPC. After its been inspected, it would then route traffic via transit gateway attachment onto VPC 2 and vis-versa.

Answer

Hi JFN,

Both approaches will work. If you have a number of VPCs expected to interconnect in a mesh fashion, the more you add VPCs to your environment, the more complicated it gets to manage routing tables. Thus, adding in Transit Gateway is a breeze. Taking us to basic benefits of TGW.  
Main thing to consider here is to maintain your traffic within the same-AZ to maintain the symmetry of the traffic when entering and leaving the GWLB endpoint. That is one of the biggest benefits TGW brings to your design if you are not enable to maintain traffic between your application stacks within the same AZ. Here is all about it: https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/
Finally, If the existing set up you have for how your VPCs communicate doesn't promote the need for Transit Gateway, then east-west inspection isn't the biggest win. You just have to handle the granularity of the subnet routing for every subnet where the GWLB endpoint is provisioned.

When building a hub and spoke topology with an inspection VPC using firewall appliances, why use a transit gateway to connect VPCs over deploying gateway load balancer endpoints in every VPC ?

相关内容