Classic RAC will not run on standard EC2, but the 2026 answer is no longer a flat no. Here is the pattern map from Oracle Database at AWS to VMware and FlashGrid, the license meter for each, and when Data Guard quietly wins.
Classic Oracle RAC does not run on standard EC2, but in 2026 the answer is no longer a flat no. Here is where RAC actually runs on and around AWS, how licensing counts in each pattern, and when the right call is Data Guard, OCI, or staying put.
Because Real Application Clusters assumes shared storage every node can write and a cluster interconnect with guaranteed low latency, and Oracle has never certified either on standard EC2. AWS engineering has narrowed the technical gap over the years, with shared block volumes and multicast features. The certification gap has not moved.
You can often make software start. Unsupported means that when the cluster misbehaves, Oracle Support can ask you to reproduce the problem on a certified configuration before helping. For the workload that justified RAC in the first place, that support posture is disqualifying on its own.
Single instance Oracle Database on EC2 is fully workable, and Amazon RDS for Oracle runs it as a managed service, with RDS Custom in between for configurations needing more control. None of them provide RAC, and that is a deliberate boundary, not an oversight.
Dedicated Hosts feel physical, so teams assume the on premises rulebook returns, complete with RAC eligibility and core factor counting. Neither is true. A Dedicated Host is still EC2 in Oracle's policy, metered by vCPU, and still absent from the RAC certification list.
What Dedicated Hosts do offer is socket and core visibility that helps some ISV licenses and some internal chargeback models. For the Oracle database itself, they change the invoice from AWS, not the count from Oracle.
In three places, each with a different support posture and a different license meter. This is the map that was a one line "no" a few years ago and is now a genuine decision.
The RAC on AWS pattern map
| Pattern | What it is | Support position | License meter |
|---|---|---|---|
| Standard EC2 | Native instances and storage | RAC not certified, single instance fine | vCPU under the cloud policy |
| Dedicated Hosts | Physical servers reserved for you | Still EC2, same RAC position | vCPU under the cloud policy |
| Oracle Database at AWS | Exadata service inside AWS data centers | RAC fully supported by Oracle | OCI service metrics, BYOL or license included |
| VMware Cloud on AWS | Dedicated vSphere hosts with shared vSAN storage | Runs RAC, supported per Oracle's VMware stance | Physical cores with the core factor |
| FlashGrid on EC2 | Engineered storage and network overlay | Vendor engineered, confirm in writing | vCPU under the cloud policy |
The pattern map also sets your negotiating posture. A workload that could credibly land on two of these patterns is a workload Oracle and AWS will both sharpen their pencils for, and the map is what makes the credibility visible.
Since its general availability in 2025, Oracle Database at AWS places Exadata infrastructure operated by Oracle inside AWS facilities, purchasable through AWS. RAC runs there exactly as it does on OCI, fully supported, in a limited but growing set of regions.
For a buyer whose application genuinely requires RAC next to AWS workloads, this is now the clean answer. Price it against keeping the cluster on premises before assuming it, because Exadata class services carry Exadata class commitments.
The VMware route works because vSAN gives the cluster real shared storage on dedicated hosts. Licensing is the catch: this is not an authorized cloud environment under Oracle's policy, so counting reverts to physical cores and the core factor.
The count then spans every host the Oracle virtual machines can reach. Pin that basis in writing before deployment, or the cluster you moved to save money becomes the biggest line in your next audit.
FlashGrid supplies the shared storage and network layer RAC misses on EC2, and publishes reference architectures with AWS. It is engineered and it works in production estates. Oracle has still not certified RAC on EC2, so the support chain runs through the vendor. Get both vendors' support positions in writing and rehearse a failure scenario before production traffic arrives.
On EC2 and RDS, by vCPU under Oracle's policy for authorized cloud environments, with no core factor. On the VMware route, by physical core with the factor applied. On Oracle Database at AWS, by the OCI service's own metrics under BYOL or license included terms.
General AWS counting mechanics, instance families, and the BYOL fine print live in our Oracle on AWS licensing guide. This section covers only the cluster specific math.
Read the policy document itself before signing anything, because it is a policy, not a contract term. It can change, it has changed before, and a design whose economics depend on it should note that dependency in the risk register.
With hyperthreading enabled, every two vCPUs count as one Enterprise Edition processor license. With it disabled, each vCPU counts as one. Missing the rule overstates an AWS estate by up to a third, which is exactly the error we kept correcting in design reviews.
Real Application Clusters is an Enterprise Edition option at 23,000 dollars per processor with 5,060 dollars of annual support at list, licensed on every node of the cluster at the same count as the database. The line items sit in our annotated technology price list.
One more sizing note: constrain vCPU counts on the instance where the licensed database runs, using the optimize CPU features, and document the configuration. A larger instance bought for memory can otherwise inflate the license count for cores the database never uses.
SE2 lost its bundled RAC rights from Oracle Database 19c, so there is no cheap cluster edition to fall back on anywhere, AWS included. The history and its consequences are covered in our SE2 RAC licensing analysis. On AWS, SE2 counts one license per 4 vCPUs within its instance size caps.
Budget owners should treat the three contrasts above as the whole story in miniature. The cluster option roughly doubles the per processor line, the meter choice moves the count, and the availability design decides whether either matters.
A Data Guard standby that is mounted or open is a running deployment and licenses in full, in the cloud as anywhere. The narrow unlicensed spare allowance in Oracle's policies covers a cold failover server, not a replicating standby.
Count development, test, and staging environments under the same vCPU rules as production. AWS makes environment sprawl effortless, and in the designs we reviewed the non production tier was where the count quietly doubled.
White Paper · Oracle
Count the Oracle cloud licence before you commit. Read it free.
Usually availability. RAC delivers two things at once, node failure survival measured in seconds and horizontal scale for a single database. Most workloads that reach an AWS design review need the first in minutes, not seconds, and can scale by instance size rather than by node count.
Application behavior is the piece architects forget to test. RAC hides node loss behind cluster services, while a Data Guard failover briefly breaks connections and relies on the application reconnecting cleanly. Test the reconnect path once, honestly, and most of the remaining argument for the cluster disappears.
Set the recovery time and recovery point objectives with the business before choosing architecture. In our reviews, almost every stated requirement for RAC dissolved into a recovery time of minutes once someone priced the difference. The application that truly cannot ride through a 60 second failover is rare, and it is usually already on Exadata.
Five questions, asked in order, settle nearly every RAC and AWS conversation we have sat in. Answer each with evidence, not preference, and write the answers into the design record.
Whatever branch you land on, file the evidence with the design record: the objectives, the pattern chosen, the counting basis, and the vendor statements. The design meeting is cheap. Reconstructing its logic two years later, mid audit, is not.
Lead with the availability requirement, then attach the license math. The cheapest compliant AWS design starts from Data Guard sizing, and only steps up when the recovery numbers force it.
Owned licenses waiting out a migration keep their support stream running, so the five year comparison between patterns should include support on everything you retain. A pattern that lets you retire licenses, not just relocate them, earns its keep twice.
RDS for Oracle changes who runs the database, not how Enterprise Edition licenses count: bring your own license applies the same vCPU rules, while license included covers Standard Edition 2 inside the hourly rate. Choose the operating model first, then confirm the license path.
And if the review concludes the workload never needed the cluster, write that down too. Retiring a RAC option nobody uses is one of the few Oracle savings that requires no negotiation at all, only the next support renewal.
The common advice is to recreate your on premises RAC cluster on EC2 so nothing changes. We disagree. In roughly 20 to 30 AWS designs we reviewed, the attempt to rebuild RAC added 30 to 50 percent cost and left an unsupported cluster, while Data Guard met the actual availability target for far less. The buyer side move is to define the real recovery objective, then pick the cheapest supported pattern that meets it, which now includes Exadata inside AWS for the few workloads that truly need the cluster. Copying the old architecture forward buys risk and cost without buying support.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The RAC question on AWS is no longer can you. It is which meter you are willing to be counted on, and whether the workload ever needed the cluster.
White Paper · Advisory
Oracle Database Options & Management Packs Licensing
The separately licensed options and packs that ship enabled by default, trigger on one click, and drive most Oracle audit findings: how feature usage is detected, prevented, and defended. Read it free.
Not on standard EC2, which Oracle has never certified for RAC. It does run fully supported on Oracle Database at AWS, on VMware Cloud on AWS under on premises style counting, and through the engineered FlashGrid pattern with vendor support arrangements.
It is Oracle operated Exadata infrastructure placed inside AWS data centers and sold through AWS, generally available since 2025 in selected regions. RAC runs on it exactly as on OCI, with full Oracle support and BYOL or license included commercial terms.
By vCPU under Oracle's authorized cloud environment policy, with the core factor table explicitly not applying. Bring your own license works on both, and RDS additionally offers license included pricing for Standard Edition 2.
When hyperthreading is enabled, two vCPUs count as one Enterprise Edition processor license, and one vCPU counts as one license when it is off. It is the single most common sizing error in AWS license budgets.
By physical cores of the hosts with the core factor applied, because the service is not an authorized cloud environment under the policy. Count every host the Oracle virtual machines can reach, and agree that basis in writing first.
Data Guard replication to a standby in another availability zone, or RDS Multi AZ on the managed path. Both deliver failover in minutes, which satisfies the stated recovery objective of nearly every workload we have reviewed.
No. SE2 lost its bundled RAC rights from Oracle Database 19c everywhere, so no supported SE2 cluster exists on any platform. On AWS, SE2 remains attractive for smaller single instance workloads at one license per 4 vCPUs.
No. The rebuild adds cost, stays uncertified, and rarely serves a measured recovery objective. Define the objective first, take the Data Guard baseline if it fits, and use the supported cluster patterns only where the evidence demands one.
The vCPU counting rule, the SE2 cloud caps, options stacking, and BYOL versus license included across both clouds, with worked numbers.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The question is rarely how to run RAC on AWS. It is how to get the availability RAC gave you without the cluster, and how to count vCPUs so the bill does not surprise you.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One short note on Oracle licensing moves, price list mechanics, audit posture, and the buyer side levers we run in client engagements. No noise.
