Oracle's two-socket SE2 cap does not disappear in the cloud, it converts into a hard vCPU and OCPU ceiling that most buyers breach by scaling. This page shows exactly where the cap sits on AWS, Azure, and OCI, and how to size shapes that keep you compliant.
Oracle's two-socket SE2 cap does not disappear in the cloud, it converts into a hard vCPU and OCPU ceiling that most buyers breach by scaling. This page shows exactly where the cap sits on AWS, Azure, and OCI, and how to size shapes that keep you compliant.
On-premises, Standard Edition 2 licensing is a physical-hardware conversation: you count occupied sockets, ignore cores entirely, and pay $17,500 per socket to a maximum of two. In the cloud, Oracle throws out that method. It abandons socket counting and the Processor Core Factor Table, and it substitutes a vCPU-to-Processor conversion that translates the two-socket ceiling into a fixed maximum instance size. The result is a cap that looks unfamiliar and that autoscaling, instance-family changes, and routine rightsizing violate without any warning from the console or the invoice.
This subpage sits under our Oracle Standard Edition 2 licensing landing page and explains the exact numbers on each hyperscaler, why the OCI figure is stated in OCPUs rather than vCPUs, and the specific ways buyers accidentally cross the line. If you are weighing whether to stay on SE2 at all, read it alongside our analysis of what happens when you outgrow the two-socket, 16-thread cap.
SE2 is defined by two limits that operate together. The first is the licensing ceiling: two occupied sockets per server, at $17,500 per socket, capping the maximum SE2 processor license at $35,000 at list before support. The second is a technical throttle: a 16-thread cap enforced by the software itself, not by the contract, which limits each database instance to 16 CPU threads of processing regardless of how many cores the box physically holds. A two-socket 2026 server commonly carries 32 to 64 physical cores, and SE2 will still use only 16 database threads.
On-premises, empty sockets still count against you. A four-socket chassis with two sockets populated is not eligible for SE2, because the box has the physical capacity to occupy more than two sockets. This is where socket-creep during hardware refresh bites, and it is a separate problem from the cloud caps we cover here, treated in full on the SE2 migration decision pillar.
When you move SE2 into what Oracle calls an Authorized Cloud Environment (defined in Oracle Policy 070617, which now names AWS, Azure, and Google Cloud), none of the physical-socket logic applies. There are no sockets to count, so Oracle publishes a conversion instead. That conversion turns the two-socket ceiling into a specific vCPU number, and it is the single figure every SE2 cloud deployment must respect.
In the cloud, Oracle does not enforce the socket cap you understand. It enforces a vCPU number most teams have never memorized, and scaling past it is silent.
Oracle's own cloud policy document sets the rule in plain language. For programs with Standard Edition 2 in the name, licensing is based on instance size. Instances with four or fewer Amazon vCPUs or four or fewer Azure vCPUs count as one socket, equivalent to one Oracle processor license. Above four vCPUs, every four vCPUs (rounded up to the nearest multiple of four) equate to one additional license. The critical sentence is the hard ceiling: SE2 may only be licensed on Authorized Cloud Environment instances up to eight Amazon vCPUs or eight Azure vCPUs.
So eight vCPUs is not a soft guideline, it is the maximum. Four vCPUs equal one socket, eight vCPUs equal the two-socket equivalent, and there is no legitimate SE2 configuration above that line. This is why an m5.4xlarge (16 vCPUs) is flatly non-compliant for SE2, and why a t3.2xlarge or m5.2xlarge (8 vCPUs) is the largest shape you can run.
| AWS/Azure vCPUs | Sockets counted | Processor licenses required | SE2 eligible? |
|---|---|---|---|
| 1 to 4 | 1 | 1 | Yes |
| 5 to 8 | 2 | 2 | Yes (maximum) |
| 9 to 16 | - | - | No, exceeds SE2 cap |
| 17+ | - | - | No, exceeds SE2 cap |
For the Named User Plus route, Oracle's cloud policy sets a floor of 10 NUP licenses per 8 Amazon vCPUs for SE2. That mirrors the on-premises structure (a minimum of 5 NUP per socket, so 10 on a two-socket equivalent) and means the NUP metric does not let you dodge the sizing limit, only the counting basis.
The practical consequence: if your workload genuinely needs more than eight vCPUs of database compute, SE2 in the cloud cannot serve it under any license metric. That is a hard edition boundary, and the decision it forces (upsize to Enterprise Edition or migrate off) is quantified in our piece on the real cost of upgrading SE2 to Enterprise Edition.
On OCI, Oracle expresses the same physical footprint in a different unit, and this trips up buyers who compare the numbers directly. An OCPU (Oracle CPU) represents a physical CPU core. A vCPU represents one execution thread. Most x86 architectures run two threads per core, so on OCI one OCPU equals two vCPUs. That is the whole explanation for the apparent gap: the AWS 8-vCPU cap and the OCI 8-OCPU cap describe the same underlying hardware, because 8 OCPUs is 16 vCPUs, which maps to the two-socket, 16-thread SE2 reality.
Oracle's Autonomous Database console enforces this directly rather than leaving it to an audit. For the Standard Edition license type, the maximum allowed OCPU count is 8. If you try to enable BYOL with Standard Edition when the base OCPU count exceeds 8, the console blocks you with the message that you cannot select Standard Edition unless your OCPU count totals eight or fewer. This is one of the rare places where Oracle stops you at the door instead of catching you later.
There is a further wrinkle buyers must confirm before sizing: which Autonomous compute model they are on. On the older OCPU compute model, the SE cap holds at 8 OCPUs, and autoscaling can use up to three times the CPU but is capped at 8 OCPUs (16 ECPUs) for Standard Edition. On the newer ECPU compute model, the same cap is expressed as a maximum of 32 ECPUs, with or without autoscaling enabled. Same edition, same intent, different unit and different number. Read the cap in the unit your console uses, not the one you remember from a blog post.
| Environment | Cap unit | SE2 maximum | vCPU equivalent |
|---|---|---|---|
| AWS / Azure (compute) | Amazon/Azure vCPU | 8 vCPUs | 8 vCPUs |
| OCI compute / Autonomous (OCPU model) | OCPU | 8 OCPUs | 16 vCPUs |
| OCI Autonomous (ECPU model) | ECPU | 32 ECPUs | varies by model |
8 vCPUs on AWS and 8 OCPUs on OCI are the same box. If you compare the raw numbers without the two-threads-per-core conversion, you will mis-size the shape.
The AWS and OCI ceilings are unambiguous. The compliance failures we see in the field almost never come from someone deliberately deploying a 16-vCPU shape. They come from scaling events that change the license requirement with no visible signal. Four patterns account for the large majority of the exposure.
The most common trap is straightforward growth. A team deploys SE2 on an 8-vCPU shape, the workload grows, and an engineer resizes the instance to the next tier up (say a 16-vCPU shape) to relieve pressure. The database still starts, the application still runs, and nothing in the cloud console mentions Oracle licensing. The instance is now non-compliant, immediately and continuously, from the moment it boots at the larger size. On AWS and Azure, no software throttle stops this because the cap there is a licensing rule, not an enforced technical limit the way it is inside Autonomous.
The vCPU-to-license ratio depends on hyperthreading being on. When hyperthreading is enabled, roughly two vCPUs map to one license unit of physical capacity. An instance-family change or a rebuild can disable hyperthreading, at which point the ratio flips from 2 vCPUs per license to 1 to 1, and the license requirement effectively doubles with no visible signal. Buyers who assume the vCPU count is the whole story miss this, because the same vCPU number now represents twice the licensable footprint.
Even where you stay inside an edition, scaling doubles cost. Oracle's own BYOL logic makes this concrete: a database on an OCI VM with 4 OCPUs requires 4 processor licenses, and scaling that VM to 8 OCPUs doubles the requirement to 8 licenses for each licensed product. For SE2 the danger is that the same move can push you from inside the cap to outside it, or from adequately licensed to under-licensed, in a single resize that no approval workflow flagged.
Over-provisioning is a quieter version of the same failure. If an OCI instance runs 8 OCPUs but you hold only 4 processor licenses, the extra 4 OCPUs are an unlicensed gap that an Oracle audit will price at list plus back-support. The instance being technically compliant with the SE2 edition cap does not help you if your license quantity does not cover the shape you actually deployed.
The cloud caps compress SE2 into a narrow band. Your entire compliant range is one to eight vCPUs on AWS and Azure, or one to eight OCPUs on OCI. That is deliberately small, because SE2 is priced to be the entry edition and Oracle wants growth to push you toward Enterprise Edition, which lists at $47,500 per processor counted as cores times the core factor. Every year you also pay support at 22 percent of net license fee, which over a five-year horizon quietly exceeds the license cost itself, so the total commitment behind even a capped SE2 deployment is larger than the sticker suggests.
Two structural facts sharpen the stakes. First, Real Application Clusters was desupported on SE2 in Oracle Database 19c, so you cannot cluster your way around the single-instance vCPU cap. Treat SE2 as having no supported cluster and plan high availability accordingly, as covered in our review of the high-availability options left for Standard Edition buyers. Second, if the workload genuinely needs more than eight vCPUs, the cloud gives you no legitimate SE2 path, and the choice narrows to Enterprise Edition repricing or a migration off Oracle, such as the move we document in leaving SE2 for PostgreSQL.
The SE2 cloud caps are among the cleanest rules Oracle publishes, which is precisely why they catch buyers off guard: they are technical numbers hidden behind a socket vocabulary, and the enforcement gap between OCI (which blocks you at the console) and AWS/Azure (which do not) means most exposure builds up on the hyperscalers where nothing warns you. Govern the shape, not just the edition, and the cap stays a design constraint rather than an audit finding.
On AWS and Azure, Oracle's cloud policy caps Standard Edition 2 at 8 vCPUs per instance. Four or fewer vCPUs count as one socket (one processor license), and 5 to 8 vCPUs count as two sockets. Any instance above 8 vCPUs is non-compliant for SE2 under any license metric.
They describe the same physical hardware. One OCPU equals one physical core, which runs two threads (two vCPUs) on most x86 architectures, so 8 OCPUs on OCI equals 16 vCPUs. The AWS 8-vCPU cap and the OCI 8-OCPU cap both map to SE2's two-socket, 16-thread ceiling.
On OCI Autonomous Database, yes. The BYOL console blocks Standard Edition selection when the OCPU count exceeds 8, with an explicit error message. On AWS and Azure there is no such technical block, so the cap is a licensing rule you must enforce yourself through instance sizing and scaling policies.
No. Real Application Clusters was desupported on SE2 in Oracle Database 19c. Treat SE2 as having no supported cluster, which means you cannot spread the workload across nodes to work around the single-instance vCPU cap.
It changes the counting basis, not the sizing limit. Oracle's cloud policy sets a minimum of 10 NUP licenses per 8 Amazon vCPUs for SE2, mirroring the on-premises floor of 5 NUP per socket. The 8-vCPU maximum instance size still applies regardless of whether you license by processor or by Named User Plus.
You are out of compliance immediately and continuously from the moment the larger shape boots. The database still runs and nothing in the AWS or Azure console flags it, but an Oracle audit will price the unlicensed footprint at list plus back-support. Cap your autoscaling policies so no scaling event can cross the 8-vCPU or 8-OCPU line.
Oracle SE2 licenses per occupied socket at 17,500 dollars, two sockets maximum, 16 thread cap. Free paper on the metric choice and Enterprise Edition trap.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
