Who this is for
Organizations where an outage is measured in consequences rather than in tickets. Emergency dispatch and 911 centres, police and fire communications, hospital operations, utilities and grid operations, and financial operations all sit in that category — but these are examples of the problem shape, not a restriction on who we work with. If your answer to “what happens if this is down for an hour?” involves something other than inconvenience, the work below applies.
Reliability targets, and the evidence behind them
A recovery time objective states how long restoration may take. A recovery point objective states how much data may be lost. Both are business decisions with engineering consequences, and both are worth less than nothing if they were never tested — an untested RTO is a number in a document that someone will discover is wrong during the incident.
Availability targets carry arithmetic that is worth doing out loud. A 99.99% target permits roughly 52 minutes 35 seconds of downtime a year. A 99.9% target permits roughly 8 hours 45 minutes. That order-of-magnitude gap is usually what decides the architecture.
One point is easy to get wrong and expensive to get wrong: a Microsoft SLA is not a reliability assurance for your application. Microsoft documents SLAs as commercial commitments about individual services, with credits when missed. Your application’s reliability is the composite of every dependency in its chain plus how your own code behaves when one of them fails. Several 99.9% services composed in series are less reliable than any single one of them.
Global routing and the fail-away path
Azure Front Door and Azure Traffic Manager solve different problems and fail differently. Front Door operates at the application layer with health probes, WAF and managed certificates at the edge; Traffic Manager operates at DNS, which means client-side and resolver caching sit between your failover decision and the user actually moving. That caching behaviour is the part most often missed in a design review, and it is the part that shows up as “we failed over but traffic did not”.
The API boundary
Tier selection at the API Management boundary has a consequence that reaches the network team. Per Microsoft’s documentation, instances in the Consumption, Basic v2, Standard v2 and Premium v2 tiers run on shared infrastructure and have no deterministic IP address — if a partner needs to allowlist you, the answer is Azure region IP ranges, not a single address. The classic Developer, Basic, Standard and Premium tiers do hold a static VIP for the life of the service, but Microsoft names the events that change it: recreating the instance, a lapsed and reinstated subscription, adding or removing a virtual network, moving subnets, enabling or changing availability zones, and vacating then reinstating a region in a multi-region deployment.
Premium v2 is generally available with full virtual network injection and availability-zone support. Its injection subnet must be dedicated to the instance, with a minimum of a /27 and a recommended /24 to leave room to scale. Premium v2 currently scales to 30 units.
State and correctness when the failover happens
Most failover damage is not caused by the failover. It is caused by what the application does during it — retries without idempotency producing duplicate work, queues draining into a half-available backend, a replica promoted before it caught up. Designing for this means idempotent operations, bounded retries with backoff, queue-based load levelling to absorb the surge, replication choices made deliberately, and an explicit recovery sequence so components come back in an order that does not overwhelm what just returned.
Observability, and knowing you are healthy
A health model is the difference between “the service responds” and “the service is doing its job”. It defines a known-healthy state in terms a human agreed to, instruments it through Azure Monitor, alerts on departures from it, integrates with Microsoft Sentinel where security and availability signals overlap, and names who owns the response. Runbooks are part of the architecture, not paperwork after it.
Landing zone and compliance
Azure Landing Zones and policy-as-code make resilience properties enforceable rather than aspirational — a zone-redundant requirement that policy will not let you violate survives staff turnover in a way a design document does not. Compliance frameworks are mapped to the controls that implement them. EPC Group names the frameworks an environment is designed against and does not claim certifications it does not hold.
Proving it: drills, chaos and evidence
This is the part that separates a resilient system from a system described as resilient.
Azure Chaos Studio injects controlled disruption — shutting down virtual machines, forcing database failovers, blocking DNS resolution. Its newer Workspaces and Scenarios experience discovers resources in scope and offers prebuilt outage patterns including Compute Zone Down, DNS Outage and Microsoft Entra ID Outage, producing a scenario report after each run.
Which model you should run is a genuine trade-off, and the sales-friendly version of the answer is wrong in both directions. Workspaces and Scenarios are in public preview — Microsoft states the preview carries no SLA and is not meant for production use, and names “you require a generally available service” as a reason to stay on the classic model. At the same time, Microsoft describes that classic model as a legacy model with no further feature development, where only critical fixes such as security updates are considered for backport. So the GA path is the one that is frozen, and the path receiving investment is the one you should not point at production yet.
Microsoft documents running both together, and that is what we do: workspaces for the common outage patterns the scenario catalog covers, in non-production; classic experiments where production is in scope, where you need dynamic targeting or scheduled runs, or where the fault you need is not in the catalog. The transition is planned rather than discovered later.
Infrastructure Resiliency Manager (preview) adds at-scale zone-resiliency posture across an estate, zonal goals and recommendations against service groups with cost and downtime insight, Availability Zone Down Drills that inject faults, fail over, reprotect and record run history with notes and attestation, and recovery orchestration plans for zonal failover. Its Resiliency agent in Azure Copilot can generate ARM or Bicep remediation — it proposes, it does not apply. Microsoft released these capabilities in June 2026; access to the agent requires tenant allowlisting.
EPC Group runs these for clients as part of the assessment rather than handing over a tool and a hope. The output that matters is the drill record.
How an engagement runs
- Reliability targets. Establish the RTO and RPO the business will actually stand behind, per workload rather than per platform, and convert them into an availability target with its arithmetic shown. Enumerate the dependency chain and the failure modes that threaten each target.
- Failure-mode analysis. Walk each dependency and ask what happens when it is gone: a zone, a region, DNS, the identity provider, a database primary, a message broker. Record the expected behaviour and the observable signal for each, because a failure nobody can see is a failure nobody will act on.
- Architecture and fail-away. Global routing, API boundary, state replication and recovery sequencing designed so that failing away is deterministic rather than heroic. Every decision recorded with the trade-off it accepted.
- Drill and evidence. Take the zone away and measure. Produce drill records, run reports and recovery-sequence runbooks that stand up as compliance evidence and as the honest answer to "when did you last prove it?"
Where to start
The Azure Mission-Critical Resilience Assessment is a fixed-scope diagnostic: a Well-Architected mission-critical review, EPC Group’s failure-mode analysis across your dependency chain, and a drill evidence pack you can hand to an auditor. Scope is agreed in a discovery session and fixed in a written Statement of Work before work begins.
Talk to an architect · Azure cloud services · Azure governance · Azure observability
Frequently asked questions
What does mission-critical mean for an Azure architecture?
It means the architecture carries a stated recovery time objective and recovery point objective, the failure modes that threaten them have been enumerated, and the recovery path has been exercised rather than assumed. A design is not mission-critical because it uses availability zones; it is mission-critical when someone has taken a zone away and measured what happened.
Does a Microsoft SLA guarantee my application stays up?
No. A service-level agreement is a commercial commitment about an individual Azure service, with financial credits when it is missed. It is an engineering input to your reliability model, not an assurance about your application, which depends on every dependency in its chain and on how your own code handles failure. A composite of several 99.9% services is less reliable than any one of them.
How much downtime does 99.99% actually allow?
About 52 minutes and 35 seconds per year, or roughly 4 minutes 23 seconds per month. The arithmetic matters because the gap between 99.9% and 99.99% is the difference between about 8 hours 45 minutes and under an hour of annual downtime — and that gap usually decides the architecture, not the other way round.
Can I allowlist a fixed outbound IP for Azure API Management?
It depends on the tier. Consumption, Basic v2, Standard v2 and Premium v2 run on shared infrastructure and have no deterministic IP address, so allowlisting is done by Azure region IP ranges instead. The classic Developer, Basic, Standard and Premium tiers hold a static VIP for the life of the service, but Microsoft documents specific events that change it — recreating the instance, adding or removing a virtual network, enabling availability zones, or vacating a region in a multi-region deployment.
What evidence proves an Azure environment is actually resilient?
Drill records. A zone-down drill that injects a real fault, fails the workload over, reprotects it, and produces a run report with per-resource downtime is evidence. Architecture diagrams and SLA percentages are not — they describe intent. The distinction matters most in regulated and public-safety settings, where an auditor asks when you last proved it, not whether you designed for it.
Is Azure Chaos Studio ready for production use?
Partly, and the honest answer has two halves. The classic experiments model is generally available and is the path Microsoft points to when you require a GA service — but Microsoft also describes it as a legacy model with no further feature development, where only critical fixes such as security updates are considered for backport. The newer Workspaces and Scenarios experience is where the investment is going, but it is in public preview, carries no SLA, and Microsoft states it is not meant for production use. Microsoft documents running both together, and that is what EPC Group does: workspaces for the common outage patterns in non-production, classic experiments where production is in scope or the fault is not in the scenario catalog.
Azure capability statements on this page were verified against Microsoft Learn on 2026-08-19. Features described as preview were in public preview on that date and may change. Preview features carry no service-level agreement.