Transit Gateway: when VPC connectivity becomes a network architecture

Suppose bfstore, the fictional organisation used throughout this series, begins with two VPCs.

bfstore-dev
     │
     ▼
VPC peering
     │
     ▼
bfstore-shared-services

A route is added on each side.

Security rules permit the required traffic.

The relationship is easy to describe.

Then another VPC arrives.

bfstore-dev
bfstore-staging
bfstore-prod
bfstore-shared-services

If every VPC needs direct connectivity to every other VPC, the number of point-to-point relationships grows quickly.

With four VPCs, a full mesh requires six peering connections.

With ten, it requires forty-five.

connections in a full mesh

n × (n - 1)
───────────
     2

The problem is not merely the number of peering objects.

Each relationship also brings:

• routes on both sides
• return-path reasoning
• CIDR coordination
• security policy
• DNS decisions
• lifecycle ownership
• evidence of who may reach whom

The diagram begins to resemble an enthusiastic spider that has recently discovered infrastructure as code.

AWS Transit Gateway changes the shape.

                 bfstore-dev
                      │
                      │
bfstore-prod ─── TRANSIT GATEWAY ─── shared-services
                      │
                      │
                observability

The VPCs attach to one Regional routing hub rather than requiring one direct connection for every pair.

AWS describes Transit Gateway as a Regional virtual router. It forwards IPv4 and IPv6 packets at Layer 3 according to the destination address and the route table associated with the attachment from which the packet arrived.

That simplifies connectivity.

It also creates a network control plane.

A transit gateway is not merely where connections meet. Its route tables decide which of those connections are allowed to become paths.

The hub reduces connection sprawl.

The architecture lives in how the hub is governed.

A transit gateway connects attachments

Transit Gateway communicates through attachments, not abstract VPC names.

Current attachment types include:

• VPC
• Site-to-Site VPN
• Direct Connect gateway
• Transit Gateway Connect
• Client VPN
• VPN Concentrator
• transit-gateway peering
• network-function attachments for AWS Network Firewall

Their routing behaviour is not identical.

A VPC attachment can advertise VPC CIDRs through route propagation.

VPN, VPN Concentrator, Direct Connect and Connect attachments can advertise dynamically learned routes where their routing model supports it.

Transit-gateway peering uses static routes.

Network-function attachments currently use static Transit Gateway routes.

The relationship for an ordinary VPC is:

VPC
 │
 ▼
VPC attachment
 │
 ▼
Transit Gateway

The attachment is an architectural object with its own:

• ID
• owner
• state
• Availability Zone coverage
• route-table association
• route advertisements
• feature settings
• capacity
• cost

Attaching a VPC creates a possible entry and exit point.

It does not automatically make that VPC reachable from every other attachment.

ATTACHMENT EXISTS

does not automatically mean

CONNECTIVITY EXISTS

A central gateway may contain attachments for production, non-production, shared services, observability, backup, central egress and partner connectivity without allowing every network to communicate with every other one.

The gateway holds the possible relationships.

Its routing creates the permitted ones.

VPC attachment subnets are part of the path

When a VPC is attached, one subnet is selected from each Availability Zone that should participate in transit connectivity.

AWS creates Transit Gateway network interfaces in those subnets. Only one attachment subnet can be selected in each Availability Zone.

A three-zone VPC might contain:

AVAILABILITY ZONE A

application-a
data-a
transit-a


AVAILABILITY ZONE B

application-b
data-b
transit-b


AVAILABILITY ZONE C

application-c
data-c
transit-c

The attachment uses:

transit-a
transit-b
transit-c

Resources in an Availability Zone can use the VPC attachment only when that zone has an enabled attachment subnet.

I prefer dedicated transit subnets because they make the routing boundary visible and prevent an application subnet from becoming part of the transit data path by accident.

AWS recommends small dedicated attachment subnets, such as /28, a common route table for ordinary transit subnets and open network ACLs on those subnets. Workload filtering can then occur through workload security groups, workload-subnet ACLs or explicit inspection architecture.

The attachment subnet is not merely somewhere AWS parks an interface.

Its route table helps determine where traffic entering the VPC from Transit Gateway goes next.

Transit routing semantics

A packet moving between two VPCs crosses more than one routing domain.

Suppose a production workload sends telemetry to observability.

source:

10.80.20.34


destination:

10.96.12.45

The forward path is:

PRODUCTION WORKLOAD
        │
        ▼
PRODUCTION WORKLOAD-SUBNET ROUTE TABLE
        │
        ▼
