VPN SLA Credits: What AWS, Azure and Google Cloud Pay When the Tunnel Drops
October 8, 2026
Your VPN has a service level agreement, and when the tunnel dies you can claim money back. But the VPN SLA is the strictest of any network service: a single dead tunnel almost never counts, a claim only exists when both ends fail at once, and the credit is a percentage of connection fees that are tiny next to the traffic those tunnels carried. The September 30 Azure incident that knocked out VPN Gateways across 18 regions is a live test case. This post lays out the exact commitments, the credit ladders, the deadlines and the math, for AWS Site-to-Site VPN, AWS Client VPN, Azure VPN Gateway and Google Cloud VPN.
The commitments, and which deployment earns them
Every provider grades the promise by how much redundancy you paid for. One tunnel gets you the weak SLA. A second tunnel, an HA gateway or an active-active pair gets you the strong one.
| Service | Deployment | Monthly uptime commitment |
|---|---|---|
| AWS Site-to-Site VPN | Any (AWS VPN connection category) | 99.95% |
| AWS Client VPN | Per region | 99.9% |
| Azure VPN Gateway | Basic SKU | 99.9% |
| Azure VPN Gateway | All SKUs except Basic | 99.95% |
| Google Cloud Classic VPN | Single tunnel | 99.9% |
| Google Cloud HA VPN | Only over Cloud Interconnect, non-critical apps | 99.9% |
| Google Cloud HA VPN | Production, including over Cloud Interconnect | 99.99% |
Two exclusions to memorize. The AWS Site-to-Site SLA covers only the "AWS VPN connection" category, not the legacy Classic VPN category. And the GCP 99.99% figure requires an HA gateway with at least one tunnel on each interface; a single-tunnel HA deployment is just a 99.9% promise.
What those percentages allow in a 30 day month: 99.99% leaves 4.3 minutes, 99.95% leaves 21.6 minutes, and 99.9% leaves 43.2 minutes. Ten minutes of blips twice in a month breaches a 99.99% promise while staying inside the 99.9% ones.
The rule that kills most claims: total loss only
Every provider defines downtime so that partial failure never counts. Read the definitions, because they are the difference between a paid claim and a form letter.
- AWS Site-to-Site VPN counts a connection as unavailable only when both of its two VPN endpoints have no external connectivity and every attempt to reach both fails. One tunnel dead, the other alive: no claim.
- AWS Client VPN is a touch looser: one or more endpoints with no connectivity, and all attempts to connect to the VPN fail.
- Azure measures per minute: a minute is unavailable only when all attempts to connect to the Virtual Network Gateway within a thirty second window in that minute fail. Lose one of two active-active instances and traffic keeps flowing, so the minute never counts.
- Google Cloud requires a full 120 consecutive seconds of the gateway serving no traffic through any of its component tunnels. Intermittent drops shorter than two minutes are not counted at all, and a single working tunnel keeps you out of breach.
The fact that decides most VPN claims: providers only count total loss. If any single tunnel or instance kept carrying traffic, there is no SLA breach, no credit and no appeal. Redundancy is the best SLA claim prevention money can buy, and also the reason most VPN outages never pay a cent.
The credit ladders
When a breach is real, the payout is a percentage of what you paid for the VPN service in the affected month, not of your whole cloud bill. The ladders differ a lot between providers.
| Service | Commitment | Credit tiers |
|---|---|---|
| AWS Site-to-Site VPN | 99.95% | 10% below 99.95 · 25% below 99.0 · 100% below 95.0 |
| AWS Client VPN | 99.9% | 10% below 99.9 · 25% below 99.0 · 100% below 95.0 |
| Azure VPN Gateway (non-Basic) | 99.95% | 10% below 99.95 · 25% below 99.0 |
| Azure VPN Gateway (Basic) | 99.9% | 10% below 99.9 · 25% below 99.0 |
| Google Cloud Classic VPN | 99.9% | 25% below 99.9 · 50% below 99.0 |
| Google Cloud HA VPN (production) | 99.99% | 10% below 99.99 · 25% below 99.9 · 50% below 99.0 |
The asymmetry is worth staring at. AWS will pay 100% of the connection fees if your month drops below 95% uptime. Azure never pays more than 25% for a VPN Gateway, even for a month-long outage, and Google tops out at 50%. So on Azure, a catastrophic VPN failure and a mediocre one pay the same 25%.
What an outage actually pays: two worked examples
The credit basis is the connection or gateway fee, not the data that crossed the tunnel. AWS bills $0.05 per Site-to-Site VPN connection-hour, which is $36 for a full month. Google bills $0.05 per tunnel-hour, so an HA VPN with two tunnels is about $72 a month. Azure bills by SKU: Basic is $26.28 a month, a VpnGw1 is $138.70. Here is what a one hour and an eight hour total outage pay on each, before your data-transfer bill (which is separate and mostly outside the credit basis).
| Service (monthly VPN fee) | 1-hour outage | 8-hour outage |
|---|---|---|
| AWS Site-to-Site VPN ($36) | 10% = $3.60 | 25% = $9.00 |
| AWS Client VPN | 10% | 25% |
| Azure VpnGw1 ($138.70) | 10% = $13.87 | 25% = $34.67 |
| Azure Basic ($26.28) | 10% = $2.63 | 25% = $6.57 |
| Google HA VPN, production ($72) | 25% = $18.00 | 50% = $36.00 |
| Google Classic VPN ($36) | 25% = $9.00 | 50% = $18.00 |
Run the numbers for your own stack and the picture gets uncomfortable. A tunnel that carries half your branch-office traffic and dies for a day earns you single-digit dollars on AWS, because the connection fee is a rounding error next to the data-transfer and business costs. The credits are real, but they are compensation for the VPN service being down, not for what the downtime did to you.
The September 30 Azure incident as a live test
On September 30, 2026 at 20:30 UTC, Azure began a networking incident that hit ExpressRoute Gateways, VPN Gateway and Azure VMware Solution across 18 regions during infrastructure servicing. Microsoft reported some gateways with "reduced redundancy or loss of connectivity". Recovery took hours, and five regions were still being worked on past 01:30 UTC.
For a VPN Gateway customer the SLA question is narrow. Was your gateway fully unreachable for more than 21.6 minutes during September? If yes, and you are on a non-Basic SKU, you are owed 10% of the gateway fee for the month. If you only lost one instance of an active-active pair, or your tunnels kept carrying traffic while the portal showed errors, there is no breach and no credit, even though the incident was real and Microsoft caused it. That is the VPN SLA in a nutshell: it indemnifies total loss only.
One check before filing: Azure excludes network failures outside its data centers, including at your site or on the path to it. If your own ISP or edge router was the problem, don't spend an hour on the claim.
What to save, and where to file
The claim windows match the general rules for each provider, and the evidence list is short if you keep tunnel metrics.
| Provider | Deadline | What to send | Channel |
|---|---|---|---|
| AWS | By end of the second billing cycle after the incident | Subject line "SLA Credit Request", account ID, billing cycle, region, connection or endpoint ID, dates and times in UTC, request logs | AWS Support Center case |
| Azure | Within 2 months of the end of the billing month | Incident description, time and duration, affected resources, what you tried, Service Health incident ID | Portal: Help + support, Billing, Refund Request |
| Google Cloud | Within 30 days of eligibility | Log files showing downtime periods with timestamps | Cloud SLA contact form |
The evidence that makes these stick is the tunnel telemetry: AWS CloudWatch TunnelState metrics, Azure VPN Gateway tunnel and BGP metrics, Google tunnel status plus TunnelInsights. A screenshot of a dead tunnel during the window, with UTC timestamps, beats a status page link every time. Google in particular will not consider a claim without log files that show the downtime periods.
One thing to do now
Check your VPN topology against the total-loss rule before the next incident, not after. For each site-to-site link, ask whether a single tunnel, instance or gateway failure leaves you with no SLA claim at all. If the answer is yes, that is a resilience gap you should close with a second tunnel or an active-active gateway, because the SLA will not cover you. Then, if your Azure gateway was fully down during the September 30 incident, pull the tunnel metrics for September and file the refund request before the end of November 2026. Two months after the end of the billing month is the deadline, and Microsoft does not volunteer the credit.