Multi-Cloud Global Connectivity with AWS CloudWAN

At a Glance

Detail	Value
Industry	Enterprise
Environment	50+ AWS accounts across 5 regions
Timeline	8 weeks design and deployment
Key Results	Unified global network, automated segmentation, 60% reduction in networking operational overhead

The Challenge

A large organisation had grown its AWS footprint organically across 50+ accounts and 5 regions. Each team spun up its own VPCs, connected via Transit Gateways and VPC peering as needed. The result was a tangled mesh of point-to-point connections.

The network team was spending over 70% of its time on manual routing configuration:

• Inter-region Transit Gateway peering required complex transitive routing configuration across region boundaries. Each new region added an order of magnitude more peering attachments.
• VPC peering was used for quick connectivity between service accounts, creating a fragile web of non-transitive connections that were difficult to audit and almost impossible to change.
• Different connectivity patterns were needed between service accounts. Some required full mesh, others hub-and-spoke, and some needed complete isolation. All managed with inconsistent ad-hoc configurations.
• Segmentation was manual. Production, staging, and development environments shared the same transit gateway route tables, relying on security groups and NACLs for boundaries that could be accidentally widened.

What the organisation needed was a way to decouple the connectivity topology from the underlying infrastructure. To express intent about which accounts should talk to each other without manually wiring up every connection.

The Solution: AWS CloudWAN

We deployed AWS CloudWAN as the central network fabric, replacing the patchwork of Transit Gateway peering and VPC peering with a single policy-driven management plane.

Declarative Network Policy

CloudWAN’s core network policy captured the organisation’s connectivity requirements as a declarative document. Instead of managing individual TGW peering attachments and VPC routes, we defined:

Segment-based Isolation: Service accounts were grouped into segments (production, staging, development, shared services). Each segment operated as an isolated routing domain. Attachments within a segment could communicate freely. Cross-segment traffic required explicit policy approval through centralised inspection VPCs.

Attachment Routing: Each VPC was attached to CloudWAN and assigned to its appropriate segment. CloudWAN automatically handled route propagation within and across regions. No more inter-region TGW peering.

What CloudWAN Eliminated

The legacy approach required N*(N-1)/2 peering attachments between Transit Gateways across regions. With 5 regions, that meant 10 inter-region peering attachments. Each requiring its own route table configuration, static routes for overlapping CIDRs, and ongoing monitoring.

CloudWAN collapsed this complexity into a single core network policy. Adding a new region was a one-line change to the policy document. Adding a new VPC attachment took minutes.

Segmentation Policies at Scale

CloudWAN’s segmentation policies were the key enabler. Each service account attachment was tagged with its environment and function. The core network policy defined:

• Production segment: full mesh between production service accounts across all regions
• Staging segment: full mesh across regions, isolated from production
• Development segment: per-region scope to reduce blast radius
• Shared services segment: selectively reachable from all segments through inspection VPCs

This replaced hundreds of manually managed route table entries in Transit Gateway route tables with a few lines of declarative policy.

The Results

• 60% reduction in networking operational overhead
• 15-minute time-to-provision for new VPC attachments (down from 2 days)
• Zero inter-region TGW peering attachments to manage
• 100% consistent segmentation. All network policy managed through Git workflows.
• Instant visibility across all regions and accounts via AWS Network Manager

Key Takeaways

1. CloudWAN eliminates the inter-region TGW peering nightmare. Cross-region Transit Gateway peering scales quadratically with the number of regions and requires meticulous route table management. CloudWAN’s global network fabric makes multi-region connectivity a built-in feature, not an operational burden.
2. Segmentation policies are the killer feature. When you have 50+ accounts with different connectivity requirements, manual route table management is unsustainable. CloudWAN’s segment-based isolation lets you express connectivity intent once and enforce it globally.
3. Declarative policy prevents configuration drift. A single policy file in Git is auditable, reviewable, and repeatable. Every VPC attachment is automatically configured to match policy. No more snowflake configurations.
4. Start with segmentation, not connectivity. Define your segments and isolation boundaries first. Connectivity follows naturally from the policy. Trying to retrofit segmentation onto an existing mesh of VPC peering and TGW attachments is far more painful than designing it from the start.