PRODUCTION VPC ATTACHMENT
        │
        ▼
TGW ROUTE TABLE ASSOCIATED
WITH THE PRODUCTION ATTACHMENT
        │
        ▼
OBSERVABILITY VPC ATTACHMENT
        │
        ▼
OBSERVABILITY ATTACHMENT-SUBNET
ROUTE TABLE
        │
        ▼
TELEMETRY INGEST

The destination workload subnet’s route table is not an inbound firewall.

It becomes relevant when the destination sends its reply.

RETURN

observability workload-subnet route table
        │
        ▼
Transit Gateway
        │
        ▼
production attachment

The forward route does not generate the return route.

Transit Gateway is not performing connection tracking merely because the reply would be convenient.

Association selects the source routing view

An attachment can be associated with at most one Transit Gateway route table at a time.

That table evaluates traffic arriving from the attachment.

PRODUCTION ATTACHMENT
          │
          ▼
ASSOCIATED ROUTE TABLE

tgw-rt-production

Association answers:

Which routing policy evaluates traffic sent by this attachment?

Development and production can therefore receive different routing views from the same gateway.

development attachment
        │
        ▼
non-production route table


production attachment
        │
        ▼
production route table

Route advertisement tells other tables how to return

The return path may be learned through propagation or created through static routes.

ROUTE ADVERTISEMENT

How does another route table
learn to reach this attachment?

- propagation where supported
- static routes where required

For a VPC attachment, propagation normally installs the VPC CIDR blocks in the selected route tables.

A VPN or Direct Connect attachment may propagate BGP-learned routes.

Connect uses BGP propagation and does not support static routes on the Connect attachment itself.

Transit-gateway peering and network-function attachments require static Transit Gateway routes.

An attachment can propagate into multiple route tables where its attachment model supports propagation.

Connectivity needs both directions

Suppose development should reach shared services.

The route table associated with development needs:

10.112.0.0/16 → shared-services attachment

The table associated with shared services needs a return route:

10.64.0.0/16 → development attachment

The useful test is two independent questions:

Can the source-associated table
reach the destination attachment?


Can the destination-associated table
reach the source attachment?

A connectivity record can make that contract explicit:

flow:
  source:
    account: bfstore-prod
    subnet_class: private-application
    cidr: 10.80.16.0/20

  destination:
    account: bfstore-observability
    service: telemetry-ingest
    cidr: 10.96.12.0/24

  forward:
    vpc_route_table: production-application
    transit_route_table: production
    destination_attachment: observability

  return:
    vpc_route_table: observability-ingest
    transit_route_table: shared-platform
    destination_attachment: production

Route-table names are not decoration.

They describe which policy evaluates each half of the conversation.

The bfstore routing model

For bfstore’s initial AWS Region, I would place one transit gateway in the bfstore-network account.

BFSTORE NETWORK ACCOUNT

AWS Transit Gateway
│
├── development attachment
├── staging attachment
├── production attachment
├── shared-services attachment
├── observability attachment
├── backup attachment
└── central-egress attachment

The route-table model could begin with four routing views.

Production

Associated attachment:

production

Routes towards:

observability
backup
approved shared services
central egress

No route towards:

development
staging
sandbox
policy-test

Non-production

Associated attachments:

development
staging

Routes towards:

non-production shared services
observability
central egress

Production remains absent or explicitly blackholed.

Shared platform

Associated attachments:

shared services
observability
backup

Routes towards approved workload allocations.

The table should not become unrestricted administrative access merely because shared services need return paths.

Egress

Associated attachment:

central egress

Contains return routes towards approved workload and platform CIDRs.

Workload route tables use:

0.0.0.0/0 → central-egress attachment

only where general public IPv4 egress is approved.

The design should begin with the smallest number of route tables that expresses the real segmentation.

One table per attachment is unnecessarily ornate.

One table for the entire organisation is too broad.

The useful unit is a group of attachments that should receive the same routing view.

Defaults, segmentation and blackholes

When default route-table association and propagation are enabled, new attachments can automatically join the default routing view and advertise into it.

That is useful for a connectivity exercise.

all attachments
      │
      ▼
one route table
      │
      ▼
all propagated routes

It is risky for a governed estate.

A sandbox attachment may acquire routes towards production, shared services and central egress before its intended policy has been reviewed.

For bfstore, I would disable automatic default association and propagation.

Every attachment would receive:

• one explicit association
• an explicit route-advertisement set
• a reviewed route contract
• positive and negative connectivity tests

