Mark BurgessOracle RDS costs can quickly spiral out of control. We’ve seen instances where monthly bills skyrocket quickly, blowing budgets along the way. The pattern is always the same – organisations respond to poor performance by throwing more resources at the problem, locking themselves into an expensive cycle of ever-increasing AWS bills.
Here’s how to break that cycle and optimise your Oracle RDS deployment for both performance and cost.
The Expensive Trap Most Organisations Fall Into
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.
The hidden cost multiplier most people miss: When you increase your cloud service provisioning to fix poor performance, you’re not just paying for the additional resources – you’re locking yourself into a never-ending cycle of adding more IOPS and CPU/memory as data volumes or workload increases.
The Real Cost Impact
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).
What starts as a $8,000 monthly bill can easily become $25,000+ when you factor in the cost multipliers of poorly optimised workloads.
How to Achieve Real AWS Cost Savings
Well-optimised database workloads are even more important in the cloud. Poorly optimized 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.” This single optimisation can reduce your IOPS consumption by 20-30% during maintenance windows.
As the data volumes grow and workloads increase, two things happen to increase the Oracle RDS cost:
- 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 as well (lets assume here that you are running multi-AZ for production databases).
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 that’s correctly matched to the required database workload, not the inefficient one.
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.
- 40-60% cost reduction: Most properly optimised Oracle RDS instances see significant cost reductions while maintaining or improving performance.
Locking in Long-Term Cost Savings
Well-optimized 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.
Industry benchmarks show that reserved instances typically provide 30-50% savings over on-demand pricing for stable workloads. When combined with proper optimisation, total cost savings of 60-70% compared to the original over-provisioned setup are achievable.
The transformation: You’ve gone from accommodating wasteful database workloads with over-provisioned cloud services to having right-sized cloud instances with predictable performance that can be locked in over the long term.
Get Your Oracle RDS Cost Assessment
Want to know exactly where your Oracle RDS costs are going? We can usually spot the biggest savings opportunities in a 30-minute conversation.
Book a complimentary Oracle RDS cost workshop – no sales pitch, just straight answers about your specific situation and immediate optimisation opportunities.
FAQ
How can one optimise SQL workloads to improve Oracle RDS performance and cost-efficiency on AWS?
Optimising SQL workloads involves identifying and modifying inefficient SQL queries that consume excessive CPU and I/O resources. This can be achieved by using AWS RDS performance insights and Oracle’s own AWR (Automatic Workload Repository) reports to pinpoint high-load queries. Once identified, these queries can be optimised by rewriting them, creating or adjusting indexes, and considering the use of Oracle’s SQL Plan Management to ensure stable execution plans. Effective SQL optimisation reduces the computational demands on the database, allowing for potential downscaling of the RDS instance type and consequently lowering costs.
What strategies should be considered when reviewing auto jobs in Oracle RDS on AWS for cost savings?
Reviewing and optimising auto jobs involves assessing the necessity and efficiency of scheduled tasks such as backups, statistics gathering, and application-specific jobs. Strategies include scheduling jobs during off-peak hours to minimise impact on performance and potentially allowing for the use of lower-capacity RDS instances. It’s also important to evaluate the frequency of jobs to ensure they’re run only as often as necessary. For example, less critical data might not need to be backed up as frequently, or statistics on stable tables might not need to be gathered after every minor change. Streamlining these jobs can lead to more efficient use of resources and cost savings.
How does configuring reserved instances for Oracle RDS on AWS lock in cost savings over the long term?
Configuring reserved instances (RIs) for Oracle RDS on AWS involves committing to a one or three-year term for a specific instance type in exchange for a significant discount compared to on-demand instance pricing. This long-term commitment allows organizations to lock in lower costs, which can be particularly beneficial for stable workloads with predictable resource needs. When choosing RIs, it’s crucial to accurately assess your database’s resource requirements to select the appropriate instance size and term length. This assessment should take into account not only current needs but also anticipated growth or changes in workload. Additionally, AWS offers Convertible RIs, which provide some flexibility to change the RI’s attributes if your needs change over the RI term, albeit with a slightly lower discount rate than standard RIs.
