Fully Understanding RDS Cost Breakdown & How to Reduce It

My clients (of all sizes) always ask me: Why is my RDS cost so high?

I work with companies who spend millions or hundreds of thousands annually to Amazon Web Services (AWS), and help them improve cost efficiency on AWS. Over the course of time, I have found many hidden secrets that AWS doesn’t advertise to everyone, and so I decided to share it here in the form of a short, sweet, yet hopefully impactful newsletter. If you ever have questions about AWS, feel free to reach out by replying to this email.

In this post, we will be discussing how to reduce RDS. For those not familiar, RDS (the 2nd largest AWS service by revenue) also has a name called Amazon Relational Database Service. Capital One, ZipRecruiter, Netflix, Airbnb, and others all use Amazon RDS.

I have learned that so many companies spend more than they should be spending on RDS, for many different reasons:

1) They didn’t understand the cost breakdown of RDS (that is what the majority of this blog post is devoted towards). An example means perhaps they were spending not a lot on compute, but a lot on the other two categories.

2) They are paying more for an RDS instance because it is getting charged at the on-demand rate. Perhaps an old RI expired.

3) They didn’t understand the difference between Aurora Serverless versus traditional RDS, and when is the best time to use either.

4) They had a bunch of idle instances that were getting charged even though they weren’t being used, or were using significantly less than was required.

Starting with the first point, let’s go over how RDS costs can be broken down. First, let’s start with the basics. When we say RDS, we mean as defined by AWS Cost Explorer. So when you go to Cost Explorer, select the service as “Relational Database Service" (RDS)”, on the right hand menu under Filters.

There are three categories that come from the RDS cost in AWS:

1) Instance type costs (compute)

2) Storage costs

3) Data transfer and backup costs

So when you see on AWS Cost Explorer that you are paying $10,000 per month on RDS, it’s super critical to figure out where the $10,000 is going. Some businesses need the vast majority of RDS to be allocated towards compute, while others need a lot of RDS storage and very little compute.

Let’s dive deeper into the three different pricing categories.  

#1 – Instance type costs: reflect charges related to the computing resources provisioned for your managed databases. In other words, these costs cover CPU (computational power), memory, and network performance, and vary with your selected instance type and configuration.

Some of the key components that impact instance-level pricing:

• CPU Capacity: Cost depends on the amount of processing power (vCPUs). Instances with more vCPUs incur higher costs.

• Memory (RAM): Instances with greater RAM allocation for memory-intensive workloads have higher hourly pricing.

• Network Performance: Instances optimized for higher network throughput or lower latency generally come at higher cost.

• Instance Class (Family and Size): AWS groups RDS instances into families like general-purpose (db.m*), memory-optimized (db.r*), compute-optimized, and burstable (db.t*). Pricing differs based on these families and sizes.

Usually if your RDS instance CPU usage is never above 50%, there is a good rule of thumb that you may consider changing the instance size down. For example, large —> medium or xlarge —> large.

There are two pricing models for this part of the RDS spend: On-Demand vs. Reserved Instances.

On-Demand: Hourly billing with maximum flexibility (but at higher hourly rate). This is the default pricing model.

Reserved Instances (RI): Reduced hourly cost in exchange for a 1- or 3-year time commitment; upfront payments further reduce costs.

AND the…

Database Engine Licensing: Proprietary databases (Oracle, SQL Server) incorporate the licensing fee into the instance cost, increasing charges compared to open-source engines (PostgreSQL, MySQL, MariaDB).

In the above screenshot, you can see the dimension type we are using is instance type, with the service only being RDS. We can see that the db.t3.medium, db.t3.micro, and db.t3.small are costing $2.63, $0.97, and $0.66 respectively. That being said, there is a $0.68 cost categorized as “No instance type”. There are a few reasons for this charge including:

1) It could be because you are using RDS serverless

2) It could be because perhaps from storage costs or backup costs (or a mix of both)

The next two sections we will dive deep on what these costs come from, and how you can lower the costs of those bills.

#2 – Storage Costs: Storage costs in Amazon RDS primarily cover the provisioning and management of the storage volumes that hold your database data. Unlike instance costs (CPU and memory), storage charges depend on the amount, type, and performance level of storage allocated, as well as backup retention and snapshot storage.

1. Storage Type

AWS offers multiple RDS storage categories, each tailored for different database workloads and budget needs:

2. Provisioned Storage Capacity

RDS costs scale directly with the volume of storage you provision. If you allocate a certain amount—say 500GB—you incur charges every month for that full 500GB, regardless of how much data you actually store. (Aurora storage, by contrast, is charged according to how much storage you actually use.)

3. Storage Performance (IOPS)

With Provisioned IOPS storage, you pay extra specifically for the IOPS you allocate. If your application needs rapid, predictable database access or runs demanding transactions, you’ll pay incrementally more due to the increased performance requirements.

4. Backup and Snapshot Storage

RDS automatically generates backups and allows you to create manual snapshots. Although AWS provides some backup storage at no additional cost, excess storage used by retained backups or snapshots beyond the free allowance is charged an additional fee.

It’s a good practice to periodically review your backup policies and stored snapshots, ensuring you're not unintentionally accumulating storage costs on unnecessary backup copies.

5. How to Cut Costs in This Section

• Match the storage option to your workload: Many databases run effectively with General Purpose SSD storage. Choose Provisioned IOPS only if your workload truly requires guaranteed performance.

