Amazon Relational Database Service (RDS) is a fully managed cloud-based service by AWS (Amazon Web Services) that simplifies the setup, operation, and scaling of relational databases. It automates many time-consuming administrative tasks like hardware provisioning, database setup, patching, and backups, allowing businesses to focus on their core applications.

RDS supports several popular database engines, like MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server, making it a versatile solution for different workloads. With RDS, companies benefit from high availability, automated backups, and the ability to scale vertically or horizontally based on their performance requirements.

However, while RDS reduces the burden of database management, it also introduces cloud-specific cost considerations. To effectively manage budgets, businesses must optimise their use of resources within AWS RDS. By understanding the pricing structure and employing cost-saving strategies, organisations can maximise performance while keeping expenses in check.

Here are some of the key things to consider when implementing the RDS/Aurora PostgreSQL database.

Identify the right instance

Amazon RDS offers a variety of instance classes, each designed for specific use cases. For example, burstable instances are ideal for applications that do not require constant CPU power but need additional compute capacity during periods of high demand. EBS-optimised instances, on the other hand, are better suited for workloads that require consistent and reliable I/O performance. Other instance types are available and should be selected based on the specific demands of your workload.

To avoid overspending, it is crucial to use benchmarking tools to evaluate and choose the most appropriate instance class based on your performance needs. Without proper evaluation, you may end up paying for more resources than necessary.

R6G instance class is cheaper than R5 instance class with similar hardware and performance. AWS R6g Vs. R5 Instances: Side-By-Side Comparison | CloudZero

Reserving the instance types

Many users are aware that committing to specific instance types for an year or three years through AWS Reserved Instances can save around 40% compared to on-demand pricing. However, it’s important to carefully assess your usage needs before making a reservation. If your estimates are inaccurate and the reserved instances go unused, you’ll still be responsible for the cost, potentially negating the savings.

Provisioning IOPS/Throughput

When provisioning IOPS or throughput, it’s crucial to align them with the capabilities of your chosen instance type. Over-provisioning resources beyond what the instance can handle is inefficient and can lead to unnecessary costs, as you’ll be billed for unused capacity.

For example, the db.m5.2xlarge instance supports a baseline of 12,000 IOPS. If you provision 20,000 IOPS, the extra capacity won’t be utilised, yet you’ll still incur the cost. Therefore, it’s essential to verify the limitations of your instance type before provisioning IOPS or throughput to ensure that your resources are cost-effective and properly matched to your workload.

This is applicable to both RDS and Aurora instances too.

Aurora IO optimized instances

AWS introduced IO-optimised instances, where the cost for IOPS is zero. These instances are ideal for workloads where IOPS expenses exceed 25% of the total cost of running Aurora (including compute and storage). While IO-optimised instances eliminate IOPS costs, they come with a 30% higher compute cost and double the storage cost compared to standard instances.

These instances are ideal for databases with smaller sizes but high workloads that require significant IOPS. If you’ve already purchased reserved instances and want to switch to IO-optimised instances, you will need to purchase 30% more instances to match the new pricing structure. Otherwise, you’ll be charged at on-demand rates, which could increase costs.

Aurora storage cost

Aurora PostgreSQL supports automatic storage shrinking, which can help reduce costs. Regularly purging data from main tables to S3 using the aws_s3 extension can further optimise storage expenses. For users who require database refreshes from production to pre-production for application testing, it’s recommended to use copy-on-write clones. These clones are fast and incur no additional storage costs until the data is modified, following a “pay for what you modify” model. This approach is particularly beneficial for users dealing with large data volumes, offering significant cost savings.

Conclusion

Cost optimization in AWS RDS requires a strategic approach to balancing performance and expenses. By understanding the pricing models and leveraging features like instance reservations, IO-optimised instances, and copy-on-write clones, users can significantly reduce costs while maintaining high performance. Regularly purging data to S3, choosing the right instance types, and carefully estimating resource needs are all critical to avoiding unnecessary expenses. With the right tools and strategies in place, businesses can maximise their investment in AWS RDS while keeping their cloud costs under control.