Dedicated Connection SLAs: Direct Connect, ExpressRoute and Cloud Interconnect
September 22, 2026
Private connectivity puts a legal structure on your network diagram. On Direct Connect, ExpressRoute and Cloud Interconnect, the uptime a provider commits to depends on how many paths you built and where they terminate, and the difference is not decorative. Google offers no SLA at all for a single Interconnect connection, or for several sharing one edge availability domain. AWS pays nothing on a single connection until its uptime falls below 95%, which allows more than a day of darkness in a month before the first credit. Azure's single-site ExpressRoute configuration waits for a breach below 99.0%. The same 30-minute outage, meanwhile, pays $150 on a properly redundant deployment from any of the three. The redundancy you bought is the SLA you hold.
The commitment ladder is a topology diagram
| Deployment shape | Commitment | What it requires |
|---|---|---|
| AWS, Multi-Site Redundant | 99.99% | four or more connections across two or more Direct Connect locations, two per location on unique devices, Enterprise Support, a completed Well-Architected Review |
| AWS, Multi-Site Non-Redundant | 99.9% | two or more connections across two or more locations, Enterprise Support |
| AWS, single connection | first credit tier below 95% | one connection; AWS states it does not recommend this for production workloads |
| Azure ExpressRoute, 2+ Site | 99.95% | two or more dedicated circuits in two or more non-Metro peering locations |
| Azure ExpressRoute, Metro Site | 99.9% | circuits inside a single Metro peering location |
| Azure ExpressRoute, Single Site | 99.0% | one non-Metro peering location |
| Google, production-level topology | 99.99% | the documented four-connection topology across two regions |
| Google, non-critical topology | 99.9% | the documented non-critical topology |
| Google, single connection | no SLA | one connection, or several in a single edge availability domain |
The requirements are the contract. AWS gates its 99.99% behind four connections plus Enterprise Support plus an architecture review. Google gates its 99.99% behind a documented topology it can point to. Azure gates 99.95% behind two circuits landing in two different non-Metro cities. Two connections in the same data centre count as one path to Azure, and several connections in one Google edge availability domain count as none at all.
How downtime is counted
All three count seconds of total loss, not slow traffic.
- AWS: complete inability to send or receive data through all connections in the deployment, or through the single connection, for at least 120 consecutive seconds.
- Google: the same 120-second bar, with the covered service unable to serve any traffic.
- Azure measures per circuit: a minute is unavailable when every attempt to reach the ExpressRoute gateway fails for longer than 30 seconds.
Two clauses inside those definitions shape real claims. In an Azure 2+ site configuration, traffic that flows over the surviving circuit is not downtime, and credits apply only when all circuits and sites are down simultaneously. One broken circuit in a redundant pair is not a payable event at the deployment level. On AWS the reverse quirk works in your favour: a connection inside a redundant deployment can claim under the Single Connection SLA for its own downtime even when the deployment as a whole stayed available. Both matter because credits are calculated from the port hour charges of the affected connections, not the whole bill.
The redundancy you built is the SLA you hold. One connection means no promise at all from Google, a credit ladder that starts below 95% from AWS, and a single-site tier from Azure that pays nothing until 99.0%. The second path is not an engineering nicety; it is the document that turns an outage into a claim.
The credit ladders
| Provider | First tier | Next tier | Top tier |
|---|---|---|---|
| AWS | 10% below the commitment (99.99%, 99.9% or 95% by shape) | 25% below 99.0% (single connection: 92.5%) | 100% below 95% (single connection: 90%) |
| Azure ExpressRoute | 10% below the commitment (99.95%, 99.9% or 99.0%) | 25% below the next rung (99.9%, or 99.0%, or 95%) | none |
| Google Cloud Interconnect | 10% below the commitment (99.99% or 99.9%) | 25% below 99.0% | none, capped at 50% |
The ladder shapes differ in two pointed ways. AWS is the only one of the three with a 100% tier, and its single-connection rungs sit at some of the lowest thresholds in the big four: 95, 92.5 and 90. Azure's ExpressRoute ladder has no top at all, so the highest credit available on any configuration is 25%, and the 2+ site shape steps down early, at 99.9 rather than 99.0. Google caps interconnects at half the bill, as it caps most of its portfolio.
Money math on $1,500 a month of port hours
| Incident | AWS Multi-Site Redundant | AWS single connection | Azure 2+ Site | Google production | Google single |
|---|---|---|---|---|---|
| 30 minutes (99.931%) | $150 | $0 | $150 | $150 | no SLA to claim under |
| 8 hours (98.889%) | $375 | $0 | $375 | $375 | no SLA to claim under |
| 40 hours (94.444%) | $1,500 | $150 | $375 | $375 | no SLA to claim under |
Read the AWS single-connection column: eight hours down pays nothing, because its ladder only starts below 95%. The Azure single-site shape behaves the same way for shorter incidents and tops out at a quarter of the bill forever. Google's single connection has no ladder to climb. The final row shows what happens when a month goes badly: AWS refunds the whole port bill, while Microsoft and Google stop at 25%, because their interconnect ladders have no 100% rung.
Filing, and the audit
Each provider wants specific artefacts.
- AWS: a support case with "Direct Connect SLA Credit Request" in the subject, the dates and times, the affected Connection IDs with their virtual interface IDs, the billing cycle, and request logs. Deadline: the end of the second billing cycle. Hosted connections and hosted virtual interfaces bought through partners are excluded; the SLA protects dedicated connections you own.
- Azure: a portal support request within two months, with one service level chosen per incident. The edge case to plan for: in multi-circuit architectures, credits apply only when every circuit is down at once.
- Google: notify technical support with log files showing the downtime periods, within 30 days. The 50% cap applies, and approved credits land within 60 days of the request.
The audit worth doing: draw your connectivity as one of the nine rows above and write down which row it earns. If the answer is a single connection, the honest reading is that the provider has told you, in writing, what it thinks of that design. Either add the second path, or accept that the unclaimable outage was priced in. Mapping topologies to the promises they carry, and watching the claim windows when a path fails, is the same bookkeeping UptimeAudit runs against the big four's service health feeds.