• Avoid over-provisioning: Monitor storage regularly and ensure you provision only as much as your workloads genuinely need.

• Regularly audit backups/snapshots: Keep retained backups lean and purposeful, to avoid unexpected charges for excessive snapshot storage over time. If you don’t need it, don’t run it!

#3 Data Transfer and Backup Costs: In addition to instance and storage charges, Amazon RDS costs can also include data transfer fees and the cost of retaining database backups and snapshots. This category often surprises organizations, as it's less obvious and easy to overlook. Here, we’ll clarify exactly what's included and how charges are determined.

1. Data Transfer Costs

AWS typically charges based on how and where your data moves. When you operate an RDS database, you'll encounter costs primarily with the following scenarios:

Data transfer OUT to the Internet:

Data leaving AWS to reach external users or applications incurs charges typically based on the total amount transferred each month.

Note: Incoming data from the Internet into AWS rarely incurs additional charges.

Data transfer between AWS Availability Zones within the same region:

If your RDS instance transfers data to instances or applications located in a different Availability Zone (AZ) within the same AWS region, you're billed at a per-GB rate.

Cross-region data transfers:

Transferring data between AWS regions (for example, from US East to US West) will incur additional charges per GB transferred.

These cross-region transfers are more expensive than transfers between AZs within the same region.

Transfers within the same AZ:

Generally free. Data transfer channels within the same AZ—between RDS instances and EC2 instances—usually do not generate any costs.

As data volumes increase, so do these transfer costs. It's beneficial to keep your database and related applications or processes in the same region and AZ, whenever feasible, to reduce transfer costs.

2. Backup and Snapshot Storage Costs  

RDS databases use automated backups and manual snapshots to ensure data durability and quick restore capabilities. However, the storage they consume can add up and incur charges:

• Automated backups: AWS offers backup storage at no additional charge up to the provisioned storage size of your RDS instance. For example, if you provision a 100GB RDS instance, you receive 100GB of backup storage at no additional charge.

  • Backup storage exceeding this amount (due to increased retention periods or larger backup volumes) leads to monthly costs per additional GB stored.

• Manual Snapshots: You can manually create snapshots, which are stored separately from your database. These incur storage fees based on the total amount of GBs they occupy per month.

  • If retained snapshots accumulate without regular cleanup or prudent snapshot management, storage charges may grow unexpectedly.

• Cross-region Backup Replication and Snapshots: If you replicate snapshots or backups across AWS regions (to enhance disaster recovery capabilities), you will incur additional storage charges at your destination AWS region and cross-region transfer fees.

  Practical Recommendations to Manage Costs:

• Limit Cross-Region Data Transfers: Whenever possible, collocate related applications and databases within the same region and AZ to minimize regional and AZ-related transfer fees.

• Regularly Manage Backups and Snapshots: Define clear and effective backup retention policies. Specifically, ensure snapshots are deleted when they're no longer needed. Regular cleanup reduces the buildup of storage charges.

Evaluate Backup Storage Needs and Retention Periods: Set retention windows carefully. Balance data recovery objectives with practical cost-reduction strategies.

Now let’s talk about the difference between using RDS instances and Aurora Serverless:

RDS Instances:

• Setup: Provisioned database service where you select instance types (e.g., t3.large) and storage for engines like MySQL, PostgreSQL, or Oracle.

• Best For: Predictable, steady workloads (e.g., enterprise apps, production databases) needing consistent performance and specific engine features.

• Control: Offers extensive customization (parameter groups, read replicas, backups) for performance tuning and replication.

• Scaling: Manual scaling of compute (instance type changes) and storage, which may cause brief downtime or require over-provisioning to handle peaks.

• Cost & Savings:

  • Pricing: Fixed costs based on instance size and storage, predictable but not flexible.

  • Save Money When: Workloads are stable and predictable, allowing you to right-size instances and avoid overpaying for unused capacity. Use Reserved Instances (1- or 3-year commitments) for up to 40-60% savings on long-term, consistent usage.

  • Cost Risk: Over-provisioning for peak loads can waste money during low usage periods.

Aurora Serverless:

• Setup: Serverless variant of Aurora (MySQL/PostgreSQL-compatible) that auto-scales compute (Aurora Capacity Units) and pauses during inactivity.

• Best For: Unpredictable or sporadic workloads (e.g., dev/test environments, apps with variable traffic) requiring minimal management.

• Control: Limited configuration options compared to RDS; lacks some Aurora features like advanced replication or fine-tuned settings.

• Scaling: Automatic scaling with no manual intervention; compute pauses when idle, resuming instantly when needed.

• Cost & Savings:

  • Pricing: Pay-per-use based on compute and storage usage, with no upfront costs.

  • Save Money When: Workloads are intermittent or unpredictable, with long idle periods (e.g., nightly batch jobs, dev databases). Pausing compute during inactivity eliminates costs for unused resources.

  • Cost Risk: High, sustained workloads can lead to higher costs than RDS due to per-second billing.

So when deciding between Aurora Serverless and Amazon RDS…

• Choose RDS for predictable workloads where Reserved Instances and right-sized provisioning save money over time.

• Choose Aurora Serverless for variable or low-usage workloads where auto-scaling and pausing compute during idle times reduce costs. Always monitor usage patterns to avoid unexpected expenses with either service.

Thanks so much for taking the time to read this! Enjoy.

Yaddle out.