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 RDS hosts your relational databases in the cloud, and their engineers handle patching, monitoring, availability, and some security concerns.
These factors make getting started with AWS RDS easy, but understanding and controlling your costs is another matter entirely. In this article, you’ll learning the following with AWS RDS:
AWS RDS Cost and Pricing
- AWS RDS Database Engine
- RDS Instance Sizes
- Reserved Instances
- RDS Storage: Aurora and Autoscaling
- RDS Backups
- Multi-AZ Deployments
RDS Cost Monitoring
- AWS Cost Explorer
- RDS Management Console and Enhanced Monitoring
AWS RDS Cost Optimization
- Right Sizing your Instances
- Database Hygiene
- RDS IOPS
- RDS CloudWatch Metrics
- RDS Data Transfer Cost
- RDS Snapshots
Instance usage, storage, I/O, backups, and data transfers drive the bulk of your AWS RDS costs. Instance usage and storage are unavoidable, but generally, you should minimize them while adequately addressing your needs. AWS 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 AWS RDS’s pricing factors to help you understand how your usage might affect your monthly bill.
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.
AWS 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 accomodate 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.
Once you select an engine, you have to select an RDS instance size with the appropriate computational (vCPU), network (Mbps), and memory capacity (GiB RAM). RDS offers instances ranging from
db.t3.micro (2 vCPUS, 1 GiB RAM, 2085 Mbps) to
db.m5.24xlarge (96 vCPUS, 384 GiB RAM, 19,000 Mbps).
Selecting the right RDS instance size can be challenging. To estimate the RDS 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 RDS monitoring and right-sizing your RDS instances later in this guide.
Without additional configuration, RDS 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 for RDS. 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.
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.
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 (for example, if the state is
STORAGE_FULL). Users can also create manual backups. These never expire and count against your backup storage total.
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.
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.
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.
The best way to audit your RDS spending is the [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/. Activating and examining your daily or monthly spend is an excellent way to visualize your organization's priorities.
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.
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.
CloudForecastsupplements AWS’s Cost Explorer through proactive monitoring and optimization reports that keeps your RDS cost in check.
Through the daily cost reports, you'll receive a daily report via email or slack that details your RDS cost in relation to your overall spend and alerts you of any cost anamolies with RDS.
The tagging compliance report helps make sure your RDS instances are properly tagged and let you know exactly which RDS resources are not following compliance.
Finally, the ZeroWaste Health Report (beta) let's you know of possible inefficiencies by identifying all your over-provisioned and unused RDS instances in one single report.
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.
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.
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. Cachingand 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.
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 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.
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.
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.
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.
If you’re struggling to understand your AWS spend, CloudForecast can help. Reach out to our CTO, email@example.com, if you’d like help tagging your resources or implementing a long-term cost-reduction strategy.
This was originally posted on our blog on 11/17/2020: https://www.cloudforecast.io/blog/aws-rds-pricing-and-optimization/