File Storage SLAs: What EFS, Azure Files, Filestore and FSx Pay When the Share Freezes
October 11, 2026
When a file share fails, the compute hanging off it does not fail cleanly. NFS clients block on locked file handles, container pods sit in CrashLoopBackOff, database clusters start arguing about who owns the shared volume. The cloud provider notices none of this on your bill, but its SLA does: file storage products carry real uptime commitments, from 99.5% to 99.99%, and the credit schedules pay 10% to 100% of your file bill when they are missed. The catch is the same as everywhere else: the definitions are narrow, the tiers depend on your deployment shape, and nobody files for you.
This is the reference map for shared file storage on AWS, Azure and Google Cloud: what each product promises, what the providers count as downtime, how much money a real outage puts back on your bill, and where the deadlines sit. DigitalOcean has no managed file share product on its SLA index at all, so if you run NFS on a Droplet you are running it without any commitment to claim against.
What each provider promises on file storage
The commitment you are entitled to depends on the product and how it is deployed. AWS splits EFS into Multi-AZ and One Zone, gives FSx three separate ladders for three deployment shapes, and Microsoft sells Azure Files Premium at 99.99% while standard-tier shares sit inside the Storage Accounts SLA at 99.9%.
| Product | Deployment shape | Uptime commitment | Credit tiers (of the affected file bill) |
|---|---|---|---|
| Amazon EFS Standard (May 4 2022 SLA) | Multi-AZ regional | 99.99% | 10% below 99.99% · 25% below 99.0% · 100% below 95.0% |
| Amazon EFS One Zone | Single AZ | 99.9% | 10% below 99.9% · 25% below 99.0% · 100% below 95.0% |
| Amazon FSx Multi-AZ (Windows, ONTAP, OpenZFS) | Paired servers across AZs | 99.99% | 10% below 99.99% · 25% below 99.0% · 100% below 95.0% |
| Amazon FSx ONTAP / OpenZFS HA single-AZ | Active-standby in one AZ | 99.9% | 10% below 99.9% · 25% below 99.0% · 100% below 95.0% |
| Amazon FSx Windows, Lustre, OpenZFS non-HA | Single file server | 99.5% | 10% below 99.5% · 25% below 99.0% · 100% below 95.0% |
| Azure Files Premium (Oct 2026 SLA) | Per file share, LRS or ZRS | 99.99% | 10% below 99.99% · 25% below 99% (no 100% tier) |
| Azure Files Standard (Storage Accounts SLA) | Hot / transaction-optimized tier | 99.9% | 10% below 99.9% · 25% below 99% |
| Azure NetApp Files | Per volume, per region | 99.99% | 10% below 99.99% · 25% below 99% (no 100% tier) |
| Filestore Basic SSD/HDD, High Scale, Zonal (Mar 4 2025 SLA) | Per instance, per region | 99.9% | 10% below 99.9% · 25% below 99.0% · 50% below 95.0% |
| Filestore Enterprise / Regional | Per instance, per region | 99.99% (99.95% Mexico, Stockholm) | 10% below 99.99% · 25% below 99.0% · 50% below 95.0% |
| Filestore Enterprise / Regional, Mexico + Stockholm | Per instance, per region | 99.95% | 10% below 99.95% · 25% below 99.0% · 50% below 95.0% |
Two structural facts change how you read this table. Google caps every Filestore payout at 50% of the month's bill for the affected instance, no matter how catastrophic the month. And the Azure Files commitment applies to Premium shares under both the provisioned v1 and the newer provisioned v2 billing models, at the same 99.99%, so the tier of storage you buy does not change what the SLA owes you.
What counts as downtime: the all-requests-fail test
Every file storage SLA here uses the same brutal measurement: a minute only counts as down when every single request against your share fails. One successful read, and the minute is available.
- EFS defines Unavailable as a 1-minute interval in which all Operations hit either a Server Delay (a response that takes more than 15 seconds to commence execution) or a Server Error (an NFS4ERR_SERVERFAULT). Intervals with no traffic at all are assumed 100% available.
- FSx uses the simpler version: all Operations on the file system fail during a 1-minute interval.
- Azure Files Premium counts Downtime only when every request fails with a Service Side Issue: ServerOtherError, ServerBusyError or ServerTimeoutError.
- Filestore says all requests to the instance fail. For Basic, High Scale and Zonal instances the failure must run five or more consecutive minutes; Enterprise and Regional instances need only one minute, and 1-minute blocks of intermittent failure do not count against them either.
The single most important sentence in every file storage SLA is the one defining what does NOT count. Slow is not down. A share that answers one request in nine minutes counts that minute as available. To earn a credit you must prove total failure of every operation, sustained for the whole minute, on your own logs, inside the claim window.
Scheduled maintenance is carved out of all four contracts, and the carve-outs matter more than they sound: Filestore excludes downtime from scheduled maintenance by definition, and Azure excludes Scheduled Downtime with notice of five days. Your 2 AM maintenance window does not owe you credits. Yours, because the DR plan you wrote that runs a failover test at 3 AM every Sunday is also, from the provider's side, indistinguishable from a customer-initiated operation that does not count.
The minute math: how much total failure buys a credit
Monthly commitments translate to hard budgets of total failure. A 30-day month has 43,200 minutes.
| Commitment | Total failure allowed per month | First credit at |
|---|---|---|
| 99.99% | 4 minutes 19 seconds | any longer outage (10% tier) |
| 99.95% | 21 minutes 36 seconds | any longer outage (10% tier) |
| 99.9% | 43 minutes 12 seconds | any longer outage (10% tier) |
| 99.5% | 3 hours 36 minutes | any longer outage (10% tier) |
That last row is the quiet trap. A single-AZ FSx for Windows or Lustre file system allows 216 minutes of total failure per month before you are owed a cent. Many incidents that look catastrophic from the office do not cross it. The same outage on EFS Standard, Azure Files Premium or Filestore Enterprise breaches a 99.99% commitment after about four and a half minutes of total failure, which is why the premium tier exists: the money side is where the deployment shape shows up.
What a real outage pays: the money math
Filing every sub-hour blip is not worth anyone's hour of paperwork, so run the numbers first. On a $500/month file storage bill, three incident sizes:
| Outage | Monthly uptime | EFS Standard / FSx Multi-AZ | FSx single-AZ (99.5%) | Azure Files Premium | Filestore Basic | Filestore Enterprise |
|---|---|---|---|---|---|---|
| 45 minutes | 99.90% | $50 (10%) | $0 (above commitment) | $50 (10%) | $50 (10%) | $50 (10%) |
| 8 hours | 98.89% | $125 (25%) | $50 (10%) | $125 (25%) | $125 (25%) | $125 (25%) |
| 40 hours | 94.44% | $500 (100%) | $500 (100%) | $125 (25% cap) | $250 (50% cap) | $250 (50% cap) |
The 45-minute row is why single-AZ FSx deployments surprise people: at 99.90% the month is above the 99.5% commitment, so a total failure of nearly an hour pays nothing. The 40-hour row shows the caps: Azure Files and NetApp Files cap at 25% and Filestore caps at 50%, while AWS pays the full file bill. On a bigger footprint the differences scale linearly; a $2,000/month EFS Standard share that loses 40 hours pays back $2,000, where the same share on Azure Files Premium pays $500.
Deadlines and evidence per provider
- AWS (EFS and FSx): open a Support Center case with "SLA Credit Request" in the subject line, within the end of the second billing cycle after the incident. Include the billing cycle, region, dates and times with time zone, your request logs (EFS) and the file system IDs (FSx). Credits under $1 are not issued, credits cannot transfer between accounts, and FSx claims cannot be stacked across SLA tiers for the same outage.
- Azure: file via a support request within 60 days of the incident. For metered pay-as-you-go, the Applicable Period is the 30 days before and including the incident day; credits are a percentage of what you actually paid for the affected file shares in that period. Microsoft processes claims within about 45 days of receipt.
- Google Cloud: notify Google technical support within 30 days of the moment you become eligible; there is no month-end grace. Filestore credits apply per instance per region, and the credit lands within 60 days of the request. Miss the window and the claim is forfeit.
For evidence, the provider is asking for the same thing across the board: your own records that every operation failed. EFS wants request logs showing Server Delays or NFS4ERR_SERVERFAULTs. FSx wants logs plus file system IDs. Azure wants proof every request returned a Service Side Issue. A status page screenshot is a start; a client-side log with timestamps in UTC is what survives review. The claim evidence guide covers the general artifact set, and the step-by-step claim walkthrough has the provider-specific filing routes.
What to do tonight
Pull the inventory of shared file systems, write down the deployment shape of each one, and look up the matching row from the first table. Teams are routinely running single-AZ FSx and One Zone EFS while assuming the 99.99% number, which means the claims they would file after an outage are not the claims they are entitled to. That mismatch is exactly the sort of thing a monitoring tool like UptimeAudit exists to catch: it watches provider health feeds down to service and region level, and drafts the claim when observed downtime crosses the threshold your actual deployment shape entitles you to. Ten minutes of inventory tonight, and the next regional incident pays you instead of the provider.