Route Table Management

Repointing your private subnets’ default route at the gateway is the one change Multistax 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, Multistax Outbound inspects each subnet’s route table:

• A subnet whose 0.0.0.0/0 route targets an internet gateway (igw-…) is public. Multistax 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 Multistax 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. Multistax Outbound follows the same resolution AWS does, so the table it manages is the one actually in effect for that subnet.

What Multistax Outbound changes

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

• If the route table has no default route, Multistax Outbound creates one targeting the gateway instance.
• If a default route exists (e.g. pointing at your old NAT Gateway), Multistax 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 Multistax 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 Multistax 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 Multistax Outbound gateway.

Ongoing reconciliation

Multistax 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 Multistax 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, Multistax 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 Multistax Outbound, during a coordinated offboarding) restore default routes to a NAT Gateway before the Multistax Outbound gateway is removed, so there’s no window without egress.