Transit Gateway route tables provide segmentation by controlling which destination networks appear in each attachment’s routing view.

That is not the complete access-control model.

Routes determine network visibility.

Security groups, firewalls and service identity refine what may happen over those paths.

Blackholes make absence explicit

A Transit Gateway route table can contain a blackhole route.

Suppose production contains:

10.64.0.0/12 → blackhole

covering non-production.

A broader route also exists:

10.0.0.0/8 → network-services attachment

Traffic for 10.64.20.30 matches both routes.

The more-specific blackhole wins.

10.64.20.30
      │
      ├── 10.0.0.0/8
      └── 10.64.0.0/12
                       │
                       ▼
                 MORE SPECIFIC
                       │
                       ▼
                   BLACKHOLE

Blackholes can protect against accidental broad summaries, withdrawn attachments or retired networks.

They should remain documented.

An unexplained blackhole during an incident looks remarkably similar to a broken network, largely because it is intentionally behaving like one.

Transit Gateway does not solve address overlap

A transit gateway cannot route normally between networks whose destination ranges have lost unique meaning.

Suppose these VPCs both use:

10.80.0.0/16

A destination such as:

10.80.12.45

does not uniquely identify one VPC.

When a new VPC attachment overlaps an already attached VPC, AWS does not propagate the overlapping route.

Transit Gateway centralises the ambiguity.

It does not resolve it.

IPAM

allocates distinct prefixes
        │
        ▼
TRANSIT GATEWAY

routes those prefixes
        │
        ▼
NETWORK POLICY

controls their relationships

PrivateLink may provide service-specific connectivity between overlapping networks because the consumer connects to local endpoint addresses rather than to the provider CIDR.

That does not make overlap suitable for the routed estate.

A hub can organise a network only when destinations retain unique meaning.

Ownership and attachment contracts

A transit gateway can be shared through AWS Resource Access Manager.

Permitted accounts can create attachments, while the gateway owner controls central route tables and routing policy.

For bfstore:

BFSTORE-NETWORK

owns:
    transit gateway
    route tables
    associations
    propagations
    static and blackhole routes
    flow logs
    Network Manager registration
    metering policy

Workload accounts own:

VPCs
attachment subnets
VPC route tables
workload security controls
attachment requests

AWS notes that users in either the gateway owner account or VPC owner account can delete a shared VPC attachment.

IAM and change control should therefore distinguish:

• request attachment
• accept attachment where required
• associate a route table
• enable propagation
• modify attachment features
• delete an attachment

Each attachment should arrive with an explicit contract.

attachment:
  name: bfstore-prod-eu-west-2
  owner_account: bfstore-prod
  transit_owner: bfstore-network
  region: eu-west-2

vpc:
  cidrs:
    - 10.80.0.0/18
  availability_zone_ids:
    - euw2-az1
    - euw2-az2
    - euw2-az3

association:
  route_table: production

route_advertisements:
  propagation:
    - shared-platform
    - observability-return
    - backup-return
  static_routes: []

allowed_destinations:
  - observability
  - backup
  - approved-shared-services
  - central-egress

denied_destinations:
  - non-production
  - sandbox
  - policy-test

features:
  appliance_mode: false
  security_group_referencing: evaluated
  ipv6_interface_addressing_and_propagation: planned

The IPv6 setting deserves its precise name.

Enabling IPv6 support assigns IPv6 addresses to Transit Gateway attachment interfaces and permits IPv6 VPC CIDRs to propagate.

Disabling it does not act as an IPv6 packet filter. Static IPv6 routes and VPC routes can still permit IPv6 traffic.

Egress and inspection are platform dependencies

A workload VPC can send:

0.0.0.0/0 → transit gateway

The associated Transit Gateway route table can forward that traffic to a central egress attachment.

WORKLOAD VPC
     │
     ▼
TRANSIT GATEWAY
     │
     ▼
EGRESS VPC
     │
     ├── inspection
     ├── NAT
     └── internet gateway

This reduces repeated egress infrastructure.

It also puts Transit Gateway, inspection and central NAT in the customer transaction path.

The platform now affects:

• payment-provider calls
• shipping-provider calls
• package retrieval
• container image retrieval
• external identity dependencies
• public software APIs

The architecture requires:

• SLOs
• reviewed route changes
• automated validation
• capacity monitoring
• cost attribution
• failure exercises
• business-impact analysis

Inspection through a VPC attachment

The established inspection model uses a VPC attachment containing third-party appliances, Gateway Load Balancer endpoints or a custom firewall path.

