AWS Advanced Networking - VPC Peering vs Transit Gateway
Cloud networking, cloud network design, network application security
With large organizations and large projects, oftentimes they will consist of microservices that are located in different networks (VPCs) . When they need to interact with each other using IPv6 or IPv4 addresses, the two commonly used solutions are VPC Peering or Transit Gateway.
VPC Peering can be effective for architectures with low complexity. In general there will be more overhead dealing with VPC Peering with 4 or more VPCs. With each additional peer, there will be a possibility of conflicting local private cidr blocks, and more operational overhead of doing the peering. Some advantages of VPC Peering are the following:
Network traffic takes one less hop.
AWS TGW has some quotas involved (2) but it is highly scalable for the vast majority of applications. The quota is 100 gbps per availability zone per transit gateway attachment.Â
TGW has a cost associated with it, the cost is a static .1 per hour, and .02 per gb processed (3).
AWS Transit Gateways are generally a great solution that is pushed heavily by AWS. It is very useful to have a hub and spoke model when you are trying to onboard a lot of services, have a lot of microservices, or generally want less operational overhead. The lower operational cost can provide longer term operational security.
In order to use AWS Transit Gateway effectively, often times people will create a customer managed prefix list, and associate all VPCs with it (4). Then, this prefix list will be used in VPC’s route tables or security groups, to match traffic destined for these cidr blocks, and set the destination being the transit gateway attachment. Then, the transit gateway should know how to route the prefix list to the associated cidrs, using transit gateway routing tables.
References:Â