.png)
Key takeaways
1
The included backup-storage allowance is shared across all eligible RDS instances in the same Region, rather than calculated separately for each database.
2
Automated backups, manual snapshots, and retained automated backups can all contribute to your total backup-storage usage.
3
Manual snapshots remain available and may continue generating charges until you delete them.
4
Changing backup retention between zero and a positive value can cause a brief database outage.
5
Amazon Aurora uses a different backup-storage model, so standard RDS billing rules should not be applied to Aurora clusters.
Amazon RDS includes a regional backup-storage allowance based on the provisioned storage of your active DB instances. You pay for backup storage that exceeds the applicable allowance at the rate for your database engine and AWS Region.
That sounds simple, but the total can include automated backups, customer-initiated snapshots, retained automated backups, and copies in other Regions. This guide explains what drives RDS backup cost and how to investigate an unexpected charge without deleting recovery points you still need.
That sounds simple, but the total can include automated backups, customer-initiated snapshots, retained automated backups, and copies in other Regions. This guide explains what drives RDS backup cost and how to investigate an unexpected charge without deleting recovery points you still need.
Important distinction:
The included backup-storage allowance is not the AWS Free Tier. The AWS Free Tier is a separate promotional program with account eligibility, credits, and time limits. The standard backup allowance is part of normal RDS pricing and does not depend on whether your account qualifies for Free Tier benefits.
Why am I being charged?
If an RDS backup charge appears on your bill, investigate these five possible causes:Backup storage exceeds the allowance created by active DB instances in the Region.
Manual or final snapshots have accumulated over time.
Automated backups were retained when a source DB instance was deleted.
Snapshots or automated backups were copied to another AWS Region.
Snapshot exports created separate Amazon S3, request, or AWS KMS charges.
Start with Cost Explorer to identify the type and Region of the charge. Then move to the RDS console to identify the backups or snapshots behind it. Export-related charges require a separate review of the destination S3 bucket and KMS usage.
For example, suppose one Region contains:
How RDS backup storage is billed
For standard Amazon RDS DB instances, AWS provides backup storage up to 100% of the total database storage provisioned for active instances in an AWS Region. This is an aggregate regional allowance.For example, suppose one Region contains:
Instance A with 200 GiB provisioned
Instance B with 500 GiB provisioned
Instance C with 300 GiB provisioned
Total provisioned storage of 1,000 GiB
Those active instances collectively create up to 1,000 GiB of included backup storage in that Region. They do not each retain an isolated allowance that only their own backups can use.
Customer-initiated snapshots and automated database backups both contribute to backup storage. If the aggregate footprint exceeds the allowance, AWS charges for the excess using the applicable engine-specific and regional rate.
Because AWS pricing varies by database engine, deployment, and Region, this article does not use one rate as a universal figure. Confirm the current rate through the relevant official Amazon RDS pricing page or model the intended configuration in AWS Pricing Calculator.
Customer-initiated snapshots and automated database backups both contribute to backup storage. If the aggregate footprint exceeds the allowance, AWS charges for the excess using the applicable engine-specific and regional rate.
Because AWS pricing varies by database engine, deployment, and Region, this article does not use one rate as a universal figure. Confirm the current rate through the relevant official Amazon RDS pricing page or model the intended configuration in AWS Pricing Calculator.
Scope note:
This article covers standard Amazon RDS DB instances. Amazon Aurora uses separate backup-storage and retention rules. Consult the Aurora backup-storage documentation before applying these calculations to an Aurora cluster.
For the cost of the primary database volume, provisioned IOPS, and throughput, see the separate RDS storage pricing guide.
What each backup option does
| Backup component | How storage is treated | Expiration behavior |
|---|---|---|
| Automated backups for active instances | Contribute to regional RDS backup storage | Recovery points expire according to the retention period |
| Manual and final DB snapshots | Contribute to regional RDS backup storage | Remain until manually deleted |
| Retained automated backups | Continue under RDS backup pricing rules | Expire as their system snapshots age out |
| Cross-Region snapshot copies | Incur destination-Region storage and applicable transfer charges | Remain until manually deleted |
| Snapshot exports to S3 | Generate export processing and separate S3, request, and potentially KMS charges | Exported objects follow the destination bucket’s lifecycle rules |
Manual RDS snapshots are stored in AWS-managed infrastructure. They are not ordinary S3 Standard objects in one of your buckets and should not be estimated using the public S3 Standard storage rate.
An exported snapshot is different. The export process writes data in Parquet format to a bucket you control. After export, standard S3 storage, request, lifecycle, and encryption considerations apply to the resulting objects.
AWS’s current RDS for MySQL pricing example charges snapshot-export processing against the full snapshot size even when filtering selects a smaller table. In that example, a 100 GB snapshot is the billing basis for exporting a 10 GB table.
Treat that as an engine-specific planning example, not a universal RDS export rate. Confirm the current price and availability for your engine and Region. Snapshot export is not supported for RDS for Db2, Oracle, or SQL Server, and support for eligible engines can vary by version and Region. AWS maintains an official snapshot-export availability table.
For a broader model covering compute, database storage, backups, and other billing components, use the complete RDS pricing calculator guide.
That means the amount consumed is influenced by actual data and changed blocks. It is not simply the provisioned database size multiplied by the number of retention days.
A reasonable planning model is:
An exported snapshot is different. The export process writes data in Parquet format to a bucket you control. After export, standard S3 storage, request, lifecycle, and encryption considerations apply to the resulting objects.
AWS’s current RDS for MySQL pricing example charges snapshot-export processing against the full snapshot size even when filtering selects a smaller table. In that example, a 100 GB snapshot is the billing basis for exporting a 10 GB table.
Treat that as an engine-specific planning example, not a universal RDS export rate. Confirm the current price and availability for your engine and Region. Snapshot export is not supported for RDS for Db2, Oracle, or SQL Server, and support for eligible engines can vary by version and Region. AWS maintains an official snapshot-export availability table.
For a broader model covering compute, database storage, backups, and other billing components, use the complete RDS pricing calculator guide.
How retention changes RDS backup cost
RDS creates automated backups during the configured backup window and captures transaction logs for point-in-time recovery. After the first snapshot, subsequent snapshots are incremental.That means the amount consumed is influenced by actual data and changed blocks. It is not simply the provisioned database size multiplied by the number of retention days.
A reasonable planning model is:
Estimated backup footprint = initial occupied data + retained changed blocks
Then:
Estimated billable storage = maximum of zero or regional backup footprint minus regional allowance
Finally:
Estimated monthly charge = billable storage multiplied by the verified engine and Region rate
These formulas are illustrative. Actual storage can differ because of engine behavior, write volume, snapshot dependencies, stopped-instance time, deletion timing, and the combined backups of other DB instances in the Region.
Consider an illustrative 500 GiB DB instance containing 400 GiB of occupied data. Suppose it generates 50 GiB of unique changed blocks each day.
Consider an illustrative 500 GiB DB instance containing 400 GiB of occupied data. Suppose it generates 50 GiB of unique changed blocks each day.
| Retention period | Simplified estimated footprint | Position relative to a 500 GiB allowance |
|---|---|---|
| 1 day | 450 GiB | Within allowance |
| 7 days | 750 GiB | 250 GiB above allowance |
| 14 days | 1,100 GiB | 600 GiB above allowance |
| 35 days | 2,150 GiB | 1,650 GiB above allowance |
This table illustrates how retention can affect storage. It does not predict an invoice. Multiply the estimated excess by the current rate for your engine and Region only after verifying that rate.
AWS permits retention from 0 to 35 days for a standard DB instance. Setting retention to zero disables automated backups. Multi-AZ DB clusters support retention from 1 to 35 days.
When a DB instance is created through the RDS console, the default retention period is seven days. When it is created through the API or AWS CLI without an explicit value, the default is one day. These rules are documented in the AWS backup-retention guidance.
AWS permits retention from 0 to 35 days for a standard DB instance. Setting retention to zero disables automated backups. Multi-AZ DB clusters support retention from 1 to 35 days.
When a DB instance is created through the RDS console, the default retention period is seven days. When it is created through the API or AWS CLI without an explicit value, the default is one day. These rules are documented in the AWS backup-retention guidance.
Availability warning:
AWS states that changing a DB instance’s retention period from zero to a positive value, or from a positive value to zero, causes an outage. Do not treat enabling or disabling automated backups as a routine, nondisruptive cost change. Schedule and test it according to your production change process.
The post-deletion backup trap
Manual snapshots remain after their source DB instance is deleted. A final snapshot created during deletion behaves the same way. It remains until someone deletes it.Automated backups require a more precise explanation. When deleting an eligible DB instance, you can choose to retain its automated backups. If you select retention, the backups remain available for a period based on the retention setting at deletion. If you do not retain them, they are deleted with the instance.
Retained automated backups eventually expire. A final snapshot does not. AWS therefore recommends taking a final snapshot when long-term restoration is required, even if automated backups are temporarily retained.
Retained automated backups and manual snapshots can continue contributing to RDS backup storage after the source instance is gone. They can share the allowance provided by other active instances in the Region under the rules described in the AWS retained-backup documentation.
Before deleting an RDS instance:
1
Inventory its manual snapshots.
2
Identify the recovery purpose and owner of each snapshot.
3
Confirm applicable legal, contractual, and internal retention requirements.
4
Decide whether short-term point-in-time recovery must be retained.
5
Create a final snapshot if a longer-lived recovery point is required.
6
Assign a review or deletion date to every snapshot that remains.
Age alone is not evidence that a backup is waste. Delete a recovery point only after confirming that it is outside the organization’s approved recovery and retention requirements.
Look for backup-related usage in the account’s results. Usage-type names can vary, so use the values shown in your own billing data instead of depending on one hard-coded label.
Cost Explorer identifies the direction and location of spend. It might not identify the exact snapshot responsible for it.
How to audit RDS backup spend
Step 1: Locate the billing category
In AWS Cost Explorer, filter Service to Amazon Relational Database Service and group the results by Usage type and Region.Look for backup-related usage in the account’s results. Usage-type names can vary, so use the values shown in your own billing data instead of depending on one hard-coded label.
Cost Explorer identifies the direction and location of spend. It might not identify the exact snapshot responsible for it.
Step 2: Open the relevant RDS views
In the Region associated with the charge, review:- Snapshots, followed by the Manual tab
- Automated backups, including the Retained view
- Snapshot identifiers and creation times
- Source DB identifiers
- Snapshot types and statuses
- Copies stored in other Regions
Step 3: Classify every retained copy
Place each manual or final snapshot into one of four categories:| Category | Recommended action |
|---|---|
| Active recovery requirement | Retain and document |
| Regulatory or legal requirement | Retain according to policy |
| Temporary migration or upgrade copy | Set a review or deletion date |
| No owner or documented purpose | Escalate for approval before deletion |
A snapshot whose source instance no longer exists is a review candidate, not automatically an orphan that should be deleted.
Development and staging databases may need shorter retention than production databases, but no duration is universally correct. Select retention based on business requirements, restore-testing results, data criticality, and downstream copies.
Use the RDS Multi-AZ comparison to distinguish failover requirements from backup and disaster-recovery requirements before removing cross-Region copies.
Once backup storage is understood, compare wider database architecture through the RDS versus Aurora cost guide and evaluate predictable compute through the RDS Reserved Instance pricing guide.
With Flex Insured Commitments, Usage.ai continuously adjusts commitment coverage as workloads change, helping teams access savings of up to 57% without taking on the same long-term risk as a traditional three-year commitment.
If committed usage costs more than equivalent On-Demand usage, Cashback Protection covers the difference. Teams can pursue stronger RDS savings while retaining the flexibility to resize, migrate, or retire workloads.
Step 4: Review retention requirements
Compare the configured automated-backup period with the workload’s recovery point objective and recovery procedures.Development and staging databases may need shorter retention than production databases, but no duration is universally correct. Select retention based on business requirements, restore-testing results, data criticality, and downstream copies.
Step 5: Separate availability from recovery
Multi-AZ provides high availability within an AWS Region. A cross-Region snapshot provides a geographically separate recovery copy. Neither feature automatically replaces the other.Use the RDS Multi-AZ comparison to distinguish failover requirements from backup and disaster-recovery requirements before removing cross-Region copies.
Step 6: Investigate export charges separately
If the bill contains S3 or KMS growth rather than only RDS backup charges, inspect:- The destination S3 bucket
- Exported object size
- S3 storage class
- PUT and other request charges
- KMS encryption or decryption usage
- Lifecycle policies
- Repeated exports of the same snapshot
Once backup storage is understood, compare wider database architecture through the RDS versus Aurora cost guide and evaluate predictable compute through the RDS Reserved Instance pricing guide.
How Usage.ai helps reduce RDS costs
Usage.ai helps FinOps teams control RDS costs beyond backup cleanup. It highlights unusual cost growth that may point to excessive retention or forgotten snapshots, while targeting the larger savings opportunity in RDS compute.With Flex Insured Commitments, Usage.ai continuously adjusts commitment coverage as workloads change, helping teams access savings of up to 57% without taking on the same long-term risk as a traditional three-year commitment.
If committed usage costs more than equivalent On-Demand usage, Cashback Protection covers the difference. Teams can pursue stronger RDS savings while retaining the flexibility to resize, migrate, or retire workloads.
Frequently asked questions
How is RDS backup cost calculated?
RDS backup cost depends on aggregate backup storage, the allowance created by active DB instances in the Region, and the applicable rate for the database engine and Region. Manual snapshots, automated backups, and retained automated backups can all contribute to the total.
Is the included backup allowance part of the AWS Free Tier?
No. The standard backup-storage allowance is part of regular RDS pricing. The AWS Free Tier is a separate promotional program with its own eligibility, credits, and time limits.
Do manual and copied RDS snapshots expire?
No. Manual snapshots, final snapshots, and cross-Region RDS snapshot copies remain until manually deleted. AWS Backup-managed recovery points may follow separate plan-based retention rules.
Does changing retention cause downtime?
AWS states that an outage occurs when a standard DB instance changes from zero-day retention to a positive value or from a positive value to zero. Changing between positive values does not carry that documented outage warning.
Does this pricing model apply to Aurora?
No. Aurora has a separate backup-storage model based on cluster volume and backup retention. Verify Aurora rules and pricing independently rather than applying the standard RDS DB instance model.
Share
Facebook
X
LinkedIn
Reddit
