Course Summary
Start course

This course explores the cost metrics associated with the Amazon Relational Database Service, known as RDS. Minimizing cloud spend is always a priority when architecting and designing your cloud solutions, and care should be taken to understand where your costs come from and the steps you can take to reduce them.

This course looks at each of the components associated with RDS that incur a cost and how those costs are broken down. It looks at on-demand instances, reserved instances, database storage & I/Os, backup storage, backtrack storage, snapshot export, and data transfer.

If you have any feedback relating to this course, please feel free to contact us at

Learning Objectives

  • Understand the different database instance purchasing options and payment plans
  • Learn about primary storage and I/O pricing options
  • Explore the costs associated with backup storage and backtrack storage
  • Learn about the pricing for snapshot exports and data transfers

Intended Audience

This course is intended for anyone responsible for designing, operating, and optimizing AWS Database solutions. It would also be advantageous for individuals planning to take the AWS Certified Database - Specialty exam.


To get the most from this course, you should have a basic understanding of the AWS global infrastructure. It would be beneficial, but not essential, to have a basic awareness of the database engines covered in this course, i.e. Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.


Hello and welcome to this final lecture. I just want to summarise some of the key points made throughout each of the previous lectures.  

I started off by discussing the different DB instance purchasing options, which included:

  • On-demand instances
  • On-demand instances (BYOL)
  • Reserved instances
  • Reserved instances (BYOL)
  • Serverless

I explained that currently, only the Oracle database engine uses the BYOL purchase options, whereas all other DB engines only use on-demand instances and reserved instances, with the added exception of Aurora has a serverless purchasing option as well.  

On-demand instances vary based upon the size and class of the instance, in addition to it’s running time which is billed hourly.  If you implement a multi-az solution instead of a single az deployment, then your running costs for your instance is effectively twice the price due to the standby instance launched in another availability zone.

When running Aurora serverless you are instead charged based upon the number of Aurora Capacity Unit (ACUs) per hour that are utilized.  

With both Oracle and SQL server, your on-demand pricing is also affected by the edition selected for each DB engine

  • Oracle
    • Standard Edition One (SE1)
    • Standard Edition Two (SE2)
  • SQL Server
    • Express
    • Web
    • Standard

At the time of writing this course, on-demand instances BYOL are only available with Oracle and supports the following editions:

  • Standard Edition
  • Standard Edition One (SE1)
  • Standard Edition Two (SE2)
  • Enterprise Edition

As you are only paying for the compute instances when using BYOL, there is no variation in prices between the different editions of Oracle being used and so this could save you cost if you already own and use Oracle licenses

Due to the discount associated with reserved instances, you can save a considerable amount by selecting a reserved instance at either a 1- or 3-year commitment, especially when coupled with the payment option of ‘all upfront’.  The same instance types apply as with the on-demand instances, the key here is simply the savings to be made through commitment of resources. 

Also, the same options apply for Oracle, SQL Server, and Aurora Serverless as it does with on-demand instance pricing as I highlighted previously

This follows the same principles I covered earlier when discussing BYOL for on-demand instance pricing but has the added advantage of the reserved instance savings.

Following the purchasing options, I then looked at database storage and I/O Pricing. In this section, I explained that for the primary storage of your MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server database, all use EBS. However, Aurora uses a shared cluster storage architecture.

The DB engines using EBS can use one of the 3 following options depending on the required use case:

  • General Purpose SSD storage, which is priced on per GB-months provisioned
  • Provisioned IOPS (SSD) storage, which is priced on both per GB-months for storage provisioned, and per IOPS-month used for the provisioned IOPS
  • Magnetic storage, which is priced on per GB-months used for storage provisioned and per 1 million requests for I/O rate consumed

Aurora storage will scale automatically as your database grows. As a result, the pricing structure for your Aurora database is priced differently.

You are charged based on GB-Months used (not provisioned, unlike EBS storage), plus the number of I/Os processed, which are billed per million requests. As a result, you are only charged for the actual consumption rather than storage that has been provisioned.

Following primary storage pricing, I looked at Backup Storage, and I covered different circumstances that utilize backup storage.  The key points from this lecture are as follows: 

  • RDS does not charge any backup storage costs that equates to the total sum of provisioned storage used with your databases within a specific region.  
  • Backup storage used over this is charged at $0.10 per GiB-Month for any region for all DB engines except Aurora
  • Aurora is charged differently based upon the region
  • Both automated and manual backups use backup storage
  • Extending your backup retention will increase backup storage used

Next up I looked at the costs associated with the backtrack feature which is only available on the MySQL-compatible Aurora database which allows you to go back in time to recover from an error or incident.  The cost is directly associated to how many hours, and how many changes within those hours were made.  To help you keep an accurate record of the number of change records, you can use Amazon CloudWatch to help you monitor the number of change records that are being generated each hour.  

The pricing is based upon a set cost per 1 million change records per hour and can be calculated using this formula:

Obtain the total number of change records for your backtrack time period:

Change records / hour set for backtrack = Total number of change records 

Calculating total costs:

(Total number of change records / 1,000,000) x $ cost in region  = $/hour

I then looked at the cost of exporting your snapshots from Amazon RDS to Amazon S3 where further analysis of the data could be undertaken.  When doing so, the cost depends on which region you are exporting from and is priced per GB of snapshot size.  Using KMS you can encrypt your snapshot, which may incur additional costs depending on the encryption keys used.  Also note, you will be charged for any S3 storage costs and PUT requests made.

Finally, I looked at the different circumstances on when you would be charged for data transfer relating to operations within your RDS database, which included:

  • Data transferred IN to your RDS database from the internet - FREE
  • Data transferred OUT from your RDS database to the internet - Tiered pricing structure per GB
  • Data transferred OUT to Amazon CloudFront - FREE
  • Data transferred OUT to AWS Regions - $0.02/GB
  • Data transferred OUT to EC2 instances in the same availability zone - FREE
  • Data transferred between availability zones for multi-az replication - FREE
  • Data transferred between an EC2 instance and an RDS instance in different availability zones of the same region -  $0.01/GB in each direction
  • Data transferred when a snapshot copy is transferred to a different region - $0.02/GB

That now brings me to the end of this lecture and to the end of this course.  

As you can see there are a wide scope of features and circumstances in which you will be charged for using Amazon RDS.  Understanding how you utilize, implement, and architect your database solutions will play a big part in how much it will cost you to run. Having foresight of where these costs arise will allow you to design your database environments with cost measures being taken into account.

If you have any feedback on this course, positive or negative, please do contact us at, your feedback is greatly appreciated.

Thank you for your time and good luck with your continued learning of cloud computing. 

Thank you.


About the Author
Learning Paths

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.