Portfolio · Notes · Dotfiles

Search everything

Search case studies, engineering notes, and Dotfiles documentation.

    all case studies

    Case study 09 · featured

    Rebuilding the network as one reviewable policy

    A transit-gateway mesh built from about 15 module copies, with routes tracked by list position, became explicit resources with stable identities and then one Cloud WAN policy with four segments.

    4 min read

    My role
    Rebuilt the route model, wrote the migration plan and its no-op proof, and proposed the Cloud WAN design the team adopted.
    Evidence
    The migration was demonstrated as a no-op before it landed; one policy document replaced about 15 module copies; production and non-production traffic cannot mix unless the policy says so.
    networkingreliability

    The situation

    All our AWS networks were interconnected through a transit-gateway setup built from about 15 copies of a community module. Routes were tracked by their position in a list, so adding one network range made the plan propose destroying and recreating production routes. That blast radius kept the stack effectively frozen for years.

    The constraint was the route model, not the team. With a transit gateway all the wiring is yours: a route table per attachment, hand-managed propagation, and no concept of “environment” beyond the discipline of whoever edits the routes.

    What I did

    Two moves: first make it safe, then make it better.

    Make it safe

    I replaced the module copies with plain, explicit resources where every route has a stable identity. Changing one range now touches exactly one route.

    Make it better

    The second move was AWS Cloud WAN, the managed successor to the transit gateway. I wrote the proposal and the team adopted it; we also evaluated AWS’s Network Orchestration for Transit Gateway solution and rejected it as too many moving parts to own.

    The network is one reviewable document. Segments (production, non-production, shared, and a quarantine for anything unrecognized) and the rules for joining them live in a single policy definition, in git, instead of being implied by dozens of route tables.

    Joining is by policy, not by hand. An attachment is admitted to a segment only if it carries the right tag and comes from the right account; anything unknown lands in quarantine with no connectivity. Nobody edits another account’s route tables any more.

    Real separation. Production and non-production traffic cannot mix unless the policy says so, a property the transit-gateway mesh never had.

    Managed and multi-region. AWS runs the core network with an edge in each region we need, so expanding to a new region is a policy change rather than a peering project.

    BEFORE · ROUTES TRACKED BY LIST POSITION
    Routes by list indexroute[0] → 10.1.0.0/16route[1] → 10.2.0.0/16route[2] → 10.3.0.0/16× 15 module copiesAdd one rangeroute[1] → 10.1.5.0/24 newroute[2] → 10.2.0.0/16 destroyed, recreatedroute[3] → 10.3.0.0/16 destroyed, recreatedthe plan touches production
    AFTER · ONE POLICY, FOUR SEGMENTS
    Core network policy · one document, in gitproductionproduction accountsnon-productiondevelopment, stagingsharedtooling both may reachquarantineanything unrecognizedan attachment joins by tag + account; unknown → quarantine, no connectivity

    Proving the migration was a no-op

    The migration to the new code had to move live production routing with no infrastructure change applied. I generated an explicit state map from every old resource to its new address, opened a deliberately unmergeable demonstration pull request to prove the plan was a no-op, wrote a rollback runbook, landed the real change, and deleted the scaffolding.

    What it changed

    Network changes are reviewable at resource and policy level, dependency updates and colleague-authored changes use the same plan-and-review path as the rest of the estate, production and non-production have explicit separation, and a new environment joins the network programmatically.