Network Peering across clouds
A private link between two networks - VPC peering, VNet peering, OCI local and remote peering - with the routes on both sides and the flags that make it carry traffic.
9 verified modules, 1 of them live-tested apply→verify→destroy; the rest are static-validated, live-test pending.
Compare by provider
| Provider | Module | Verification |
|---|---|---|
| Alibaba Cloud | A VPC Peer Connection with the Route Entries on Both Sides That Make It Carry Traffic | static-validated |
| AWS | A VPC Peering Accepted in One Apply, with DNS Across It and Routes on Both Sides | ✓ live-tested |
| Azure | Both Halves of a Hub-and-Spoke VNet Peering with Gateway Transit Set as a Pair | static-validated |
| DigitalOcean | The One Peering Where the Routes Are Programmed for You, and What That Costs You Instead | static-validated |
| Google Cloud | VPC Peering in Both Directions with the Routes Stated | static-validated |
| Huawei Cloud | A VPC Peering with the Routes on Both Sides and the Cross-Tenant Case Refused Early | static-validated |
| Oracle Cloud | A Cross-Region DRG Peering that Says What It Still Needs | static-validated |
| Oracle Cloud | A Local Peering Gateway Pair that Is Connected and Routed | static-validated |
| Tencent Cloud | A Peering Connection with the Route Table Entries on Both Sides, Postpaid by Default | static-validated |
How to choose
Peering is two halves everywhere, and the module has to write both. Compare what crosses it (Azure and OCI need the routes and the flags set as a pair; AWS needs a route per table per CIDR), whether names resolve across it, and the per-gigabyte price, which is charged at both ends on every cloud.
When not to use
Peering is not transitive on any cloud. Two spokes peered to a hub cannot reach each other through it; at about five networks the mesh stops being manageable and the transit hub is the product you wanted.