How To: AWS Cost Savings for Oracle RDS

Oracle RDS costs can climb fast. The usual cause is the response to poor performance: add IOPS, move to a bigger instance, and repeat as the data grows. Each step is easy to make in the cloud, and each one adds to every bill that follows.

This post covers how to get out of that cycle by fixing the workload first, then sizing RDS to match.

Where the Cost Comes From

Generally speaking – we come across two types of scenarios for “problem” Oracle RDS deployments:

• Lift and shift of an existing poorly performing Oracle database – the performance problems get migrated to the cloud along with the data.
• New implementation of custom or packaged application that hasn’t been optimised for data growth.

The initial response to poor performance for both scenarios is typically the same:

• Increase the IOPS for the RDS instance EBS volumes.
• Increase the instance size to add more memory and CPU.

One of the big selling points of going to the cloud is that these things are easy to do – and they are. It’s also just as easy to set yourself on a path for ever-increasing RDS costs as your database grows.

When you increase provisioning to fix poor performance, you also commit to adding more IOPS, CPU and memory every time data volumes or workload grow.

How the Costs Multiply

Consider a typical scenario: a standard 2TB Oracle RDS instance running on r5.4xlarge with 10,000 provisioned IOPS. As the data volumes grow and workloads increase, two things happen to multiply your Oracle RDS costs:

• The size of the EBS volumes increase – this cost is multiplied by the number of provisioned IOPS on the RDS block volumes.
• The replica copy in a multi-AZ configuration also increases (let’s assume here that you’re running multi-AZ for production databases).

Before long you’re in a position where your Oracle RDS costs are increasing faster than your databases are growing (EBS size + provisioned IOPS + replica copy + non-prod copies etc).

How to Achieve Real AWS Cost Savings

Well-optimised database workloads are even more important in the cloud. Poorly optimised Oracle RDS will have a direct impact on your cloud service bills.

The most effective cost savings come from optimising the Oracle workload first, then rightsizing the AWS infrastructure to match the optimised performance profile.

Start with Oracle-Specific Optimisations

Check the SQL workload and execution plans The usual Oracle optimisation principles apply, but for Oracle RDS we’re specifically looking for statements that perform much higher physical IO than what would reasonably be expected.

Common culprits include:

• Missing or incorrect indexing.
• Empty interface tables that have full scans performed.
• Updating many rows in a table where a CTAS (Create Table As Select) could be used instead.

Review automatic maintenance jobs Check whether you really need the SQL Tuning Advisor and Segment Space Advisor auto jobs to run. Both can generate additional workload for no benefit if you don’t use the advisor outputs.

You want to leave the auto Gather Stats job running – but avoid doing a full gather stats on the schema/database “just because.”

Identify wasted space allocation Check if there are segments or table spaces that have “large” amounts of unused space. “Large” is going to be very subjective here – but we’re looking for space in the database that has been allocated but not used.

You can probably see where we’re going with this. Optimising the IOPS consumed by the Oracle RDS instance and using correctly sized block storage ensures that you’re not paying for wasted IOPS or unused space.

This AWS cost saving is multiplied if you have multi-AZ configured and also require matching non-prod environments.

Rightsizing Your Oracle RDS Instance

By this stage you should have “right sized” your AWS Oracle RDS storage configuration based on actual workload requirements rather than performance band-aids.

If you’ve been going down the path of increasing the provisioned IOPS and instance size to solve your performance problems, then it’s time to rightsize the instance to match the optimised workload profile.

The optimisation approach depends on your workload pattern:

• For workloads with optimised SQL statements (using indexes vs. full scans): You can typically reduce both the RDS instance size and provisioned IOPS
• For legitimate full scan-based workloads: You can reduce instance size but may need to maintain higher IOPS
• For instances with significant unused space: You can reduce both block storage size and the IOPS required

The end result is an instance sized for the workload once it’s been optimised.

Expected Outcomes from Proper Rightsizing

From these changes you’ll typically find:

• Better scalability: The database will scale with additional workload much better. You’ll have more headroom on the instance for additional workload, and more consistent response times.
• Predictable cost management: Cloud cost forecasting becomes much easier when you’re not accommodating “waste” workload or inconsistent query response times.
• Lower cost: a smaller instance and fewer provisioned IOPS, with the same or better performance.

Locking in Long-Term Cost Savings

Well-optimised Oracle RDS performance is predictable. This enables you to accurately understand your workload profile and what attributes (CPU, memory, storage) of the RDS instance types are needed to service your workload.

This predictability opens up two areas that can drive additional cost savings:

Instance Class Optimisation

Consider running your Oracle RDS workload on a smaller M class instance instead of a T class instance for similar cost. M class instances often offer more consistent response times for database workloads, which equals more predictable sizing for your instance.

Reserved Instance Strategy

Configure reserved instances for your database servers. This can offer substantial cost savings when multiplied out across multi-AZ and non-prod environments.

AWS discounts reserved instances against on-demand pricing, and the saving applies to every multi-AZ and non-prod copy. A predictable, optimised workload is what makes committing to a one or three-year term safe.

You’ve now replaced over-provisioned cloud services with right-sized instances whose performance is predictable enough to commit to long term.