AWS Transit Gateway supports both dynamic and static routing. By default, the network elements (VPCs; VPN or DX connections; peered TGWs) attached to a TGW are associated with its default route table, unless otherwise specified. You naturally have the choice to organize routing as you please by creating additional routing tables and then associating each network element attached to the TGW with the routing table of your liking.
The routes that are defined in those routing tables can be defined statically or dynamically. When you attach a network element to a TGW, you specify whether you want the routes coming from that element to be automatically propagated to the TGW route table associated with that element. If you prefer not to, you must specify routing statically to and from the TGW.
Routes can be propagated automatically both from your on-premises networks connected to the TGW via VPN or DX and from your VPCs attached to the TGW. In the first case, routes are advertised back and forth using BGP between the TGW and your on-premises network equipment on the other end of the VPN or DX connection. In the case of VPCs, the routes are propagated from the VPCs to the TGW but not back to the VPCs from the TGW. You then need to update your VPCs’ route table, creating static routes for your VPCs to communicate with the TGW.
One more thing worth mentioning on routing is that Transit Gateway cannot handle VPC attachments when some VPCs contain IP addresses overlapping with each other. Thus, when you want to attach a set of VPCs (or on-premises networks) that may have overlapping IP addresses to a TGW, you need to deal with the overlapping IP addresses first. Going into more details on how exactly to do this goes beyond the scope of this chapter, but make sure to find a solution to that problem before attempting to connect these networks to a TGW. Multiple solutions exist out there, such as network address translation (NAT), leveraging IP version 6 (IPv6) instead of IP version 4 (IPv4) addresses, or leveraging a third-party solution to do the magic for you (typically through NATing).
This chapter started with a discussion of the various options available and how best complex organizations can communicate in a hybrid cloud setup between their on-premises network and their AWS environment. You also looked at specific AWS cloud storage solutions that enable hybrid cloud solutions and extend the capabilities of your on-premises infrastructure.
You then reviewed how complex organizations can make the most of the connectivity options offered by AWS to improve their network security, reliability, and performance postures.
All the network constructs that you have reviewed in this chapter constitute the core components that complex organizations will inevitably leverage when laying out their AWS environment network topology.
The next chapter will focus on how you can best organize and structure your resources within your AWS environment, covering (among other things) topics such as AWS Organizations, service control policies (SCPs), and AWS Control Tower.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
