Migrating your Oracle database from your datacenter or another vendor to AWS can be daunting. Unlike an application, data can’t be recreated or reinstalled, so companies often plan ahead for months to make sure migrations run smoothly.
In this post, we’ll discuss why and how you should migrate your Oracle DB to AWS RDS, EC2, or Aurora. If you want the full technical guide, download it free here.
Why Cloud Databases?
The value proposition of the cloud is well-known: scalability, agility, cost efficiency, etc. But what are the specific reasons why your team, running Oracle or MySQL databases, would want to move those databases to AWS and not keep them on-premises?
Simplify Management and Save Your DBAs Time. As much as DBAs want to spend time on applications and on tuning, it turns out that the majority of time is spent in non-differentiated tasks, like patching, break/fix, and other maintenance. The goal of migrating your database to the cloud is to flip this model on its head, and let the cloud provider manage the platform so you can focus on the application.
Cost. The top reason for companies wanting to move on-premises databases to the cloud is cost, according to a survey by the Independent Oracle UsersGroup and AWS (2018). However, this should come with a few caveats. We’ll explore this in more depth in this Guide, but if you’re migrating your Oracle database to run on an Amazon EC2 instance, without any changes, it’s unlikely that you’re going to see major cost savings vs. an on-premises system. The real cost savings factor of the cloud is when you move to an open source platform (i.e. MySQL, PostgreSQL) and use a cloud-native database like Amazon Aurora.
Licensing Freedom. One of the most common questions we get is how to be “free from Oracle”. Part of this is cost-related, part of this is vendor lock-in, and part of this is frustration with Oracle itself.
Scalability. This is the top reported benefit that Oracle users are getting on public cloud platforms. For DBAs accustomed to spending a significant amount of time adding storage and capacity planning in general, cloud-native and fully-managed databases like Amazon RDS and Aurora allow DBAs to increase storage (with no downtime, running on elastic volumes) and compute power (with minimal downtime) on demand.
Which AWS Database is Right for You?
AWS provides a variety of tools and services to help you deploy enterprise-grade relational database solutions. Let’s review the three most popular models for running relational databases on AWS.
Option 1: Database on Amazon EC2
In this model, you run your database yourself on top of an Amazon instance/virtual machine, much like running it on your own servers except you don’t manage the physical server, networks, or storage. There are 33 different AWS instance types (as of 2020), each optimized for different use cases (ex. storage, compute, memory).
This is the simplest model for running your database on AWS, but doesn’t allow you to take full advantage of cloud-native database technologies. We usually don’t recommend it unless there’s a specific reason why Amazon RDS or Aurora doesn’t work.
Option 2: Amazon Relational Database Service (RDS)
Amazon Relational Database Service (RDS) allows you to run your relational database in the cloud without having to worry about certain database administration tasks. Varieties include:
- Amazon RDS for Oracle
- Amazon RDS for MySQL
- Amazon RDS for SQL Server
- Amazon RDS for MariaDB
- Amazon RDS for PostgreSQL
The benefits of RDS are that it scales your database’s compute or storage needs automatically, usually without downtime, and performs tasks like patching and backups automatically. RDS Multi-AZ creates a secondary RDS instance in a second AZ with synchronous replication. If volumes or backups have problems, RDS ensures that everything is replaced.
Option 3: Amazon Aurora
Amazon Aurora is a fully-managed database solution that is compatible with MySQL and PostgreSQL. A customer that’s running Oracle or SQL Server on-premises requires a schema and code transformation to MySQL or PostgreSQL before database migration occurs.
Why would a company want to do this schema conversion work? Because Amazon Aurora is about 1/10th of the cost of a traditional database. You no longer have licensing costs, it automatically replicates 6 copies of your data across 3 Availability Zones and backs up your data continuously to Amazon S3, and it automatically grows storage as needed. Also, performance, scalability, and throughput are better in many cases.
Oracle Licensing on AWS
You spend much more on Oracle licenses than you do on any underlying infrastructure, so the impact of AWS on licensing should always be the top consideration. Each of the models listed above have different licensing models.
Bring-Your-Own-License
As the name suggests, this model allows you to run Amazon RDS using your existing Oracle Database software licenses. You can also purchase Oracle Database 11g or 12c licenses directly from Oracle and run them on Amazon RDS. You must have the appropriate Oracle Database license (with Software Update License & Support). You can create and manage license configurations in AWS License Manager.
Oracle’s Cloud Licensing Policy allows licensing in EC2 and RDS, but counts two vCPUs as equivalent to one Oracle processor licensing if hyper-threading is enabled, and one if not enabled. This means that running on AWS can be more expensive than traditional processor licensing.
If you run multi-AZ, you must have a license for both the primary DB instance and the standby DB instance.
Supported under this model: Enterprise Edition, Standard Edition Two, Standard Edition, Standard Edition One. Charges do not vary by edition for BYOL Amazon RDS pricing.
License Included
In this model, available only for Amazon RDS, AWS holds the license for the Oracle software. Pricing includes software, underlying hardware resources, and Amazon RDS management capabilities. This model is almost always cheaper than purchasing an Oracle license, and involves no direct engagement with Oracle.
If you run multi-AZ, you just pay the per-hour costs for each RDS instance-hour consumed.
Just be aware that the RDS License Included model only supports Standard Edition 1 and 2, which has a smaller feature set than Enterprise Edition. That said, many companies have been able to use RDS with SE2 by replacing Enterprise Edition features with other AWS-native features.
Supported under this model: Standard Edition One (SE1), Standard Edition Two (SE2)
Choosing the Right Licensing Model
If you’ve already purchased Enterprise Oracle software and support licenses, the most cost-effective option is usually to BYOL on EC2 or RDS. If you have not already purchased Oracle licenses, it is significantly cheaper to purchase instances with License Included (SE2 on RDS) rather than to purchase Oracle licenses separately. Look below for a more detailed cost breakdown.
Feature Parity: EC2 vs. RDS vs. Aurora
One of the many reasons that enterprises use Oracle are its enterprise-grade feature set and rock-solid availability. It’s important to understand which features are or are not supported by each AWS service.
RDS for Oracle AWS Documentation
Aurora PostgreSQL AWS Documentation
One of the top reasons why companies tend to run their database on EC2 is that they want 100% feature parity or application does not support RDS, e.g. Oracle Ebusiness Suite. That said, we’ve found that RDS for Oracle works for the vast majority of use cases.
Aurora PostgreSQL usually has greater feature parity than Aurora MySQL. That said, there are a significant number of features that require a DBA to rethink and refactor the database before migration. We’ll review this in detail in the following sections.
Maintenance Responsibility: EC2 vs. RDS vs. Aurora
It’s no secret that the “care and feeding” of Oracle databases takes significant time, effort, and expertise. Fully-managed services like RDS and Aurora reduce the maintenance burden on your in-house IT team. In the chart below, you can see the comparison between running your database on-premises, running on EC2, and running on RDS or Aurora.
In Amazon RDS and Aurora, Amazon takes care of all common database infrastructure management tasks; you only have to take care of the data itself. When you run on EC2, you still have to worry about scaling, HA, patching, and backups.
For some teams, outsourcing these tasks to Amazon is very attractive. Other teams that want to be able to control these factors themselves often choose to run their database on EC2. This is especially common for companies that want to avoid automatic software patches that might not be compliant with their applications.
Comparing Sample Costs: EC2 vs. RDS vs. Aurora
Each of the models listed above have very different cost implications. Let’s review these briefly.
*Source: https://www.oracle.com/assets/cloud-licensing-070579.pdf, https://www.oracle.com/assets/technology-price-list-070617.pdf
The chart demonstrates that running Oracle on EC2 is significantly more expensive than running Aurora. But three final notes on AWS costs.
- This chart shows On Demand pricing; once you migrate to AWS, you should consider purchasing AWS Reserved Instance or Savings Plan, which reduces per-hour costs by 50-70%.
- This chart shows the cost of a single AZ deployment. Costs will vary for a multi-AZ deployment.
- Based on your requirements, some additional AWS charges may apply:
-
- Provisioned IOPS SSD Storage (Starts at $0.125/GB per month)
- Additional backup storage (Starts at $0.095/GB per month)
- Egress traffic (Starts at $0.05 per GB per month)
- Multi-AZ cost
Calculating AWS costs is quite complicated. We recommend checking out the AWS Calculator or getting a validated TCO Analysis from an AWS Partner.
A Final Note
The above comparisons reveal that RDS and Aurora are cheaper, require less ongoing maintenance, and can help you avoid ever having to interact with Oracle again. What’s the catch?
The trade-off is of course upfront effort to migrate to AWS. You can lift-and-shift your Oracle database to EC2 with little effort. Migrating to RDS for Oracle requires some effort, but is low risk. Migrating to Aurora requires a schema conversion to MySQL or PostgreSQL before migration — a high-risk proposition for even the most seasoned DBAs. AWS provides some tools to make this easier, but significant manual work is still required.
That said, migrating from Oracle to Aurora is possible and has been completed by thousands of companies. But many choose a two-step process: first they migrate to RDS, then they migrate to Aurora later. This can help minimize perceived organizational risk.
To get the full details on how to migrate your Oracle database to AWS, download our full technical guide. It includes the most common architectural patterns and processes for building a target database in AWS and de-risking migrations to the cloud. We provide architecture diagrams and sample templates, approved by AWS and used by thousands of companies, to help kickstart your migration planning efforts. Download the Guide here.
No Comments