Hyperplane TGW latency

Question

Hello,
lets assume a flow from EC2 in VPC A to EC2 in VPC B via a transitgateway.

Would the actual flow look like this?

ENI of EC2 in VPC A -> ENI of TGW Hyperplane node in VPC A -> ENI of TGW Hyperplane node in VPC B -> ENI of EC2 in VPC B

In that case I would have two "hops". From EC2 to TGW and from TGW to EC2.

With a VPC peering instead, I would have a single hop (EC2 to EC2).

That means, adding a TGW in-between must add *some* latency, right (even if we ignore the "processing time" on hyperplane node)?

I wonder if there is always a "nearby" hyperplane ingress node so that the "additional first hop" is very close and then the second hop is similar to the "original" distance from A to B? Then, the additional latency would be minimal. Is this the case (i.e. hyperplane ingress node is always in your "placement group")?

re:Post Agent · Answer

While your understanding of the general flow is correct, there are some nuances to consider regarding Transit Gateway (TGW) and its impact on latency:

1. Flow path: Your described flow is generally accurate. Traffic does indeed go from the source EC2 instance in VPC A to the TGW, then from the TGW to the destination EC2 instance in VPC B.

2. Additional hops: You're correct that using a TGW introduces additional network hops compared to direct VPC peering. This can potentially add some latency to the communication.

3. Latency impact: While TGW does add some latency compared to VPC peering, the impact is typically minimal for most use cases. AWS has designed TGW to be highly efficient and performant.

4. Availability Zone (AZ) affinity: TGW is designed to maintain AZ affinity when possible. This means that if the source and destination EC2 instances are in the same AZ, the TGW will try to keep the traffic within that AZ, minimizing additional latency.

5. Hyperplane nodes: AWS doesn't publicly disclose the exact details of TGW's internal architecture or the placement of hyperplane nodes. However, TGW is designed to be highly available and distributed across AZs in a region.

6. Proximity: While there isn't public information about "nearby" hyperplane ingress nodes or placement groups for TGW, AWS has optimized the service to minimize latency impact. The TGW infrastructure is likely distributed to ensure efficient routing across the region.

7. Trade-offs: While TGW may introduce a small amount of additional latency compared to direct VPC peering, it offers significant benefits in terms of scalability, centralized management, and the ability to connect multiple VPCs and on-premises networks.

In most cases, the added functionality and simplification of network architecture provided by TGW outweigh the minimal latency increase. However, for extremely latency-sensitive applications, direct VPC peering might still be preferred if it meets all other requirements.  
**Sources**  
[Community | Optimizing Performance and Cost with Multi-AZ Architecture: Guidelines for Multi-Account Environments](https://community.aws/content/2dj5ViJTpDlQZYmsplIwGarLcyj/improving-availability-and-performance-with-multi-az-architecture)  
[AWS hybrid connectivity services - Hybrid Connectivity](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-hybrid-connectivity-services.html)  
[Enabling global expansion and reduced operational overhead at Comcast with AWS Transit Gateway | Networking & Content Delivery](https://aws.amazon.com/blogs/networking-and-content-delivery/enabling-global-expansion-and-reduced-operational-overhead-at-comcast-with-aws-transit-gateway/)

Hyperplane TGW latency

Add your answer

Relevant content