The Essential Guide to Amazon RDS Pricing and Optimization

Amazon Web Services makes getting your data into their Relational Database Service (RDS) relatively easy. Import costs are free, and you can store up to 100 terabytes across all your instances. AWS hosts your relational databases in the cloud, and their engineers handle patching, monitoring, availability, and some security concerns.

These factors make getting started with RDS easy, but understanding and controlling your costs is another matter entirely. In this article, you’ll see how Amazon’s Relational Database Service is priced, how you can get insights into your current spend, and finally, some tips for minimizing your costs.

Amazon RDS Pricing Factors

Instance usage, storage, I/O, backups, and data transfers drive the bulk of your RDS costs. Instance usage and storage are unavoidable, but generally, you should minimize them while adequately addressing your needs. RDS offers some I/O and backup capability bundled into the cost of storage, but you might need more. Moving data into RDS from the internet is free, but moving it out of RDS can get expensive.

In this section, I’ll dive deeper into each of RDS’s pricing factors to help you understand how your usage might affect your monthly bill.

Database Engine

Amazon currently offers six database engines: Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server. Normally you won’t be able to change your database engine, but you can choose to optimize for memory, performance, or I/O.

The three open-source databases (Postgres, MySQL, and MariaDB) are similar in price. Depending on the size, PostgreSQL instances are five to ten percent more expensive per hour, but PostgreSQL, MySQL, and MariaDB share pricing for storage, provisioned I/O, and data transfer.

Aurora is Amazon's proprietary database, so it gets special treatment. AWS offers a serverless option, making it ideal for applications that don’t need to be on all the time, like test environments. Aurora also has a multi-zone backup system that charges per million replicated I/O operations. Storage per gibibyte (GiB) is a few cents more expensive, but if you're dealing with intermittent usage or need fast failovers and many read replicas, Aurora can save money over implementing these features on other engines.

Oracle and SQL Server aren't open-source or owned by Amazon. To accommodate licensing, hourly instances can cost nearly twice as much. You can self-license with Oracle, which brings the cost in line with open-source options. Other fees, like storage and data transfer, match their open-source counterparts.

While this guide isn’t intended to help you choose the best database engine, it is important to note that pricing varies based on the engine you choose.

Instance Size

Once you select an engine, you have to select an instance size with the appropriate computational (vCPU), network (Mbps), and memory capacity (GiB RAM). RDS offers instances ranging from

db.t3.micro

db.m5.24xlarge

Selecting the right instance size can be challenging. To estimate the instance size you’ll need, estimate or track the amount of data your queries need (called your working set), then select an instance that can fit your working set into memory. I’ll touch on monitoring and right-sizing your instances later in this guide.

Reserved Instances

Without additional configuration, instances are created on-demand. These instances are billed in one-second increments from the moment the instance starts to its termination. You can stop, start, or change an on-demand instance size at any time.

The alternative to on-demand pricing is Reserved Instances. You commit to lease an RDS instance for a set period (1 or 3+ years) in exchange for discounts up to 60%. AWS offers sizing flexibility for all Reserved Instance engines except SQL Server and License Included Oracle, allowing administrators to freely change instance size within the same family. If you're able to commit to RDS for a year or three and have monitored your requirements enough to develop a solid performance baseline, you can save money by trading away the flexibility to turn off or downsize your databases.

Storage

For most engines, you buy storage per GiB in advance. Aurora is the exception: you only pay for what you use. It's important to accurately predict your monthly storage needs as you cannot reduce storage on an instance except Aurora.

AWS can auto-scale your storage when an instance has under 10% space remaining for more than 5 minutes. This option has the benefit of keeping storage costs low, but can surprise you if something unexpected happens. To protect against auto-scaling to 65,536 GiB, set a maximum storage threshold for your instance.

If you can accurately predict your storage needs, manually provisioning is the cheapest option. If you're facing unpredictability or unused storage, consider auto-provisioning and focus on maintaining a reasonable storage maximum.

Backups

AWS backs up 100% of the storage you've purchased in any zone for free. If you buy 20 GiB of storage across two instances, it includes 20 GiB of backup space.

If you need more space for backups, you pay per GiB at a slightly lower rate than regular storage costs. RDS automatically backs up each storage volume every day. These backups are stored according to the backup retention period. Automated backups will not occur if the DB's state is not

AVAILABLE

STORAGE_FULL

Regions

As with most AWS services, RDS costs are specific to a region. Choose your region carefully because the most expensive regions double the hourly cost of instances, increase storage by a few cents per GiB, and 5x inter-zone data transfer pricing.

On the other hand, if your database is located further from your application servers, you’ll add latency to every database call. If this latency degrades user experience, you probably don’t want to use a distant, slightly cheaper region.

Multi-AZ Deployments

If you need availability when an AWS regional data center encounters trouble, you can enable Multi-AZ deployments. This creates a backup database instance and replicates your data to a second AWS data center. Be aware that this doubles your monthly instance and storage costs but enhances the reliability of critical services. If you need a Multi-AZ deployment, focus on reducing your storage needs and instance size, these gains are won twice.

Understanding Your RDS Spending

Once you understand the many options RDS offers and set up an instance, there are a few tools that will help you audit your current usage and predict future requirements.

