Oracle RAC on AWS: Tackling Licensing, Support, and Technical Hurdles

One common impediment we hear concerning moving Oracle workloads to AWS concerns Oracle RAC. Most of the Oracle customers that have purchased and implemented Oracle RAC are reluctant to try to live without the features that RAC provides. As a result, Oracle RAC support in AWS becomes a requirement for a cloud migration.


Unfortunately, there are at least three issues that will need to be addresses before migrating any Oracle RAC workloads. These issues include:

  • Oracle licensing
  • Oracle Support
  • Technical limitations concerning shared storage and multicast networking


The Oracle document Licensing Oracle Software in the Cloud Computing Environment (aka The Cloud Policy), defines the rules for applying Oracle license in an AWS environment. Within The Cloud Policy is a link that provides a list of all of the software that is eligible under The Cloud Policy. Oracle Real Application Clusters is not of this list, and as such The Cloud Policy cannot apply to it. Traditional core-based licensing would then apply.

There are a few corner cases where a client may have appropriate licensing for Oracle RAC within AWS. These include the Standard Edition RAC bundle and certain Unlimited License Agreements (ULA). However, these circumstances are very rare.


The My Oracle Support note Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1) is Oracle’s official policy statement. It quite explicitly states that Oracle Support does not support Oracle RAC in any 3rd party cloud. This would include AWS. In House of Brick’s experience there are no exceptions to this policy. Any attempt to “check in” with Oracle to get an exception will simply draw unwanted attention to your organization and the fact that you are looking at moving to AWS.

Technical Issues

Even in on-premises environments Oracle RAC has several technical issues that must be resolved, and these are no different in an AWS environment. These issues concern shared storage and the multicast networking that is required by the private interconnect. Any cloud environment will have restrictions on network features and the Oracle RAC required multicast networking is usually disabled, and AWS is no different.

Overcoming the Issues

With the potential issues now known it is time to discuss possible solutions for each of these issues. The technical issues are actually the easiest ones to solve and potentially affect licensing, they will be discussed first.

Technical Issues

I will start off with the statement that from a technical standpoint I know that Oracle RAC will run in an AWS environment. As noted, the two technical issues to solve are shared storage and networking for the private interconnect network. For deploying Oracle RAC into an AWS environment EC2 (Elastic Cloud Compute) instances with EBS (Elastic Block Storage) storage will be needed.

The shared storage component is the easiest to solve and is accomplished through native tooling. For the io1 and io2 storage options within EBS there is a feature called Multi-Attach. This does exactly what the name implies, the EBS volume can be presented to more than one EC2 instance at a time. Once presented to the EC2 instances the volume can them be made available for use to ASM. The required configuration is simply managed through the AWS console or CLI.

Another possibility for the shared storage component is to use EFS (Elastic File System), the AWS implementation of NFS. It is allowable for Oracle RAC database files to live on an NFS mount and there is nothing wrong with using EFS as a storage option. However, the use of EBS Multi-Attach volumes is a better solution.

The networking issue is a little more complicated. For what are hopefully obvious reasons multicast networks are huge no-no in a cloud environment. The 3rd party software vendor FlashGrid solves the networking issue through a fairly easy to use package that runs on each node of the RAC environment. This is the recommend solution and best practice from AWS, and in House of Brick’s experience very reliable.

Another solution for the technical issues would be to implement Oracle RAC in a VMware Cloud on AWS environment (VMC). This solution is nearly identical to an on-premises vSphere environment. Many organizations have been implementing Oracle RAC solutions in a VMC environment with no issue and through native tooling, FlashGrid is not needed. An additional benefit is that traditional Oracle core-based licensing can be applied to a VMC environment thus Oracle RAC is licensable. The one drawback to a VMC environment is the minimum number of cores to be licensed.


In order to solve the licensing issue, you need to have an environment where you can count the cores of the underlying server. In an AWS environment there are only a few ways to accomplish this. These include:

  • Dedicated Hosts
  • VMC

With a Dedicated Host an entire server is reserved for the AWS customer and then EC2 instances are then deployed to it. The customer is allowed to deploy as many EC2 instances to the host until it is “full.” AWS does not allow the host to be over provisioned (assigning more resources than exist) for either CPU or memory.

Since the deployed resources are EC2 instances all available AWS services can be used by the EC2 instance. EBS Multi-Attach volumes could be used for storage and FlashGrid can be utilized to help manage the interconnect. Multiple dedicated hosts can be used so that no two EC2 instances of the same cluster are on the same host. AWS also allows for automated failover of Dedicated Hosts in case of host failure.

As noted VMC is also a possible licensing solution. VMC is a dedicated VMware cluster that runs on AWS dedicated hosts. This is a managed service from VMware, and they are responsible for the vSphere software management. The end user is allowed to configure most aspects of the cluster which would include shared storage and the needed networking for the interconnect. It is nearly identical to running Oracle RAC on VMware on-premises.

With both Dedicated Hosts and VMC traditional core-based licensing can be used which opens up the possibility of licensing Oracle RAC. The only drawback with these solutions is that the minimum number of cores per server is relatively high and then at least 2 (Dedicated Hosts) and 4 (VMC) hosts must be licensed. For larger installations this may not be an issue, however if only a few RAC licenses are owned these solutions may prove cost prohibitive.


The last issue is with Oracle Support, and the short answer is there are no solutions here. Oracle does not support Oracle RAC in 3rd party clouds period. They are explicit in the referenced Oracle Support note. If you choose you can simply accept the risk and run Oracle RAC regardless. The Oracle Support notes and patches will be available, the issue would be opening a support request. Depending on the issue some 3rd party support organizations may also be an option


Based on the above, if Oracle RAC is still an option for your organization or if you are looking for solutions other than Oracle RAC in your AWS environment House of Brick is here to help. We have implemented Oracle RAC solutions in AWS environments, we have migrated from Oracle RAC to single instance databases, and have migrated off clients off Oracle entirely. Whatever your need simply contact us and we can help.

Table of Contents

Related Posts