Cloud Regions and Availability Zones

A cloud region is a geographic area in which a provider operates data centres, and an availability zone is a distinct location within a region, separated so that a failure in one zone need not affect another. Placing a service across zones within a region can therefore absorb a failure confined to a single location, while placing it across regions can absorb a wider failure affecting a whole area. Neither arrangement is resilience by itself. What matters under DORA is whether the placement of a specific service, its data, and its dependencies allows that service to keep running or to recover within its tolerance when a localised failure occurs. A diagram showing zones is not evidence. A recovery sequence that uses those zones, tested for the service in question, is closer to evidence.

Zones and regions protect against different kinds of failure, and confusing them is a common source of false comfort. A zone protects mainly against a failure in one facility or its immediate supporting systems, such as power or cooling for that location. A region protects against a broader failure that affects several locations together, or against a need to operate from a different geographic area altogether. A service spread across zones in a single region may survive a zone failure yet still be lost if the region itself is affected. Conversely, a service spread across regions may survive a regional failure yet fail if its data, identity service, or supporting component exists in only one region. Placement decisions therefore need to follow each dependency, not only the main application.

Card authorisation offers a clear illustration. A customer presenting a card expects a prompt decision, and the service behind that decision involves an authorisation engine, a fraud checking component, and a record of the transaction. If the authorisation engine runs across zones but the fraud component runs in a single zone, a zone failure affecting that component can still block authorisation, even though the headline application appears resilient. If transaction records are written to a store that replicates slowly to another region, recovery in a second region may produce an incomplete picture of recent authorisations. The service view, tracing every component that must work for a decision to be made and recorded, reveals these weak links. The provider view, showing that a platform spans zones, does not.

Data placement adds a further layer that is easy to overlook when the focus is on computing capacity. Data may be stored in one region, copied to another for backup, and processed in a third through an analytics or support tool. Each location raises questions about availability during recovery, about the freshness of a copy used for recovery, and about the legal and contractual position of data held there, which is treated separately in this cluster. A recovery plan that restores computing in a new region but cannot reach current data, or cannot reconcile data written during the disruption, has restored a platform without restoring a service. Recovery therefore needs to be rehearsed with data included, not assumed from storage settings.

Failover is where placement promises are tested, and where they often disappoint. Automatic failover can move traffic quickly, but it can also move traffic to a location that lacks current data, a configuration change, or a dependent service. Manual failover can preserve control, but it depends on people, decisions, and provider actions being available during a disruption. Either approach needs a defined trigger, a named decision maker, and a rehearsed sequence, so that the move between zones or regions is a practised operation rather than an improvisation. A firm that has never failed a service over in a test cannot know whether its placement design works. It knows only that the design was drawn.

Placement choices also carry cost, complexity, and concentration effects that deserve honest treatment. Running actively in more than one region can improve resilience while increasing operational complexity, data synchronisation work, and the number of components that must be monitored. Running passively in a second region can reduce cost while leaving recovery dependent on activation steps that may not have been rehearsed. The right balance depends on the service, its tolerance, and the harm caused by its loss, rather than on a general preference for more regions. DORA asks, in effect, for placement to be justified service by service, with the reasoning recorded and the recovery sequence tested. A placement that cannot be explained in those terms is a preference, not a resilience decision.