A stateful appliance must see both directions of a flow.

Transit Gateway appliance mode preserves the selected appliance-attachment Availability Zone for the lifetime of the flow.

SOURCE VPC
     │
     ▼
TRANSIT GATEWAY
     │
     ▼
APPLIANCE VPC AZ B
     │
     ▼
TRANSIT GATEWAY
     │
     ▼
DESTINATION VPC

Appliance mode does not create the routes.

Transit Gateway and inspection-VPC route tables must still steer both directions through the middlebox.

Direct AWS Network Firewall attachment

AWS also supports a network-function attachment that connects Transit Gateway directly to AWS Network Firewall.

TRANSIT GATEWAY
      │
      ▼
NETWORK-FUNCTION ATTACHMENT
      │
      ▼
AWS NETWORK FIREWALL

This model:

• removes the requirement to operate a separate inspection VPC
• uses service-managed supporting infrastructure
• enables appliance mode automatically
• currently uses static Transit Gateway routes
• supports AWS Network Firewall rather than arbitrary third-party appliances

The two models solve related problems but have different ownership and routing contracts.

Inspection should not be introduced merely because the architecture diagram contains an attractive space labelled firewall.

Encryption Support changes the available architecture

Transit Gateway Encryption Support can enforce encryption-in-transit between attached VPCs using VPC encryption controls.

It is not an independent checkbox that can be enabled beside every other feature.

Current incompatibilities include:

• Connect attachments
• Transit Gateway peering
• network-function or Network Firewall attachments
• VPN Concentrator attachments
• Client VPN attachments
• security-group referencing
• multicast

Attempting to create incompatible attachments or features fails.

Enabling Encryption Support on an existing gateway is described as non-disruptive to existing flows, but migration to encrypted lanes can take up to fourteen days.

For bfstore, the decision must therefore be made alongside:

Do we require direct Network Firewall attachment?

Do we require Transit Gateway peering?

Do we require Connect?

Do we require cross-VPC
security-group references?

Do we require enforced
VPC-to-VPC encryption?

Those requirements cannot all be assumed to coexist.

The encryption decision belongs in the initial transit architecture, not in a later hardening backlog.

Security-group references have limits

Transit Gateway can support security-group references across VPCs attached to the same gateway.

The feature must be enabled on both the gateway and the relevant VPC attachments.

References are supported for inbound rules, not outbound rules.

This can permit:

TELEMETRY INGEST SECURITY GROUP

allow tcp/4317

from production-telemetry-agent
security group

rather than allowing the entire production CIDR.

The feature is not universal.

It is not supported:

• across Transit Gateway peering
• for PrivateLink endpoints
• through Gateway Load Balancer or AWS Network Firewall inspection paths
• in some Local Zones
• for unsupported Outposts and Wavelength Zone paths
• in the documented use1-az3 Availability Zone

It is also incompatible with Transit Gateway Encryption Support.

Security-group referencing narrows some relationships.

It does not replace CIDR rules, firewalls or service identity throughout the architecture.

Transit Gateway does not solve DNS

Attaching VPCs does not automatically make custom Route 53 private hosted-zone names resolve across them.

Routing and naming remain separate.

TRANSIT GATEWAY

Can traffic reach
the destination CIDR?


ROUTE 53 RESOLVER

Can the client discover
the destination address?


PRIVATE HOSTED ZONE

Which names exist
inside which DNS boundary?

For bfstore, central DNS should define:

• which account owns private zones
• which VPCs associate with them
• where Resolver endpoints and forwarding rules are required
• how on-premises and other clouds resolve names
• how DNS failures are observed

Transit Gateway joins routing domains.

It does not become the organisation’s telephone directory.

Regional and multi-Region design

Transit Gateway is Regional.

VPCs in the Region can attach directly, including cross-account VPCs when the gateway is shared.

Transit gateways can be peered within or between Regions.

Peering does not dynamically exchange every route.

Static Transit Gateway routes are required.

LONDON TGW

10.128.0.0/10
    → Frankfurt peering attachment


FRANKFURT TGW

10.64.0.0/10
    → London peering attachment

This reinforces the importance of Regional IPAM summaries.

A clean parent allocation can become one peering route.

A set of unrelated VPC CIDRs becomes a growing static-route inventory.

MTU matters during migration

Transit Gateway supports an MTU of 8,500 bytes for VPC, Direct Connect, Connect and peering attachment traffic.

VPN traffic can use a lower MTU.

