- 최신
- 최다 투표
- 가장 많은 댓글
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.
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.
관련 콘텐츠
AWS 공식업데이트됨 3년 전- AWS 공식업데이트됨 2년 전
