Working With Amazon RDS Snapshots: The Basics and a Quick Tutorial

What Is an RDS Snapshot? 

An Amazon RDS snapshot is a point-in-time backup of an Amazon RDS database instance or cluster, capturing the state of the data and configuration at a specific moment. These snapshots can be used to restore the database to the captured state or to create new instances. There are two types: automated, which are created based on a backup window and retention period, and manual, which are initiated by the user and retained until explicitly deleted. 

Key aspects of RDS snapshots include:

• Purpose: Snapshots serve as backups, enabling recovery to a specific point in time or creation of new instances from that point. 
• Point-in-Time Recovery (PITR): Automated backups with transaction logs support PITR, allowing restoration to a specific time, while snapshots only allow restoration to the snapshot’s point in time.
• Retention: Automated snapshots are automatically deleted based on the retention period set, while manual snapshots are retained until explicitly deleted. 
• Storage: Both automated and manual snapshots are stored in Amazon S3. 
• Cross-region copying: Snapshots can be copied to different AWS regions for disaster recovery or other purposes. 
• Cost: RDS snapshots incur storage costs, and you are billed for the storage space used by the snapshots. 
• Multi-AZ deployment: Automated backups and snapshots are taken from standby instances to avoid impacting the primary database’s performance. 
• Performance: Creating a snapshot of a Single-AZ RDS instance can temporarily suspend I/O operations. 

This is part of a series of articles about AWS Backup

In this article:

• Understanding Basic Snapshot Concepts
• Tutorial: Creating a Manual DB Snapshot for Amazon RDS
• Best Practices for Managing RDS Snapshots
  • 1. Encrypt Snapshots for Data Protection
  • 2. Set Clear Retention Policies
  • 3. Automate Snapshot Verification and Testing
  • 4. Monitor and Optimize Storage Costs

Understanding Basic Snapshot Concepts 

Point-in-Time Recovery

Point-in-time recovery (PITR) allows you to restore an RDS database instance to any second within the retention period of automated backups. This is useful for recovering from accidental data deletion or corruption by rolling back to a moment just before the incident.

PITR works by restoring the latest automated snapshot and replaying transaction logs up to the specified time. This process requires that automated backups are enabled. PITR is not supported with manual snapshots alone since they capture only a specific state without incremental logs.

The recovery target time must fall within the backup retention period, and the restored database is created as a new instance, preserving the original one unless manually deleted.

Types of Snapshots: Automated vs Manual 

Amazon RDS provides two types of snapshots: automated and manual, each with distinct use cases and management requirements.

Automated snapshots are managed by RDS and occur automatically based on a daily backup window configured for the database instance. These snapshots are stored for a specified retention period, which can range from 1 to 35 days. Once the retention period expires, the snapshots are automatically deleted by AWS. Automated backups also support point-in-time recovery within the retention window.

✅ Pro Tip: Using N2W lets you automate RDS backup, DR, and lifecycle management from a single easy-to-use console.

Manual snapshots are user-initiated and persist until explicitly deleted. They provide more control and long-term storage options, making them suitable for compliance, data archiving, and creating backups before major updates or migrations. Unlike automated snapshots, manual snapshots are not subject to automatic expiration and can be copied across regions or accounts.

Snapshot Retention and Storage

Snapshot retention policies differ for automated and manual snapshots. Automated snapshots are retained for a user-defined number of days (1–35), after which they are automatically purged. Manual snapshots remain indefinitely until manually deleted.

Snapshots are stored in Amazon S3, and while RDS does not charge for snapshot creation, storage costs apply based on the amount of data retained. Retaining too many large manual snapshots can significantly increase costs. It’s a best practice to regularly review and delete outdated snapshots that are no longer needed.

✅ Pro Tip: If you need more flexibility over your retention and archiving, N2W gives you full control over retention and storage options.

Cross-Region RDS Snapshot Copying for Disaster Recovery

RDS supports copying manual snapshots across AWS regions. This improves disaster recovery strategies by maintaining offsite backups and supporting region-based migrations or testing environments.

