Disaster recovery plan template for a startup on AWS, with RTO and RPO.
Most seed and Series A startups on AWS need one thing from a disaster recovery plan: backups outside the production account that whoever breaks into it can't delete, and that have been restored on purpose. On our illustrative stack that costs about $16 a month. Below: a disaster recovery plan template to copy, RTO and RPO in plain words, the four AWS strategies priced, and the quarterly restore test.
Facts and prices checked: 31 Oct 2026, us-east-1 and us-east-2, on-demand list prices
Illustrative. The stack is the seed SaaS from our AWS cost guide: three Fargate tasks, a load balancer, one NAT gateway and a Multi-AZ Postgres database, about $294 a month.
How much does disaster recovery on AWS cost a small team?
From about $16 a month for locked backups in a separate account to about $310 for a second Region serving traffic, on our illustrative $294 stack. Most teams of 2 to 15 engineers need only the first.
| AWS DR strategy | What runs in the second Region | Planning RTO / RPO for this stack | Added per month |
|---|---|---|---|
| Backup and restore, done properly | Nothing. Locked backup copies in a separate account. | 2 to 6 hours / up to 24 hours | $15.96 |
| Pilot light | A database replica. App servers defined in code but off. | 30 to 90 minutes / minutes | $69.31 |
| Warm standby | A small, working copy of everything | 10 to 30 minutes / minutes | $171.87 |
| Multi-site active/active | A full copy serving traffic | Near zero / near zero for a Region loss | about $310 |
The RTO and RPO ranges are our planning numbers for a rehearsed setup of this size, not AWS figures; your first restore test replaces them. Section 05 shows the cost lines.
Our default for 2 to 15 engineers: Multi-AZ in your main Region, backup and restore done properly, a restore test every quarter, and the plan written down. Move to pilot light when a contract or a security review asks for recovery in under a few hours.
RTO vs RPO: what's the difference?
RTO is how long you can be down. RPO is how much recent data you can lose, measured in time. AWS's disaster recovery whitepaper defines them like this. Recovery Time Objective (RTO) is "the maximum acceptable delay between the interruption of service and restoration of service". Recovery Point Objective (RPO) is "the maximum acceptable amount of time since the last data recovery point".
An RTO and RPO example: the database dies at 14:00, you restore the 02:00 snapshot by 17:00: RTO three hours, RPO twelve.
| RTO vs RPO | RTO | RPO |
|---|---|---|
| The question it answers | How long until customers can use it again? | How much data, measured in time, can we lose? |
| What shortens it | Infrastructure as code, runbooks, rehearsal, standby capacity | More frequent backups, point-in-time recovery, replication |
| On RDS, out of the box | However long a restore takes you; test it | About five minutes inside the Region, from point-in-time recovery |
How do you choose RTO and RPO targets at seed or Series A?
Pick one number per system, not one for the company, and start from what you've already promised: read your contracts and terms of service for uptime commitments first. A recovery target looser than a contract is a gap a reviewer will find. Then sort systems into three tiers. These starting targets are our suggestion, not a standard:
| Tier | Typical systems | Starting RTO | Starting RPO |
|---|---|---|---|
| 1. Customers can't work | Production database, API, login, file uploads | 4 hours | 15 minutes in-Region, 24 hours if the Region is lost |
| 2. Annoying, not fatal | Background jobs, search index, admin panel, email sending | 24 hours | 24 hours, or rebuild from tier 1 |
| 3. Rebuild from code | Caches, staging, preview environments, CI runners | 1 week | None. Don't back it up. |
Weigh each target against what it costs to meet. AWS's whitepaper puts it plainly: if the recovery strategy costs more than the failure or loss it prevents, "the recovery option should not be put in place unless there is a secondary driver such as regulatory requirements." A customer contract is the other common driver.
Sources: AWS post-event summary, Oct 2025, The Register on Codefinger, RDS: deleting a DB instance, RDS point-in-time restore, RDS retention, 1 to 35 days.
What disasters should a startup's recovery plan cover?
Deleted databases, bad migrations, leaked keys, Region outages and vendor outages. What a small team on AWS really faces is more often a person, a script or a stolen key than a fire. The ones to plan for:
| Scenario | What saves you | What doesn't |
|---|---|---|
| A bad migration or script corrupts data | RDS point-in-time restore to a minute before the change, into a new instance, then copy the damaged rows back | Multi-AZ or a read replica: both copy the damage within seconds |
| Someone deletes the production database | Deletion protection, so it can't happen. Retained automated backups or a recent manual snapshot if it does. | Automated backups, if "retain" wasn't chosen when the instance was deleted |
| Leaked keys, ransomware, a hostile insider | Copies in a separate AWS account, in a vault nobody can empty early | Snapshots in the same account: whoever can delete the database can usually delete them too |
| A whole Region degrades for hours | A recovery plan for a second Region, or a decision, written down in advance, to wait it out | A plan that depends on launching new capacity in the affected Region |
| A vendor you depend on is down | Knowing which vendors you depend on, their status pages, and what you tell customers | Anything inside your AWS account |
Deleted databases. Delete an RDS instance without retaining automated backups and "RDS deletes the automated backups that reside in the same AWS Region", AWS's docs say, for good. Manual snapshots survive.
Bad migrations. RDS uploads transaction logs every five minutes, so you can restore to any point in your retention period (1 to 35 days) as a new instance, if someone knows how under pressure.
Leaked keys and ransomware. In January 2025, The Register reported Halcyon's research on a group called Codefinger that used exposed AWS keys to re-encrypt S3 objects with customer-provided keys (SSE-C) and set them to be deleted within seven days. Locked copies in another account survive that.
Region outages. AWS's summary of the October 2025 DynamoDB event in us-east-1 runs from 11:48 PM PDT on 19 October to 2:20 PM PDT on 20 October, about 14.5 hours. New EC2 launches failed while instances already running stayed healthy, ECS and Fargate saw container launch failures, IAM users saw console sign-in failures, and customers with IAM Identity Center in us-east-1 couldn't sign in through it. Capacity already running beats capacity you plan to launch, and break-glass access must not depend on normal sign-in.
What are the four AWS disaster recovery strategies?
Backup and restore, pilot light, warm standby and multi-site active/active. AWS's whitepaper sorts DR into these four approaches, from cheap backups to multiple active Regions. If your disaster is the loss of one data centre, a well-built, highly available workload "may only require a backup and restore approach". The other three plan for losing a Region.
| Strategy | How it works | The catch |
|---|---|---|
| Backup and restore | Copy backups to another account and Region; keep all infrastructure in code so you can rebuild anywhere. | Without infrastructure as code, AWS warns, restoring in a new Region can exceed your RTO. |
| Pilot light | Data replicates to the second Region. Core infrastructure is there; app servers are defined but off. | Replication copies corruption too, so you still need point-in-time backups. |
| Warm standby | A scaled-down, working copy of production runs in the second Region. | You run and patch a second environment all year. |
| Multi-site active/active | Both Regions serve users. There's no failover, only traffic moving away from a failed Region. | The most complex and costly option, AWS says, and corruption still needs backups. RDS for PostgreSQL replicas in other Regions are read-only until promoted, so writes happen in one Region. |
Backup and restore vs pilot light vs warm standby.
Backup and restore keeps nothing running in the second Region. The whitepaper's test for pilot light vs warm standby: pilot light "cannot process requests without additional action taken first"; warm standby serves traffic at reduced capacity immediately. It also recommends a separate account per Region "in the case compromised credentials are part of your disaster recovery plans", and failing over with data-plane operations such as DNS health checks rather than control-plane API calls.
Illustrative. Primary Region us-east-1, recovery Region us-east-2. Usage numbers are ours; unit prices are AWS's.
Sources: RDS for PostgreSQL, AWS Backup, Fargate, ELB, VPC, S3, KMS, Route 53, EC2 data transfer, ECR, RDS free backup allowance, whitepaper on replica promotion.
What does each DR strategy cost for a small ECS and RDS stack?
Backup and restore about $16 a month, pilot light about $69, warm standby about $172 and active/active about $310, on top of the $294 bill. The stack: three Fargate tasks (0.5 vCPU, 1 GB), an Application Load Balancer, one NAT gateway, RDS for PostgreSQL db.t4g.medium Multi-AZ with 50 GB, and 100 GB in S3. We assume about 1 GB of database change a day and 10 GB of new S3 data a month.
| Unit price | us-east-1 |
|---|---|
| RDS backup storage beyond the free allowance | $0.095 /GB-month |
| RDS PostgreSQL db.t4g.medium, Single-AZ / Multi-AZ | $0.065 / $0.129 /hour |
| RDS gp3 storage, Single-AZ | $0.115 /GB-month |
| Data transfer between Regions, out of us-east-1 | $0.01 /GB to us-east-2, $0.02 /GB to us-west-2 |
| S3 Standard, first 50 TB / PUT requests | $0.023 /GB-month / $0.005 per 1,000 |
| AWS Backup restore testing | $1.50 per recovery point |
| KMS customer managed key | $1 /key-month |
| Fargate, Linux/x86, vCPU / memory | $0.04048 /vCPU-hour / $0.004445 /GB-hour |
| Application Load Balancer | $0.0225 /hour + $0.008 /LCU-hour |
| NAT gateway | $0.045 /hour + $0.045 /GB |
| Public IPv4 address | $0.005 /hour |
| Route 53 health checks | not billed for load balancers; first 50 AWS endpoints free |
From the AWS Price List API files for each service, read 31 Oct 2026. us-east-2 lists the same price for every RDS, Fargate, ALB, NAT, IPv4, S3 and KMS line above. Inter-Region transfer prices come from the AWS Data Transfer price list. A month is 730 hours. Inter-Region transfer is charged by the sending Region; inbound is free.
Backup and restore, done properly: about $16 a month.
| Line item | Arithmetic | $ /month |
|---|---|---|
| Daily RDS snapshot copied to a backup account in us-east-2, kept 35 days, about 85 GB stored | 85 × $0.095 | 8.08 |
| Transfer of the daily changes, about 30 GB | 30 × $0.01 | 0.30 |
| S3 replicated to a versioned bucket in the backup account, 120 GB with old versions | 120 × $0.023 | 2.76 |
| S3 replication transfer, 10 GB of new data | 10 × $0.01 | 0.10 |
| S3 replication requests, 200,000 objects | 200 × $0.005 | 1.00 |
| Monthly automated restore test of the database | $1.50 + 3 h × $0.065 + 50 GB × $0.115 × 3/730 | 1.72 |
| Two customer managed KMS keys | 2 × $1 | 2.00 |
| Vault Lock | no charge | 0.00 |
| Total | 15.96 |
One surprise: RDS gives you free backup storage up to 100% of your database storage, but only "for a region", and AWS says moving a snapshot to another Region "increases backup storage in the destination region". The backup account runs no databases in us-east-2, so we price every gigabyte copied there as billed. The first full copy also costs a one-off $0.50 to transfer (50 GB × $0.01).
Pilot light: about $69 a month.
| Line item | Arithmetic | $ /month |
|---|---|---|
| Everything in backup and restore | from above | 15.96 |
| Cross-Region read replica, db.t4g.medium Single-AZ | 730 h × $0.065 | 47.45 |
| Replica storage, 50 GB gp3 | 50 × $0.115 | 5.75 |
| Replication traffic, about 15 GB | 15 × $0.01 | 0.15 |
| VPC, subnets, ECS cluster and task definitions, defined in Terraform, no tasks running | no hourly charge | 0.00 |
| Route 53 health check on the main load balancer | not billed for load balancers | 0.00 |
| Total | 69.31 |
Add a few dollars for container images replicated to ECR ($0.10 per GB-month in us-east-1). No NAT gateway until you fail over. Promoting the replica "takes a few minutes", AWS says, and includes a reboot.
Warm standby: about $172 a month.
| Line item | Arithmetic | $ /month |
|---|---|---|
| Everything in pilot light | from above | 69.31 |
| Fargate, 2 tasks, 0.5 vCPU, 1 GB | 2 × (0.5 × 730 × $0.04048 + 730 × $0.004445) | 36.04 |
| ALB, hourly | 730 h × $0.0225 | 16.43 |
| ALB, 1 LCU average | 730 h × $0.008 | 5.84 |
| ALB public IPv4, 2 AZs | 2 × 730 h × $0.005 | 7.30 |
| NAT gateway, hourly | 730 h × $0.045 | 32.85 |
| NAT public IPv4 | 730 h × $0.005 | 3.65 |
| NAT data, 10 GB | 10 × $0.045 | 0.45 |
| Total | 171.87 |
That's 58% on top of a $294 bill, before the time spent keeping a second environment patched and deployed. Multi-site active/active is the whole stack again plus backups, about $310, and the application must be built to run in two places.
Sources: AWS Backup pricing, AWS Elastic Disaster Recovery pricing, Vault Lock docs, AWS Backup vs RDS charges.
How much do AWS Backup and AWS Elastic Disaster Recovery cost?
AWS Backup for RDS costs the same as RDS backup storage, $0.095 per GB-month beyond the free allowance, and Vault Lock is free. AWS Elastic Disaster Recovery is $0.028 per source server per hour, but it isn't built for RDS or Fargate.
| AWS Backup pricing, us-east-1 | List price |
|---|---|
| RDS backups | billed as RDS backup storage, $0.095 /GB-month beyond the free allowance |
| EBS snapshots | billed as EBS snapshots, $0.05 /GB-month |
| S3 backups, warm storage | $0.05 /GB-month |
| Logically air-gapped vault, S3 or EBS, warm | $0.0575 /GB-month |
| Restore from warm storage, S3 | $0.02 /GB |
| Cross-Region copy of S3 backups, to us-east-2 | $0.02 /GB |
| Restore testing | $1.50 per recovery point, plus the restored resource while it runs |
| Backup Audit Manager | $0.00125 per evaluation, plus AWS Config items |
| Vault Lock | no additional charge |
For Postgres on RDS, AWS Backup adds little to the bill: you pay RDS backup storage either way, and get the schedule, copy rules, locked vault and restore tests on top. S3 is the exception. AWS Backup's $0.05 per GB-month is over twice S3 Standard, so versioning plus replication is often cheaper.
AWS Elastic Disaster Recovery pricing, and who it's for.
AWS Elastic Disaster Recovery costs $0.028 per source server per hour, about $20.44 a month, whatever the disk size or number of drills. Staging volumes, snapshots, replication servers and recovery instances are billed on top at EC2 and EBS prices. AWS's whitepaper says it suits AWS workloads only if they "consist only of applications and databases hosted on EC2 (that is, not RDS)". For a team on Fargate and RDS, it isn't the right tool.
Sources: Cross-account backup, AWS Backup Vault Lock, Feature availability, Logically air-gapped vault, AWS blog on aws/rds keys.
How do you set up cross-account backups with AWS Backup Vault Lock?
Copy every backup to a vault in a separate AWS account, then lock that vault in compliance mode so nobody, not even the root user, can delete recovery points before their retention ends. This protects against the scenario that can end a small company: someone with admin rights in production, an attacker, a script or a tired engineer, deleting the data and the backups together.
- Create a backup account in AWS Organizations; cross-account copies only work inside one organization. Nobody's day-to-day role should reach it. If you don't have Organizations yet, start with the account structure we suggest for startups on AWS.
- Use customer managed KMS keys. A database encrypted with the default
aws/rdskey can't be copied to another account, because AWS managed keys can't be shared. For an existing database, AWS's blog describes copying through an intermediate vault that re-encrypts the snapshot. - Create a vault in the backup account in your recovery Region, with a vault access policy that lets the production account copy into it.
- Lock it in compliance mode. After the grace time, at least 72 hours, AWS says the lock "cannot be changed or deleted by any user or by AWS", and backups can't be deleted before their retention ends, even by the root user. Test in governance mode first; users with the right IAM permissions can remove that.
- Set minimum and maximum retention on the lock, for example 7 and 90 days. Never let a recovery point be kept "Always" in a compliance-locked vault: AWS warns those are kept forever and you pay for them forever.
- Add a copy rule to the production backup plan that sends each daily backup to that vault. RDS does cross-Region and cross-account copy in one action. Multi-AZ DB clusters (the readable-standby kind) don't support copies.
- Copy S3 too: versioning plus replication to the backup account, or AWS Backup for S3 to use the locked vault.
- Back up what you need to rebuild: Terraform state, secret names, DNS records and container images.
Air-gapped vaults and plain RDS. AWS Backup's logically air-gapped vault is locked in compliance mode automatically and can be shared to a recovery account. On the day we checked, AWS's feature table lists Aurora, EBS, EC2 and S3 as supported, but not RDS DB instances. For Postgres on RDS, use a compliance-locked vault in a separate account.
Copy it into your docs. The example rows are illustrative; replace every one.
What should a disaster recovery plan template include?
Seven sections: scope and owner, contacts and access, systems with their RTO and RPO, scenarios, runbooks, communication, and testing. Sized for a small business or startup, it fits on two or three pages. Store a copy outside AWS and outside any wiki that might be down with it: a PDF in a shared drive and pinned in the incident channel.
[COMPANY] · Disaster recovery plan · version [N] · last reviewed [DATE]
1. Scope and owner
- Plan owner[name, role]
- In scope[production AWS accounts, Regions, SaaS vendors]
- Out of scope[staging, laptops, office]
- Primary / recovery Region[us-east-1 / us-east-2]
- Next review[date, at least yearly and after big changes]
2. Contacts and access
- Incident lead / deputy[names, phone numbers]
- Who talks to customers[name]
- Break-glass access to production[where the credentials are, who can open them, MFA device]
- Break-glass access to the backup account[as above, different people if possible]
- Critical vendors and status pages[DNS, email, payments, auth, CI]
3. Systems, RTO and RPO
| System | Tier | RTO | RPO | Backup and where copies live | Last restore test |
|---|---|---|---|---|---|
| Postgres (RDS) | 1 | 4 h | 15 min / 24 h on Region loss | PITR 14 days; daily copy to backup account, us-east-2, locked 35 days | [date, minutes taken] |
| File uploads (S3) | 1 | 4 h | 15 min | Versioning; replication to backup account | [date] |
| API and workers (ECS) | 1 | 4 h | n/a | Terraform in Git; images in ECR | [date of last rebuild] |
| Redis cache | 3 | 1 day | none | Rebuilt empty | n/a |
| Terraform state, DNS, secrets list | 1 | 4 h | 24 h | [where] | [date] |
4. Scenarios and who decides
- Data corrupted or deletedRunbook R1. Incident lead decides the restore time.
- AWS account compromisedRunbook R2. Restore from the backup account only.
- Region degradedRunbook R3. Fail over if not improving after [2 h].
- Critical vendor downRunbook R4. Comms only, unless [fallback].
5. Runbooks
One page each, with exact commands and the date last run: R1 point-in-time restore, R2 restore from the backup account, R3 rebuild in the recovery Region, R4 vendor outage.
6. Communication
- Status page updated within[30 min] of declaring an incident
- Customer email[template link], sent by [role]
- Contract notice duties[which customers, how fast]
- Internal channel[#incident], notes kept for the review
7. Testing and changes
Restore test every quarter (section 10), results filed in [location]. Every change to this plan is dated in a change log at the bottom.
Sources: RDS point-in-time restore, copying back across accounts, DR whitepaper on read replicas.
How do you restore from a disaster on AWS? Three runbooks.
Three runbooks cover most startups: a point-in-time restore after a bad migration, a restore from the backup account after a compromise, and a rebuild in the recovery Region. Each one needs exact commands and the date it was last run.
R1: point-in-time restore after a bad migration.
- Stop the damage: pause the deploy, the job or the script. Write down the time it started.
- Check how far back you can go:
aws rds describe-db-instance-automated-backups --db-instance-identifier prod-db --query "DBInstanceAutomatedBackups[0].RestoreWindow"returns the earliest and latest restorable times. - Restore to a new instance a minute before the damage:
aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier prod-db --target-db-instance-identifier prod-db-pitr --restore-time 2026-10-30T14:05:00Z, with your subnet group, security groups and parameter group. - Decide: copy the damaged rows back into production (usually), or point the app at the restored instance (if the damage is everywhere).
- Write down how long each step took. That's your real RTO.
The restored instance keeps loading data from S3 in the background after it's available, so expect it to be slow at first.
R2: restore after an account compromise.
- Contain: deactivate the leaked keys, check CloudTrail for what they did, and treat the production account as altered.
- Sign in to the backup account with its own break-glass credentials, not through production.
- Copy the last recovery point from before the first suspicious event to a clean account with
aws backup start-copy-job, and restore it there. - Redeploy from Git with Terraform, rotate every secret, then repoint DNS.
R3: rebuild in the recovery Region.
- Decide, using the plan's trigger, that waiting is worse than moving. A false-alarm failover loses data too.
- Pilot light: promote the replica with
aws rds promote-read-replica. Backup and restore: restore the latest copy in the recovery Region. - Apply the Terraform for the recovery Region, start the ECS services, and check the health checks pass.
- Move DNS, or let a Route 53 failover record do it, and tell customers what data window, if any, was lost.
How do you test a disaster recovery plan? A quarterly checklist.
Restore production from the locked backup copy into an isolated environment, time every step, and compare the measured RTO and RPO with your targets. Use this disaster recovery testing checklist once a quarter.
AWS Backup restore testing can run scheduled restores, time them and delete the results, which covers the database every month. Once a quarter, a person should do the whole thing by hand, so the runbook gets tested along with the backups. Allow half a day.
- Pick the scenario (R1, R2 or R3) and someone who didn't write the runbook. Start a log with a timestamp per step.
- Restore the production database from the backup account copy, not from the convenient same-account snapshot.
- Restore a sample of S3 objects, including an old version of one you deleted on purpose.
- Start the application against the restored data in an isolated environment, and run a smoke test: sign in, load a record, upload a file.
- Check the data: row counts on the main tables, and the newest timestamp. That newest timestamp is your measured RPO.
- Try to delete a recovery point in the locked vault. It should fail.
- Record the measured RTO and RPO next to the targets in the plan. If you missed, fix the plan or the target.
- Fix every runbook step that was wrong, missing or needed a question to someone.
- Delete the restored resources, and file the log, timings and screenshots where an auditor can find them.
The wider list is in our production readiness checklist.
What do SOC 2 auditors and due diligence reviewers ask about disaster recovery?
A written plan with an owner, RTO and RPO per system, backups in a separate account, and dated evidence of a restore test. In SOC 2, only the Security category is required, according to Linford & Co's guide; Availability is optional. If you include it, criterion A1.2 covers "data back-up processes, and recovery infrastructure" and A1.3 says "the entity tests recovery plan procedures supporting system recovery to meet its objectives." Linford's example controls test backup integrity and the continuity plan "on at least an annual basis". A written plan with no test behind it is exactly what A1.3 catches.
Security questionnaires and Series A due diligence ask the same things either way:
- The DR plan itself, with an owner and a review date.
- RTO and RPO per system, and how they match your contracts.
- Where backups live, and whether they're in a separate account and Region.
- Who can delete backups. "Nobody, the vault is locked" is the answer they hope for.
- The date and result of the last restore test, with the time it took.
The rest of the infrastructure evidence is on SOC 2 on AWS, and the full investor list is in our Series A technical due diligence guide.
Disaster recovery planning: frequently asked questions.
What is a disaster recovery plan?
A short document saying which systems matter, how long each can be down (RTO), how much data each can lose (RPO), where the backups are, who decides, and how you tell customers. On AWS it's backed by backup plans, infrastructure as code and runbooks someone has run.
How do you create a disaster recovery plan in AWS?
List your systems and give each an RTO and RPO. Turn on deletion protection and point-in-time recovery for RDS, copy backups with AWS Backup to a compliance-locked vault in a separate account and Region, and keep infrastructure in Terraform. Write one runbook per scenario, then run a restore test and record how long it took. The template on this page has the sections.
What's the difference between RTO and RPO?
RTO is the time until service is back. RPO is data loss measured in time, back to your last good copy. A nightly backup restored in three hours means an RTO of three hours and an RPO of up to 24. Shortening RTO takes runbooks, rehearsal and standby capacity; shortening RPO takes more frequent backups, point-in-time recovery or replication.
What are good RTO and RPO targets for a SaaS startup?
There's no standard number. Our starting suggestion for a seed or Series A SaaS: an RTO of 4 hours for the production database, API and login, and an RPO of 15 minutes inside the Region from RDS point-in-time recovery, or 24 hours if the whole Region is lost. Then read your contracts, because a target looser than a promise you've made is a gap.
Does a small business or seed startup need a disaster recovery plan?
Yes, but a short one. Two pages, backups in a second account, and one tested restore cover what most small companies face. You don't need a second Region running all year until a customer or contract asks for recovery in minutes. Security questionnaires and Series A due diligence will ask to see the plan and the last restore test.
What's the difference between pilot light and warm standby?
Pilot light keeps data replicating to a second Region with app servers defined but switched off, so it can't serve requests until you start them. Warm standby runs a small, working copy of everything and serves traffic at reduced capacity straight away. On our illustrative $294 stack, pilot light adds about $69 a month and warm standby about $172.
Does Multi-AZ count as disaster recovery?
For losing one data centre, largely yes; AWS's whitepaper says a well-built, highly available workload may only require a backup and restore approach. Multi-AZ does nothing for corruption, deletion or a compromised account, because the standby copies every change within seconds. You still need point-in-time backups and copies in a separate account.
How often should we test disaster recovery?
Run an automated database restore monthly with AWS Backup restore testing, and a full manual exercise once a quarter, done by someone who didn't write the runbook. Linford & Co's example SOC 2 controls say at least annually, but quarterly catches runbooks that went stale after a database upgrade or a Terraform change. Record the measured RTO and RPO every time.
Is there a free disaster recovery plan template?
Yes: the template in section 08 of this page is free to copy into Google Docs, Word or your wiki. It has seven sections: scope and owner, contacts and access, RTO and RPO per system, scenarios, runbooks, communication, and testing. Replace every example row with your own systems, and keep a PDF copy somewhere that doesn't depend on AWS.
How much does AWS Backup cost?
For RDS, the same as RDS backup storage: $0.095 per GB-month in us-east-1 beyond the free allowance. S3 backups are $0.05 per GB-month, restore tests $1.50 per recovery point plus the restored resource while it runs, Vault Lock is free. Copying RDS snapshots from us-east-1 to us-east-2 adds $0.01 per GB transferred; AWS Backup charges $0.02 per GB to copy S3 backups on the same route.
How much does AWS Elastic Disaster Recovery cost?
$0.028 per source server per hour, about $20.44 a month per server, whatever the disk size or number of drills. On top you pay EC2 and EBS prices for staging volumes, snapshots, replication servers and any recovery instances. It is built for servers on EC2 or outside AWS, not for RDS databases or Fargate tasks.
Production readiness checklist
46 checks, including backups, restores and access, tagged by stage.
How much AWS costs a startup
The $294 stack priced above, and two others, line by line.
SOC 2 on AWS
The infrastructure half of SOC 2, including backup evidence.
AWS DevOps Agent
An AI investigator for incidents. It won't prove your backups restore.
If you have one database, Terraform and a free afternoon, you can do everything on this page yourself with the template above. If you'd rather have it checked, our fixed-price AWS readiness review covers backups, retention, access and whether a restore works, and hands you a ranked fix list. To have someone run the quarterly restore test and record the result in the plan, that is included in our Growth and Scale fractional DevOps plans, from $4,900 a month (on request on Essentials). If you'd rather hand over day-to-day operations as well, managed DevOps describes the same plans from that side.