Compiling Cloud Network Topology
I think cloud network engineers should take a serious look at the compilation approach given the routing policy language fell out of the architecture naturally. What started as a functional route generator evolved into something with algebraic properties and those properties change what’s possible.
From Aggregates to Identity
Previous versions of the system built full meshes from VPC aggregate semantics. You’d collect all VPCs, compute the cartesian product of route tables and CIDRs, and emit every possible route. The result was always full mesh. Every VPC could reach every other VPC, with no ability to selectively control reachability.
Now we operate on full VPC identity. Each VPC enters the compiler as a typed object with CIDRs, route tables, and address family information. The routing policy evaluates constraints against that identity to determine which routes should exist. The shift from “generate all routes” to “generate the correct routes” is the difference between a code generator and a compiler.
The Policy Algebra
Four primitives with fixed precedence:
deny > allow > segments > default
- deny unconditionally blocks routes between two VPCs
- allow unconditionally permits routes between two VPCs
- segments partitions VPCs into isolation groups
- default is the fallthrough, either
"allow"(full mesh) or"deny"(zero trust)
Every VPC pair resolves to reachable or unreachable. No ambiguity. The algebra is total, monotonic, commutative, and deterministic. Same inputs always produce the same route set.
A single declaration controls both IPv4 and IPv6 route generation. One policy, dual-stack output.
Mathematically Guaranteed Routes
The routes emitted by the compiler are mathematically guaranteed by the algebra. There is no configuration state where an unintended route can appear. If the policy says deny, the route is not emitted. If it says allow, the route exists. The precedence is fixed: deny always wins, regardless of what allow or segments say.
terraform plan becomes the complete proof of your network’s reachability state. The plan output shows exactly which routes exist and which don’t, before any infrastructure changes. You’re not hoping the network does what you intended. You’re reading a deterministic output that the algebra produced.
# terraform plan output for the policy above:
+ aws_route.this["rtb-abc|10.0.64.0/18"] # app -> infra (explicit allow)
+ aws_route.this["rtb-abc|192.168.64.0/18"] # app -> general (same segment, workloads)
+ aws_route.this["rtb-def|10.0.64.0/18"] # general -> app (same segment, workloads)
# No route from general -> infra (cross-segment deny, route not emitted)
# No route from infra -> general (cross-segment deny, route not emitted)
The absence of a route is the enforcement. No firewall, no NACL, no security group. The packet never enters the TGW because the VPC has nowhere to send it.
Shape and Reshape on Demand
The topology is not a fixed artifact you build once. Changing a line in the routing policy reshapes which VPCs can communicate:
# Isolate db during an incident in one line
deny = [
{ from = module.vpcs["app"], to = module.vpcs["db"] }
]
The TGW stays untouched. The attachments stay untouched. The forwarding plane is unchanged. Only VPC route table entries shift. You reshape the network through language, not infrastructure operations. Remove the line, apply again, connectivity returns.
Scope Invariance
The same policy language works identically at every scope:
- Regional IR (Centralized Router): intra-region VPC routing
- Global IR (Full Mesh Trio): cross-region VPC routing across three regions
- Domain IR (Super Router): cross-region and intra-region across peered router domains
The compilation unit doesn’t know which scope it’s operating in. It receives a set of VPCs and a set of constraints, and emits the permitted routes. Whether you’re shaping a 3-VPC regional mesh or a 30-VPC cross-domain topology, the language is the same, the precedence is the same, and the guarantees are the same.
This isn’t three implementations of the same idea. It’s one compilation unit parameterized over scope. The scope invariance wasn’t designed, it fell out of the abstraction being at the right level.
Compliance as a Terraform File
Network compliance frameworks (PCI-DSS, HIPAA, FedRAMP, SOC 2) require demonstrable isolation between environments and evidence that access controls exist. Traditionally, this means separate documentation describing what the network should look like, reviewed against what it actually looks like.
With the routing policy, the compliance artifact is the policy declaration itself:
routing_policy = {
default = "deny"
segments = {
payment = [module.vpcs["checkout"], module.vpcs["processor"]]
general = [module.vpcs["api"], module.vpcs["web"]]
}
allow = [
{ from = module.vpcs["api"], to = module.vpcs["checkout"] }
]
}
This is simultaneously the network configuration, the access control documentation, and the audit evidence. The gap between documentation and implementation that auditors typically probe does not exist. The documentation is the implementation. Git history is the change log. Plan output diffed between commits is the audit trail.
The Mental Model
The mental model is now: declare what should communicate, the compiler handles the rest.
You don’t need to know routing. You don’t need to manage route tables, propagation rules, or TGW attachments for policy. You declare intent: these VPCs are in one group, those are in another, this specific pair needs an exception. The compiler generates the mathematically correct route set across every route table, every CIDR (including secondaries), both address families, at whatever scope you’re operating in.
The strong part of this model is that it’s scope-invariant. Learning the policy language once means you can shape any topology the system supports (regional, global, or domain) without learning a new tool or mental model for each. The algebra doesn’t change. The guarantees don’t change. Only the set of VPCs participating changes.
The routing policy language specification is available at docs/routing-policy-language.md.
Working examples with segmentation and deny rules are in Centralized Egress Dual Stack Full Mesh Trio Demo and full mesh (domain peering) is in Super Router Revamped Demo.
For the full compiler architecture and complexity analysis, see the white paper (work in progress).