How to Improve Network Resilience

By Jason Bordujenko, Global Head of Solutions Architects

Learn the difference between network redundancy and resilience, plus practical ways to improve failover, path diversity, and uptime.

In summary

To build a more resilient network, combine redundant infrastructure with diverse providers and physical paths, active-active routing, multiple cloud on-ramps, and protection for shared dependencies such as DNS, identity, and firewalls. Regularly test failover, monitor recovery and routing metrics, and select a topology that balances resilience, complexity, and cost for your environment. Redundancy provides backup components; resilience ensures the network can continue operating and recover quickly when failures occur.

What’s the difference between redundancy and resilience?

Redundancy and resilience are related, but not the same. Redundancy is what you build – like duplicate circuits, routers, and power feeds. Its purpose is to eliminate single points of failure. Resilience is how your network performs under stress. This includes redundancy but extends to other factors routing logic and how quickly your team can respond.

The divide between redundancy and resilience is where network outages usually happen – slow failover, misrouted traffic, or hidden shared dependencies are all examples. Redundancy without orchestration will still fail.

The consequences of not planning for both redundancy and resilience range from downtime minutes and degraded customer experience to SLA penalties.

How can I improve my network resilience?

Resilience improvements don’t have to mean a full redesign. Here are the highest-impact changes you can make, starting with your architecture and working down to the dependencies that often get overlooked.

Build diverse paths, not just duplicate ones

Two circuits don’t mean much if they share one provider, conduit, or internet exchange. True path diversity spans different providers, physical routes, and workloads distributed across availability zones or regions, so a single failure can’t take down both paths at once.

Move from active-passive to active-active routing

Active-passive setups leave capacity sitting idle until something breaks. Active-active routing, on the other hand, keeps both paths in use and reduces failover time significantly.

Tune BGP carefully. Local preference and AS path prepending give you fine-grained control over how traffic distributes and reroutes when something fails (and allow it to be tested). Regular failover drills are the only way to actually know your routing does what you think it does.

Diversify your cloud on-ramps

A single connection to a cloud provider is a single point of failure, regardless of how resilient the cloud itself is. Use multiple on-ramps to your providers, place connections across different diversity zones, and consider using connectivity solutions like Megaport Cloud Router (MCR) instead of static circuits to get dynamic path control and the ability to reroute traffic without waiting on physical provisioning.

Run failure simulations

Uptime tells you how often things work. It doesn’t tell you how fast you recover when they don’t. Drop a link, disable a router, and time the actual recovery. Do it regularly and you’ll find any gaps in your failover logic before an unplanned outage finds them for you when you least expect it.

Audit your hidden dependencies

The failure that brings down a resilient network is often something nobody thought to protect, like a shared DNS provider, centralized identity provider, or shared firewall. Map your dependencies, identify which ones are shared across paths, and treat them with the same scrutiny you’d apply to your primary circuits.

Best network topologies for resilience

The topology you pick is one of the biggest resilience decisions you’ll make, and the right answer depends on your environment, budget, and risk tolerance. Here are the four patterns that come up most.

Dual-homed (basic resilience)

Two upstream connections, two paths out. It’s the simplest form of resilience there is, cheap and easy to manage, and a solid starting point if you don’t need much complexity.

Best for when:

• you’re running a small to mid-sized environment
• budget is a constraint
• workloads aren’t mission-critical.

Hub and spoke (controlled resilience)

A central hub connects out to multiple spoke sites, which gives you one place to enforce policy and control traffic. Most SD-WAN deployments look like this.

But keep in mind that the hub itself ccan become a potential bottleneck; if it fails, so does everything connected to it.

Best for when:

• you’re managing branch networks
• you need a centralized security stack
• SD-WAN is part of your architecture.

Full mesh (high resilience)

Every node connects directly to every other node, so there’s no single dependency left to eliminate. It’s the highest-resilience option on this list, and also the most complex and expensive to run, unless you’re using a NaaS platform like Megaport to handle the connectivity layer for you.

Best for when:

• you have latency-sensitive apps or need low latency across all paths
• you’re running multi-region active-active systems.

Hybrid/partial mesh (real-world sweet spot)

This is the most common pattern in real enterprise environments. Critical nodes are selectively meshed, while less critical paths use simpler connectivity. You get most of the resilience benefit at a fraction of the full-mesh cost and complexity.

