Route Table Management

Repointing your private subnets’ default route at the gateway is the one change Outbound makes to your existing network configuration. This page spells out exactly what that means — and what it doesn’t.

How subnets are classified

During a network scan, Outbound inspects each subnet’s route table:

• A subnet whose 0.0.0.0/0 route targets an internet gateway (igw-…) is public. Outbound places gateways in public subnets and never changes their routing.
• A subnet whose 0.0.0.0/0 route targets a NAT gateway, NAT instance, or network interface is private. These are the subnets whose egress Outbound manages.
• A subnet with an explicitly associated route table uses that table; a subnet with no explicit association uses the VPC’s main route table. Outbound follows the same resolution AWS does, so the table it manages is the one actually in effect for that subnet.

What Outbound changes

For each private subnet in a managed network, Outbound manages exactly one route: the default route (0.0.0.0/0).

• If the route table has no default route, Outbound creates one targeting the gateway instance.
• If a default route exists (e.g. pointing at your old NAT Gateway), Outbound replaces it in place with one targeting the gateway instance.

Replacing a route is atomic from the subnet’s point of view: new connections immediately take the new path, and connections already established through the old NAT Gateway continue until they close (the old NAT Gateway keeps translating them as long as it exists).

What Outbound never touches

• The VPC local route.
• Routes to VPC peering connections, Transit Gateways, VPN or Direct Connect gateways, VPC endpoints, or any other specific-prefix route.
• Route tables of public subnets.
• Route table associations — which table a subnet uses is always your decision.
• Any route table in VPCs you haven’t enabled for Outbound management.

If your route table routes 10.0.0.0/8 to a Transit Gateway and 0.0.0.0/0 to a NAT Gateway, after cutover it routes 10.0.0.0/8 to the Transit Gateway — untouched — and 0.0.0.0/0 to the Outbound gateway.

Ongoing reconciliation

Outbound’s control plane periodically compares the desired routing state with what’s actually in your route tables and re-applies the default route if it has drifted — for example, after a terraform apply from a state file that still contains the old route. This reconciliation is also why route ownership must be unambiguous:

One owner per route

If Terraform (or any other tool) also believes it owns a managed default route, the two systems will fight: Terraform reverts the route to the old target, egress breaks or bypasses the gateway, then Outbound repairs it — repeatedly. Remove managed default routes from your IaC state. The Terraform & IaC guide shows how.

During gateway replacement

When a gateway is upgraded or resized, Outbound launches the replacement first, then updates the default routes to the new instance, then removes the old one — the route always targets a live gateway. See Reliability for the full sequence.

Rollback

If you disable a network or offboard, egress cutover happens in reverse: you (or Outbound, during a coordinated offboarding) restore default routes to a NAT Gateway before the Outbound gateway is removed, so there’s no window without egress.