Migrate to Amazon RDS for Oracle with cost optimization

When migrating Oracle Database applications to AWS, you have many opportunities to modernize and optimize your architecture. This migration provides increased agility and flexibility, as well as the potential to migrate to a fully managed service, such as Amazon Relational Database Service (Amazon RDS) for Oracle. RDS for Oracle offers compute scaling, automated backups, event notifications, and more. It also helps relieve DBAs and other IT staff of many traditional aspects of Oracle Database infrastructure administration, allowing them to focus their attention on application aspects that lend more value to the business. In this post, we discuss several of our frequently recommended steps to optimize costs when migrating and running Oracle databases on AWS. Implementing these steps requires detailed database and application knowledge. As such, this post is targeted at DBAs and DBA managers.

Migrating is a prime time to optimize costs by right-sizing resources to the needs of the workload, taking advantage of AWS automation and features you didn’t have in your traditional data centers, and reevaluating your need for legacy solutions and third-party add-ons. Although a lift and shift in the simplest sense would be an easy path to the cloud, that method brings with it all the over-provisioning and legacy aspects of your on-premises solution. Analyzing your true needs as you embark on the migration project allows you to potentially avoid migrating unnecessary data, reduce downtime compared to implementing changes separately, and save time by combining testing efforts. You don’t need to address everything during the migration, but look for changes with a clear return on investment (ROI). You may even find that certain applications can be completely retired or absorbed into another system.

Retire what you can

The first suggestion is obvious on one level: after all, there is no cheaper way to run an application than not running it at all. But it’s worthwhile to verify that each database and its hosted applications are still relevant when you’re planning for migration. They may be running simply because no one bothered to stop them—or a stopped system was restarted after an incident as part of an outdated playbook. Know what you’re moving, who the stakeholders are, and what the database supports before moving forward with decommissioning or migrating the workload.

Retiring a database that is already running on Amazon RDS for Oracle is easy: by default, the service takes a final snapshot of the instance before deleting it. You can restore that snapshot later if you determine you need access to that data. Amazon RDS allows you to upgrade the snapshot if the major version has been deprecated in the meantime.

Examine feature usage and question the need for Enterprise Edition over Standard Edition

After you identify an Oracle database that you need to migrate, examine its Oracle Database edition and feature requirements. For more information about Enterprise Edition (EE) vs. Standard Edition Two (SE2), refer to Rethink Oracle Standard Edition Two on Amazon RDS for Oracle.

The price difference between EE and SE2 is substantial. If an application doesn’t require EE features or add-ons, migrating it to SE2 can remove dependence on EE licenses and higher support costs, as well as provide the option to run on Amazon RDS for Oracle License Included (LI) instances or an open-source database engine. LI instances allow you to pay as you go for Oracle Database licensing as well as the compute instance, which opens up additional savings potential and avoids long-term license purchases and contracts. Amazon RDS for Oracle offers synchronous replication to a second Availability Zone and automated failover for both EE and SE2 with Multi-AZ deployments, providing an alternative to Oracle Data Guard or self-managed storage replication. We have discussed ways to remove reliance on features such as partitioning and alternative methods for SQL plan management previously. Consider a combination of Amazon RDS Performance Insights and Oracle Statspack for your performance analysis needs, rather than Oracle Diagnostics and Tuning Packs for Oracle Enterprise Manager, which are separately licensed on top of EE. Amazon RDS for Oracle supports Oracle Transparent Data Encryption (TDE), which requires licensing the Advanced Security Option, and it also provides Amazon RDS storage encryption via AWS Key Management Service (AWS KMS) keys natively.

Implement reasonable application query and Oracle instance tuning changes and baseline performance ahead of the migration

Tuning an application reduces its resource consumption, whether in a data center or in the cloud, and we recommend performing regular analysis and tuning of database applications—especially prior to migration. A poorly performing query impacts the user experience, but it also requires more resources to run. More resources consumed—often across multiple aspects of compute, memory, storage operations and throughput, and network bandwidth—means greater costs that don’t add value to the application, and these should be reduced or eliminated. Be sure to baseline the database performance prior to the migration; this will help you determine whether performance issues are related to the migration itself or the application. Performance Insights supports Oracle query run plan capture to help you identify changes during the migration.