Best for when:

• you’re running a multicloud environment with prioritized paths
• you’re an enterprise after a practical balance of cost and resilience.

Building resilience at scale with Megaport

Megaport is particularly well-suited to partial mesh architectures, where the challenge is connecting multiple nodes dynamically without long provisioning cycles or physical builds.

Use Megaport to spin connections up on demand, with over 1,200 global enabled locations available. MCR also enables dynamic rerouting without static circuits to give you rapid failover paths, multicloud diversity, and freedom from single-carrier dependency.

Multicloud active-active in practice

The following is a pattern we see work well across a lot of deployments:

• AWS + Azure + GCP connected via Megaport.
• MCR handles routing between clouds.
• Dual on-ramps per cloud (different metros / zones).

This configuration removes dependency on a single cloud region or carrier, keeps costs manageable, and lets you shift traffic during outages. It’s a common pattern for customers who require strict uptime, tight latency, and near-instant failover — financial services being a good example.

Common mistakes that kill resilience

Most of the environments our solution architecture team review already have some form of redundancy in place. Very few are actually resilient.

The reason is almost always the same: a team built redundancy to tick a box and never went back to check whether it does anything under real failure conditions. A few patterns come up again and again.

Two “diverse” circuits that share a last mile

On paper it’s two providers, two contracts, and two invoices. In practice both circuits enter the building through the same conduit or hand off to the same local exchange carrier a few miles upstream. But nobody is tracing the physical path past the provider’s marketing map.

The fix: Ask both providers for the actual physical route, not just the logical diagram, and confirm the point of divergence is far enough upstream to survive a single dig-up or DC incident.

Dual cloud on-ramps that land in the same metro

Two connections into a cloud provider looks like redundancy until you realize both terminate in the same city, sometimes the same data centre. If that facility has a bad day, both paths go with it.

The fix: Spread on-ramps across at least two availability zones, not just two ports.

Active-passive that’s never been forced to fail over

This is the most common one. A backup path has been built, provisioned, and then left for a year or more. Now nobody knows if the BGP timers are sane, if the passive side even has current routes, or if someone will need to manually intervene when it counts.

The fix: Schedule real failover drills, not a config review. If you haven’t pulled the primary link on purpose in the last six months, you don’t actually know your failover works.

Redundant hardware, single human workflow

This setup includes two routers and two circuits, but both changes go through the same change ticket, the same engineer, and the same maintenance window. The redundancy protects against hardware failure but not against a bad config push, because both sides get the same bad config at the same time.

The fix: Stagger changes across redundant paths and require validation on one side before touching the other.

Multicloud on paper, single chokepoint in practice

We see plenty of AWS + Azure + GCP deployments that all funnel through one MCR instance or one on-prem router, with no fallback path if that device or that connection goes down. A multicloud strategy removes provider risk but can reintroduce a different single point of failure.

The fix: Treat your routing layer with the same scrutiny as your circuits. If there’s only one path into your routing fabric, that’s your actual single point of failure, not the clouds behind it.

The common thread across all of these is that the redundant component exists, but nobody has recently proven it works the way they assume it does. Resilience isn’t a one-time build, but something you have to keep testing as the network changes around it.

Network resilience metrics that actually matter

Uptime percentages alone tell you little about how resilient your network actually is. To gauge resilience, these are the metrics worth tracking consistently.

Core

• Mean time to recover (MTTR)
• Mean time between failures (MTBF)
• Failover time in seconds

Network

• Packet loss %
• Latency variance (not just average)
• Route convergence time (BGP)

Service-level

• Application availability (not just link uptime)
• Transaction success rate

Operational

• Time to detect incident
• Time to reroute traffic.

The bottom line: Redundancy isn’t enough

Redundancy is the baseline for every network. But resilience is the next step, engineered deliberately through routing decisions, failover logic, topology choices, and the operational discipline to test it all.

Network as a Service (NaaS) platforms like Megaport abstracts the physical connectivity layer so provisioning a new path, rerouting traffic, or standing up a new connection becomes as simple as a software command.

This make achieving resilience easy by:

• reducing the time it takes to adapt
• increasing path diversity without physical builds
• putting control back in the hands of the network team.

Learn how your peers are approaching network resilience in our Cloud Network Report, or get more network building tips in our Megaport Connect Virtual Summit.