AWS warns that moving from VPC peering to Transit Gateway can create an MTU mismatch and packet loss during an asymmetric migration.

Update both sides deliberately.

Retain the ICMP required for Path MTU Discovery.

Test large packets and real application flows rather than assuming a successful small request proves the migration complete.

Encryption and peering are separate choices

Inter-Region Transit Gateway peering already uses AWS encryption on the inter-Region path.

The newer Transit Gateway Encryption Support feature is not compatible with peering attachments.

A multi-Region design must therefore distinguish:

inter-Region peering encryption

from:

Transit Gateway Encryption Support
for attached VPC traffic

They are not one interchangeable feature.

Capacity, cost and failure domains

AWS operates Transit Gateway as a managed Regional service that scales with traffic.

That does not make the architecture unbounded.

Control-plane scale

Current default quotas include:

5,000 attachments per transit gateway

20 route tables per transit gateway

10,000 combined static and
dynamic routes across the route tables

Some quotas are adjustable.

Good IPAM and route aggregation reduce route count, policy repetition and troubleshooting effort.

Data-plane scale

For a VPC attachment, AWS currently documents per Availability Zone:

up to 100 Gbps in each direction

up to 7.5 million packets per second

Central egress and inspection must also account for:

• firewall throughput
• NAT capacity
• downstream service limits
• attachment concentration by Availability Zone
• packet size and traffic mix

CONTROL-PLANE SCALE

attachments
route tables
route entries


DATA-PLANE SCALE

bandwidth per attachment and AZ
packets per second per attachment and AZ
middlebox and downstream capacity

The policy failure domain

The managed gateway can remain healthy while customer route tables are perfectly and consistently wrong.

An incorrect route can affect every attachment associated with a table.

A moved association can change the world visible to one entire VPC.

A removed propagation can break return paths for several routing domains.

A central egress or DNS failure can affect many accounts.

A privileged network role can alter a large number of journeys.

That is why routing changes require:

• review
• automated tests
• staged rollout
• rollback
• audit evidence

Cost allocation

Transit Gateway charges include attachment hours and processed traffic, plus related services and transfer.

By default, processing is generally charged to the source-attachment owner.

Metering policies can allocate supported processing and transfer usage to the source owner, destination owner or Transit Gateway owner based on ordered rules matching attachment types, IDs, addresses, ports and protocols.

One gateway can have one metering policy with up to fifty ordered entries.

The policy does not reassign attachment-hour charges.

Changes take effect after the relevant billing transition rather than immediately.

This is useful for central egress and inspection because the network account can operate the service without necessarily carrying every workload’s processing cost.

FinOps does not replace routing design.

It decides which account receives the receipt.

Evidence and testing

Transit Gateway Flow Logs can record traffic through the hub and deliver records to CloudWatch Logs, Amazon S3 or Firehose.

They should be combined with:

• VPC Flow Logs
• CloudWatch metrics
• CloudTrail
• route-table exports
• attachment state
• firewall logs
• application traces
• DNS logs

AWS Network Manager can register transit gateways and display topology.

Route Analyzer can inspect the configured path through Transit Gateway route tables.

Its boundary is important.

It does not analyse:

• VPC route tables
• customer-gateway routes
• security groups
• network ACLs

It reports a return path only after finding the forward Transit Gateway path, and it does not support intra-Region peering analysis.

Route Analyzer validates the hub portion.

It is not an end-to-end reachability oracle.

The troubleshooting sequence remains:

1. Which subnet originated the packet?

2. Which VPC route selected Transit Gateway?

3. Which attachment received the packet?

4. Which route table is associated
   with that attachment?

5. Which route won the lookup?

6. Which attachment became the next hop?

7. Which attachment-subnet route
   completed the forward path?

8. Which workload-subnet route
   returns the response?

Expected denials are part of correctness

A transit design is not correct merely because one permitted flow succeeds.

It must also prove that forbidden relationships remain absent.

Tests should verify:

• DNS where names are used
• forward and return routes
• the intended application port
• security-group or firewall policy
• that a broader unintended port fails
• that a prohibited network remains unreachable

Transit Gateway routes are governance code.

They deserve explicit requirements, tests, evidence and rollback.

A staged implementation

I would introduce bfstore Transit Gateway in phases.

1. Establish the hub

Create:

• one Regional transit gateway
• explicit route tables
• default association disabled
• default propagation disabled
• flow logs
• Network Manager registration
• RAM sharing
• a documented encryption and feature-compatibility decision

2. Attach non-production

Connect development, staging, shared services and observability.

Test permitted and denied paths.

3. Introduce production

Attach production only after:

• CIDRs are verified
• route contracts are reviewed
• return paths are tested
• rollback is prepared
• observability is working
• MTU behaviour has been tested where peering is replaced

4. Centralise selected services

Move appropriate traffic towards observability, backup, shared platforms and private DNS infrastructure.

5. Introduce central egress

Route only approved workload subnets through the egress platform.

Retain VPC endpoints for suitable AWS-service traffic.

6. Introduce inspection

Choose deliberately between an inspection VPC attachment and a direct Network Firewall network-function attachment.

Validate symmetric routing, failure behaviour and feature compatibility.

7. Extend Regionally

Use the IPAM hierarchy and Transit Gateway peering only when another Region genuinely exists.

HUB
 │
 ▼
NON-PRODUCTION
 │
 ▼
PRODUCTION
 │
 ▼
SHARED SERVICES
 │
 ▼
EGRESS
 │
 ▼
INSPECTION
 │
 ▼
MULTI-REGION

The network should grow with actual requirements.

The final enterprise diagram does not need to be deployed on day one merely because it looks pleasantly complete.

The decision table I keep

These questions turn the gateway from a hub icon into an operating model.

The mental model I am keeping

My earlier model was:

TRANSIT GATEWAY

connect all the VPCs

avoid lots of peering

The stronger model is:

                     TRANSIT GATEWAY
                            │
                            ▼
                        ATTACHMENTS
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼
        ASSOCIATION                ROUTE ADVERTISEMENT
             │                             │
             ▼                             ▼
     WHICH TABLE EVALUATES        PROPAGATION OR STATIC
        SOURCE TRAFFIC                RETURN ROUTE
             │                             │
             └──────────────┬──────────────┘
                            ▼
                    ROUTING VISIBILITY
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
        SEGMENTATION     SHARED SERVICES   EGRESS
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                    NETWORK ARCHITECTURE

The attachment answers:

Which network or connection
participates in the hub?

The association answers:

Which routing policy evaluates
traffic arriving from it?

Propagation or a static route answers:

How do other routing views
learn to reach it?

A blackhole answers:

Which destination must remain
unreachable despite broader routes?

IPAM answers:

Which unique and summarised prefixes
represent each network?

Appliance mode answers:

How does stateful inspection retain
a symmetric zonal path?

Encryption Support answers:

Which attached-VPC traffic
must use enforced encrypted lanes,
and which other features
does that decision exclude?

Flow logs answer:

Which attachments carried
the traffic that actually occurred?

And the route contract answers:

Which networks were never supposed
to communicate in the first place?

VPC peering connects a pair of networks.

Transit Gateway creates a routing system.

The architectural value of Transit Gateway is not that every VPC can reach the hub. It is that the hub can give every VPC a deliberately different view of the network.

Production may see observability, backup and central egress.

Development may see non-production platform services.

Sandbox may see the internet and almost nothing else.

Shared services may return traffic to several environments without receiving unrestricted permission to explore them.

The gateway holds the attachments.

The route tables hold the policy.

The route advertisements hold the return paths.

The flow logs hold the evidence.

And the network account holds a small set of permissions capable of changing a very large number of journeys.

That is the point at which VPC connectivity stops being a collection of links.

It becomes architecture.

References and further reading

• What is AWS Transit Gateway? Defines Transit Gateway as a Regional routing hub and documents supported attachment models and MTU behaviour.

• How AWS Transit Gateway works Covers route tables, association, propagation, route priority, blackholes, peering and appliance mode.

• VPC attachments Documents attachment subnets, Availability Zone behaviour, IPv6 support and security-group referencing.

• Transit Gateway design best practices Covers dedicated attachment subnets, network ACLs, route tables, BGP and peering migration.

• Network-function attachments Explains direct Transit Gateway integration with AWS Network Firewall.

• Encryption Support for AWS Transit Gateway Covers encrypted lanes, activation and incompatible attachment and feature types.

• Transit Gateway peering attachments Covers intra-Region and inter-Region peering and static-route requirements.

• Transit Gateway quotas Documents attachment, route-table, route, bandwidth, packet-rate and MTU limits.

• Flexible cost allocation Explains metering policies for Transit Gateway processing and transfer usage.

• Transit Gateway Flow Logs Documents hub-level traffic records and delivery destinations.

• Route Analyzer Explains Transit Gateway route-path analysis and its boundaries.

• Transit Gateway document history Records current capability additions, including network-function attachments and Encryption Support.