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 support@cloudacademy.com., your feedback is greatly appreciated.

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

Thank you.