Choosing an ISP for an SD-WAN deployment looks straightforward until you start comparing what providers are actually offering.
Bandwidth is easy to compare. Price is easy to compare. Uptime guarantees are usually printed prominently in the proposal.
Those are important, but they are not where I would stop.
When I evaluate connectivity for an SD-WAN environment, I am trying to answer a broader question:
Will this network consistently deliver the performance, resilience, support, and economics the business expects once real applications are running across it?
That distinction matters.
SD-WAN gives an organization much more control over how traffic moves across its WAN. It can measure link conditions, recognize application traffic, steer sessions between available paths, and fail over when a connection deteriorates.
But SD-WAN cannot manufacture network quality that does not exist underneath it.
A poorly performing internet circuit is still a poorly performing circuit. SD-WAN simply gives us better tools for identifying the problem and moving traffic somewhere else—assuming we have designed another viable path.
That is why I believe ISP selection should be treated as part of the SD-WAN architecture itself, rather than as a procurement exercise that happens after the architecture has already been decided.
What I Would Prioritize
If I were evaluating ISPs for an SD-WAN deployment today, I would focus on six areas:
- Actual network performance — latency, jitter, and packet loss, not simply advertised bandwidth.
- Backbone and peering quality — how efficiently the ISP reaches the cloud platforms, networks, and geographies the business actually uses.
- Physical diversity — whether redundant circuits are truly independent.
- SLA and support quality — what the provider commits to when performance deteriorates or a circuit fails.
- Application requirements — whether the connection fits voice, video, SaaS, cloud, backup, and other workloads.
- Total economics — including installation, equipment, support, management, contract terms, and downtime risk.
For critical locations, I generally prefer having more than one viable transport path. But simply ordering circuits from two different carriers does not automatically create redundancy.
The underlying physical paths matter just as much as the logos on the invoices.
What SD-WAN Changes—and What It Doesn't
SD-WAN fundamentally changes how enterprises can use connectivity, but it does not eliminate the importance of the underlying network.
In a traditional WAN architecture, a business might depend heavily on a carrier-managed MPLS network. The carrier controls much of the transport, and the enterprise pays for predictable connectivity between locations.
SD-WAN separates much of that control from the underlying carrier network.
I can now build an enterprise WAN using different combinations of:
- Dedicated Internet Access (DIA)
- Business broadband
- Fiber
- MPLS
- LTE/5G
- Fixed wireless
- Satellite or LEO connectivity
The SD-WAN platform can continuously evaluate those connections and make routing decisions based on application policies and real-time network conditions.
ISP-agnostic does not mean ISP quality is irrelevant.
The SD-WAN overlay may be transport-independent, but the packets still have to travel across a physical network.
If the underlying ISP has congestion, poor routing, excessive jitter, or unstable international transit, those conditions can still affect the applications riding on top of it.
SD-WAN gives us the ability to respond intelligently to those conditions. It does not eliminate them.
Why ISP Quality Matters More Than the Speed on the Quote
A 1 Gbps connection from Provider A and a 1 Gbps connection from Provider B may look identical on a spreadsheet.
They may behave very differently in production.
Latency
Latency measures how long it takes traffic to travel between endpoints.
For ordinary web browsing, small differences may not be noticeable. For voice, video conferencing, virtual desktops, cloud applications, and other interactive workloads, latency can materially affect the user experience.
Jitter
Jitter is variation in packet arrival time.
This becomes particularly important with real-time communications. A connection can have plenty of available bandwidth and still produce poor voice or video quality if packet timing is inconsistent.
Packet loss
Packet loss occurs when packets fail to reach their destination.
Applications may retransmit lost packets, which consumes additional bandwidth and introduces delays.
Bandwidth tells me the size of the pipe. It does not tell me the quality of the journey through it.
Look Beyond the Last Mile
One of the most overlooked parts of ISP evaluation is what happens after traffic leaves the local circuit.
An ISP does not operate in isolation. Traffic may pass through the provider's backbone, internet exchanges, transit providers, and other networks before reaching its destination.
For many organizations, a significant percentage of WAN traffic is now headed toward cloud and SaaS platforms rather than another corporate office.
When I evaluate a provider, I therefore want to understand:
- Where does the ISP peer with major networks?
- Which upstream carriers does it rely on?
- Does it have direct relationships with major cloud platforms?
- How does traffic leave the local market?
- What happens to international traffic?
- Are there obvious regional aggregation points?
- How many network handoffs occur before important destinations?
Autonomous System connectivity can provide useful context, but I would not make a carrier decision based on AS count alone.
What ultimately matters is the quality of the routes my applications actually use.
SLA: Read Beyond the Uptime Percentage
A carrier advertising 99.99% uptime sounds reassuring.
But uptime alone does not answer many of the questions I care about.
Suppose the circuit remains technically "up," but packet loss suddenly increases or latency doubles during peak periods.
From the carrier's perspective, the circuit may still be available. From the user's perspective, Microsoft Teams calls may be unusable.
This is why I recommend examining the actual SLA language rather than simply comparing availability percentages.
- Network availability
- Latency
- Packet loss
- Mean time to repair
- Service restoration
- Escalation procedures
- Service credits
A service credit after an outage may satisfy the contract, but it does very little for employees who could not work during the outage. For critical locations, the operational response matters more than the credit calculation.
The Redundancy Question I Would Always Ask
One of the most important questions in an SD-WAN design is also one of the easiest to overlook:
Are my two circuits actually physically diverse?
Buying one connection from Carrier A and another from Carrier B does not guarantee that they follow independent physical routes.
Both circuits could ultimately share:
- The same underground conduit
- The same building entrance
- The same utility pole
- The same central office
- The same local exchange carrier
- The same metro fiber ring
- The same regional aggregation facility
If a construction crew cuts the shared fiber path, both carriers can disappear at the same time.
From a billing perspective, you had two providers.
From a network-resilience perspective, you had one failure domain.
For especially important locations, I would also consider using different transport technologies.
Primary DIA + secondary 5G can sometimes provide better failure diversity than two fiber circuits running through the same physical conduit.
The objective is not simply carrier diversity.
The objective is failure-domain diversity.
Four SD-WAN Connectivity Models I Commonly Consider
There is no universally correct WAN architecture. I would select the transport model according to the business importance of each location.
Dual-ISP Internet
Two independent internet connections serve the same location. SD-WAN can distribute traffic or move applications when one path falls outside acceptable performance thresholds.
DIA + Business Broadband
DIA provides a stronger primary connection while broadband adds capacity or backup at a lower cost.
Internet + LTE/5G
Wireless transport provides rapid deployment and a different physical failure path where a second wired connection is difficult or expensive.
MPLS + Internet
MPLS continues carrying selected critical traffic while internet connectivity handles cloud and SaaS applications.
Comparing Connectivity Options
| Transport | Where I Would Consider It | Primary Advantage | Main Trade-Off |
|---|---|---|---|
| DIA / Fiber | Headquarters, data centers, major branches | Symmetric capacity, consistent performance, stronger SLAs | Higher cost and longer installation times |
| Business Broadband | Branches or secondary transport | Cost-effective bandwidth and broad availability | Performance may vary with congestion |
| LTE / 5G | Backup, temporary, and difficult-to-wire locations | Rapid deployment and physical diversity | Variable performance and coverage |
| MPLS | Critical legacy or specialized workloads | Predictability and contractual performance | Higher bandwidth cost and slower provisioning |
| Satellite / LEO | Remote locations and specialized resilience | Connectivity where terrestrial options are limited | Economics and performance vary considerably |
I would not choose one transport technology for every location simply for architectural consistency.
A headquarters with 1,000 employees has a very different risk profile from a branch with 12.
The network design should reflect the business value of the site.
SD-WAN vs. MPLS: I Would Build the Business Case Carefully
Cost reduction is one of the major reasons enterprises evaluate SD-WAN.
There is a legitimate economic argument.
Internet bandwidth can often be purchased far more economically than equivalent MPLS capacity, and the organization may be able to increase bandwidth while reducing transport spending.
But I would be cautious about presenting a single savings percentage as though it applies universally.
Vendor-neutral analyses often place multi-site SD-WAN savings in approximately the 30%–50% range, while some vendor case studies report significantly higher figures.
Those numbers are useful benchmarks.
They are not a business case.
When I build the financial comparison, I would include:
- Current MPLS charges
- New ISP circuit charges
- Installation costs
- Construction charges
- SD-WAN licenses
- Edge hardware
- Security services
- Managed services
- Internal network staffing
- Support costs
- Contract termination penalties
- Bandwidth growth
- Downtime exposure
Sometimes the best outcome is not simply spending less.
The organization might spend approximately the same amount but receive significantly more bandwidth, better resilience, and greater architectural flexibility.
That can still represent a strong business case.
My 8-Step Framework for Selecting an ISP for SD-WAN
If I were running an ISP selection today, this is the process I would use.
Start with applications, not carriers
I would identify users, voice, video, SaaS, cloud infrastructure, backups, large transfers, remote access, and expected growth before requesting carrier quotes.
I would also forecast at least 12–24 months ahead.
Determine site criticality
I would classify locations by business impact so the level of redundancy reflects the actual cost of an outage.
Tier 1 sites may justify dual DIA. Tier 3 sites may be adequately protected by broadband plus 5G.
Evaluate network quality
I would request performance information for the routes that matter to the organization rather than relying on generic national averages.
Verify physical diversity
I would validate the building entrance, last-mile provider, conduit, central office, metro ring, and aggregation point wherever resilience is important.
Review SD-WAN compatibility
I would check carrier-grade NAT, static IP availability, traffic shaping, filtering, MTU, encrypted tunnels, and IPsec behavior.
Evaluate the support organization
I want to know who answers during an outage, how quickly the issue reaches a network engineer, what restoration commitment exists, and how chronic problems are escalated.
Compare total cost
I would normalize installation, construction, contract terms, upgrades, managed services, support, and termination charges before comparing providers.
Match provisioning to the rollout
Fiber construction can take weeks or months. In some cases the practical sequence may be 5G first, broadband second, and fiber when available.
The ISP Scorecard I Would Use
Rather than selecting a provider primarily on price, I recommend using a weighted scorecard.
| Evaluation Area | Suggested Weight | What I Would Measure |
|---|---|---|
| Network performance | 25% | Latency, jitter, packet loss, route quality |
| Reliability & diversity | 20% | Physical path, architecture, redundancy |
| SLA & support | 20% | Availability, MTTR, escalation, support model |
| Commercial terms | 15% | Monthly cost, installation, contract flexibility |
| Coverage & scalability | 10% | Geographic reach and bandwidth expansion |
| Provisioning | 5% | Installation lead time |
| SD-WAN compatibility | 5% | NAT, IP addressing, tunnels, traffic policies |
These weights are a starting point. Financial services, retail, healthcare, global enterprises, and rapidly growing companies may weight the categories differently.
The important thing is that price becomes one component of the decision rather than the decision itself.
Questions I Would Put Directly to Every ISP
Before signing a contract, I would want clear answers to the following.
The quality of the answers can tell you almost as much about the provider as the answers themselves.
ISP Selection Checklist
Before approving an ISP for an SD-WAN deployment, I would make sure the team has validated the following.
- Current bandwidth requirements
- 12–24 month growth requirements
- Upload as well as download capacity
- Latency
- Jitter
- Packet loss
- Backbone and peering
- Physical route diversity
- Last-mile ownership
- SD-WAN compatibility
- SLA terms
- MTTR
- 24/7 escalation
- Installation costs
- Contract flexibility
- Early termination charges
- Provisioning timeline
- Upgrade options
If several of those answers are still unknown, I would not consider the carrier evaluation complete.
Frequently Asked Questions
Does SD-WAN work with any ISP?
Generally, yes.
SD-WAN is designed to operate across different IP transports, including fiber, broadband, DIA, LTE/5G, MPLS, and satellite.
But I would distinguish between compatibility and suitability.
A connection may technically work with SD-WAN while still providing poor latency, unstable routing, or insufficient upload capacity for the applications using it.
How many ISPs should I have at each site?
There is no universal answer.
For a business-critical site, I generally prefer two viable paths with genuinely different failure domains.
For a smaller branch, one wired ISP plus LTE/5G backup may provide sufficient resilience.
Do I still need MPLS?
Not necessarily.
Many enterprises can operate effectively using internet-based SD-WAN.
But I would not remove MPLS simply because the technology is considered legacy. If MPLS is supporting a workload with a clear performance or business requirement, I would compare its value against the alternatives.
How much bandwidth does an SD-WAN site need?
SD-WAN itself does not determine the bandwidth requirement.
Applications do.
I would size the connection according to users, voice, video, SaaS, cloud traffic, backups, and anticipated growth.
For many mid-sized branches, 100 Mbps to 1 Gbps may be reasonable territory, but I would treat that as context rather than a sizing rule.
Does an ISP need to be SD-WAN certified?
There is no universal ISP certification that I would use as the deciding factor.
I care more about whether the provider can reliably support the connectivity requirements of the SD-WAN architecture, including IP addressing, encrypted tunnels, NAT behavior, and traffic policies.
Final Perspective: Buy the Network You Need, Not the Circuit You're Offered
The biggest mistake I see in WAN planning is treating connectivity as a commodity too early in the decision process.
It is tempting to put carrier proposals into a spreadsheet, compare Mbps and monthly recurring cost, and select the lowest number.
SD-WAN gives enterprises far more freedom than traditional WAN architectures, but that freedom makes network design more important—not less.
I would start with the business.
Which applications matter? Which locations matter? What happens if connectivity fails? How quickly must the organization recover?
From there, I would design the transport strategy.
Only then would I select the carriers.
For some sites, that may mean dual DIA. For others, broadband plus 5G may be entirely appropriate. Some organizations may continue using MPLS for a subset of workloads. Others may eliminate it completely.
There is no single carrier or connectivity architecture that is right for every enterprise.
The goal is to build a WAN in which performance, resilience, cost, and business risk are deliberately balanced.
That is the standard I would use when choosing an ISP for SD-WAN.
Sources and Methodology
This guide is intended as a decision framework rather than a recommendation for a particular ISP or SD-WAN vendor.
- Network World — Choosing ISPs for SD-WAN
- TechTarget — How to select and set up SD-WAN and DIA
- TechTarget — SD-WAN and MPLS costs
- Check Point — SD-WAN configuration documentation
- MarketsandMarkets — SD-WAN market research
- SDxCentral — SD-WAN market analysis
Cost savings, performance benchmarks, and market projections vary by methodology, geography, deployment size, and publication date. Time-sensitive statistics should be reverified before publication and reviewed periodically.
Editorial & Accuracy Policy
This article does not promote a specific ISP, SD-WAN vendor, or managed service provider.
Provider names should be included only when necessary to identify technical documentation, research, or the original source of a statistic.
Because ISP pricing, SD-WAN products, SASE offerings, carrier SLAs, and market forecasts change frequently, important statistics and provider-specific claims should be reviewed at least every six months.