Your recovery copies live in separate regions. The architecture diagram shows multiple paths. Replication is running.
Now assume the identity used to administer those paths is compromised.
Which options can your team still use? Which copies can the attacker alter? Which recovery decisions depend on keys, permissions or services that may be unavailable?
Those questions require a recovery topology: a view of how production, protection and recovery are connected, including the dependencies behind each path. Location is one part of that view. Authority, freshness and verification matter too.
What should a recovery topology include?
Start with a business service and work outward. For a payments service, identify its critical database, the protection mechanisms attached to it, and the resources required to return that service to an acceptable operating state.
The topology should answer:
| Element | What to establish | Decision it supports |
|---|---|---|
| Service requirement | Owner, criticality, RPO and RTO | What the recovery path must achieve |
| Source and destination | Resource IDs, accounts, regions and provider | Which disruption each path addresses |
| Protection mechanism | Read replica, snapshot, retained backup or another mechanism | What type of recovery the option supports |
| Freshness | Replication mode, schedule, observed lag or recovery-point timestamp | Whether the option fits the data-loss target |
| Administrative authority | Identities able to change protection, delete copies or initiate recovery | What survives compromised access |
| Encryption dependencies | Keys, key policy, ownership and required grants | Whether retained data remains accessible |
| Recovery evidence | Test date, scope, conditions and measured result | What has actually been demonstrated |
Record the observation time and missing data alongside the answer. An unresolved dependency should remain visible rather than appearing as a confirmed safe path.
Begin with the RDS question, then follow the dependencies
For an important Amazon RDS database, ask:
What is the replication topology? Show source, target, replication mode or frequency, current lag, and encryption for each relationship.
Be precise about the protection mechanism. RDS read replicas use asynchronous replication; a replica’s observed lag is a different measurement from the age of a retained backup. AWS documents both the replication model and monitoring through the ReplicaLag metric, whose interpretation depends on the database engine.
For a scheduled copy, ask for the configured frequency, most recent successful completion and latest usable recovery point. For an asynchronous replica, ask for current status, lag history and whether the measurement is available and meaningful.
Next, inspect the permissions and keys supporting each option. AWS documents destination-region KMS keys for encrypted cross-region RDS read replicas. Distinct regional key resources do not, by themselves, establish independent administration; that requires a review of who can manage or use them.
The useful answer connects these facts to the service requirement. A label such as “cross-region enabled” cannot do that on its own.
Evaluate independence against a named scenario
A path can be useful under one failure and inadequate under another. Review the same topology through several explicit assumptions:
- Regional disruption: Can the destination operate without the unavailable region’s dependencies?
- Privileged identity compromise: Which production and recovery resources are reachable through that identity?
- Unwanted data change: Which retained recovery point predates the change, and what evidence supports its use?
- Recovery-access disruption: Can authorized responders access the necessary destination and keys?
A replica follows changes from its source. It should not automatically be treated as a substitute for an earlier retained recovery point. Similarly, a separate account should prompt an access review rather than an assumption that all authority is isolated.
For an AI-assisted attack scenario, ask what the acquired privileges allow and which protection changes would remove viable options. The architectural question remains concrete: what survives the assumed compromise?
Worked example: a path can meet one requirement and miss another
Consider this hypothetical review. The values illustrate a decision process, not a Forttic customer result or a recommended design.
The service owner has approved a 15-minute RPO and a two-hour RTO.
| Observed option | Evidence available | What the review can conclude |
|---|---|---|
| Cross-region read replica | Observed lag is 4 minutes; the same privileged administrative route reaches both regions | Freshness looks promising for that observation, but administrative independence is not established |
| Retained backup in a separately administered account | Latest usable point is 6 hours old | It may address an access-compromise scenario, but that point misses the 15-minute data-loss target |
| Previous database restore test | Resource restoration took 70 minutes; application validation was excluded | Database restoration has evidence; the two-hour business-service target remains unproven |
The first action depends on the scenario and the alternatives that remain. Improving backup frequency, separating authority and expanding validation address different gaps.
This is why a single “protected” flag is too coarse for a service-level decision. Preserve the specific findings, then group them around the service and the action required. If the next conversation turns to buying another system, diagnose the gap before changing the stack.
Choose the change and define its proof
A topology review should produce a decision record containing:
- The service requirement and failure assumption.
- The current options and shared dependencies.
- The gap, its impact and remaining uncertainty.
- The proposed change, owner and approval boundary.
- The verification criterion and review trigger.
For example, if the concern is shared administrative authority, define how the intended separation will be checked and how authorized recovery access will be demonstrated. Another successful backup job would not answer that question.
Use tests proportionate to the claim. AWS Backup offers automated restore testing and optional validation, which can supply useful evidence within its supported scope. A resource restore result still needs to be interpreted against the service outcome being claimed.
Where Forttic fits
Forttic’s CRE framework connects discovery, assessment, guarded action, verification and reporting. Applied to a topology review, that means relating observed protection to service requirements and keeping the resulting decisions tied to evidence.
Work with the existing cloud and backup systems. Confirm the supported integrations, permissions and verification scope for the environment being assessed. The objective is a defensible answer to a specific recovery question across the connected estate.
For the operating discipline behind that work, see ResOps Needs an Enforcement Layer.
Start with one critical service
Choose the service whose recovery you would need to explain during an incident. Map its destinations, authority and evidence. Then ask which decision changes when a shared dependency is unavailable.
Start the free CRE assessment to review your operating maturity and identify a next step. The questionnaire is a maturity snapshot, not a scan or technical validation of your connected estate.
Location is not the whole path
Separate regions can reduce exposure to a regional disruption. Authority, keys and the last relevant test still decide whether that path is usable.
Frequently asked questions
What is recovery topology?
Recovery topology is a map of a workload’s protection and recovery relationships, including sources, destinations, copies, replication and the identities, keys and other dependencies needed to use them.
Does cross-region replication guarantee recovery isolation?
No. Regional separation addresses location-related risks. Administrative authority, encryption access and other dependencies must also be reviewed against the failure scenario.
Is an RDS read replica the same as a retained backup?
No. A read replica follows source changes through replication. A retained backup provides a recovery point with its own retention and restoration characteristics. Their suitability depends on the recovery requirement.
What evidence should a topology review request?
Request current source and destination records, replication or copy freshness, relevant access and key policies, and dated recovery-test results. Include the scope and limits of each record.
How often should recovery topology be reviewed?
Use service criticality and change to determine the cadence. Changes to accounts, replication, permissions, keys or recovery procedures should trigger a review of affected assumptions and evidence.