Demystifying Amazon RDS backup storage costs

Amazon Relational Database Service (Amazon RDS) is a managed service that makes it easy to set up, operate, and scale relational databases in the cloud. Amazon RDS gives you access to the capabilities of a familiar MySQL, MariaDB, Oracle, SQL Server, or PostgreSQL database.

Amazon RDS provides two different methods for backing up and restoring your DB instances: automated backups and database snapshots (manual snapshots). Automated backup performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs to allow point-in-time restore. Manual snapshots are user initiated and allow you to back up your DB instance in a known state as frequently as you need and restore to that specific state at any time.

Customers often ask about the estimated Amazon RDS backup storage cost during technical sessions with them, especially for new customers who are embarking on their cloud journey and getting used to the pay-as-you-go model. They often want to forecast and set aside some budget for database backup purposes based on their business requirements.

In this post, we explain the cost that is related to Amazon RDS backup, the variables that determine the final monthly cost, and common backup and retention scenarios. You are not charged for the backup storage cost if the total backup storage doesn’t exceed 100% of your databases storage size within a Region. Amazon RDS automated backup and manual snapshots contribute to the consumption of the backup storage. The statement is referenced in both Amazon RDS Pricing and the AWS Pricing Calculator.

There are a few out-of-scope items we would like to mention before continuing with the post:

• The backup storage cost doesn’t cover the cost incurred when performing native database backups. Amazon RDS doesn’t perform native backup itself, but you can do it if necessary.
• Cross-Region backup (storage and data transfer cost).
• Amazon Aurora backup cost. For more information about Aurora backup storage cost, refer to Understanding Amazon Aurora backup storage usage.

Let’s now focus on the variables that could potentially affect the monthly cost of backup storage:

• Database storage size
• Database workload patterns
• Retention period
• Frequency of user-initiated snapshots (manual snapshots)
• Other instances, their database storage size, and backup policies in the Region

Database storage size

This refers to the provisioned database storage of your instances within a Region. For example, if you have an active Amazon RDS for Oracle instance with 1 TiB of provisioned storage and an active Amazon RDS for SQL Server instance with 800 GiB of provisioned storage, we provide up to 1.8 TiB-month of backup storage at no additional cost. When your database storage increases either through auto scaling or manual resizing, the free quota of your backup storage increases too. Transaction log backups required for database point-in-time recovery in the automated backup window don’t contribute to backup storage sizing. There is no difference between Single-AZ and Multi-AZ configuration during non-chargeable backup storage calculation. For example, for a Multi-AZ RDS for Oracle instance with 1 TiB of provisioned storage that has 2 TiB of storage in total (1 TiB for primary and 1 TiB for standby), you’re getting only 1 TiB of storage at no additional cost.

Database workload pattern

The initial snapshot contains blocks used for your data. For example, for a database provisioned with 1 TiB storage, the used storage space might be 700 GiB for your data, with 30% free storage space. Subsequent snapshots are incremental (as long as the full snapshot is available), and only contain blocks changed after your most recent snapshot. Between snapshots, if the workload changes blocks randomly, the snapshot size will be larger.

Retention period

Automated backup retention period is between 0 and 35 days. Setting the backup retention period to 0 disables automated backups and deletes all existing automated backups for that instance. If you set your retention period to 1 day, most likely you will not be charge for backup storage. However, if you increase your backup retention period, that would increase the backup storage consumed by your account within that Region. Review your Amazon RDS backup lifecycle policy and set the retention period according to your organization’s compliances and retention policy.

Frequency of manual snapshots

Apart from the automated backups, you can initiate manual snapshots of your instances for long-term archival. Manual backups don’t fall within the set retention period. The more frequently you perform manual snapshots, the more backup storage they consume, which can lead to additional backup storage cost. Use manual snapshots according to your requirements and delete those that are no longer required, for example snapshots taken prior to a major or minor version upgrade.

Other instances, storage sizes, and backup policies

Because the allocated non-chargeable backup storage quota is based on the total database storage of all instances within a Region, other instances and their backup and retention policies within the account will contribute towards the monthly cost of your backup storage. If the backup and retention policy is standardized across all instances, the setting could possibly contribute to additional cost. This is where grouping of the instances and having separate backup and retention policies may help control the cost.

Amazon RDS backup storage sizing scenarios

Let’s run though few scenarios to articulate how to estimate the snapshot sizing for our database workload. To simplify the process, we assume there is no other database in the Region affecting non-chargeable backup storage.

Scenario 1: Automated backup with 1-day retention

In this scenario, the allocated database storage size doesn’t matter; there is no additional charge for backup storage up to 100% of your total database storage for a Region. The estimated chargeable backup storage is 0 GiB.

Scenario 2: Automated backup with 7-day retention

Let’s explore this scenario with the following assumptions:

• Database storage size – 1,000 GiB
• Data size – 700 GiB
• Daily change – 50 GiB

