In Part 1 , we looked at what happens when a single bad write hits your database: how Aurora Backtrack can rewind it, how idempotency stops the same request from running twice, and why a restored database quietly leaves behind the data written during the restore.

Part 2 zooms out to the questions every team eventually has to answer:

How much data can we afford to lose, and how long can we afford to be down?

How does DynamoDB Point-in-Time Recovery actually work?

Can we let automation detect a disaster and restore the database on its own?

Which of the four AWS disaster recovery strategies should we pick?

I will be honest: some of my first answers to these questions were wrong. I will show you where I went wrong too, because those mistakes are exactly the ones that look smart on a whiteboard.

RTO and RPO: The Two Numbers That Decide Everything

Before you choose a single AWS service, you need two numbers.…