Disaster recovery

Disaster recovery addresses how an organization restores technology services when their normal operating environment becomes unavailable or untrustworthy. Events include regional outages, accidental deletion, failed deployments, compromised credentials, and ransomware. It is part of business continuity, which also covers people, facilities, communications, and business processes. A disaster recovery plan must identify dependencies and recovery order: restoring an application server is insufficient if its database, identity provider, encryption keys, or network connectivity remain unavailable.

Begin with recovery time objective, or RTO, and recovery point objective, or RPO. RTO is the target maximum time to restore a service after disruption. RPO is the maximum acceptable data loss measured in time. For example, an order-processing application might require recovery within one hour and tolerate losing no more than five minutes of transactions. A daily backup alone cannot reliably meet that RPO; frequent backups, transaction-log capture, or replication would be needed. Actual recovery performance must be measured rather than inferred from a product feature.

Cloud recovery strategies range from backup and restore to pilot light, warm standby, and multi-site active-active deployments. Backup and restore generally has lower ongoing infrastructure costs but requires more rebuilding and data restoration. Pilot light keeps essential components available while other resources are deployed or scaled during recovery. Warm standby maintains a smaller functioning environment that can be expanded. Active-active deployments can reduce interruption but introduce costs and challenges around consistency, conflict resolution, routing, and operational coordination. None automatically guarantees zero downtime or zero data loss.

Availability Zones provide isolation within an AWS Region and help applications tolerate localized infrastructure failures. Multiple Zones do not provide protection against every Region-wide disruption. A secondary Region can provide geographic separation for recovery, but the application must have usable data, configuration, permissions, capacity, and recovery procedures there. Multiple Regions also support other goals, including lower latency for geographically distributed users and meeting jurisdictional requirements. These goals are distinct: copying data into another country for recovery can violate data-sovereignty restrictions unless the destination and processing arrangements are permitted.

Replication and backup solve different problems. Replication can make recent data available elsewhere, but it can also propagate corruption, unwanted changes, or encrypted files. Retained backups provide historical recovery points. For ransomware resilience, combine appropriately configured immutable retention with restricted deletion permissions, separate administrative boundaries, monitoring, and restore testing. Cross-account and cross-Region copies reduce different risks and are not interchangeable. Encrypt backups and replicated data, protect encryption keys from unauthorized use or deletion, and verify that recovery identities can decrypt the destination copies.

For example, an engineering team could centrally schedule database and volume backups, retain protected copies in a separate account, and copy supported backups to an approved recovery Region. It could also replicate critical servers to reduce recovery time. Infrastructure-as-code templates would recreate networks and application resources, while a runbook would specify database recovery, application validation, traffic redirection, and eventual failback. Recovery exercises should verify data integrity, application behavior, recovery duration, replication lag, quotas, and key access. A successful backup job is evidence that data was captured, not proof that the business service can be recovered.