Fixed-scope engagement

Hybrid Networking

A hybrid networking engagement makes your on-prem, AWS, and other clouds behave as one coherent network — routing, DNS, and segmentation you can reason about and reproduce — delivered as Terraform you own instead of a pile of hand-cut tunnels nobody fully understands.

Request a scoping call

The problem this solves

"Our connectivity grew one VPN tunnel and one peering at a time. Now routing is a mystery, DNS resolves differently depending on where you are, and the whole thing is one flat blast radius. When something breaks, only one person can debug it — and we can't reproduce any of it." Root cause: organically-grown connectivity with no central routing/DNS/segmentation design produces undocumented paths, overlapping CIDRs, and flat trust between environments; none of it is in code, so it can't be reasoned about or rebuilt.

What you own when we leave

  • Terraform/IaC for the connectivity fabric in scope (transit/hub routing, VPN/Direct Connect/interconnect, peering, route tables).
  • A unified DNS and resolution design (consistent name resolution across on-prem and clouds), as code.
  • A segmentation model that bounds blast radius between environments and tiers, enforced and documented.
  • Clear network diagrams generated from / kept in sync with the actual IaC — not a one-off Visio.
  • Runbooks for adding a site/VPC/cloud, and a documented IP/CIDR plan.
  • ADRs for the routing and segmentation decisions.

Not a network assessment report. A network you can reproduce from code and extend safely.

How we approach it

  1. 01

    Discovery

    We read your accounts, configs, and constraints directly (scoped read-only access or exported state), map the real current state, and agree on a written scope and success criteria before any code is written.

  2. 02

    Architecture Decision Records

    We write down the key decisions — what we’re doing, the options we rejected, and why — as ADRs in your repo, so the reasoning survives long after we’re gone and you can challenge it before we build.

  3. 03

    Implementation

    We build the solution as reviewable Terraform/IaC in small, tested pull requests against your CI, so you watch it land incrementally and nothing arrives as a black box.

  4. 04

    Handover

    We walk your team through the repo, the threat model, and the runbooks live, confirm you can apply/destroy/extend it yourselves, and then we leave. You own everything — there is no phase 5 where you still need us.

Engagement shape

A fixed-scope build/redesign over a defined set of sites, clouds, and connections — delivered as Terraform with a tested routing/DNS/segmentation design and a live handover. Scope is set by the number of environments and connections in play, agreed in writing first.

Engagements typically start at $30,000 USD. Contact for scope and a fixed price.

A sample of what we ship

network/transit.tf Sanitized sample
# network/transit.tf — hub: explicit routing, no flat mesh
resource "aws_ec2_transit_gateway" "hub" {
  description = "on-prem + cloud hub"

  # No implicit any-to-any: every attachment is associated and
  # propagated deliberately, per environment.
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
}

# Prod and non-prod live in separate route tables: non-prod reaches
# shared services and on-prem, never prod.
resource "aws_ec2_transit_gateway_route_table" "env" {
  for_each           = toset(["prod", "nonprod", "shared"])
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  tags               = { Name = "rt-${each.key}" }
}
The hub of the connectivity fabric: default route association disabled, so no attachment gets implicit any-to-any reach — segmentation is a routing decision you can read in code.

FAQ

Questions about this engagement

What do I actually get — is this just a report?

No. Every engagement ends with infrastructure-as-code in your repository: Terraform/IaC, the guardrail set (Service Control Policies or equivalents), a threat model, ADRs, and runbooks. The documents exist to help an engineer run the code — they are never the deliverable instead of the code. "We ship, not slide" is the whole point. The sample Terraform on this site shows the shape of what you get.

What if something breaks after you’ve handed over and left?

Every engagement includes a 90-day warranty: if anything we shipped does not behave as documented, we fix it at no charge — that is a defect we own, not new scope. After that window the code is standard Terraform/IaC on standard tools, so your team or any engineer can maintain it. If you would rather we come back for a defined follow-on — a new scope, a new fixed price — we are a short email away. We make ourselves unnecessary by default; we do not make ourselves unreachable.

We already have a security team / platform team. Why bring you in?

Usually because they are at capacity, or the work needs a specific senior depth (landing-zone design, zero-trust enforcement, hybrid routing, AI guardrails) that is hard to staff for a one-time build. We work as reviewable PRs against your CI so your team reviews and absorbs everything as it lands — by handover it is genuinely theirs, not a black box dropped on them.

What access do you need, and how do you handle our data and credentials?

Discovery uses scoped, read-only IAM roles that you create in your accounts and can revoke at any second — never long-lived keys we hold. Where you must export configuration or state, it lands encrypted in storage you control, and we delete our working copies on a documented schedule with written confirmation. We use no sub-processors and nothing leaves the jurisdiction you specify; wherever possible, implementation runs entirely inside your own tenancy and CI so we never hold your credentials at all. We will complete your security questionnaire (CAIQ/SIG-lite) before you grant any access. You can inspect this site too: cookie-free self-hosted analytics, Cloudflare only for edge/CDN and bot protection, a clean CSP, and no third-party trackers.

Start with a scoping call