In this blog, we will explore RDS rightsizing, discussing its significance and benefits. We’ll also cover key best practices and actionable steps for minimising costs associated with RDS instances.
Before diving deep into RDS rightsizing, we need to understand what the term rightsizing means.
Generally, Rightsizing is the process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost. It’s also the process of looking at deployed instances and identifying opportunities to eliminate or downsize without compromising capacity or other requirements, which results in lower costs. In the case of RDS, we want to match the DB instance and storage types to the workload performance and capacity requirements at the lowest possible cost.
If an RDS instance is over provisioned, then the cost of using that RDS instance can be very high. This is when rightsizing can be beneficial to optimise the overall cost of running an RDS database in AWS.
Now let us look at various factors that can lead to high RDS cost:
- Database instance hours: Resources incur charges when they are running; for example, from the time you launch a database instance until you terminate it.
- Database characteristics: The physical capacity of the database you choose will affect how much you are charged. Database characteristics vary depending on the database engine, size, and memory class.
- Database purchase type: When you use On-Demand database instances, you pay for compute capacity for each hour your database instance runs, with no required minimum commitments. With Reserved database Instances, you can make a low, one-time, up-front payment for each database Instance you wish to reserve for a one or three-year term.
- Number of database instances: With Amazon RDS, you can provision multiple database instances to handle peak loads.
- Provisioned database storage: There is no additional charge for backup storage of up to 100 percent of your provisioned database storage for an active database Instance. After the database Instance is terminated, backup storage is billed per GB per month.
- Additional storage: The amount of backup storage in addition to the provisioned storage amount is billed per GB per month.
- Deployment type: You can deploy your DB Instance to a single Availability Zone (analogous to a standalone data center) or multiple Availability Zones (analogous to a secondary data center for enhanced availability and durability). Storage and I/O charges vary, depending on the number of Availability Zones you deploy to.
In this blog, we are mainly focused on the provisioned capacity of the RDS instance which leads to high cost.
AWS RDS pricing:
As an example, let us conduct a comparison of graviton-based DB instance type pricing against an intel DB instance type in Asia Pacific (Sydney) region.
Graviton offers a range of powerful features, including:
- Enhanced Performance and Power Efficiency: The Graviton2 processor boasts an improved architecture, delivering superior performance and power economy. This results in faster job execution and cost savings through lower resource utilisation.
- Cost Savings without Compromising Performance: Compared to their x86 counterparts, Graviton-based instances provide significant cost savings while maintaining or even improving performance and functionality.
- Extensive Application Support: Graviton processors enjoy extensive application support, thanks to partnerships with software vendors and open-source communities. This means existing applications can be seamlessly migrated and run without any compatibility issues.
- Integration with AWS Nitro System: Graviton Processors are fully compatible with the AWS Nitro System, enabling users to leverage specialised hardware for virtualised tasks. This integration reduces system overhead and enhances overall speed.
- Versatile Instance Options: Graviton-based instances are available in multiple families, catering to a wide range of workloads. Whether it’s general-purpose, compute-intensive, memory-intensive, or burstable workloads, there’s a suitable Graviton instance for every requirement.
db.m6g – General-purpose DB instance classes powered by AWS Graviton2 processors. These instances deliver balanced compute, memory, and networking for a broad range of general-purpose workloads.
db.m6i – General-purpose DB instance classes powered by 3rd Generation Intel Xeon Scalable processors. These instances are SAP Certified and ideal for workloads such as backend servers supporting enterprise applications, gaming servers, caching fleets, and application development environments.
In the screenshot below we have showed an estimated price calculation of an Intel based m6i.4xlarge DB instance type for a MySQL database.
However, we can significantly reduce the price of this RDS database by moving to a graviton based architecture without compromising on performance.
Below screenshot shows the pricing calculation using m6g.4xlarge graviton based instance type.
RDS Cost optimisation best practices:
- Use RIs: Reserved Instances (RIs) are a way to commit to using a certain amount of RDS capacity for a certain period. This can lead to significant savings compared to on-demand pricing.
- Use Spot instances for RDS read replicas or to run other non-critical workloads: Spot instances are a way to take advantage of unused capacity in the AWS cloud and can lead to significant savings compared to on-demand pricing.
- Use autoscaling: AWS RDS allows you to scale your database instance up or down based on your workload. By using autoscaling, you can ensure that you are only paying for the resources you need at any given time. Read AWS’s blog on scaling RDS instances vertically and horizontally to learn more.
- Ensure you are right-sizing your RDS instance types: Choosing the right instance type for your workload is critical to optimising costs. If your instance is too large, you may be paying for resources you don’t need. If it is too small, you may experience performance issues. You can read AWS docs and cost management articles to self educate on right-sizing.
- Remove backup for non-critical RDS: If you don’t need backup, you can save costs by removing it. However, if you do need backup, make sure to enable tag propagation to snapshots from the main RDS, as it’s not enabled by default. Read more about RDS backup features and automated backups on AWS’s docs.
- Use database storage optimisation: You can optimise storage by archiving or deleting no longer needed data, and by using compression and encryption to reduce storage costs. AWS offers two storage types: Provisioned IOPS SSD and General Purpose SSD, which offer different performance and cost options. Choosing the right storage type for your workload can lead to significant savings.
- Remove enhanced monitoring and insights if you don’t need them: Enhanced monitoring and insights are additional features that come at an extra cost. If you don’t need them, removing them can help reduce costs.
- Periodically review and delete manual snapshots (or move encrypted snapshots to S3 bucket instead): Manual snapshots are a way to back up your database, but they can also take up a lot of storage and lead to increased costs. By periodically reviewing and deleting manual snapshots that are no longer needed, you can reduce costs.
- Stop RDS during off-work hours: If your database is not needed during off-work hours, you can stop it to reduce costs. However, make sure to have a plan for restarting it before it’s needed again. You can use AWS Lambda functions to start and stop using these services, as well as an automated scheduler.
- Use Multi-AZ only when necessary: Multi-AZ (Availability Zone) deployment provides high availability and automatic failover in case of a database instance failure. However, it also comes at an additional cost. If high availability is not critical for your workload, consider using a single AZ deployment to reduce costs.
Rightsizing possibilities:
There are various parameters that can be rightsized for an RDS instance. This includes DB instance type, storage type, storage size, storage IOPS, throughput.
Instance Type and storage are separate entities in RDS, and they can be managed separately. What it means is depending upon the requirement and recommendation both instance type and storage parameters can be rightsized independently.
FinOps technical approach for RDS rightsizing:
It is possible to write a boto3 API based automated solution that interacts with your AWS accounts to action the necessary steps to modify an RDS database for rightsizing purpose.
This automated suite can read the recommendations from cloud governance tools like Cloudability or even a Cloudwatch metrics. This automated solution is then able to read what parameters are required to modify to achieve the recommended cost. APIs can take a snapshot of the database and then modify the parameters immediately or during maintenance period. In case of a failure, it can report what went wrong as an SNS notification or through SMTP emails.
Conclusion
Rightsizing is an effective strategy for achieving considerable savings on Amazon RDS instances. It’s all about making sure your infrastructure meets your organisation’s capacity and performance requirements. Rightsizing is a continuous process that requires constant monitoring and analysis of your AWS environment. Some SaaS products like Cloudability or native tools like Cloudwatch Metrics can be used to track costs, performance, and utilisation across AWS accounts, projects, regions, resources, and costs.
