How to Access RDS Snapshots on S3 (The Right Way)

Introduction

AWS RDS snapshots provide an easy way to back up your database, but they are not a flexible restoration endpoint. Many assume that exporting RDS snapshots to S3 allows for quick restoration, but the reality is different—AWS snapshots capture the entire database cluster, not individual databases. If you need to restore a single database from a multi-tenant RDS instance, you’ll be forced to restore the entire cluster, which is often impractical and time-consuming.

A better approach is to supplement RDS snapshots with database dumps using mysqldump for MySQL and pg_dump for PostgreSQL. This strategy provides fine-grained control, faster recovery, and efficient storage in Amazon S3.

This guide explains:

• The limitations of AWS RDS snapshots and why they shouldn’t be your only backup strategy.
• How to export RDS snapshots to S3 and what format they use.
• How to back up MySQL and PostgreSQL databases to S3 using mysqldump and pg_dump.
• Automating database backups and optimizing costs in AWS.
• Pro Tip: The importance of cross-region and cross-cloud backups for disaster recovery.

Why You Shouldn’t Rely Solely on RDS Snapshots

AWS makes it simple to take an RDS snapshot, but the way these backups work introduces some major drawbacks:

1. Full Cluster Restorations Only

When restoring an RDS snapshot, AWS restores the entire database cluster, not just one database. If you have multiple databases running in a single RDS instance (common for multi-tenant setups), you can’t restore just one—you must restore everything.

2. Snapshots Aren’t Directly Usable

You can export RDS snapshots to S3, but AWS converts them into Apache Parquet format—a format optimized for analytics, not direct database restoration. Unlike a standard SQL dump, you cannot directly import a snapshot’s exported data into MySQL or PostgreSQL without additional conversion steps.

3. High Storage and Restoration Costs

• Storing multiple RDS snapshots can get expensive, especially for larger instances.
• Restoring a snapshot requires spinning up a new RDS instance, which means additional AWS costs.
• If you’re using Point-in-Time Recovery (PITR), AWS retains backups based on a retention period, which could lead to unexpected costs.

4. Limited Backup Frequency

With RDS snapshots, you’re limited to the backup schedules AWS allows, which might not fit your needs. In contrast, database dumps can be taken as often as needed and stored in Amazon S3 for long-term retention.

5. No Cross-Platform Portability

A snapshot of a MySQL RDS instance can’t be restored into a PostgreSQL instance. If you need cross-database compatibility or migration flexibility, SQL dumps are a much better option.

Exporting RDS Snapshots to S3

If you still want to export an RDS snapshot to S3, you can do so via the AWS CLI or AWS Management Console. Keep in mind that the exported data will be in Parquet format, which is useful for analytics but not for direct restoration.

Export an RDS Snapshot to S3 (AWS CLI)

aws rds start-export-task \
    --export-task-identifier my-export-task \
    --source-arn arn:aws:rds:region:account-id:snapshot:snapshot-id \
    --s3-bucket-name my-s3-bucket \
    --iam-role-arn arn:aws:iam::account-id:role/my-export-role \
    --kms-key-id my-kms-key-id

Once the export is complete, you’ll find the Parquet files in your S3 bucket. If you need to retrieve structured data from them, you’ll have to use AWS Glue, Athena, or another tool to process and convert the data.

For practical backups and easy restoration, using mysqldump (for MySQL) and pg_dump (for PostgreSQL) is a far better solution.

Backing Up MySQL and PostgreSQL Databases to S3

Instead of relying on RDS snapshots, you can use database dumps to store backups efficiently in S3.

MySQL: Using mysqldump

mysqldump -h your-rds-endpoint -u your-user -p your-database > backup.sql
gzip backup.sql
aws s3 cp backup.sql.gz s3://your-backup-bucket/

PostgreSQL: Using pg_dump

pg_dump -h your-rds-endpoint -U your-user -d your-database -F c -f backup.dump
aws s3 cp backup.dump s3://your-backup-bucket/

Pro Tip: Cross-Region and Cross-Cloud Backups for True Disaster Recovery

Even if you store backups in S3, they are still within your AWS account. What happens if:

• AWS has a region-wide outage?
• Your AWS account gets compromised and attackers delete your S3 backups?

Cross-Region Backups

To protect against AWS region failures, store backups in an S3 bucket in a different AWS region. You can automate this using S3 replication:

aws s3 cp backup.sql.gz s3://your-secondary-region-backup-bucket/

Cross-Cloud Backups (AWS to Google Cloud, Azure, or Others)

For maximum security, store backups in another cloud provider like Google Cloud Storage. This ensures that even if your AWS account is completely compromised, attackers can’t delete your offsite backups.

1. Use AWS CLI to download the backup

   aws s3 cp s3://your-backup-bucket/backup.sql.gz .
   

2. Upload to Google Cloud Storage (GCS)

   gcloud storage cp backup.sql.gz gs://your-gcp-backup-bucket/
   

Make It a Write-Only Backup for Security

To prevent hackers from deleting backups, make the GCS bucket "write-only"—meaning only your automated backup process can upload files, and even an AWS admin can’t delete them.

1. Set an IAM policy in Google Cloud that allows writes but denies deletions.
2. Enable monitoring on cross-cloud backups to alert you if backups fail.

Monitor Your Backups

Set up alerts using AWS CloudWatch or Google Cloud Monitoring to notify you if:

• A scheduled backup fails.
• A backup file is missing.
• There’s unusual access activity on your storage buckets.

Conclusion

While AWS RDS snapshots are useful for full cluster recovery, they are not a viable solution for fine-grained backups or selective database restoration. Relying on them as your only backup strategy is a mistake.

Instead, using mysqldump or pg_dump with Amazon S3 offers more flexibility, faster recovery, and lower costs.

For true disaster recovery, implement cross-region backups or, even better, cross-cloud backups to Google Cloud or Azure. Write-protect your offsite backups so they can’t be deleted, and monitor them actively for failures.

If your backup strategy is snapshot-only, it’s time to rethink it. Combine RDS snapshots with database dumps for a complete disaster recovery plan.

Relying solely on AWS RDS snapshots is a bad strategy