Storage
Mobility
Protection
Analysis and control
TOPICShare
Subscribe to our blog
Thanks for subscribing to the blog.
Oracle remains a popular choice for both SaaS and enterprise database applications. Since its inception in 1977, Oracle has been one of the quieter dominant players in the database industry. That tradition continues in the cloud, as Oracle is a viable option for AWS database deployment.
With the modernization of data management and much of it moving to the cloud, so too has Oracle. What is great about Oracle databases in AWS is that there are multiple deployment options to choose from: either through AWS’s fully managed service, Amazon Relational Database Service (Amazon RDS) or by building the database on native AWS Amazon EC2 compute instances.
Both of these methods of deploying Oracle on AWS come with their own sets of pros and cons. Where Amazon RDS provides a managed service that takes away much of the heavy lifting and design considerations, deploying on EC2 provides a developer much more control and flexibility.
In this article we will consider both of these Oracle deployment options on AWS, and show how NetApp Cloud Volumes ONTAP managed storage solutions can help.
Oracle on AWS: An Intro
Oracle was the first relational database ever commercialized, which took place in the 1980s. Many of the fundamental, daily electronic transitions that take place today likely pass through some form of Oracle database. Oracle is especially popular with enterprise resource planning systems and financial systems. Even Amazon.com itself ran on Oracle until 2019.
However, as popular as Oracle has been for the past several decades, there has been a mass exodus for open-source options, such as Postgres. This platform migration has a lot to do with Oracle’s licensing practices, expensive price tag, and slowness to adapting to the cloud.
Many of your enterprise applications that you will need to migrate to the cloud probably still run on Oracle. To continue those operations in the cloud, AWS is a provider that should be strongly considered. Enabling developers to deploy Oracle databases for nearly a decade, AWS has a great array of options for Oracle customers.
Before we go in-depth about the different options for deploying Oracle on AWS, it’s important to consider how you will get your Oracle database to the cloud. AWS has developed a few different methods to migrate databases. For example, AWS Storage Gateway allows developers to create a copy of their data infrastructure on AWS that integrates with their on-premises database. There is also AWS’s Database Migration Service, which utilizes change data capture technology to keep your databases in sync, thus reducing downtime. Alternately, If you’re using an existing NetApp system and plan on using EC2 for your database, SnapMirror® can easily get your data from the data center to a Cloud Volumes ONTAP environment on AWS.
Another technicality you will need to consider when migrating to AWS with Oracle is the Oracle AWS licensing agreement. Oracle is usually quite strict with licensing and the running environment. Luckily, AWS is one of the few cloud providers whose users can fully take advantage of Oracle, provided they have a license. AWS offers two different types of licensing methods, largely dependent on the deployment model that you plan on taking advantage of: You can either include your licensing fees in with your charges for Amazon RDS or you can bring your own license (BYOL).
As mentioned above, there are two options when it comes to deploying your Oracle instance on AWS, either with the managed service or by building it on AWS storage and compute. Both provide slightly different benefits, so it is important you figure out which one is right for you. Let’s take a look at them each below.
Using the Amazon RDS Managed Service for Oracle
One of the easiest ways to spin up an Oracle instance is just to use Amazon Relational Database Service. This is a managed service that allows you to spin up a host of different types of relational databases, including Oracle. It is very popular because of its easy set up.
Ease of use: As a managed service, Amazon RDS makes it easy to deploy Oracle with the task of configuring the database yourself. All you need to do is select the type of database, version (from the versions provided), size, cores, and you're essentially done from the standpoint of deploying. There are a few other parameters that you will need to set up, but compared to launching Oracle on premises, this is easier.
Scalability: Another benefit of deploying Oracle on AWS is its ability to scale easily. Unlike on-premises solutions that will often require you to buy more hardware and then wait months for that hardware to arrive. RDS lets you scale as needed up to 64 TB. This means if you suddenly double your transactions or data size, you can pay for more space or compute. In that same vein, if you are using less space and compute you can reduce costs. However, if your database is larger than 64 TB, or if its data growth pattern will eventually reach that threshold, this can become a concern.
Cross-regional support: Another more recent benefit to Amazon RDS is cross-region read replica support. This had been a major limitation when deploying Oracle on AWS in the past. Without this kind of support, databases were at much higher risk of downtime and data loss, which is not tolerable at the enterprise level. The release of cross-region read replica support for Oracle has largely solved these issues, though there are a few stipulations. For Amazon RDS users you must be using versions Oracle Enterprise Edition 12.1 or greater to create cross-region replicas. Also, if you’re using a BYOL license then you must also own a separate license for Oracle Active Data Guard.
Drawbacks and Limitations to the AWS RDS Service
The benefits mentioned above make Amazon RDS popular largely because they don't require users to have much hands-on control over the database. However, handing over that responsibility introduces some limitations.
Configuration and Flexibility: Using Amazon RDS limits your ability to configure and optimize your Oracle instance for your specific deployment needs. Since RDS does not give you access to the database servers’ file system, you won’t be able to configure how your system will run monitoring, backups, management agents and restoration. Furthermore, you don’t have the ability to use every optional module available in Oracle Database. One of the things that makes Oracle popular is its ability to fine-tune and optimize the underlying configuration. This provides developers the ability to configure their database to their applications vs. the other way around.
Version Limitations: Another limitation is the Oracle version you can deploy on AWS. You can find a list of the Oracle editions you can deploy on AWS here. This should be less of an issue for new Oracle instances but might cause problems if your company hasn’t been keeping up to date with the new Oracle versions.
Cloud Lock-In: Using Amazon RDS is specific to AWS. That means that you will make design decisions and code around Amazon RDS and AWS exclusively. If your team ever decides they want to migrate away from AWS, then they will have to rewrite their code to match wherever your new Oracle instance will be deployed. That will increase costs and slow down the new deployment, potentially making it less likely of ever leaving the platform.
Managed Service Charges: Another tradeoff for handing responsibility for the database to AWS is that you are now being charged at a premium for the routine tasks of configuring and maintaining Oracle on AWS. Pricing for Amazon RDS is determined by the amount of storage used as well as how long the service is provided at an hourly rate. For example, if you spin up an Oracle instance on RDS that is a db.t3.micro which has 1 core, 2 vCPUs and 1 GiB of memory and run it all month, AWS estimates that it will cost around $20 a month.
And while the service is fully managed, it will still require supervision on your part as the user.
The 64 GB Threshold: As mentioned above, scalability on RDS only goes so far. Once a database reaches that 64 GB threshold, the service will effectively not be applicable for that database. While not every database scale that large, for an enterprise deployment it can be quite common.
Deploying Oracle with AWS EC2 Instances Using Managed Storage
Another method to deploy an Oracle database on AWS is to use EC2 as a VM and deploy your own Oracle instance. EC2 is an elastic compute service provided by AWS that can act as a virtual machine for your Oracle instance to exist on.
As far as designing and deploying Oracle on EC2, there is a lot more flexibility and control than with RDS. You have full control over how you want to store the data itself, whether it’s in AWS EBS (Elastic Block Storage) or some other AWS storage service, like Amazon EFS or S3. You can also control how you back up your service, how often, and what kind of backups you’ll use.
These are just a few of the reasons a developer might decide to launch an Oracle instance on EC2 instead of RDS. Let’s look at some more in detail:
More control over configuration and optimization: This is the important distinction. With a database built on EC2, the developer will have more control of the database and its configuration. You aren’t limited to the parameters provided to you by RDS. If there are more specific settings or optimizations you would like to select for your Oracle instance, that is entirely possible.
One example of this is where you locate and manage your data. You can decide to use striping for your data across EBS (Elastic Block Store) volumes for improved performance or you can decide to leave your data as is on EBS. Small optimizations such as these help you better tune your Oracle instance depending on the size of your data and use case. With Amazon RDS, you don’t get this much control, and wind up with a database that isn’t optimized for your usage.
Scalability: Using an EC2-based Oracle database will essentially give you limitless scale. You can add instances as needed, with the only costs being the additional resources you need to provision. Managed storage services that run on top of such databases may have limitations as well; but, as you can see in the case with Cloud Volumes ONTAP, which can scale to over 368 TB, this far exceeds the 64 TB cap on RDS.
Avoid vendor lock-in: By developing your Oracle instance on EC2 you can design it to be more portable across various cloud providers. This is dependent on how reliant you built the rest of your services on AWS. If you decide to use S3, AWS Gateway, and other AWS components, then you will have a hard time moving your infrastructure because all of these technologies are AWS specific.
Meaning you will need to rewrite all of your code base that interact specifically with those components.
Cross-Region: Similar to RDS, deploying on EC2 with Oracle allows you to create cross-region duplicates of your Oracle database.
Deploying Oracle on EC2 comes with more control and flexibility, however, all that flexibility does require a higher level of technical skill. to manage your custom architecture. Unlike Amazon RDS, which is geared to be a managed service, optimizing your architecture on EC2 requires a database admin or developer who understands what they are doing at a much deeper level.
More points of failure: Another drawback to deploying your Oracle Instance on EC2 is you are allowing for more points of failure. You will be utilizing many different AWS components, each with their own set of logging and management. If an issue occurs in any of them, it may be difficult to assess where the problem is coming from. It also just puts your team at greater risk in general of a component failing.
One solution to these drawbacks is to employ a storage management layer over your AWS deployment, such as NetApp Cloud Volumes ONTAP, NetApp’s enterprise cloud data management platform, which can solve issues related to data protection, storage efficiency, business continuity, automobility, and cost-optimizations.
A Cloud Volumes ONTAP Managed Storage Case Study
One Oracle user that was able to deploy managed storage for their database on Cloud Volumes ONTAP was a major financial software enterprise located in the US. Their business is to develop and market software and services to help individuals and small-to-midsize businesses manage finances, tax preparation, and accounting. A considerable portion of the US population relies on this company’s software to prepare their taxes every single year.
This company had a directive to move all operations to the cloud by the end of 2020, which included thousands of VPCs in multiple regions. To run their Oracle Goldengate with high availability, this company had to choose between the managed service (Amazon RDS) and managed storage option. While it would have been possible to replicate Oracle from their on-premises data center to AWS RDS, or to replicate Oracle RDS between two different AWS regions, they chose to deploy with a database on EC2 with Cloud Volumes ONTAP instead.
The main benefits to this approach were clear:
- Centralized management through Cloud Manager supporting 1000s of AWS accounts and VPCs.
- AWS high availability for business continuity that met their strict Recovery Point Objective (RPO) of zero seconds, and Recovery Time Objective (RTO) of under 60 seconds.
- Multi-region disaster recovery backed by NetApp Snapshot™ and SnapMirror technologies to ensure recovery within an hour.
- 30-day backups with single file restore.
This company is also using Cloud Volumes ONTAP and Cloud Sync for use with their Hadoop data lakes to Amazon S3. You can read more about how this company uses Windows Server Failover Clustering with Cloud Volumes ONTAP here.
How Will You Deploy Your Oracle Instance on AWS?
Overall, choosing either RDS or EC2 to deploy Oracle on AWS is one of many possible ways you can set up Oracle on the cloud. However, you decide to deploy your Oracle instance, there will be limitations such as lack of control, increased technical complexity, and vendor lock-in.
One way to improve on many of these issues as well as reduce costs is to consider utilizing NetApp Cloud Volume ONTAP.
Cloud Volume ONTAP is the enterprise-grade data management solution from NetApp built on native AWS, Azure, or Google Cloud resources. With full support for databases or any other enterprise workload, including file services, SaaS applications, DevOps, and Kubernetes deployment.
A large part of the Cloud Volumes ONTAP benefit for databases comes from its ability to drastically lower cloud data storage costs on AWS through thin provisioning, data compression, deduplication, and other cost efficiency features.
One such feature is automatic data storage tiering. This critical storage usage and cost optimization feature automatically and seamlessly tiers infrequently used data from Amazon EBS storage to less-expensive Amazon S3 object storage. When data is needed again, it is automatically reheated for use back on the EBS performance tier. This can be a huge cost savings in running an enterprise database.
FlexClone® data cloning gives developers an easy and cost-effective way to use complete, zero-cost writeable copies of their existing databases for dev/test purposes. Utilizing NetApp Snapshot technology, FlexClone copies only consume storage for changes that are made to the original data set.
