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 fragile route model became safe to change through explicit resource identities. A separate Cloud WAN design then expressed network segmentation and attachment rules in one policy.

    6 min read

    My role
    Rebuilt the Terraform route model, proved the state migration with a no-op plan, and proposed the Cloud WAN design adopted by the team.
    Evidence
    A no-op plan verified the routing refactor; the Cloud WAN policy defines four segments and sends unmatched attachments to quarantine.
    networkingreliability

    Remove the risk from an ordinary route change

    Our AWS networks were connected through a transit-gateway configuration built from about 15 copies of a community module. Routes were identified by their position in lists. Adding a network range could shift those positions and cause Terraform to propose replacing unrelated production routes.

    That behavior made even small changes difficult to approve. I separated the work into two steps: stabilize Terraform’s representation of the existing network, then redesign how the network expressed connectivity.

    Prove the refactor preserves live routing

    I replaced the module copies with explicit resources and stable route identities. A change to one range could then be reviewed without unrelated routes moving because of list order.

    The migration needed evidence before it touched the state. I mapped every old resource address to its new address and opened a demonstration pull request that could not be merged accidentally. Its plan showed no infrastructure changes after the state mapping. I documented rollback, landed the refactor, and removed the temporary demonstration code.

    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

    The no-op proof applied to this representation change. The subsequent Cloud WAN redesign was a separate architectural change.

    Express connectivity as policy

    I proposed AWS Cloud WAN, and the team adopted the design. We also evaluated a transit-gateway orchestration solution, but it would have left us operating more of the coordination machinery ourselves.

    The Cloud WAN policy defines production, non-production, shared services, and quarantine. Production and non-production each exchange routes with shared services; quarantine shares no routes and isolates its attachments from one another.

    Production and non-production are not directly shared with each other. Attachment rules check both the owning account and the requested segment tag; unmatched combinations fall through to quarantine. A tag alone is insufficient to grant connectivity.

    CLOUD WAN · FOUR SEGMENTS, EXPLICIT SHARING
    Cloud Wan Segments One AWS Cloud WAN policy defines four segments. Production and non-production each exchange routes with shared services, with no direct route sharing between production and non-production. Attachment membership checks both account and requested segment tag. Unmatched attachments enter quarantine, which shares no routes with other segments and isolates its attachments from each other. This diagram shows the policy relationships, not a live attachment inventory. One core network policy Membership checks account + requested segment tag EXPLICIT ROUTE SHARING Shared services Common platform services Production Production workloads Non-production Development + staging shared routes shared routes NO DIRECT SHARING QUARANTINE · UNMATCHED ATTACHMENTS Attachment A Isolated Attachment B Isolated No segment sharing · attachments isolated from each other
    EXHIBIT 01 — Production and non-production each share routes with shared services. Unmatched account-and-tag combinations enter quarantine. Route sharing and attachment admission are defined separately in the same policy.

    This also changes regional expansion. The core network’s regions and segment rules are reviewed in the policy, and a new cell can request its attachment through Terraform.

    What changed

    The first step made an existing production network maintainable again, with a state migration demonstrated before it was applied. The Cloud WAN design gave the team an explicit, reviewable model for network membership and separation. These address different risks: unintended resource replacement during a refactor, and unintended connectivity as the platform grows.