The story of an 11th-hour architectural pivot and a Secondary CIDR bridge that saved a utility giant’s cloud migration.
By Menelik Rowe/Menox/Linktech AWS Security Expert & Network Architect
The Stakes: 48 Hours to "The Swap"
We were two days away from the production cutover for a massive integration between our SaaS platform ** and a **Fortune 500 Utility Provider. The goal was simple: migrate their legacy call center to a private cloud environment.
But in enterprise networking, "simple" is a dangerous word.
The integration involved a global communications partner and a high-compliance utility environment. We were building the "bridge" between an AWS environment and a massive private cloud.
Then we hit the "10.0.0.0/8" Wall.
The Conflict: The 10.0.0.0/8 Trap
Our internal environment lived on a standard 10.0.0.0/16. It worked perfectly for us—until we tried to talk to the client.
Our partner’s internal network was a behemoth; they essentially "owned" the entire 10.0.0.0/8 private range. Because a /16 (our VPC) is more specific than a /8 (their global backbone), BGP (Border Gateway Protocol) would have prioritized our VPC for any traffic matching that range.
The Disaster Scenario: If we advertised our 10.0 range, we wouldn't just connect to their cloud—we would "hijack" their global internal traffic, black-holing packets meant for offices halfway across the world. We were 48 hours away from a global outage.
The Strategy: The Secondary CIDR "Bridge"
We couldn't change our entire VPC range overnight—that would break every internal service we had. Instead, we executed a surgical architectural pivot: The Secondary CIDR Implementation.
Instead of fighting for the 10.x space, we added 172.16.0.0/16 as a secondary CIDR block to our existing VPC.
This allowed us to:
- Maintain the Status Quo: Internal
services continued to run on the 10.0 range.
-
Create a "Safe Zone": We provisioned a new subnet (
172.16.1.0/24) specifically for the integration. -
Control the Identity: When our servers talked to the partner, they appeared as
172.16.x.xaddresses—a range that didn't conflict with their global backbone.
The Pivot: From "Tunnel" to "Governance"
To make this bridge work, we moved from a standard Virtual Private Gateway (VGW) to an AWS Transit Gateway (TGW).
While a VGW is a passive "pipe," the Transit Gateway acts as an intelligent Cloud Router. It gave us the granular control needed to:
- Suppress the 10.0.0.0/16: We manually ensured our internal range was never advertised over the VPN.
- Inject the 172.16.1.0/24: We surgically advertised only our new "bridge" range to the partner.
The Technical Execution
| Phase | Action | Purpose |
|---|---|---|
| Conflict Identification | Us (10.0/16) vs. Partner (10.0/8) | Prevented a global routing loop/outage. |
| Secondary CIDR | Add 172.16.0.0/16 | Created a non-conflicting communication bridge. |
| BGP Injection | Static route to TGW | Specifically shouted the "Safe Zone" to the partner. |
| Verification |
nc -zv & SG Updates |
Confirmed 172.16.x.x could reach the partner's 10.201.x.x. |
Lessons Learned for Cloud Architects
- Scale Dictates Architecture: A VGW is fine for simple site-to-site. But when connecting to a partner with a massive legacy footprint, the Transit Gateway is a mandatory safety requirement for route filtering.
- Don't Rebuild, Extend: When IP conflicts occur, adding a Secondary CIDR is often faster and safer than a full VPC migration.
- Specific Beats General: In BGP, the most specific route always wins. If you don't control your advertisements, your small VPC can accidentally "claim" traffic meant for a global data center.
Final Thoughts
We successfully executed "The Swap" on schedule. By pivoting to a Secondary CIDR and using Transit Gateway for route governance, we moved the project forward without risking the partner's global stability.
In the world of DevSecOps, the best "war stories" are the ones where the disaster never actually happens because of a well-timed architectural pivot.
Have you ever had to resolve a massive IP conflict at the 11th hour? Let’s discuss Secondary CIDRs and TGW routing strategies in the comments.
Top comments (0)