Skip to content

Latest commit

 

History

History
52 lines (45 loc) · 3.47 KB

transit-gateway.md

File metadata and controls

52 lines (45 loc) · 3.47 KB
Raw

AWS Transit Gateway

  • It is a network transit hub which connects VPCs to each other and to on-premise networks using Site-to-Site VPNs and Direct Connects
  • It is designed to reduce the network architecture complexity in AWS
  • It is a network gateway object, it is HA and scalable
  • Attachments: we create attachments in order for the TGW to connect to VPCs and on-premise networks. Valid attachments are:
    • VPC attachments
    • Site-to-Site VPN attachments
    • Direct Connect Gateway attachments
  • Attachments are configured in each subnet of the connected VPCs
  • We can also peer transit gateways across cross regions and/or cross accounts
  • We can also attach transit gateways to the DX connections
  • Transit Gateway Considerations:
    • Supports transitive routing: single transit gateway with multiple attachments using route tables
    • Can be used to create global networks with peering
    • We can share transit gateways using AWS RAM
    • Transit Gateways offer less complex architectures compared to VPC peering solutions

Transit Gateway - Deep Dive

  • Transit gateway is a hub-and-spoke architecture, it can connect to various types of networking objects within AWS
  • Integration with Direct Connect:
    • A Transit VIF is required which goes through a DX Gateway
    • The DX Gateway can be attached to the Transit Gateway with a Transit Gateway Attachment
    • 1 DX Gateway can be attached to 3 Transit Gateways
  • Transit Gateway has a default route table which is populated from the attachments:
    • For the VPCs we have the CIDR ranges of these VPCs
    • For VPNs we have the routes learned via BGP
    • For DX Gateways with the Transit Gateway Attachment we define the networks within the attachment configured at the DX Gateway side
  • We can peer TGWs with other TGWs between regions. We can peer a TGW with up to 50 other TGWs, and these TGWs can also peer with other TGWs
  • A TGW by default has one route table
  • All attachments use this RT for routing decisions, by default all attachments propagate routes to this route table, exception peering attachments
  • All attachments can route to all other attachments by default

Transit Gateway Peering

  • In case of peering attachments routes are not shared, we need to use static routes, similar to VPC peering (AWS recommends using unique ASNs for future enhancements for route advertisements)
  • Resolution of public DNS to private addressing is not supported over inter-region peers
  • Data transfer over peering connection is encrypted and is sent over AWS network
  • We can peer up to 50 peering attachments per TGW, these can be in different regions, different AWS accounts

Transit Gateway Isolated Routing

  • By default:
    • All attachments are associated with the same route table
    • All attachments propagate to the same route table, all attachments are aware of any other attachments
  • Attachments can only be associated with 1 route table, route tables can be associated to many attachments
  • Attachments can propagate to many RTs, event to those they are not associated with
  • If we would want to isolate networks:
    • We create a route table and we configure all attachments to propagate to the route table
    • We associate the route table with only the attachments we would want to communicate with each other
    • We create another route and associate it to the attachment we don't want to communicate with each other. We configure other attachments to propagate to this route table