AWS Cloud Practitioner Study Notes · Part 31

AWS Database Backups: Automated Backups, Snapshots, and PITR

AWS Cloud Practitioner study notes explaining RDS backups, manual snapshots, point-in-time recovery, DynamoDB PITR, Redshift, and EC2 databases.

Tan Chin SiangBackend & Cloud Software Engineer

21 Aug 2026 10 min read

A database backup is a recoverable copy of database data. It protects against accidental deletion, application bugs, corruption, hardware failure, and disaster. High availability keeps a service running through some infrastructure failures; backups let you recover data after a bad write, deletion, or other logical mistake.

This is Part 31 of the AWS Cloud Practitioner Study Notes. Part 29 introduced RDS backups and snapshots, while Part 30 compared AWS database services by workload.

The two RDS backup types to remember

Backup type	Created by	Retention
Automated backup	AWS, according to the configured settings	Automatically removed after the retention period
Manual snapshot	You or an authorised automation process	Remains until deleted or until its configured retention policy removes it

This distinction is heavily tested. Automated backups are designed for routine protection and point-in-time recovery. Manual snapshots are deliberate checkpoints that are useful before upgrades, migrations, or long-term retention.

Why backups matter

Imagine an application accidentally executes:

DELETE FROM customers;

Multi-AZ does not solve this logical mistake. A bad delete written to the primary can be replicated to the standby. A backup or point-in-time recovery operation gives you a way to restore the database to a state before the deletion.

Accidental deletion
        │
        ▼
Restore from an earlier point in time
        │
        ▼
Recover the customer records

1. Amazon RDS automated backups

Amazon RDS automatically creates backups according to the DB instance or cluster configuration and retains them for the selected backup retention period. The automated backup contains the information required to restore the database within that window.

Automated backups support point-in-time recovery (PITR). If a developer deletes records at 10:15, you can restore to a time immediately before the mistake instead of restoring only a backup from the previous day.

09:00  Database is correct
10:15  Accidental DELETE runs
11:00  Problem is discovered

Restore to approximately 10:14:59

RDS creates a new DB instance when you perform a point-in-time restore; it does not overwrite the original database. This gives you an opportunity to validate the restored data before changing application traffic.

Automated backups are useful for:

Recovering from accidental data changes
Recovering from corruption within the retention window
Routine operational recovery
Restoring a database to a selected time

The retention period is a recovery-window decision. A longer window provides more protection from delayed discovery but may increase backup storage costs and operational expectations.

2. Manual DB snapshots

A manual snapshot is created on demand. It captures the database state at a particular point in time and is commonly used before a risky change.

Before a major upgrade
        │
        ▼
Create manual snapshot
        │
        ▼
Perform the upgrade
        │
        ├── Success → continue
        └── Failure → restore the snapshot

Use a manual snapshot for:

A database-engine upgrade
A schema migration
A major application release
A one-off environment copy
Long-term retention
A deliberate recovery checkpoint

Unlike an RDS automated backup, a manual snapshot is not removed simply because the automated retention window moves forward. Manual snapshots remain available until you delete them or apply an explicit retention policy through your backup process. You can also copy snapshots to another Region for disaster recovery, subject to encryption, permissions, Region support, and cost considerations.

Automated backups versus manual snapshots

Feature	Automated backup	Manual snapshot
Created automatically	Yes	No
Created on demand	Not the main purpose	Yes
Point-in-time recovery	Yes, within the retention window	No; restores the snapshot state
Retention	Configured recovery window	Long-term or policy-controlled retention
Best use	Routine recovery and accidental mistakes	Upgrade checkpoint and durable copy

Exam shortcut: restore to a specific time → point-in-time recovery; keep a backup before an upgrade → manual snapshot.

3. Amazon Aurora backups

Aurora provides continuous automated backup capability for its cluster and supports point-in-time recovery within the configured retention window. Aurora also supports manual DB cluster snapshots.

Aurora’s automated backup process incrementally retains the database changes needed to recreate the cluster at a selected point in time. Manual snapshots are useful when you need a named, deliberate checkpoint such as before a migration or major version change.

The exam-level memory aid remains:

Aurora automated backup → continuous protection and PITR
Aurora manual snapshot  → user-created long-term checkpoint

4. DynamoDB backups

Amazon DynamoDB provides two important backup options:

On-demand backup

An on-demand backup is a user-initiated full backup of a DynamoDB table. It is useful for long-term retention, compliance, migrations, and a deliberate recovery point. You can restore the table to the state represented by the backup.

Point-in-time recovery

DynamoDB PITR provides continuous backups at per-second granularity for a configurable recovery period of up to 35 days. It protects against accidental writes and deletes without requiring you to schedule individual backups.

When you restore a DynamoDB table using PITR, DynamoDB creates a new table. Plan how to validate the restored table and how application traffic would be redirected if the original table is still serving requests.

Accidental DynamoDB write or delete
                │
                ▼
Restore to a selected point in time
                │
                ▼
New restored DynamoDB table

The important distinction is similar to RDS but the names differ:

DynamoDB on-demand backup → user-created backup
DynamoDB PITR            → continuous recovery window