Examine recent resource consumption for current needs and target the appropriate instance class and size

When you’re determining resource requirements for a database application, it’s critically important to understand actual resource consumption and not simply duplicate the current resource allocation. In a capital expenditure model where servers are typically refreshed every few years, administrators often have to over-provision systems for today’s usage in anticipation of growth before the next refresh cycle. This leads to lower cost-efficiency while the workload doesn’t need those additional resources. However, when running your application on Amazon RDS for Oracle or self-managed Oracle on Amazon Elastic Compute Cloud (Amazon EC2), provisioning a larger instance and making more resources available to the database is a matter of just a few minutes’ outage. This means it’s easy to respond quickly to changes in workload demand—both increases and decreases—rather than guessing at future needs. It also enables you to stay up to date with the latest instance type with a new chipset and the fastest CPUs. Newer chipsets and higher clock speeds can mean fewer CPU cores are required to support a given workload, potentially allowing you to downsize to a smaller instance and save costs. Oracle has provided tools such as the Automatic Workload Repository (AWR, EE only) and Statspack (EE and SE2) to help DBAs assess performance and resource requirements. We have built a solution based on Oracle AWR data to help you assess resource requirements at scale.

Remember: when you provision a CPU for a commercial database, you’re generally required to pay a database license cost whether the database actively uses that CPU or not. Your goal should be to minimize CPU consumption and then provision only what you need for a given workload to avoid wasting money on infrastructure and licensing. Amazon RDS for Oracle offers the latest generation of EC2 instance classes with excellent performance/price ratios and also offers extended memory instances with up to 32:1 memory-to-vCPU ratio for right-sizing. Additionally, watch out for databases on premises that have been over-provisioned on CPU and RAM to make up for under-performing storage. Amazon RDS for Oracle offers high-performance, low-latency block storage options with Amazon Elastic Block Store (Amazon EBS). Allocating the amount and class of storage the database needs can be cheaper in the long run than allocating additional cores and RAM.

Consider also your actual performance requirements for an application, as opposed to its current performance. Similar to over-provisioning for future growth, allocating more resources than required to achieve your performance objectives potentially means wasting money on unnecessary performance improvements. Determine what performance you need today, and allocate resources to achieve that performance, without spending more to achieve unnecessary gains.

Consider migrating large objects and historical data to an object store, like Amazon S3

Block storage is more expensive than object storage. Many serverless applications can interact directly with objects on Amazon Simple Storage Service (Amazon S3), which is a highly available and extremely durable object store. Replacing large objects (LOBs) with Amazon S3 URLs can drastically reduce the total storage capacity required for the database, moving the objects out where other applications can potentially interact with them more easily, and making the database smaller and cheaper to run. Additionally, some open-source databases interact with LOBs differently, meaning removing them from the database can be a step toward eventually migrating to an open-source database engine. This will require application changes but may well be worth it for databases where the bulk of data is in the form of LOBs.

You may consider a similar approach to implementing data life cycling, where you perform one-time exports of old data by partition, date range, or other data characteristic, storing the resulting export files in Amazon S3 and removing the data from the database. In the event the data is needed later, you can import the data back into the primary database or create a separate database instance to which to restore the historical data while it’s needed, and then drop that instance when it’s no longer required. Oracle Data Pump can perform such an export, or you can use Oracle SQLcl or a custom procedure to export data directly into a comma-separated value (CSV) format that, when stored in Amazon S3, may be accessed by other tools, such as Amazon EMR, for analysis.

Determine HA and DR requirements per application and implement solutions granularly

Business-critical applications require high availability (HA), and nearly every application needs a disaster recovery (DR) plan. But Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) vary widely by application and environment. With a monolithic architecture running bin-packed databases, every core has to be licensed for every database option, whether a given database needs the option or not. In Amazon RDS for Oracle, you can host each database on its own instance, allowing you to enable HA features, such as Multi-AZ deployments and Oracle Data Guard-based replication within an AWS Region or even across Regions with Oracle replicas, on a per-instance basis. This allows you to optimize the license allocation and spend for applications that truly need these features, while relying on automated backups and even cross-Region automated backups for applications with less stringent RPO and RTO requirements.