Cross-region copies are asynchronous and can be encrypted during transfer, even if the original snapshot was unencrypted. Copy times depend on snapshot size and network conditions.

After copying, the snapshot can be restored in the target region as a new RDS instance. Automating this process using AWS Backup or scripts ensures consistent offsite backups without manual intervention.

Cost (Creation Cost vs Storage Cost)

RDS snapshot costs primarily come from storage. While creating snapshots (automated or manual) is free, AWS charges for the data stored in them. This cost is based on the total size of the snapshot data and is billed per GB per month.

For automated snapshots, AWS provides backup storage equivalent to the size of your RDS instance at no additional charge, as long as you have an active instance. Any backup storage beyond this—such as when you retain backups longer than your instance size—incurs charges.

Manual snapshots are billed entirely based on their storage usage. The longer you retain them, the higher the cumulative cost, especially for large databases. Cross-region snapshot copies also incur additional transfer and storage charges in the destination region.

✅ Pro Tip: To reduce long-term storage costs, use a tool like N2W with built-in cost-saving features.

Backup Times in Multi-AZ Failover

In a Multi-AZ deployment, automated backups and snapshots are taken from the standby instance rather than the primary. This reduces performance impact on the primary database and avoids backup-related slowdowns.

During a failover event, a new standby is created, and backup processes shift accordingly. Because backups are managed from the standby, they continue to run even if the primary instance is under load or fails.

However, backup initiation might be briefly delayed during a failover. It’s important to monitor backup schedules and adjust the backup window to minimize conflict with peak usage times.

How Amazon RDS Snapshot Creation Affects Performance 

Snapshot creation time depends on the size of the database and the type of storage used. Manual snapshots usually take a few minutes but can be longer for larger datasets or under high I/O loads.

Automated snapshots, especially in Multi-AZ configurations, have minimal impact since they occur on the standby. On single-AZ deployments, snapshot operations can cause brief I/O suspension, typically lasting a few seconds.

To avoid performance degradation, schedule manual snapshots during low-traffic periods and monitor instance performance metrics during backup windows.

✅ Pro Tip: Use N2W to automate application-consistent backups. That way, you get a clean, restorable state without worrying about I/O disruptions or partial transactions.

Tutorial: Creating a Manual DB Snapshot for Amazon RDS 

This tutorial walks you through the steps to create a manual DB snapshot for an Amazon RDS instance using the AWS Management Console. Manual snapshots are useful for preserving the state of your database before updates, migrations, or for long-term backup. Instructions are adapted from the AWS documentation.

Step 1: Navigate to RDS Snapshots

1. Navigate to the Amazon RDS console.
2. Sign in with your AWS credentials.
3. In the left-hand navigation pane, choose Snapshots.
4. The Manual snapshots tab appears by default.
   

Step 3: Take a New Snapshot

1. Click the Take snapshot button.
2. In the Take DB snapshot window, select the DB instance you want to back up from the dropdown list.
3. Enter a Snapshot name. Choose a name that clearly identifies the purpose or date of the snapshot.
4. Click Take snapshot.

Step 4: Monitor Snapshot Status

1. After submission, the new snapshot appears in the Manual snapshots list.
2. Its status will be Creating while the snapshot is in progress.
3. Once complete, the status changes to Available, and the Creation time will be displayed.

Related content: Read our guide to AWS Backup RDS

Best Practices for Managing RDS Snapshots 

Development teams and administrators should be familiar with the following practices when working with snapshots in Amazon RDS.

1. Encrypt Snapshots for Data Protection

Encryption is vital for securing sensitive data and complying with security policies and regulations. Amazon RDS supports encryption at rest using AWS Key Management Service (KMS). When an RDS instance is encrypted, all snapshots derived from it—including both automated and manual ones—are also encrypted using the same key.

For unencrypted snapshots, AWS allows users to create an encrypted copy using a KMS key, enabling teams to retroactively secure existing backups. This is especially useful when transitioning to encryption policies or consolidating legacy systems. Cross-region copies can also be encrypted during transfer, even if the original snapshot was unencrypted.

