Routing policy that can be read
Routing policy is executable documentation. Every rule should have a narrow match, a clear purpose, and an obvious place in the order of evaluation.
Put restrictive rules first
Private destinations and traffic that must never leave a trust boundary should be handled before broad regional or service rules. The final catch-all must be deliberate: operators should know whether unmatched traffic is sent directly, through a controlled exit, or blocked.
Names matter. Tags such as regional-direct, selected-service, and blocked-private communicate intent better than numbered labels whose meaning lives only in someone's memory.
Test branches independently
One successful request cannot validate a policy with several exits. Test regional domains, regional IP addresses, international destinations, blocked networks, and every special proxy branch separately. Confirm the observed egress where possible.
Health checks also need to use representative destinations. A probe can report that an outbound is alive while the service people actually need remains unreachable.
Prefer a small policy
Complex routing is sometimes necessary, but complexity should be earned by a measurable requirement. Remove dead outbounds, stale selectors, and duplicate conditions. A smaller policy produces fewer ambiguous failures and makes rollback safer.
- ← Previous
Measure the whole path - Next →
Certificates are a lifecycle