PENTESTY · EDITORIAL ANALYSIS · · 5 min read
If a zone does not return: test recovery of your cloud dependencies
Distributing resources is only part of continuity. An exercise should show that data, permissions and alternate capacity let a business function resume.
By Pentesty
The incident and the timing of this review
Cyber Security Brazil reports the incident at Yandex’s Sasovo data center. In Yandex Cloud’s official history, an October 8 update links a fire to a UAV attack, reports the facility’s shutdown and ru-central1-b unavailability. Later entries recommend recovery alternatives. The consulted source does not establish who conducted the attack. This history is not a real-time measurement of the platform’s current availability.
Choose a function before designing the contingency
Choose a business activity, such as receiving orders or retrieving contracts. Record tolerable interruption, necessary information and who may approve an alternative. Define the outcome demonstrating recovery; starting a machine alone does not demonstrate that the business service has resumed.
Map authentication, storage, communication and administrative dependencies for that function. Our Microsoft 365 continuity analysis complements the exercise by distinguishing the visible service from the route used to reach it. Assign an owner and a testable hypothesis to each dependency so missing access does not become a surprise during the exercise.
Four forms of evidence for executable recovery
Begin in a controlled environment without shutting down a real availability zone. Use synthetic data, specific permissions and resources whose impact is authorized. Select one business activity and document what will count as success before attempting restoration or measuring its timing.
- Recoverable data: restore an authorized copy and check the records needed for the chosen activity. Evidence: copy origin and date, applicable integrity checks, limitations and acceptance by the data owner, without assuming a usable copy exists merely because a policy requires one.
- Independent access: use an exercise account to reach the destination and obtain only approved resources. Evidence: authentication, effective permissions, external dependencies and emergency-access handling, including expiry and review of exceptions rather than unrestricted privileges during a simulated disruption.
- Available capacity: verify resource requirements, procurement limits and conditions for activating the alternative. Evidence: capacity actually obtained during testing, observed time and decisions about reservations, rather than relying solely on a supplier estimate or a capacity figure recorded before the exercise.
- Operation and return: perform the simulated function at the destination and rehearse a controlled return. Evidence: business outcome, applied configuration, identified differences, an accountable decision owner and criteria to confirm consistency after recovery and before declaring the original function restored.
Redundancy needs explicit hypotheses
Document what each option intends to cover: a component failure, zone loss, administrative dependency or inability to obtain additional capacity. Yandex Cloud’s best-practice documentation recommends distribution and redundant resources. Pentesty’s proposal adds tests of the selected end-to-end workflow, without extending an architectural recommendation into a guarantee that recovery will succeed under every condition.
Compare the alternative’s cost and operational requirements with the consequences of interruption. A destination with wider permissions or unclear maintenance can introduce another exposure during a crisis. Our cloud configuration article helps include security in acceptance of the change, so an emergency operating path can be reviewed rather than silently becoming the permanent configuration.
The report should capture decisions as well as time
Show exercise conditions, resources used and the result of the business activity. Distinguish preparation, transfer, validation and release-to-operation time. State what was simulated and what was actually executed. Those distinctions support a discussion about capacity and priorities with the people accepting the consequences of unavailability, instead of presenting one recovery number without its assumptions.
The supplier dependency analysis offers another perspective on substitution. Retain recovery evidence and resolve uncertainties found in the exercise. A penetration test can assess digital controls within scope without guaranteeing physical availability or a provider’s operation.
Frequently asked questions
Are two zones sufficient for my application?
Define the failures your design intends to cover and test dependencies of the chosen activity. Approval should reflect the observed scenario, its limitations and the recovery process the team can actually execute under those conditions.
Does a backup demonstrate that the business can recover?
Request restoration and validation of the required function. Beyond the data, check access, tools, capacity and decisions. The outcome should show what was recovered and which steps remain untested or incomplete in the exercise.
Do we need to move to several providers?
Compare alternatives against business needs, operational capacity, information and required controls. This article proposes testing the selected route, without recommending a universal design or assuming a provider change reduces every dependency affecting the business activity.
How should a status page be used during investigation?
Record the update’s time and content and compare them with observed symptoms. Published history and current availability are different evidence. Use official context without treating an older record as a live monitor of the provider’s operation.
Sources and references
- Cyber Security Brazil: editorial news reference
- Yandex Cloud: ru-central1-b incident history
- Yandex Cloud: load balancing best practices
Original Pentesty analysis, published October 15, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.