Always audit the backup environment to ensure encryption is consistently applied. Use IAM policies to restrict access to KMS keys and enforce encryption requirements via tagging and compliance tools like AWS Config.

⚠️ NOTE: Cross‑region RDS snapshot copies can be encrypted during transfer—even if the original is unencrypted. However, AWS Backup does not support cross‑region copies with a custom KMS key rotation for RDS/Aurora; you must choose either cross‑region or a custom key. With N2W, you get full multi‑region KMS support and can securely switch encryption keys as part of the copy process, offering enhanced flexibility and compliance.

2. Set Clear Retention Policies

Effective retention policies prevent storage sprawl and ensure that backups serve both operational and compliance needs. For automated backups, define a retention window based on the recovery requirements of each application—longer for critical systems and shorter for transient or dev/test environments. Retention is configured per instance and can be adjusted without downtime.

Manual snapshots should be reviewed regularly since they are not deleted automatically and can accumulate over time. Classify snapshots based on purpose (e.g., pre-upgrade, archival, testing) and assign expiration dates where applicable. Use AWS tags to label snapshots by owner, environment, and lifecycle stage to enable management and reporting.

Establish a process for reviewing and purging outdated snapshots, ideally with automation tools such as AWS Backup lifecycle policies or custom Lambda scripts. Align retention policies with legal, regulatory, and internal audit requirements to avoid unnecessary risks or costs.

3. Automate Snapshot Verification and Testing

Backups are only useful if they can be reliably restored. Regular testing validates that snapshots are complete, consistent, and restore correctly into a functioning database instance. Manual verification is time-consuming and error-prone, so automation is recommended to ensure thorough and consistent testing.

The easiest way to set up scheduled snapshot restores to a test environment is with N2W’s Recovery Scenario tool. You could also use scripts, AWS Lambda functions, or AWS Backup workflows (but note that these alternative options do not allow for a failover, only for testing). Validate not just the restore operation but also application-level functionality, such as user authentication, data consistency, and performance metrics. This uncovers issues with schema compatibility, configuration drift, or corrupted data.

Document the restore process and maintain runbooks that outline the steps to recover from a failure using snapshots. Include both automated and manual snapshots in testing schedules to ensure full coverage. Proactive testing reduces recovery time and increases confidence in the backup strategy during actual incidents.

4. Monitor and Optimize Storage Costs

Snapshot storage can grow quickly and become a significant cost factor, especially when managing multiple RDS instances with frequent manual backups. Use AWS tools like Cost Explorer and the RDS console to monitor snapshot storage usage over time and identify trends.

✅ Pro Tip: AWS Cost Explorer is built into N2W’s dashboard for easy monitoring at-a-glance

Tag snapshots with meaningful metadata, such as project name or environment type, to attribute storage costs accurately and hold teams accountable. Implement alerts via Amazon CloudWatch to notify stakeholders when storage usage exceeds predefined thresholds.

Delete redundant or obsolete snapshots regularly, especially those left over from completed projects or expired environments. Consider consolidating snapshots for long-term retention by creating a single verified backup per interval (e.g., monthly). Use automation to enforce cleanup policies and align with the organization’s retention strategy.

Optimizing RDS Backup with N2W

Manually managing RDS snapshot policies can be tedious—and risky. N2W makes it ridiculously easy to automate snapshot creation, retention, archiving, and cross-region disaster recovery across AWS accounts.

• Schedule snapshots with intelligent policies (as frequently as every 60 seconds, if you want for maximum precision and minimum RPO).
• Instantly archive snapshots to any S3/Glacier storage tier or Wasabi for long-term storage (and massive savings).
• Restore RDS instances—or specific DB snapshots—across accounts, VPCs, or even regions.
• Enforce snapshot immutability and use air-gapped accounts for next-level protection.

With N2W, you’re always in control—no scripts, no guesswork, just automated, cost-effective RDS backup and recovery.

Evaluating backup options? 📙 Download our free guide to choosing the best AWS backup.