This course examines the RDS (Relational Database Service) expense metrics offered by Amazon. Optimizing cloud expenditure is always a top concern when architecting and creating your cloud solutions. It’s important to know where your costs are coming from and what you can do to cut them.
This course examines the expenses associated with each RDS component and the breakdown of those expenditures. It examines data transmission, backup storage, backtrack storage, on-demand instances, reserved instances, database storage & I/Os, and snapshot export.
You may reach us at firstname.lastname@example.org if you have any comments about this course.
- Recognize the various payment choices and database instance purchase possibilities.
- Discover the I/O cost choices and significant storage details.
- Investigate the expenses related to backup and backtrack storage.
- Find out how much data transfers and snapshot exports cost.
Anyone in charge of planning, running, and improving AWS Database systems should take this course. Additionally, it would be helpful for those who intend to take the AWS Certified Database – Specialty exam.
You should have a fundamental grasp of the AWS global infrastructure to get the most from this course. A basic understanding of the database engines covered in this course—Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server—would be helpful but is not required.
Hello and welcome to this lecture, in which I will examine the configurations for primary storage and I/O price.
I want to concentrate on the storage components of your databases and how these costs are determined across the various DB engines now that we have looked at the price choices for your database compute instances.
Elastic Block Store (EBS) volumes are used by MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server for data and log storage. On the other hand, Aurora does not employ EBS and instead uses a shared cluster storage architecture.
So let’s start by looking at the prices for most DB engines that use EBS.
RDS offers three distinct kinds of storage configurations:
- SSD for General Purpose Storage
- Storage with provisioned IOPS for SSD
General-purpose SSD storage: This is an excellent alternative with single-digit millisecond latency and a cost-effective storage solution for various use cases. The minimum SSD storage for your primary data set is 20 GiB, and the maximum SSD storage for SQL Server is 16 TiB.
The maximum SSD storage for MySQL, PostgreSQL, MariaDB, and Oracle is 64 TiB. When utilizing SSD, you are only paid for the storage that is provisioned—not for the I/Os performed.
Provisioned IOPS (SSD) storage is a fantastic choice if you have workloads that require a lot of I/O. For MySQL, PostgreSQL, MariaDB, and Oracle, you can supply up to 80000 IOPS. However, the most you can provision for SQL Server is just 40000. The minimum storage for your primary data set is 100 GiB, with a maximum of 64 TiB for MySQL,
PostgreSQL, MariaDB, and Oracle, and 16 TiB for SQL Server. Additionally, you must be able to supply the IOPS required for your workload. Again, you are not paid for the total number of I/Os performed; instead, the fees for this choice depend on the quantity of storage provided in addition to the chosen IOPS throughput.
Lastly, magnetic storage is only supported to provide backward compatibility; AWS advises choosing General Purpose instead.
The settings screen for figuring out your MySQL storage needs is shown in the image below. With a minimum of 100 GiB of primary storage and 1000 provided IOPS as throughput, Provisioned IOPS (SSD) has been chosen as the storage in this example.
Now let’s look at how much the storage will cost you.
Depending on whether your database deployment has been set up as a single-AZ or multi-AZ, there are two alternative pricing points for the storage charges. Multi-AZ deployments are often twice as expensive as single-AZ deployments, much like instance pricing.
The costs of General Purpose SSD, Provisioned IOPS (SSD), and Magnetic storage change for each kind of storage. Priced per GB-Month for each sort of storage employed, but what precisely is a GB-Month?
This essentially states how many GBs of storage have been allocated and for how long. Let me use an illustration. The following circumstances might lead to a cost for 10GB-Months of storage if we are dealing with a 30-day billing cycle: