Hybrid & Multi-Cloud Topologies: What Works and Why – Key Takeaways
Overview
Britton Anderson, Senior Specialty Solutions Architect at AHEAD, presents a practical view of hybrid and multi-cloud architecture based on customer conversations around cloud adoption, SD-WAN, SSE, cloud integration, and campus networks. The focus is how organizations evolve from early cloud experiments into more resilient, distributed, and policy-driven architectures.
The central theme is data center of gravity: where an organization’s data lives, how it moves, and how users and applications interact with it. Those flows shape the right architecture, user experience, and cost profile. Cloud connectivity decisions are not only about bandwidth or provider choice; they are about latency, routing control, application requirements, operational resilience, and data movement economics.
The discussion follows a maturity path: beginning with a single cloud provider and region, adding regional redundancy, introducing another provider through acquisition or application need, using the public internet as an initial path, and then augmenting that architecture with private peering, SD-WAN policy, security controls, and software-defined cloud interconnect.
1. Data Center of Gravity Should Drive Cloud Architecture
Hybrid and multi-cloud decisions begin with understanding where the organization’s data sits and how it moves. Some organizations remain primarily on-premises and use cloud services as an extension of the data center. Others become cloud-first and need to optimize how users, applications, and secondary services reach data hosted in public cloud environments.
This “data center of gravity” affects architecture and cost. If large datasets must move frequently between regions, providers, or data centers, connectivity design becomes a major factor in performance and spend. If most users access applications from a specific geography, placing workloads closer to those users can improve the experience. If cloud is primarily used for backup or disaster recovery, the architecture may emphasize resilience and replication rather than active user traffic.
There is no universal hybrid or multi-cloud design. The right topology depends on the application estate, user locations, provider dependencies, compliance considerations, traffic patterns, and growth path.
2. Many Organizations Start With One Cloud Provider and One Region
A common first step is a single cloud provider in a single region, often for cautious adoption or targeted use cases such as disaster recovery, storage backup, or cyber resilience.
VMware-driven conversations often fall into this category. Organizations may want to extend familiar infrastructure into cloud, preserve application mobility, or use cloud as a recovery engine. In some cases, they want Layer 2 extension to support workload mobility between the data center and cloud. Others simply want cloud storage or compute selectively while keeping most production systems on-premises.
This single-region model can remain valid for a long time. Reasons include compliance requirements, geographic scope, application simplicity, or a deliberate choice to use cloud only for specific strengths. Connectivity from the data center into the cloud may use a physical private circuit such as AWS Direct Connect or Azure ExpressRoute, a virtual path through a provider such as Megaport, or a VPN, depending on the use case.
The single-cloud model can also provide secondary benefits beyond direct workload access. Private peering can support provider-adjacent services such as Microsoft 365 through Azure, Google Workspace through GCP, or Amazon WorkSpaces through AWS. In those cases, the cloud connection privatizes traffic to more than the organization’s own cloud-hosted applications.
3. Multi-Region Designs Add Geographic Diversity and Resilience
Once organizations become comfortable with cloud consumption and architecture, they often add a second region for resilience, disaster recovery, user proximity, or active-active application design.
In the AWS-oriented example, the data center peers with multiple cloud regions. That creates a more resilient ring-like pattern with granular control over traffic between on-premises infrastructure, cloud on-ramps, and cloud regions. Each connection may be physical, virtual through Megaport, or VPN-based depending on requirements.
The second region can support several patterns:
- Backup and recovery: A secondary region can hold recovery resources or replicated data.
- Primary and secondary workload placement: One region may serve active users while another provides resilience.
- Active-active applications: Workloads can be stretched across regions when the application architecture supports it.
- Latency optimization: Placing resources closer to users can improve application quality of experience.
Application support is a major constraint. The network may make multiple regions reachable, but application architecture determines whether active-active operation, failover, replication, or workload mobility is realistic.
4. Multi-Cloud Often Emerges From Resilience, Service Choice, or M&A
The multi-cloud conversation often begins after the organization has built cloud confidence. One driver is resilience: if a single provider such as AWS has a problem, the organization may want options that reduce dependency on one platform. Another is provider-specific services, where an application or data workflow benefits from a capability in a different cloud.
Mergers and acquisitions are also common. When one company acquires another, it often inherits different infrastructure, data centers, and cloud providers. The result may be an environment where one side of the business uses AWS in one region while another uses GCP in another region, with separate data centers still in the picture.
This changes the design problem. AWS and Google Cloud are not automatically connected in a way that serves the customer’s architecture. The organization must build the constructs that allow data to move between providers, regions, and data centers. That may begin with public internet connectivity, VPNs, SD-WAN overlays, SSE providers, cloud firewalls, third-party firewalls, or traditional routers.
The key question remains the same: how does data move across the whole architecture, and which paths should be intentional rather than accidental?
5. The Public Internet Is a Fast Starting Point, but It Has Limits
The public internet is often the simplest way to begin connecting cloud environments. The infrastructure already exists, cloud gateways are available, and teams can build quickly. VPNs over public IP addresses can be selective, familiar, and useful for early-stage connectivity between cloud providers or between a data center and cloud.
That simplicity is why internet-based connectivity often becomes the first implementation. It can work well for testing, initial integration, or lower-risk workloads. Organizations can combine it with cloud-native firewalls, third-party firewall appliances, SD-WAN, SSE platforms, or traditional routing to create secure overlay paths.
The limitation is variability. Internet paths can introduce inconsistent latency and jitter, which can harm throughput and application responsiveness, especially when large datasets move over TCP. The session calls out TCP slow start and TCP receive window scaling: when latency and jitter vary, throughput can rise and fall sharply, creating inconsistent performance.
The caution is that temporary internet-based designs often become permanent. That may be acceptable for some use cases, but it can become costly and operationally painful when data volumes grow or application performance becomes more sensitive.
6. Latency, Jitter, and Throughput Matter More as Data Volumes Grow
One customer example involved a dataset in GCP on the East Coast and a desire to use AWS Bedrock for AI integration in the West. The initial path used VPN over the public internet between public IP addresses. In testing, the public path between AWS and GCP measured about 55 milliseconds of latency with roughly 10 milliseconds of jitter.
Those numbers matter because large data transfers are sensitive to variation. Jitter affects TCP throughput behavior, which can cause bandwidth utilization to swing up and down rather than stay stable. The result is slower transfer completion and more variable application response times.
The same use case was then routed private IP to private IP through Megaport’s private backbone. The workload stayed comparable, but the path changed. Latency dropped from 55 milliseconds to 38 milliseconds, and jitter stabilized at about 2 milliseconds.
The improvement was described as roughly a 20-25% decrease in latency and an 80% reduction in jitter. The private path was not only faster; it made traffic more predictable, stabilizing throughput for a data-intensive workflow.
Private peering gives organizations a way to optimize east-west traffic between clouds and regions as well as north-south traffic between data centers, branches, and cloud environments. It does not eliminate the public internet. It lets teams use the internet where it makes sense and steer sensitive or high-volume traffic across private paths.
Cost becomes important as data volumes rise. The session frames standard public internet egress at about $0.09 per GB from a non-discounted, non-committed rate perspective. For tens or hundreds of terabytes, that can produce large and fluctuating monthly costs.
In the private-peering comparison, the relevant cloud-side data movement cost was described as approximately $0.025-$0.03 per GB. For the customer use case involving roughly 10 TB datasets and multiple data sets, the lower per-gigabyte cost could help offset the cost of adding private connectivity. Megaport itself was described as not charging on a per-gigabyte licensing model, allowing circuits to be used fully for a fixed fee.
That combination changes the business case. Private peering may be justified by improved latency, reduced jitter, and more predictable economics when data volumes are high enough. The architecture investment can be offset by reduced cloud data transfer costs while improving the user or application experience.
8. SD-WAN Helps Make Cloud Routing Policy-Based and Resilient
SD-WAN appears throughout the architecture as a way to control how traffic reaches cloud resources. It can build cloud on-ramps, optimize path selection, and make routing decisions based on application, user, performance, or policy requirements.
In a hybrid and multi-cloud topology, SD-WAN can participate on both the internet-facing side and the private-peering side. For example, a branch office may use the internet as a backup path while preferring a private peering path for specific application traffic. If the private path has issues, SD-WAN can facilitate resilience by steering traffic through the internet into the chosen cloud region.
SD-WAN can also determine whether internet transport is sufficient for a user or application. If top-tier throughput is not required and the internet path provides acceptable latency, policy can allow it. If an application is sensitive or data-intensive, policy can prefer the private on-ramp.
The broader lesson is that hybrid and multi-cloud routing should not be a static diagram. It should reflect application priority, user context, latency, throughput needs, resilience requirements, and cost considerations.
9. Security Must Follow the Distributed Architecture
Security remains central as workloads stretch across regions and cloud providers. Each provider has native security services, but many organizations also use SSE platforms, cloud firewalls, third-party firewalls, DDoS prevention, web application firewalls, and segmentation controls.
The session emphasizes shrinking the perimeter closer to the application. In cloud environments, security policy can include microsegmentation within regions and providers, allowing controls to follow workloads instead of depending entirely on a traditional data center perimeter.
Public-facing services still have a place. Organizations may use the internet front door for applications that need to reach external users, with DNS and global distribution mechanisms steering users toward the closest active instance. Active-active application deployments can stretch across regions and providers when the application supports that model, improving reachability and user experience while maintaining security controls.
The important design principle is consistency. Visibility, policy enforcement, segmentation, and routing need to scale with the architecture. As cloud regions and providers multiply, security cannot remain tied only to the original data center model.
10. Software-Defined Cloud Interconnect Extends the Data Center Model
Megaport is positioned as a software-defined way to connect physical data centers, virtual infrastructure, cloud providers, and private peering paths. The model can be entirely software-defined, but it can also incorporate physical circuits from a data center and terminate them onto virtual infrastructure.
That flexibility matters for organizations changing their data center footprint. Some want to leave a colocation facility and move workloads into cloud without losing the private connectivity peers and circuit functions they previously used. In that case, the private connectivity model can move into a software-defined interconnect layer rather than disappearing with the physical data center.
This allows the architecture to evolve over time. An organization may begin with one cloud provider and one region, add multiple regions, integrate another cloud through acquisition or service need, and later reduce physical data center dependency. A software-defined cloud interconnect can provide a consistent connectivity layer across those phases.
The goal is not to choose one static topology. It is to right-size connectivity as cloud consumption grows, balancing performance, resilience, flexibility, security, and cost.
Key Takeaways
- Data center of gravity is the starting point. Where data lives and how it moves should shape cloud regions, providers, connectivity, routing, and cost decisions.
- Single-cloud and single-region designs can be valid. Many organizations start with one provider for backup, recovery, storage, or controlled cloud adoption, and some remain there for good reasons.
- Multi-region architecture improves resilience only when applications support it. The network can create reachability, but application design determines whether active-active, failover, or recovery models work.
- Multi-cloud often arrives through real-world pressure. Resilience goals, provider-specific services, and mergers or acquisitions can all create environments that span AWS, Azure, GCP, data centers, and branches.
- The public internet is useful but variable. It is fast to deploy and often appropriate for initial connectivity, but latency, jitter, throughput variation, and egress cost become more important at scale.
- Private peering can stabilize performance. In the customer example, a private path reduced latency from 55 ms to 38 ms and jitter from 10 ms to 2 ms.
- Cost and performance are linked. High-volume public internet egress at around $0.09 per GB can become expensive, while private paths may lower cloud-side transfer costs and improve predictability.
- SD-WAN makes routing more intentional. Policy-based path selection can account for application needs, user location, latency, throughput, and failover requirements.
- Security must move with the architecture. SSE, cloud firewalls, microsegmentation, WAF, DDoS protection, and cloud-native controls need to support distributed workloads rather than depend only on a fixed perimeter.
- Software-defined interconnect supports gradual evolution. Organizations can combine physical circuits, virtual infrastructure, cloud on-ramps, and private peering as their footprint changes.
Conclusion
Hybrid and multi-cloud architecture is a progression, not a single target state. Many organizations begin with one provider and one region, then add resilience, geographic diversity, provider choice, and private connectivity as their applications and data movement patterns mature.
The most important design question is where the data lives and how it needs to move. That answer influences whether an organization should use public internet paths, private peering, SD-WAN overlays, regional expansion, multiple cloud providers, or a software-defined interconnect layer.
The practical message is to make cloud connectivity intentional. Internet-based paths can be a useful starting point, but performance variability and data transfer economics become significant at scale. Private peering, SD-WAN policy, and distributed security controls give organizations more ways to optimize traffic, stabilize user experience, and manage cost.
Successful hybrid and multi-cloud topologies are built around application behavior, user experience, operational resilience, and data movement economics. The right architecture fits the organization’s current center of gravity while leaving room to evolve as cloud consumption grows.