5. Amazon Redshift snapshots

Amazon Redshift uses snapshots as point-in-time backups of a data warehouse cluster. It supports automated snapshots and manual snapshots.

Automated snapshots: created periodically and deleted according to the configured retention period.
Manual snapshots: created on demand and retained according to the snapshot’s retention settings.

Snapshots are stored in AWS-managed Amazon S3 storage for Redshift. You can restore a cluster from a snapshot, and you can configure snapshot copies to another Region when regional disaster recovery is required.

Redshift snapshots protect the warehouse, but they are not the same as operational backups for an RDS transactional database. Always choose the recovery method for the service that owns the data.

6. Databases installed on EC2

If you install MySQL, PostgreSQL, Oracle, or another database directly on EC2, AWS does not automatically manage the database backups for you. You are responsible for designing, scheduling, monitoring, and testing them.

Possible approaches include:

Database-native logical or physical backups
EBS snapshots coordinated with the database state
AWS Backup or another central backup service
Replication to another instance or Region
Exporting backup files to Amazon S3

An EBS snapshot captures the state of an EBS volume, not necessarily a transactionally consistent database state. For an active database, use a database-aware backup method or coordinate the database and storage snapshot process so that the restored files are consistent.

EC2 database
    │
    ├── Database-native backup
    ├── EBS snapshot, coordinated when appropriate
    └── Backup copy to another Region or account

Exam shortcut: database on EC2 → the customer manages backups.

7. Cross-Region backup copies

A backup in one AWS Region does not automatically protect an application from a complete outage in that Region. For regional disaster recovery, organisations may copy supported snapshots or backups to another Region.

Singapore Region
        │
        ▼
Snapshot copy
        │
        ▼
Tokyo Region

Cross-Region recovery requires more than copying the data. Plan the destination networking, encryption keys, database configuration, application deployment, DNS or traffic switching, permissions, and restore procedure. A backup that has never been restored is only an assumption, so test the complete recovery process.

8. Backup strategy and recovery objectives

A useful backup strategy starts with two objectives:

Recovery Point Objective (RPO): how much recent data the business can afford to lose.
Recovery Time Objective (RTO): how quickly the service must be restored.

For example, a low RPO may require continuous point-in-time backups or replication, while a low RTO may require a warm standby or prepared recovery environment rather than a backup that takes hours to restore.

A practical RDS strategy might combine:

Automated backups with a recovery window
        │
        ├── Point-in-time recovery for logical mistakes
        ├── Manual snapshot before major changes
        └── Cross-Region copy for regional disaster recovery

Backups should also be encrypted, access-controlled, monitored for failure, protected from accidental deletion where appropriate, and tested through regular restore exercises.

Availability is not the same as backup

This distinction is one of the most important Cloud Practitioner exam concepts:

Requirement	Feature
Keep serving through an Availability Zone or infrastructure failure	Multi-AZ or another high-availability design
Recover after accidental deletion or corruption	Automated backup and point-in-time recovery
Create a checkpoint before an upgrade	Manual snapshot
Recover after a Regional outage	Cross-Region backup copy or a broader disaster-recovery architecture

Multi-AZ and backups solve different problems. A standby improves availability, but it is not a historical copy that lets you undo a bad transaction.

Common exam questions

Scenario	Likely answer
AWS should automatically back up an RDS database	Automated backup
Restore an RDS database to 10:35 yesterday	Point-in-time recovery
Create a checkpoint before a database upgrade	Manual snapshot
Keep a database backup for long-term retention	Manual snapshot or an appropriate backup policy
Recover a DynamoDB table after an accidental delete	DynamoDB PITR, if enabled and within its recovery window
Back up a database installed on EC2	Customer-managed database backup or coordinated storage backup
Protect a warehouse cluster with scheduled copies	Redshift automated snapshots
Recover if an entire Region becomes unavailable	Cross-Region backup copy or a multi-Region DR design

Memory map for CLF-C02

Need automatic RDS backups? → Automated backups
Need to restore to 10:15 AM? → Point-in-time recovery
Need a backup before an upgrade? → Manual snapshot
Need long-term RDS retention? → Manual snapshot
Need DynamoDB continuous recovery? → DynamoDB PITR
Need a user-created DynamoDB backup? → On-demand backup
Database on EC2? → You manage the backups
Need protection from an AZ failure? → Multi-AZ, not a backup

Conclusion

Automated backups, snapshots, point-in-time recovery, replication, and high availability are related but different tools. Automated backups provide a managed recovery window. Manual snapshots create deliberate checkpoints. PITR restores data to a selected time, while cross-Region copies extend recovery beyond a single Region.

For the exam, remember the core mapping: automated backups for routine protection, PITR for a specific time, manual snapshots before changes, and customer-managed backups for databases on EC2. In production, add restore testing and explicit RPO/RTO decisions so the backup is a demonstrated recovery capability rather than merely a stored file.

Sources

AWSCloud PractitionerDatabasesBackupsDisaster Recovery

Written by

Tan Chin Siang

Backend and cloud software engineer writing about reliable systems, infrastructure automation, and engineering practice.