Consolidate smaller, related applications into a single database, and break up larger, unrelated applications into their own databases

Database bin packing is still very common: A small number of physical servers, with each CPU licensed for the database software, and a large number of smaller databases co-hosted for maximum cost-efficiency of those licenses. This results in a smaller number of servers and database installations to manage, but the downside is that this model presents little option for hardware, operating system, or database maintenance without impacting multiple aspects of the business. Buying a small server to host a database is risky—What if the database outgrows the server? In AWS, changing out the underlying instance class or shape is efficient, reducing risk. Applications may be commingled or separated as appropriate for your business needs. In today’s microservices landscape, it makes sense to split up applications for individual right-sizing and scaling, customized maintenance needs and windows, and DR solutions tailored to individual RPO and RTO requirements. We recommend only commingling those applications that truly make sense to run together.

Consider a caching service for frequently requested objects

Caching for relational databases with Amazon ElastiCache is another area where a purpose-built system can offload frequently run queries and requested objects to a high-performing system, delivering even lower response times to applications while reducing the read load directed toward the database. This type of change requires application changes but can improve application responsiveness while also reducing the database infrastructure allocation.

Take advantage of AWS-native services and features

After closely examining the requirements of each database application, consider what functionality may be offloaded to a managed service. Amazon RDS for Oracle delivers optional EBS encryption for your database, and it automatically backs up your database in-Region and can be configured to back up cross-Region with just a few clicks. With automated backups, you can perform a point-in-time restore (PITR) operation to a new database instance with only a few clicks or a single API call. You can refresh a non-production environment from a snapshot of production in minutes. You can also use replicas to provide DR options and facilitate blue-green deployments. Multiple options are available in AWS to improve your operations over on-premises environments, making them run faster, with less effort, and less expensively.

Turn off instances when they’re not in use to save on instance charges

You can stop EC2 and RDS for Oracle instances as needed and save on instance costs (allocated storage is still charged) until you need them available again. You can use AWS Instance Scheduler or AWS Lambda to start the instance at the beginning of the workday and stop it at the end, cutting the instance costs significantly for environments that don’t need 24×7 availability. For more information about using Lambda with Amazon RDS, refer to Schedule Amazon RDS stop and start using AWS Lambda. We also have burstable instances for applications that see occasional spikes, and these instances can burst to absorb the additional load and provide greater cost-efficiency than allocating a larger instance full time.

Iterate on these best practices

As with performance tuning, cost optimization is rarely ever completely done. Applications change, in turn altering their resource requirements, and data volumes fluctuate. In the absence of comprehensive data life cycling processes, a database will continue to grow over time. Although we recommend frequently monitoring an application’s performance and resource requirements, you can also configure Amazon CloudWatch alerts to notify DBAs when resource consumption crosses an upper or lower threshold, indicating that it’s time to think about scaling up or down. You can even configure a Lambda function to perform a scaling operation for you when the alarm is triggered.

Once you have a good idea of your instance needs, purchasing a Reserved Instance can substantially reduce operating costs for RDS for Oracle instances. If you can eliminate your reliance on EE features and migrate to SE2, you may also consider the License Included (LI) option for Amazon RDS for Oracle. In the LI model, you don’t need to purchase Oracle licenses separately. AWS holds the license for the Oracle database software. In this model, if you have an AWS Support account with case support, contact AWS Support for both Amazon RDS and Oracle Database service requests.

Conclusion

In this post, we discussed best practices for cost optimization when migrating Oracle databases to Amazon RDS for Oracle. Because every environment is unique, some of our suggestions will have greater impact than others to your specific use case.

If you have questions about planning your migration or how to implement any of these suggestions, we encourage you to work with your account team to locate an AWS Partner or engage an AWS specialist to work directly with you.

About the Author

Nathan Fuzi is a Principal Oracle Specialist Solutions Architect at AWS. He is a frequent presenter at AWS Data Modernization Week and AWS Online Tech Talks. Nathan works directly with AWS customers to migrate, run, and optimize their database applications on Amazon RDS for Oracle. With over 20 years of experience in the database realm, he enjoys helping customers build technical solutions to solve business problems.