AWS Cost Explorer

The best way to audit your RDS spending is the AWS Cost Explorer. Activating and examining your daily or monthly spend is an excellent way to visualize your organization’s priorities.

Tagging your resources helps you understand which projects and teams are using which databases. Cost Explorer also offers suggestions for using reserved instances based on your past usage.

RDS Management Console and Enhanced Monitoring

AWS provides a “Monitoring” tab in the RDS Console that displays free-tier CloudWatch metrics like the number of connections and CPU utilization. Keeping an eye on your usage in the console can help you prepare to right-size your storage or purchase reserved instances.

AWS gives you the option to activate additional monitoring services.

Performance Insights gathers data about the database load. This tool has its own pricing model with a free tier that includes 7-day retention.

Enhanced Monitoring is stored and priced as CloudWatch logs. It reports metrics from a user agent instead of the hypervisor, allowing you to examine running processes and the OS, which is useful for examining the resource usage of individual queries.

Finally, you can enable and access database logs directly for the price of storing the files.

RDS Cost Optimization

Armed with insights into your requirements and RDS’s abilities, it’s time to put cost-saving measures and AWS best practices to use. In the rest of this guide, I’ll offer some strategies for decreasing your RDS costs using the insights you gathered above.

Right-Sizing your Instances

In short, turn off anything that’s not being used.

Every month, you pay for instances and storage and the infrastructure attached to them. You can check each database’s utilization using the connections metric in the RDS Console. On-demand RDS instances can be stopped for up to 7 days. When stopped, you aren’t charged for DB Instance hours, but you are charged for storage. You can use an AWS Lambda scheduled event and DB Instance API calls to programmatically stop and start instances.

To practice right-sizing, act on your monitoring and purchase the machine with the minimum requirements to meet your needs. Multiple RDS instances can also be consolidated into a single instance to minimize costs. This is especially helpful for development environments where a low number of users can access several databases running on a single instance. CloudForecast also makes this easy through our ZeroWaste Health Check Report that reports on all your overprovisioned and unused RDS instances. By getting a full roll up of possible idled resources, you can easily see and turn off anything that is not being used.

Database Hygiene

Indexing and database sanitation are both important for controlling costs. Proper indexing is important for performance and I/O, as it allows your instance size to remain small and minimizes bottlenecks.

Removing unused tables, columns, and indexes directly impacts your storage costs. Caching and batching statements can improve performance. You can use Enhanced Monoring and database-specific tools like the MySQL slow query log to track and examine outliers that take lots of resources, then optimize them.

RDS IOPS

Input/Output (I/O) operations are extremely important to databases. You use an input operation to write to the database and an output operation to read data. You can monitor read and write I/O per second (IOPS) from the RDS Console.

General Purpose SSD instances start fully stocked with 5.4 million IOPS credits, enough to perform 3,000 operations a second for 30 minutes. They also generate I/O credits at a rate of 3 IOPS per GiB of storage.

In the first months of an RDS transition, keep an eye on your IOPS credit balance (also reported in the RDS console) so you don’t run out.

The options for directly increasing I/O are purchasing more storage or switching to the Provisioned IOPS storage type, where you pay a fixed price per thousand IOPS. Indexing and increasing the instance size can also increase I/O speed as each item in the queue is handled more efficiently.

CloudWatch Metrics

CloudWatch is an excellent monitoring tool, but it incurs its own costs. It’s important to consider your monitoring frequency. Going from 5-minute monitoring to 1-minute monitoring will dramatically increase the size of your logs. If your CloudWatch budget is slowly expanding, consider modifying the log data retention period and auditing your alarms to be sure they’re relevant.

Data Transfer Cost

Importing data to RDS from the internet is free, but you often want to use your data elsewhere. Data transfer out to the internet costs between .09 and .13 cents per GiB. Data transfer prices between zones are very dependent on the chosen zone, ranging in price from .02 to .13 cents per GiB.

Be aware that you’re actually charged twice: once when the data leaves a zone and again when it enters a target zone. To reduce these costs, minimize the amount of data you’re sending. Limit queries, and don’t re-run reports. Transferring data between Amazon RDS and EC2 Instances in the same Availability Zone is free, so you can sidestep some data fees by consolidating services into a single zone.

RDS Snapshots

Database snapshots contribute to your storage costs as well. You can reduce backup storage by reducing your backup retention period and deleting manually created snapshots, which are never automatically removed. If you need to store snapshots, move them somewhere cheaper like an S3 instance. For MySQL, storing snapshots in S3 is about 1/5 as expensive as keeping them in RDS.

Conclusion

AWS RDS is extremely powerful and deeply customizable, but the complex pricing model means that your monthly spend can grow quickly and unexpectedly.

RDS optimization starts with understanding your current requirements using monitoring tools like CostExplorer and CloudWatch. Once you know the resources you need, you can select the best region, instance engine, and size. Then, keep an eye on your IOPS credits, data transfers between zones and out to the internet, and backup requirements. Database hygiene matters even more when you’re paying per GiB, so optimize queries and use efficient indexes.

Reach out to me at, [email protected], if you’d like help tagging your resources or implementing a long-term cost-reduction strategy.

Previously published at https://www.cloudforecast.io/blog/aws-rds-pricing-and-optimization/