Advanced Architectures with AWS Transit Gateway

In this session, we discuss the need for AWS Transit Gateway, dive into common use cases, and discuss reference architectures. The session will prepare you with the fundamentals to understand AWS Transit Gateway operations and create advanced architectures. Learn how AWS Transit Gateway interacts with other services, like Amazon Route 53 Resolver and AWS PrivateLink, to provide enterprise scale service in large operating environments.

[@jamesren4949]

Dear Alan, thanks very much for the excellent explanation of Transit Gateway. However, I have two questions:
1. when you mentioned about the 10.0.0.0/8 blackhole rule, I think there is a pre-requisite that the SNAT instance is single-nic. In a typical NAT setup, you would have traffic flowing from inside to outside. because both source and destination reside behind inside, the SNAT instance should return the traffic without NAT.
2. could you please explain more about the Availability Zone affinity rule for Transit Gateway? For example, if one VPC attaches with two subnets in two AZs, and the other VPC attaches with three subnets in three AZs, what would happen to/from traffic from the third AZ?

[@brandondyzel130]

Hi Alan, I'd also like to get some more details regarding how exactly the Transit GW Routing Domains share routes with each other? For instance, you have your two VPC's connected to a VPC Route Domain, and then an outbound route domain, did those prefixes have to be manually created or is there a way to have automatic propagation with an approval review process?

[@studyit8141]

Does Amazon ECS service discovery work with this Centralized private link with Hybrid cloud architecture reference in this video ?
Could you share us more details how it works with conjunction with shared service VPC hosting all private hosted zones and R53 DNS resolver endpoints setup ?

[@felixkhang1243]

are there plans to allow connectivity between tgw's across different regions and different AWS accounts?

[@nikhiljaswal]

TGW peering is available across some AWS regions which allows this

[@peppigue]

Transit gateway - 4 syllables
TGW - 5 syllables
Sometimes acronyms only make sense in writing

[@TheMightyWalk]

Good find 😂

[@fukhell684]

Awesome. 10/8 not needed actually for VPC routing domain as this route table is used only for association VPCs. Propogation of 0/0 to VPC routing domain will be done for the attachment of Egress (centralized VPC) in Outboand routing domain.

[@alakanandas6358]

Can I enable communication between multiple VPCs in different region to the on-premise network through a single VPN connection attached to my transit gateway (if transitive peering enabled)?

[@SRohit52]

yes

[@expensivetechnology9963]

This presenter is EXTREMELY organized and easy to follow. I’ve found a small mistake in his presentation at 18:30. His VPC is defined as 10.1.0.0/16. So far so good. But then he uses the following example...’I have a host 10.1.0.1 that wants to communicate with an on-premises host 172.x.x.x’. Anyone? Anyone? The 10.1.0.1 is reserved for the router. And just to be crystal clear - I think this presenter is FAR FAR more knowledgeable about AWS networking than me. I’m under no illusion.

[@komalthecoolk]

He's made a number of mistakes during his presentation sadly.

[@ozzykozy]

is it possible to make active active / active-standby two vpn tunnel by using static route ?

[@ashishniture5436]

You can build route based VPN on one CGW (Keeps both the tunnels of VPN UP - CGW must be capable of handling asymmetric routing) We got Active Active | Active standby can be achived by creating a policy based VPN tunnel on the CGW, provided that some kind of failover mechanism is implemented to bring make the Standyby tunnel active.
But always make use BGP based VPN.

[@ozzykozy]

Do you have any example? İs it possible with static route..

[@krzysztofhermanowski7137]

18:35, you can't have instance with the IP of 10.1.0.1 there ;)

[@krzysztofhermanowski7137]

19:30, you meant routing domain for VPN