Octet

Say this first

An AWS transit gateway is a regional router you attach VPCs, VPNs, Direct Connect gateways and other transit gateways to. Each attachment is associated with one TGW route table, used for its lookups, and can propagate its routes into one or more route tables. That gives hub-and-spoke routing with segmentation, instead of a full mesh of peerings. Azure does the same with Virtual WAN or a hub VNet with a firewall, and GCP with Network Connectivity Center.

Go deeper

Building blocks

Attachments: VPC (one subnet per AZ, best as a small dedicated /28), site-to-site VPN, Direct Connect gateway (through a transit VIF), TGW peering (between regions, static routes only), and Connect (GRE plus BGP for SD-WAN appliances).
Route tables: a TGW can have many. Association says which table an attachment uses when its traffic enters the TGW (exactly one). Propagation says which tables learn that attachment's routes (zero or more).
Static routes can be added, including blackhole routes that drop traffic.
VPC side: the VPC's own route tables still need routes such as 10.0.0.0/8 to tgw-....

Packet walk

Output

VPC A instance -> VPC A route table (10.0.0.0/8 to tgw) -> TGW attachment A
  -> lookup in the route table associated with A -> attachment B -> VPC B local route -> instance

Things to know

It is a regional resource. Inter-region needs TGW peering with static routes.
It charges per attachment hour and per GB processed, so it is not free like peering.
With BGP VPNs it can ECMP across many tunnels, which is how you get past the per-tunnel bandwidth.
Amazon side ASN defaults to 64512 unless you set it at creation.

Equivalents

Azure Virtual WAN: a Microsoft-managed hub with transitive routing between VNets, VPN, ExpressRoute and point-to-site. The do-it-yourself version is a hub VNet with Azure Firewall or an NVA, spokes peered to it, and UDRs pointing at the firewall.
GCP Network Connectivity Center: a hub with VPC spokes and hybrid spokes (VPN, Interconnect, router appliances).

They will ask next

Why put the TGW attachment in its own small subnet?
The attachment ENIs follow the subnet's network ACL and route table. A dedicated subnet lets you keep those simple and separate from workload subnets, which matters for inspection designs.
Does attaching a VPC automatically make it reachable?
Only if the attachment propagates into the right TGW route tables and the VPC route tables point the right prefixes at the TGW. Missing either half is the most common TGW bug.

Traps

Confusing association (where I look up) with propagation (where my routes are learned).
Forgetting the VPC route table entry pointing to the TGW.

How did you do?