India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
AWS Backup & Disaster Recovery Services: Mumbai to Hyderabad
AWS Backup and Disaster Recovery is the combination of AWS Backup for policy-driven, immutable backups and AWS Elastic Disaster Recovery for continuous server replication and fast failover. NTSPL designs and tests these for Indian organizations, replicating from on-premises or Mumbai (ap-south-1) to Hyderabad (ap-south-2) with vault locks, documented RPO and RTO per application, and quarterly recovery drills.
AWS services in scope
The Problem AWS Backup and AWS Backup Vault Lock Solve
Most Indian organizations we assess have backups but not recovery. Nightly jobs report success, yet nobody has restored the HIS, ERP or MES database end to end in the last twelve months, and the recovery runbook still names a server that was decommissioned. Ransomware has changed the stakes: attackers now locate and delete backup catalogues and snapshots before encrypting production, often using the same domain admin or AWS root credentials. A backup that sits in the same account, under the same administrators, with deletion allowed, is not a recovery strategy.
NTSPL starts from recovery objectives per application, not from tools. We classify each system into RPO and RTO tiers, then choose between AWS Backup schedules, continuous replication with AWS Elastic Disaster Recovery, or database-native replication. Backups land in a separate backup account, locked with AWS Backup Vault Lock in compliance mode and copied to Hyderabad. Every plan ends with a timed drill: we fail over, measure actual RTO, and fail back.
When AWS Backup and Elastic Disaster Recovery Fit Your Recovery Targets (and When They Do Not)
Signals that point to backup & disaster recovery on AWS
- Your last full end-to-end restore test was more than 12 months ago, or has never been timed.
- Backups and production share the same AWS account or the same Active Directory admin group.
- A business continuity plan or regulator (RBI, SEBI CSCRF, IRDAI, NABH for hospitals) requires a documented DR site and periodic drills.
- You operate a secondary data centre for DR that costs more than INR 40 lakh a year and is barely used.
- Ransomware hit a peer in your sector and the board asked how long you would take to recover.
- Retention obligations of 7 to 10 years exist for records, but current backups are on tapes nobody can restore.
When a different approach is better
- If an application needs zero data loss and near-zero downtime across Regions, server replication is not enough; use database-native active-active or synchronous designs such as Aurora Global Database for low-RPO reads, or DynamoDB global tables, and accept the cost.
- If workloads are fully SaaS (Microsoft 365, Salesforce), AWS Backup does not protect them; use a SaaS backup product, optionally storing its output in S3 with Object Lock.
- If a system is a short-lived, fully reproducible container fleet defined in code, replicating servers adds cost without value; rebuild from pipelines in Hyderabad and protect only state and images.
Recovery Building Blocks: AWS Backup Vault Lock, Elastic Disaster Recovery and S3 Object Lock
| Service | Role in the architecture | Choose it when |
|---|---|---|
| AWS Backup | Centralizes backup plans, schedules, retention and lifecycle for EBS, EC2, RDS, Aurora, DynamoDB, EFS, FSx, S3 and VMware workloads, applied across accounts through AWS Organizations backup policies. | Backups are configured service by service or script by script, and you cannot show auditors one report of what is protected and for how long. |
| AWS Backup Vault Lock | Applies a write-once-read-many policy to a backup vault; in compliance mode, after a grace period of at least 72 hours, no user including the root user can delete recovery points or shorten retention. | Your ransomware threat model assumes an attacker may obtain administrator credentials in the AWS account holding backups. |
| AWS Backup logically air-gapped vault | Stores immutable copies of supported resource types in a vault isolated from your account's administrators, which can be shared to a clean recovery account through AWS RAM for restore. | You need an isolated recovery copy for a scenario where the whole production account or organization is compromised. |
| AWS Elastic Disaster Recovery | Continuously replicates block-level changes from on-premises, other-cloud or EC2 source servers into a low-cost staging subnet in the target Region, and launches recovery instances from point-in-time snapshots. | An application needs an RPO measured in seconds and an RTO under an hour, and rebuilding from nightly backups would take most of a day. |
| Amazon S3 Object Lock | Enforces WORM retention on S3 object versions in governance or compliance mode, plus indefinite legal holds independent of retention periods. | Records such as documents, scans, audit logs or exports must be provably unaltered for a defined period or until a dispute is closed. |
| S3 Cross-Region Replication and AWS Backup cross-Region copy | Copy objects and recovery points from ap-south-1 to ap-south-2 automatically, keeping a second in-country copy over 600 km away on a different seismic zone and power grid. | A Mumbai-wide event must not take out both production and backups, and data residency rules require the second copy to stay in India. |
Mumbai production to Hyderabad recovery with isolated, locked backup vaults
Mumbai production to Hyderabad recovery with isolated, locked backup vaults
Production servers in Mumbai or on-premises stream block changes through Elastic Disaster Recovery to a staging subnet in Hyderabad, while AWS Backup plans snapshot databases and file systems into a locked vault in a separate backup account. Recovery points are copied cross-Region to Hyderabad, and on declaration the runbook launches recovery instances and repoints DNS.
Select any component
Mumbai production to Hyderabad recovery with isolated, locked backup vaults: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
DR Engineering Decisions: RPO and RTO Tiers, Immutability Mode and Cross-Region Copy Design
RPO and RTO tiers mapped to mechanisms
We use three tiers. Platinum, RPO under 1 minute and RTO under 1 hour, uses Elastic Disaster Recovery or database replication such as RDS cross-Region read replicas. Gold, RPO 1 hour and RTO 4 hours, uses hourly AWS Backup with cross-Region copy and pre-staged infrastructure as code. Silver, RPO 24 hours and RTO 24 hours, uses daily backups only. Putting every server in platinum typically triples DR spend; most estates end up with 10 to 20 percent of servers in that tier.
Governance versus compliance mode immutability
Vault Lock and S3 Object Lock both offer governance mode, where privileged users with a specific permission can bypass retention, and compliance mode, where nobody can. Compliance mode on a vault becomes irreversible once the grace period, minimum 72 hours, expires, so we always run governance mode or a short grace period first and confirm retention values. A typo setting 3,650 days instead of 365 in compliance mode means paying to store that data for ten years with no way out.
Elastic Disaster Recovery versus pilot light from backups
Elastic Disaster Recovery suits stateful, hard-to-rebuild servers such as Windows HIS application servers, legacy MES or ERP boxes, where the replication agent captures OS, application and data together. For cloud-native stacks built from Terraform and AMIs, a pilot light of infrastructure code plus AWS Backup copies is cheaper because you pay only for storage. The breakpoint is usually RTO: if the business accepts four hours or more, pilot light wins on cost.
Cross-Region copy and key design
Cross-Region copies need a KMS key in Hyderabad, so we create backup-account keys in both Regions or a multi-Region key. Copy jobs are charged for inter-Region data transfer per GB, so we copy gold and platinum tiers daily and silver weekly. For databases above a few terabytes, incremental snapshot copies keep transfer manageable, but the first full copy needs to be scheduled outside business hours and monitored.
Failback is part of the design
Teams test failover and forget failback. Elastic Disaster Recovery supports failback to on-premises or back to Mumbai by reversing replication, but the original source must be reachable and running the failback client or agent. We document the reverse path, network routes and DNS TTLs, and set Route 53 TTLs to 60 seconds on records that move during failover so client caches do not extend the outage.
How NTSPL Builds and Proves a Mumbai-to-Hyderabad Recovery Plan
Application recovery tiering
Interview application owners and agree RPO, RTO and retention for every system, recorded in a signed tiering register that drives all later configuration.
Backup account and locked vaults
Create a dedicated backup account, KMS keys in Mumbai and Hyderabad, and vaults with Vault Lock in governance mode, converting to compliance mode after retention values are confirmed.
Organization backup policies and tagging
Publish backup policies by tier through AWS Organizations and enforce backup-tier tags with a Config rule so untagged resources surface within a day.
Elastic Disaster Recovery replication
Install agents on platinum servers, size the staging subnet in Hyderabad, throttle bandwidth on thin links and wait for initial sync before configuring launch templates.
Recovery VPC and runbooks
Pre-deploy the Hyderabad VPC, connectivity and DNS failover records in Terraform, and write a per-application runbook with launch order and validation checks.
Timed drill and evidence pack
Run a non-disruptive drill, measure actual RPO and RTO per application, fix gaps, then repeat quarterly with AWS Backup restore testing between drills.
What you receive
Ransomware-Resistant Recovery: Vault Lock, Air-Gapped Vaults and Separate Backup Accounts
The adversary in backup design is a ransomware operator with your admin credentials. They delete snapshots, disable backup jobs, and schedule KMS key deletion so recovery points become unreadable. The defence is separation: backups owned by a different account, encrypted with keys that account controls, locked against deletion, and an isolated copy that no production identity can touch. Detection matters too: deleting recovery points should page someone immediately.
- Vault Lock compliance mode so recovery points cannot be deleted before retention ends, even with root credentials
- Backup-account KMS keys with key policies denying ScheduleKeyDeletion except to a break-glass role
- SCP denying backup:DeleteBackupVault and backup:DeleteRecoveryPoint across workload OUs
- Logically air-gapped vault copies restorable into a clean recovery account via AWS RAM
- EventBridge alarms on failed jobs, disabled plans and Elastic Disaster Recovery replication lag above 5 minutes
Backup and DR Pricing: Warm Storage, Cross-Region Copy, Staging Servers and Restore Charges
Backup cost is storage-dominated: AWS Backup bills per GB-month for warm and cold storage by resource type, plus cross-Region copy data transfer and, for some types, restore charges. Elastic Disaster Recovery bills per replicating source server per hour, plus staging EBS, snapshots and replication server instances; full recovery instances cost money only when launched. Recovery speed is bounded by snapshot hydration and replication bandwidth, not just by compute.
- Transition long-retention recovery points to cold storage after 90 days for supported resources such as EBS and EFS
- Copy only gold and platinum tiers cross-Region daily; silver weekly
- Keep Elastic Disaster Recovery for platinum servers and use pilot light for the rest
- Set point-in-time snapshot retention in Elastic Disaster Recovery to days needed, not the maximum
- Use S3 Intelligent-Tiering or Glacier Deep Archive for Object Lock records retained for years
AWS Elastic Disaster Recovery vs AWS Backup vs a secondary data centre: which DR approach fits?
Decide by RTO, rebuild complexity and fixed cost. Elastic Disaster Recovery gives an RPO of seconds and an RTO typically in minutes to under an hour for servers, at a per-server hourly fee plus staging storage; use it for stateful legacy servers that are slow to rebuild. AWS Backup with cross-Region copy and pre-built infrastructure code gives an RPO of an hour to a day and an RTO of several hours, at storage-only cost; use it for cloud-native or less critical systems. A secondary data centre gives full control and works for OT systems that cannot leave the plant, but carries fixed hardware, power and licence costs whether you fail over or not. Most Indian mid-size enterprises we work with retire the DR data centre and run a mix of the first two.
Key facts about backup & disaster recovery on AWS
Backup & Disaster Recovery on AWS in Practice
3 backup & disaster recovery scenarios from Healthcare (multi-specialty hospital), Manufacturing (integrated steel), Legal services: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
Steel plant gets ransomware-ready MES recovery with air-gapped AWS copies
Law firm puts 11 years of matter files under S3 Object Lock legal holds
Cement manufacturer adds HANA high availability and Hyderabad DR to S/4HANA on AWS
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Backup & Disaster Recovery on AWS: Frequently Asked Questions
What does AWS disaster recovery cost for 30 servers?
For 30 platinum-tier servers with about 6 TB of total disk, Elastic Disaster Recovery typically costs INR 1.5 to 2.5 lakh per month, covering the per-server fee, staging EBS, snapshots and replication servers. Moving 20 of those servers to pilot light with AWS Backup often brings the total under INR 1 lakh per month. Drill costs are extra but small because recovery instances run only for hours.
Can we use AWS as the DR site for our on-premises data centre?
Yes, and this is the most common starting point. Elastic Disaster Recovery replicates physical servers, VMware and Hyper-V VMs from your data centre to Mumbai or Hyderabad over the internet or Direct Connect. You need outbound TCP 443 and 1500 from source servers, and enough bandwidth for daily change rates; we measure change rate in week one to size the link.
Is Hyderabad far enough from Mumbai for disaster recovery?
For most regional disaster scenarios, yes. The two AWS Regions are over 600 km apart, on separate power grids and in different seismic and flood zones, and each has multiple Availability Zones. Using both keeps all copies inside India, which helps with DPDP Act obligations and sector regulators' data localization expectations, such as RBI's payment data storage rules.
Does Vault Lock protect us if our AWS root account is compromised?
Vault Lock in compliance mode does: once the grace period ends, nobody, including the root user, can delete recovery points or shorten retention. An attacker could still try to schedule deletion of the KMS key, which is why NTSPL keeps backup keys in a separate account and adds a logically air-gapped vault copy for supported resources.
How often should we run DR drills, and do they disrupt production?
Quarterly for platinum systems and at least annually for the rest. Elastic Disaster Recovery drills launch recovery instances in an isolated subnet in Hyderabad while replication continues, so production is not touched. We run application smoke tests, record timings and terminate the drill instances, usually within a four-hour window.
How does this help with CERT-In and DPDP breach obligations?
Immutable, tested backups shorten the time from incident to recovery and give you evidence for reports. CERT-In's six-hour reporting rule applies to ransomware, and the DPDP Act expects reasonable safeguards including the ability to restore personal data. Restore testing reports and drill results document that capability.