The data size includes the space consumed by data files, transaction log, and other files as part of database operation. The estimated chargeable backup storage size is 700 + 7*50 – 1000 = 50 GiB. In this scenario, there will be no additional charge for backup storage up to 1,000 GiB (depending on your total database storage size). Any backup storage above this will be charged a rate of $0.095 per GiB-month. The rate is based on Singapore region and up-to-date at the time of publication. The rate for additional backup storage is the same for scenarios 3 and 4.

Scenario 3: Automated backup plus weekly manual snapshot, with 30-day retention period

If we increase the number of snapshots retained in scenario 2, the estimated backup storage size will be increased. With a retention period of 30 days, and additional manual snapshots on Saturday, we have a total of 34 snapshots retained for this database. The estimated chargeable backup storage size is 700 + 34*50 – 1000 = 1,400 GiB. The formula used here serves the purpose of high-level estimation, although with one additional manual snapshot created on Saturday, the total snapshot storage size is unlikely to become double, because snapshots are always incremental.

Scenario 4: Automated backup with 30-day retention, plus monthly manual snapshot with 12-month retention

Let’s consider a scenario with a longer retention period, which is common for customers running business-critical workloads in regulated industries. The monthly manual snapshots are still incremental snapshots.

If your monthly data change is 200 GiB, the estimated chargeable backup storage size is 700 + 12*200 + 30*50 – 1000 = 3,600 GiB.

Simulations

To better understand how backup storage size associates with data changes, we have set up the following two environments to simulate and capture the backup volumes charges for a month.

Simulation 1

For our first simulation, we conducted an experiment in a Region with no other RDS instances created in the same account during the testing period. The environment parameters are as follows:

• Database engine – Oracle
• Initial database storage – 40 GiB
• Initial database size – 30 GiB (table size 27.4 GiB with index size 0.4 GiB)
• Final database storage size – 140 GiB (storage auto scaling enabled)
• Workload – Based on record count in current table, perform 5% INSERT, 4% UPDATE, and 1% DELETE every day
• Manual snapshot – Every Sunday
• Snapshot retention – 31 days
• Period – October 16, 2021, to November 17, 2021

The testing instance was configured with RDS Storage Auto Scaling, which increased storage capacity automatically in response to data growth in the workload. Based on our recorded data, the database allocated storage grew to 140 GiB at the end of the testing. With the help of AWS Cost Explorer, we can visualize the cost and usage for the charged back cost, as shown in the following screenshot. The amount of charged backup usage is 823.84 GiB during the testing period.

During the initial 3 days, there is no charged backup cost, because backup storage size is less than allocated database storage size. From the fourth day onward, the charged backup cost increases per day, because new snapshots are created daily, and no snapshots are deleted within the retention period.

Simulation 2

The second environment contains other RDS instances that have a larger total Amazon Elastic Block Store (Amazon EBS) volume size but with a retention period of 1 day for all except the testing instances. The parameters are as follows:

• Database engine – SQL Server
• Initial database storage – 20 GiB
• Initial database size – 10 GiB (9 GiB data file, 1 GiB log file)
• Final database storage size – 256 GiB (storage auto scaling enabled)
• Workload Patterns – 5% INSERT, 4% UPDATE, and 1% DELETE daily
• Manual Snapshot – Every Monday
• Snapshot Retention – 31 days

The difference between the second simulation compared to the first is the existence of other RDS instances within the same Region, which means the total database storage size is larger than just one instance. The total database storage for other instances amount to 61 GiB prior to the simulation. Based on our variables, the following graph shows the total backup charges for a period of 30 days from October 18 to November 17. There is a dip in the usage and cost of the backup storage on November 14 due to the increased Amazon RDS storage allocation. This shows that the total database storage size has an impact on the cost of your backup storage.

The backup storage cost wasn’t registered for half of the period, because the backup storage size is less than the allocated database storage size. For more information, refer to Amazon RDS for SQL Server Pricing.

How do you track backup charges per database instance?

You can track the backup charges of your individual database instance through the usage of cost allocation tags. We highly recommend that you tag your database instances when you first create them in order to track their charges later. For more information about tagging your Amazon RDS resources, refer to Amazon RDS now supports detailed backup storage billing.

Conclusion

In this post, we explained key variables affecting your Amazon RDS backup cost, as well as how to estimate backup storage size for common scenarios. The key takeaway points are:

• Delete manual snapshots that are no longer required
• Keep the retention period minimal to meet your business recovery point objective
• Apply cost allocation tags to track backup storage cost

Apply these key takeaway points to optimize and track your backup storage cost and if you have any comments or questions, leave them in the comments section.

About the Authors

Donghua Luo is a Senior RDS Specialist Solutions Architect. He works with AWS customers to migrate and achieve higher flexibility, scale, and resiliency with database services in AWS cloud.

Barry Ooi is a Senior Database Specialist Solution Architect at AWS. His expertise is in designing, building and implementing data platform using cloud native services for customers as part of their journey on AWS. His areas of interest includes data analytics and visualization. In his spare time, he loves music and outdoor activities.