Architecting a Global WAN Across Clouds and Data Centers – Key Takeaways
Overview
Tim McConaughey, a technical marketing engineer at Cisco, presents this session on architecting a global WAN across clouds and data centers. His background includes a CCIE in enterprise infrastructure, an AWS Advanced Networking Specialty certification, more than 15 years as a network engineer and architect, and experience from NOC operations through architecture roles.
The session traces the evolution of wide area networking from leased physical circuits through Frame Relay, MPLS, VPN, DMVPN, and SD-WAN, then connects that history to cloud and hybrid cloud networking. The central theme is that WAN design has always involved balancing reachability, performance, cost, complexity, and provider capabilities, but cloud changes the constraints and operating model.
Modern global WAN architecture is not only a technology selection exercise. Effective designs start with business requirements, application tolerance, geography, budget, delivery timelines, and the practical limits of the weakest link. A technically elegant design that is too hard to operate will not be adopted.
1. The WAN Began With Dedicated Physical Connectivity
Early wide area networking was built around leased lines. A business that needed to connect sites together bought access to a physical circuit from a service provider so users and systems could share resources such as file shares or business applications across distance.
In that model, the service provider operated much like a telephone switchboard. Physical infrastructure was cross-connected so one site could communicate with another. If the provider already had infrastructure in place, the customer could buy access to the line; if not, additional physical infrastructure had to be installed.
The customer was responsible for connecting equipment to the provider’s demarcation point using whatever physical handoff the provider supported. The result was simple in concept but limited in scale: a line was a line, and demand eventually outgrew that model.
2. Virtual Circuits and MPLS Shifted Complexity Into the Provider Network
The first major breakthrough came when service providers could virtualize connectivity across shared infrastructure. Instead of dedicating an entire physical line to one customer, providers could use private virtual circuits, including Frame Relay, to segment customers over common physical cabling and switching infrastructure. Data-link connection identifiers, or DLCIs, made it possible to separate traffic logically while sharing the same underlying medium.
This changed the economics and scalability of WAN services. Providers no longer needed to lay separate cables for every customer connection. Customers could buy a portion of available bandwidth while the provider handled shared infrastructure and segmentation.
MPLS extended this evolution further. Rather than providing only Layer 2 connectivity, service providers built MPLS clouds using routers, switches, cabling, and label-switched paths. Customers could peer with the provider using a routing protocol, and the provider network became a platform for WAN connectivity and additional services.
Layer 2 services still existed alongside MPLS, including VPLS, or virtual private LAN service. But the broader direction was clear: providers took on more complexity so customers could plug in, peer with the provider, and obtain WAN connectivity with less complexity on their side.
3. VPN and DMVPN Made Commodity WAN Practical
VPN technology introduced the ability to build private point-to-point connectivity over many kinds of transport, including the internet, service provider networks, and other media. Point-to-point VPNs remain useful, but they are static by nature.
Dynamic Multipoint VPN, or DMVPN, made commodity WAN more practical by adding traffic engineering, routing, failover, and resilience across different transport types. It made the internet and other lower-cost transports viable parts of WAN design.
This was especially useful because it allowed overlays to steer traffic based on application needs. Critical traffic such as voice or latency-sensitive applications could be pinned to a more resilient MPLS circuit with better SLA characteristics and lower latency. Bulk traffic such as file transfers could use cheaper internet transport when the application could tolerate more variation.
That distinction mattered for both performance and cost. In environments where MPLS was metered or expensive, moving less sensitive traffic to lower-cost commodity links reduced spend while preserving better transport for traffic that needed it. The WAN became a way to choose the right path for the right traffic.
4. Cisco IWAN Illustrated the Cost of Operational Complexity
Cisco IWAN is used as an example of a technically sophisticated approach that struggled because of operational complexity. IWAN attempted to combine multiple technologies, including performance routing, into an orchestrated WAN architecture that could react to changing network conditions.
The problem it tried to solve was real. Traditional traffic engineering could steer traffic across transports, but it did not always respond effectively to brownouts, packet loss, service provider instability, or failures that degraded service without causing a complete outage.
The challenge was usability. The guide for designing and implementing IWAN was described as nearly 900 pages long, and even engineers with advanced services experience found it technically challenging to deploy and operate.
The broader lesson is central to the webinar: operational simplicity wins. A WAN design can be brilliant on paper, but if only a small group of experts can deploy and maintain it, adoption will suffer. Networks must be designed so other people can operate them reliably.
5. SD-WAN Delivered a More Operable Policy-Based WAN
SD-WAN addressed many goals that earlier approaches struggled to deliver in an accessible way. Its value is not simply that it uses overlays or multiple transports, but that it provides a controller-based operating model for defining policy and reacting to network conditions.
In an SD-WAN architecture, teams define policies in a control surface. Those policies establish thresholds and behavior for path selection, failover, and transport use. The WAN can then respond to failures or degraded conditions by automatically choosing a better path or routing around the problem.
This allows organizations to build resilient WANs across different transports. Dedicated circuits, internet links, and other connectivity options can all participate in the design, provided the organization understands their reliability, cost, and performance characteristics.
SD-WAN represents the current stage of modern WAN design in the presentation’s historical arc: a usable way to create a responsive WAN that supports application-aware routing, resilience, and operational simplicity.
6. Cloud Changes the WAN Design Problem
Cloud introduces a different networking paradigm. Early adoption often begins with developers prototyping in a public cloud environment using platform services, virtual machines, or other cloud resources. At first, connectivity can be simple because everything may live in the same VPC or VNet, and the native cloud network allows application tiers to communicate.
That simplicity can become a challenge as prototypes move toward production. Once security and networking teams become involved, requirements change. Security may require firewalls or segmentation between applications, and networking teams may need to retrofit controls into an environment that developers already built.
This creates a familiar tension. Native cloud networking may offer only certain design options. Third-party products may provide more features or flexibility, but they also introduce additional ownership and operational complexity.
The gap between on-premises networking and cloud networking can be wide. Features, limitations, tooling, deployment workflows, and operational assumptions differ substantially. A global WAN design cannot treat cloud as just another data center.
7. Infrastructure as Code Provides Agility, but Raises the Skill Bar
Infrastructure as code is central to cloud networking because cloud infrastructure is API-driven and can be created, changed, and destroyed quickly. Tools such as Terraform, Pulumi, and Ansible can build virtual networks, deploy resources, test changes, and tear environments down in minutes.
This agility changes how teams test and promote changes. A network design can be built in a test environment, validated, destroyed, and then pushed to production through the same workflow.
The benefits are significant: virtual infrastructure can often be built in minutes, the same code can create equivalent environments across test and production, and changes can be validated before production deployment.
The trade-off is skill and tooling complexity, especially for network engineers who may be more familiar with CLI-driven infrastructure management. Network automation has existed for years, but adoption has been uneven because vendors, tools, and operational models vary.
Tooling changes can also break automation. A working Ansible playbook, Terraform configuration, or other automation workflow may need to be updated when the tool or provider changes behavior.
8. Physical Infrastructure Still Has Different Lifecycle Constraints
Infrastructure as code is most effective with virtual infrastructure. Physical infrastructure behaves differently because hardware has to be ordered, shipped, racked, cabled, powered, configured, and integrated.
Traditional network infrastructure often starts with basic management access. Engineers install gear in a rack, cable it, configure it enough to make it manageable, and either paste configuration directly or connect it to a controller that applies the intended configuration.
This creates several constraints:
- Long lead times: Hardware procurement, shipping, staging, and installation take time.
- Limited testing: Validation may happen in a production environment or in a separate lab that only approximates production.
- Physical failure modes: Layer 1 problems, cabling issues, and hardware faults can require on-site work.
- Management risk: A bad change can remove remote access and force someone to physically intervene.
An enterprise network refresh example illustrates the difference: equipment for an international site might be staged and tested in a lab, then repacked, shipped, and installed in the destination country. That reduces risk, but it also shows the long lifecycle of hardware-based infrastructure compared with cloud-based virtual infrastructure.
9. Middle-Mile Providers Can Reduce Cloud-to-Physical Friction
Hybrid and multi-cloud WAN design often requires connecting virtual environments to physical infrastructure. The tooling, lifecycle, and capabilities on each side are different, which creates friction. Middle-mile providers, including Megaport, can reduce that friction by providing an abstraction layer between physical networks and cloud environments.
These providers may allow organizations to connect physical gear, circuits, cloud networks, and virtual edge capabilities through a managed fabric. The design value is to make it easier to stitch together hardware environments, cloud connectivity, and virtual networking.
This approach is often attractive for agility. It does not remove the need for design decisions, but it can simplify the mechanics of connecting environments with very different provisioning models and feature sets.
10. WAN Design Starts With Constraints, Not Products
WAN design is strategic rather than tactical. The session frames design as a puzzle: some pieces are fixed, and the architecture must be built around them.
The fixed “corners” include geography, budget, and deadlines. The “borders” include resources, compliance frameworks, and application requirements. These factors define what is possible before specific technologies are selected.
Some essential questions cannot be answered by the network engineer alone:
- Business risk tolerance: What level of service is the organization willing to pay for?
- Availability expectations: Is the business willing to fund five nines of uptime, or is a lower level acceptable?
- Application tolerance: What latency, packet loss, or failure behavior can critical applications withstand?
- Center of gravity: Are users and applications primarily reaching data in the cloud, in the data center, or somewhere in between?
- Delivery constraints: What must be implemented within a specific deadline?
The speaker gives a simple example: five nines of uptime might cost $1 million, while three nines might cost $10,000. The network architect needs the business decision, but should not make that decision alone.
The tightest constraints define the design. A remote site may not be able to receive an MPLS circuit, so satellite or another available transport may become the practical option. Prefix limits, latency requirements, resilience targets, budgets, and deadlines all shape the final architecture.
11. Connectivity Options Require Explicit Trade-Offs
Final design choices come down to trade-offs among safety, cost, delivery time, ubiquity, and operational model.
Dedicated private circuits are generally the safest option. They can offer stronger SLA characteristics and private connectivity, but they are expensive, slow to deliver, and not always available everywhere.
Commodity internet with VPN or SD-WAN is inexpensive, fast to deliver, and broadly available. The trade-off is lower SLA expectations. Commodity internet is useful when cost, speed, and ubiquity matter, but it needs appropriate design if used for critical workloads.
Middle-mile connectivity can offer a pay-as-you-go model and faster provisioning for connecting cloud and physical environments.
Managed services introduce a contract-based operating model. They can offload certain responsibilities, but they also change the organization’s dependency model.
The practical recommendation is to design for the weakest link. That weakest link might be a cloud-native limitation, a managed service boundary, older equipment, a physical circuit, or an operational constraint. Designs should avoid gold-plating and unnecessary complexity.
Key Takeaways
- Operational simplicity is a design requirement. A technically elegant WAN architecture will fail if it is too difficult for the organization to deploy and operate.
- WAN evolution has moved complexity into abstractions. Virtual circuits, MPLS, VPN overlays, DMVPN, and SD-WAN each made it easier to scale connectivity by abstracting transport complexity.
- Application needs should drive path selection. Latency-sensitive or critical traffic may need higher-SLA transport, while bulk traffic can often use lower-cost links.
- SD-WAN adds policy-based resilience. Controller-driven policy allows the WAN to react to changing link conditions instead of relying only on static design.
- Cloud is not just another site. Cloud networking has different constructs, tooling, feature limits, and operating models than physical infrastructure.
- Infrastructure as code is powerful but must be maintained. It enables fast deployment and testing, but requires automation skills and introduces dependency on tooling versions and provider behavior.
- Design begins with constraints. Geography, budget, deadlines, compliance, application tolerance, risk appetite, and center of gravity shape the architecture before products are selected.
- Design for the weakest link. Cloud limitations, managed services, older equipment, and physical constraints all need to be accounted for instead of hidden behind an idealized design.
Conclusion
Architecting a global WAN across clouds and data centers requires understanding how WAN technologies evolved and why each stage emerged. Dedicated circuits offered straightforward private connectivity, virtual circuits and MPLS improved provider scale, VPN and DMVPN made commodity transport useful, and SD-WAN made policy-based resilience more operationally accessible.
Cloud adds complexity because it changes the lifecycle, tooling, and assumptions of network infrastructure. Virtual cloud networks can be created quickly through APIs and infrastructure as code, while physical infrastructure still has procurement, installation, cabling, and management constraints.
The strongest WAN designs are not built by choosing the most advanced technology first. They begin with fixed requirements, business risk tolerance, application behavior, geography, budget, operational capability, and deadlines. From there, architects can choose dedicated circuits, commodity internet, SD-WAN, middle-mile connectivity, managed services, or a combination that fits the actual constraints.
The overall message is pragmatic: build networks that are resilient, understandable, and operable. Avoid gold-plated designs and unnecessary complexity. A global WAN must serve the business and the applications, but it must also be something the organization can run reliably after the architect leaves the room.
