Regional cloud outage: what your continuity plan quietly assumes
A regional cloud outage exposes the assumption inside most continuity plans, that the cloud is always there. Your provider commits to a monthly uptime percentage and pays a service credit when it misses. Microsoft's own published figures show Microsoft 365 at 99.526 percent worldwide in the first quarter of 2026.
- A cloud service level agreement pays a service credit against your own bill. Amazon calls it your sole and exclusive remedy, and it does not fund a lost trading day.
- Microsoft states plainly that availability zones do not protect against a full-region outage. Zone redundancy and regional redundancy are two different purchases.
- The uptime tier you were quoted has eligibility conditions tied to how your systems were deployed, and Microsoft says it does not monitor or enforce your eligibility.
- Amazon published a 14 hour 32 minute disruption in its Northern Virginia region in October 2025. A provider post incident review is the only honest source for duration and scope.
- Programmatic outage alerts are free on both major platforms, so a health feed nobody subscribed to is a choice rather than a budget problem.
What does your continuity plan assume about a regional cloud outage?
Your continuity plan assumes the cloud region is always there. It names a backup provider, a phone tree, an insurance contact and a spare office, then goes quiet at the point where the cloud begins. Nobody wrote that assumption down, which is exactly why it survives every annual review.
The provider never promised what the plan assumes. It promised a monthly uptime percentage, and it publishes how often it hits it. Microsoft's own service description reports Microsoft 365 worldwide uptime of 99.526 percent in the first quarter of 2026, against 99.994 percent in the second quarter of 2026. The same published table shows 99.954 percent in the fourth quarter of 2025 and 99.927 percent in the fourth quarter of 2024. A 90-day quarter holds 129,600 minutes, so 99.526 percent leaves roughly 10 hours unaccounted for. That is our calculation from Microsoft's figure, not a number Microsoft states.
Ten hours is a trading day. Your plan has nothing in it for that day, because the plan was written about your building and your server room. This guide makes the assumption visible. It covers what the provider commits to in writing, which exclusions apply, what a cloud region and an availability zone mean for a buyer, and the three questions that reveal whether a plan has a cloud-outage branch at all.
We do not re-cover ground our other guides own. Read RTO and RPO Explained for the recovery objectives, How Long a Full Restore Takes for restore duration, Cloud Disaster Recovery for the architecture patterns, and The Cloud Shared Responsibility Model for the full responsibility split. This one is about the published commitment and what it does not promise.
What does a cloud service level agreement actually promise?
A cloud service level agreement promises a monthly uptime percentage and pays a service credit against your own bill when the provider misses it. Amazon commits to making EC2 available in each region with a Monthly Uptime Percentage of at least 99.99%, and commits separately to an Instance-Level Uptime Percentage of at least 99.5%.
Those two numbers are not the same promise, and the second one is the one your server sits under. A 30-day month holds 43,200 minutes. The 99.99 percent regional commitment permits about 4 minutes and 19 seconds of it. The 99.5 percent instance-level commitment permits 3 hours and 36 minutes. Both conversions are our arithmetic from Amazon's published percentages.
The remedy is where the document stops being generous. Amazon writes that the agreement sets forth your sole and exclusive remedies, and that remedy is a credit on your invoice. You also have to claim it. A credit request must be received by us by the end of the second billing cycle after which the incident occurred. Miss the window and the credit is gone. Our guide to the cloud shared responsibility model sets out the full credit ladder.
Check the version date before you quote any of it. The Amazon EC2 agreement carries Last Updated: May 25, 2022, so the contract behind a 2026 deployment was written four years ago. Microsoft goes further and does not publish its agreement as a web page. The Service Level Agreement for Microsoft Online Services ships as a Word document, current edition dated 1 October 2026. You download a .docx to read the terms that govern your email.
Which exclusions move your outage outside the agreement?
Four exclusion categories move an outage outside the Amazon EC2 agreement, and the first is broad enough to swallow most bad days. The agreement does not apply to unavailability caused by factors outside of our reasonable control, including any force majeure event, or to Internet access or related problems beyond the demarcation point. It also excludes anything that result from any actions or inactions of you, anything that result from your equipment, software or other technology, and anything arising from suspension of your right to use the service. The exclusions are contractual rather than discretionary, so arguing them after the event rarely works.
Microsoft draws a similar line for Microsoft 365. Its service description states that interruptions caused by third party service providers, or changes made within customer managed environment, aren't considered service incidents. Your single sign-on vendor, your line-of-business web app and your own change window all sit outside that definition, and outside the credit.
The condition nobody checks
The sharpest sentence either provider publishes is about eligibility, not exclusions. Microsoft's reliability guidance says a service level agreement carries any conditions you need to meet to be eligible for the SLA, then adds the part that matters to a buyer. You're responsible for understanding and meeting these conditions; Microsoft doesn't monitor or enforce your eligibility.
The uptime percentage written into your continuity plan may be a tier your deployment never qualified for, and the provider does not tell you. Nothing in the portal flags it. No invoice line reveals it. You find out when somebody files a claim after an outage and gets a shorter answer than the plan assumed.
What is a cloud region, and what is an availability zone?
A cloud region is a set of datacentres in one metropolitan area, and an availability zone is a separated group of datacentres inside that region. Microsoft describes an Azure region as a set of physical facilities that include datacenters and networking infrastructure, typically located within a large metropolitan area, and says Azure runs over 70 regions globally. Regions that support zones have at least three zones.
Zones sit close together on purpose. Microsoft says availability zones are typically separated by several kilometers, and usually are within 100 kilometers of each other, and that it targets inter-zone communication with round-trip latency of less than approximately 2 milliseconds. Amazon's position has the same shape. All Regions currently have three or more Availability Zones, and this separation between Regions limits service failures, when they occur, to a single Region. Microsoft publishes the table of which regions support zones, and it is worth opening rather than counting. Most listed regions show three, a few show more, and some rows carry a coming-soon marker, which means zone support in that region is announced rather than available. Look up your own region instead of assuming the general case, because an announced zone is not one you can deploy into today.
One Amazon sentence settles the topic for a buyer. The resources and data that you create in one Region do not exist in any other Region unless you explicitly use a replication or copy feature offered by an AWS service or replicate the resource yourself. Nothing crosses a regional boundary by default. If nobody configured data replication, there is no second copy to fail over to.
Microsoft states the limit just as plainly. Availability zones don't protect against a full-region outage. Zone redundancy and regional redundancy are two different purchases, and buying the first does not deliver the second.
Single-region deployment is a choice somebody made
Single-region deployment is a default rather than a law, and the uptime tier you were quoted usually depends on it. Microsoft's own virtual machine guidance recommends two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA. One machine on its own does not reach that tier. The architecture decides the number, and somebody chose that architecture, probably years ago, probably without telling the owner.
The default placement carries a trap worth understanding. Microsoft warns that regional resources may or may not exist in an Availability zone, and there is no insight into what physical or logical zone a regional resource is in, and that a failure in any of the availability zones in a region has the potential to bring down a regional VM. A resource nobody assigned to a zone still sits in one of them, and you cannot see which.
Who performs the failover
You perform the failover, when a resource is zonal rather than zone-redundant. Microsoft is explicit about it. For zonal resources, Microsoft doesn't manage the process for you. If an outage occurs in an availability zone, you're responsible for failover to another zone. For zone-redundant resources, Microsoft manages failover to another zone automatically. Those two sentences describe one provider and opposite outcomes, separated only by a configuration choice.
The cheap move is zone redundancy, and the price is published. Azure doesn't charge for data transfer between availability zones in the same region, whether the traffic uses private or public addressing. A multi-region deployment costs real money, because it crosses the provider's global network and doubles your footprint. Microsoft's recommendation lands in between. Production workloads should be configured to use multiple availability zones if the region they are in supports availability zones, and only mission-critical workloads need a design that is both multiregion and multi-zone.
Two more published facts belong in the conversation. You do not get to pick a second region freely, because Microsoft pairs some regions itself and you can't choose your own pairs. The provider also rehearses this. Microsoft says each Azure service must have a detailed disaster recovery plan and that it conducts full-region down drills in regions that match production environments. Ask when your provider last ran a drill.
Who restores what, in the providers' own words
Both providers describe a resilient platform and then hand you the rest. Amazon frames it as two halves. It is responsible for resiliency of the infrastructure that runs all of the services offered in the AWS Cloud, while you are responsible for managing resiliency of your data including backup, versioning, and replication strategies. Customers running virtual machines are responsible for deploying Amazon EC2 instances across multiple locations.
Microsoft splits reliability into three levels and keeps only the bottom one. It is solely responsible for core platform reliability and supplies the reliability-enhancing capabilities, but you're entirely responsible for selecting and using the appropriate ones for your needs. You are also responsible for defining your reliability requirements, which is the sentence that quietly hands you the recovery time objective. Our cloud shared responsibility model guide covers the rest of that split, and business continuity vs disaster recovery covers how the two plans fit together.
Microsoft even names the document you are supposed to be writing. Its regions guidance says some services are not tied to a single region, and that it's important to recognize how nonregional services operate in the case of a regional failure, and to take them into account when you design your solutions and business continuity plan. The provider is telling you the plan is yours.
The provider's agreement is a contract about availability. Your continuity plan is a promise to your customers. Nobody is going to write the second one for you.
What a published cloud outage actually looked like
Read the provider's own post incident review, because it is the only account that carries the duration, the scope and the date together. Amazon published a summary of its October 2025 disruption in Northern Virginia. The event started at 11:48 PM PDT on October 19 and ended at 2:20 PM PDT on October 20, which is 14 hours and 32 minutes on our arithmetic from those two timestamps. Amazon describes three distinct periods of impact and names the cause as a latent race condition in the DynamoDB DNS management system.
Recovery did not end when the root cause did. Amazon reports that Lambda message backlogs were processed by 6:00 AM and that Redshift full availability was restored at 4:05 AM PDT on October 21, more than a day after the event began. A continuity plan that treats the all-clear as the end of the incident sends staff back to a half-working system and calls it recovered.
Scope matters as much as duration
Microsoft's status history applies the same discipline. Its Post Incident Review (PIR) - Network Connectivity - Gateway service degradation in multiple regions, tracking ID 7Q30-010, records impact between 20:30 UTC on 30 September 2026 and 02:15 UTC on 1 October 2026, which is 5 hours and 45 minutes on our arithmetic. The published impact was intermittent failures when performing service management operations. Running resources kept running. What failed was changing anything, which is precisely what a failover requires.
A second entry shows how narrow an outage can be. Tracking ID 7QL5-Z50 records intermittent request failures and latency in Sweden Central from 10:03 to 15:58 UTC on 29 September 2026, about 5 hours and 55 minutes by our calculation, in one region for one family of services. Your plan needs a branch for the narrow case as well as the loud one.
You are entitled to this paperwork for your own tenant. Microsoft commits that for incidents with broad impact a preliminary post-incident review (PIR) will be delivered via your Service health within 48 hours of incident resolution, followed by a final PIR within five business days. Ask your provider to forward the last one they received.
The status page is a control, not a courtesy
Treat the provider's health feed as a control you configure, because both major providers hand you programmatic outage notification at no extra cost. Amazon states that the AWS Health Dashboard is available for all AWS customers at no additional cost and that all AWS customers can receive AWS Health events through Amazon EventBridge at no additional cost. Only the integration route sits behind a paywall. The AWS Health API needs an AWS Business Support+, AWS Enterprise Support, or AWS Unified Operations plan.
Azure splits the same job three ways, across Azure status, Service health and Resource health. A Service Health alert can escalate through email recipients, Short Message Service (SMS) notifications, Azure app push notifications, and Webhook, Logic Apps, or Information Technology Service Management (ITSM) integrations, and it can fire on Service issues, Planned maintenance, Health advisories, Security advisories. Microsoft adds a configuration tip most people get backwards. Select all Services and all Regions when configuring Service Health alerts, because the alert only triggers for regions where your services actually run.
Microsoft 365 and Google Cloud offer the same thing for their own estates. The Microsoft 365 Service Communications API exposes real-time service health and Message center posts, planned maintenance is announced no later than five days in advance, and incident updates arrive on an hourly cadence. Google's Personalized Service Health logs service health events in Cloud Logging and exposes a Service Health API for events affecting your own projects.
Somebody has to subscribe for any of this to matter. A health feed nobody reads is a smoke alarm with the battery out, and the person who should monitor it is named in your contract or in nobody's job description.
Three questions that reveal whether your plan has a cloud-outage branch
Three questions reveal whether a continuity plan has a cloud-outage branch at all. Send them to your managed IT provider in one email and keep the written answers.
- Name the region every production system runs in, and say which of them run across more than one availability zone. A provider who cannot answer in writing has not checked, and Microsoft doesn't monitor or enforce your eligibility for the tier you were quoted.
- Show the written plan for the first four hours of a cloud region being unavailable, and name the person who declares it. Published cases run from 5 hours 45 minutes to 14 hours and 32 minutes, so four hours is the first window, not the whole event.
- Open the provider health alert rule on screen, and show the last notification it sent to a named person. Both AWS Health events through Amazon EventBridge and Azure Service Health alerts are included at no extra cost, so an unconfigured feed is a choice rather than a budget problem.
A good answer is specific and boring. It names regions, names people, and shows a dated alert. A weak answer names the cloud provider and stops there.
Then verify one assumption yourself. List the systems the business cannot trade without, and write beside each one whether it would survive its region going dark for a working day. Most firms have fewer than ten that matter, including email, accounting, the phone system and the file store. An hour of honest labelling beats a 40-page document nobody has opened.
What this does not buy you
None of this prevents an outage, and no honest provider claims otherwise. A region will have a bad day, the service credit will be small, and the published percentage may still be met. What the work buys you is a documented position. You know which region each system sits in, whether it is zonal or zone-redundant, who performs the failover, which exclusions apply and who gets paged at 2am.
That is the difference between an outage and a crisis. One is a few hours of degraded service with a written branch to follow and an independent record of what the provider owes. The other is discovering at 9am that the continuity plan assumed something nobody ever wrote down.
FAQ
Does a cloud SLA cover my lost revenue?
No. A cloud service level agreement pays a service credit against your own bill, and Amazon writes that the agreement sets forth your sole and exclusive remedies. You must also request it, by the end of the second billing cycle after which the incident occurred. Lost revenue, idle payroll and missed deadlines sit outside the document entirely.
What is the difference between a cloud region and an availability zone?
A region is a set of datacentres in one metropolitan area, and an availability zone is a separated group of datacentres inside that region. Azure regions that support zones have at least three zones, usually within 100 kilometers of each other. Microsoft states that availability zones don't protect against a full-region outage, so zone redundancy is not regional redundancy.
Does Microsoft 365 ever miss its published uptime target?
Yes. Microsoft's own service description reports Microsoft 365 worldwide uptime of 99.526 percent in the first quarter of 2026, against 99.994 percent in the second quarter of 2026. Microsoft publishes that quarterly table itself, so you can check the record rather than trust a sales slide about nine nines.
How long does a regional cloud outage actually last?
Published cases run from a few hours to most of a day. Amazon's October 2025 Northern Virginia event started at 11:48 PM PDT on October 19 and ended at 2:20 PM PDT on October 20. An Azure post incident review records impact between 20:30 UTC on 30 September 2026 and 02:15 UTC on 1 October 2026. Use provider reviews rather than outage trackers.
Who is responsible for failing over to another cloud region?
You are. Amazon says customers are responsible for managing resiliency of your data including backup, versioning, and replication strategies. Microsoft says that for a zonal resource, you're responsible for failover to another zone. The provider supplies the capability and publishes the price, and your business decides whether to use it.
Best IT MSP is the independent directory of vetted managed IT and cybersecurity providers across North America. Organic ranking is earned on rating and verified data, and paid placement is always clearly labelled. Take these three questions to merit-ranked firms in your city and compare the written answers side by side.