Oracle SE2 Cloud Socket Rules:
Standard Edition 2 on AWS & Azure

What Are Oracle's SE2 Cloud Socket Rules?

A socket is the physical CPU slot on a server motherboard, and on-premise Oracle Database Standard Edition 2 is licensed by occupied socket — a maximum of two sockets per server (or two single-socket servers for legacy SE2 RAC). In the cloud, sockets are invisible to the customer, so Oracle's Authorized Cloud Environment policy redefines the SE2 metric entirely: it counts virtual CPUs and converts them to socket equivalents using a fixed ratio.

Under that policy, Oracle treats every four Amazon EC2 or Azure vCPUs as one socket when hyper-threading is enabled, and every two vCPUs as one socket where it is not. Because SE2's on-premise ceiling is two sockets, the cloud equivalent lands at eight vCPUs. This is the number that governs every SE2 deployment on AWS and Azure, and it is the number Oracle's audit team checks first. An Authorized Cloud Environment is the defined set of public clouds — AWS and Microsoft Azure — to which Oracle's cloud licensing policy applies; Oracle Cloud Infrastructure has its own, separate counting model.

How Does Oracle Count SE2 vCPUs on AWS and Azure?

Oracle counts SE2 by mapping the instance's allocated vCPUs to socket equivalents, then enforcing the two-socket SE2 ceiling. With hyper-threading enabled — the default on most AWS and Azure shapes — four vCPUs equal one socket, so a maximum of eight vCPUs fits within SE2. With hyper-threading disabled, two vCPUs equal one socket, and the eight-vCPU ceiling still holds because the socket cap, not the thread count, is the binding constraint.

The practical danger is that AWS and Azure instance families scale vCPUs in steps that straddle the limit. An m5.2xlarge (8 vCPUs) is the largest AWS shape that keeps SE2 compliant; the next step up, m5.4xlarge (16 vCPUs), silently doubles your requirement to four sockets — which SE2 cannot satisfy at all, forcing Enterprise Edition. On Azure, a Standard_D8s_v5 (8 vCPUs) is compliant while a Standard_D16s_v5 is not. Right-sizing the shape is the entire game.

Does the Oracle Core Factor Table Apply to SE2 in the Cloud?

No. The Core Factor Table is Oracle's on-premise multiplier that discounts processor counts by chip type (for example, 0.5 for x86 cores), and Oracle's Authorized Cloud Environment policy explicitly excludes it from cloud counting. In the cloud, Oracle counts vCPUs directly through the socket ratio described above — there is no 0.5 multiplier to soften the number. This catches teams who assume their familiar on-premise math carries over.

SE2 is doubly insulated from the Core Factor Table because it is socket-licensed even on-premise, where the table never applied to SE2 at all. The takeaway: for SE2 in AWS or Azure, ignore the Core Factor Table entirely and count vCPUs against the eight-vCPU ceiling. For Enterprise Edition the cloud math is different again, which is why a forced EE relicense is so punitive — the discount you never had on SE2 still does not appear, and EE pricing is roughly 2.7x SE2 per unit.

What Is the Minimum NUP for SE2 on Public Cloud?

Oracle requires a minimum of 10 Named User Plus (NUP) licenses per server for Standard Edition 2. Named User Plus is Oracle's per-user metric, counting every individual and non-human device authorized to access the database. In the cloud, the per-server minimum applies per the socket-counted instance, so even a small two-vCPU SE2 database carries a 10-NUP floor — there is no fractional minimum for small cloud shapes.

For SE2 you can license by socket or by NUP, and the cheaper option depends on user count. The 10-NUP-per-server minimum and the eight-vCPU socket ceiling interact: a high-user, small-footprint workload may be cheaper on socket licensing, while a low-user instance may be cheaper on NUP. Our Oracle license optimization service models both metrics against the actual deployment to right-size the position before renewal — and before any audit forces the question.

Can You Run SE2 RAC in AWS or Azure?

Not on Oracle Database 19c or later. Oracle removed SE2 RAC (Real Application Clusters on Standard Edition 2) support starting with Oracle Database 19c, so on every currently supported release you cannot cluster SE2 at all — in AWS, in Azure, or on-premise. Legacy SE2 RAC on older releases was limited to two single-socket servers with a combined ceiling, and that configuration does not translate cleanly to public-cloud shapes anyway.

This matters for cloud high-availability design. Teams that relied on SE2 RAC for resilience must move to single-instance SE2 with a standby, or step up to Enterprise Edition with Data Guard — a decision with major licensing cost implications. Pairing SE2 with a manually managed standby keeps you inside Standard Edition pricing, but watch the disaster-recovery licensing rules, which we cover in our Oracle disaster recovery licensing across clouds guide.

Where Do SE2 Cloud Deployments Trigger Back-License Claims?

The most expensive SE2 cloud mistakes are not deliberate — they are configuration drift. Across our engagements, the recurring triggers are autoscaling rules that resize an instance above eight vCPUs, a lift-and-shift that lands SE2 on a 16-vCPU shape "to be safe," and SE2 databases running on instances also hosting Enterprise Edition-only features such as Partitioning or Diagnostics Pack that were enabled by default. Any one of these converts a routine deployment into a back-license claim — Oracle's demand for retroactive licenses plus 22% annual support.

In our client base, the average Oracle audit claim arrives at three to five times what the customer actually owes once the deployment is correctly counted and unsupported assumptions are challenged (Oracle Licensing Experts, 2026). The defense is evidence-based: a forensic reconciliation of every SE2 instance shape, the vCPU count at each point in time, and the feature usage, so that the position can be proven rather than assumed. See how this plays out in our client case studies, where right-sizing cloud shapes before renewal removed seven-figure exposure.

SE2 vs Enterprise Edition in the Cloud: The Cost Cliff

The financial stakes make the eight-vCPU line a genuine cost cliff. SE2 lists at roughly USD 17,500 per socket; Enterprise Edition lists at roughly USD 47,500 per processor, before any options. A workload that fits in eight vCPUs and needs no EE-only features runs on two SE2 sockets — about USD 35,000 list. The same workload pushed to 16 vCPUs cannot use SE2 at all and, counted as Enterprise Edition processors, can multiply the license bill several times over, plus recurring support.

This is why shape selection is a licensing decision, not just an infrastructure one. Before any SE2 migration to AWS or Azure, the target shapes should be locked to the eight-vCPU ceiling and protected against autoscaling overruns. For the full picture of how Oracle prices and counts each edition, see our Oracle Database licensing guide and the Oracle Cloud licensing guide.

Frequently Asked Questions: Oracle SE2 Cloud Socket Rules