How Oracle counts your licenses on AWS, Azure, and Google Cloud, and what the arithmetic does to every hyperscaler decision. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session eleven of thirty, and welcome to module three, where the terrain genuinely changes: Oracle software running on clouds Oracle doesn't own. AWS, Azure, Google Cloud. Over the next five sessions we'll do the counting rules, the AWS services in practice, JD Edwards and the application estates, the new Database at services, and a full platform comparison. But it all starts today, with one document: the authorized cloud environment policy, the rulebook that decides how your licenses count when the underlying hardware belongs to Amazon, Microsoft, or Google. If you took the Mastery course, you'll feel a familiar chill: it's another unsigned policy running enormous commercial outcomes. But this one, unusually, is workable, and knowing its arithmetic cold is what separates estates that migrate confidently from estates that migrate into findings. Let's read the rulebook.
Five takeaways. One, the policy itself: what it is, which clouds it names, and its exact contractual weight, which is a story you already know how to read. Two, the rule: two vCPUs per processor license with hyperthreading on, one without, and, critically, the core factor table switched off, because the half sized instinct that rule creates is the most expensive mistake in hyperscaler licensing. Three, the comparison: the same license counted three ways, on premises under the partitioning policy, on a hyperscaler under today's rule, and on OCI under BYOL, and why that gradient is strategy rather than accident. Four, the neighbors: the rules that travel with the workload, NUP minimums, options, disaster recovery, the one license one place rule. And five, the traps: five specific counting mistakes that turn clean migrations into audit findings, each preventable in a design review.
The policy, precisely. What it is: Oracle's published policy for licensing programs in what it calls authorized cloud environments, and the named ones are AWS, Azure, and Google Cloud. It defines how virtual CPUs convert to processor licenses, and within those clouds it replaces the on premises counting rules entirely, no core factor table, no host counting, no cluster scope. What it is not, and say it with me if you took the Mastery course: a contract term. It's a policy document, published on Oracle's website, revisable at Oracle's discretion, and almost never referenced in any paper you signed. Its power is commercial practice: audits count by it, customers count by it, because the alternative to a workable convention is chaos. Now, why does Oracle publish a workable convention for rival clouds at all? Think about the alternative: without this policy, a VM on AWS would face the partitioning policy's could run logic across a datacenter Oracle can't even see, an unresolvable absurdity that would simply stop migrations, including the ones Oracle profits from. So the policy trades absurdity for a clean per instance rule, priced hostile enough to make OCI look warm by comparison, workable enough that you can actually comply. It's a toll road between the partitioning policy's minefield and OCI's subsidized highway. And the Mastery discipline applies unchanged: know what's policy and what's contract, and where policy is silent or worrying, get language into an order.
The counting rule, worked, because this arithmetic has to become reflex. The rule: with hyperthreading enabled, which is the default on modern instances, two vCPUs count as one processor license. Without hyperthreading, one vCPU is one license. And the core factor table does not apply, hold that, we'll test it. The table on screen: an eight vCPU instance, hyperthreading on, four EE processor licenses. The same instance with hyperthreading off, eight licenses, which is why nobody sane disables hyperthreading on Oracle instances without a licensing conversation first. A sixteen vCPU analytics box, eight licenses. Standard Edition 2 gets its own line: SE2 counts four vCPUs as one SE2 processor, with an instance size cap, and for smaller workloads that pricing is genuinely attractive, worth remembering when EE features aren't actually needed. And the last row is the contrast that frames the module: that same eight vCPU workload, on premises in a VMware cluster, faces the core factor table and cluster scope, potentially the whole datacenter under the could run theory. Here, it's four licenses, per instance, with a clean boundary. Per instance counting is the policy's gift. The rate itself, as you're about to see, is its price.
First check, the reflex test. A team sizes an EE database on a sixteen vCPU AWS instance, hyperthreading on. Applying on premises instincts, they compute: sixteen vCPUs, times the zero point five core factor, is eight cores, is four licenses. The policy actually requires: A, four licenses, their math holds. B, eight licenses: sixteen vCPUs at two per license, because the core factor table does not apply in authorized clouds. C, sixteen licenses, one per vCPU always. Or D, two licenses, cloud instances count at quarter weight. Pause here. Which rulebook is running: the core factor table, or the cloud policy?
The answer is B, eight licenses, and the team's error is the single most common one in hyperscaler licensing, so let's dissect it. They applied two rules where only one exists: they took the vCPU count, applied the core factor as if vCPUs were cores, and got a number exactly half of reality. The policy's arithmetic is self contained: sixteen vCPUs, hyperthreading on, divide by two, eight licenses, done. No core factor, because the core factor table explicitly does not apply in authorized cloud environments. Why does this matter so much? Because the half count error systematically undercounts every estimate it touches: the migration business case is wrong by half, the license allocation is wrong by half, and the deficit compounds silently until an audit prices it at list plus back support. An error that fits in one spreadsheet cell funds entire audit practices. C, one per vCPU, is the rule only when hyperthreading is off, which is exactly why turning hyperthreading off is a licensing decision wearing a performance costume. And D's quarter weight exists nowhere, though I've seen it confidently asserted in two real meetings. The rule fits on a sticky note: HT on, divide by two, no core factor. Put it on the sticky note.
Now the comparison that frames every platform decision your estate will make, the same eight EE licenses in three worlds. World one, on premises VMware: those eight licenses face the partitioning policy, cluster scope claims, could run logic, and containment costs architecture and evidence. Hostile counting, and strategically, it's the push. World two, the hyperscalers: the same eight licenses cleanly cover sixteen vCPUs with hyperthreading on, per instance, defensible boundaries, no cluster theories. Neutral counting, the toll road: fair-ish rules, full price. World three, OCI with BYOL: the same eight licenses cover sixteen OCPUs, and an OCPU is a full hyperthreaded core, roughly two vCPUs, so call it thirty two vCPUs of capacity, plus the BYOL service rate, plus Support Rewards accruing on the consumption. Generous counting, the pull. One license, three values, and the gradient runs exactly one direction: away from your datacenter, toward Oracle's cloud, with the hyperscalers priced deliberately in between. This isn't an accident of policy drafting, it's Oracle's migration strategy expressed as arithmetic, and once you see it, you can use it: every platform business case your estate produces should show all three columns, because the license capacity difference alone can swing a TCO before a single service rate is compared. Let's hear what happens when nobody runs this comparison.
Guest analyst A retail client called me eight months after migrating forty Oracle databases from their datacenter to AWS, because their license position suddenly did not add up. Here is what had happened, and I want you to hear how reasonable every step sounded. The infrastructure team sized the AWS instances generously, because cloud, why not, the hardware is elastic. Databases that ran on four cores on premises landed on sixteen vCPU instances. The licensing analyst, a good one, applied the core factor out of habit and signed off a count that was half the real requirement. And then autoscaling was enabled on the three busiest workloads, because that is what cloud is for. Net effect: an estate that was properly licensed for its on premises footprint needed roughly two point four times its license count on AWS, and nobody had noticed, because three teams each made one locally sensible decision. The remediation cost seven figures, negotiated down from a much worse opening position. And here is the part that stays with me: on OCI BYOL, their existing licenses would have covered the entire migrated estate with room to spare. Nobody ran that comparison, because the platform decision was made in an infrastructure meeting that licensing was not invited to. One meeting invitation would have been the cheapest license optimization in the company's history.
Three teams, three locally sensible decisions, two point four times the license requirement, and the platform that would have covered everything was never compared. The meeting invitation is the control: licensing sits in the migration design review, every time. That's trap prevention for the price of a calendar entry.
Check two, the capacity question, CFO phrasing. We hold twenty EE licenses. Capacity wise, what do they buy on Azure versus OCI BYOL? A, the same either way, a license is a license. B, Azure: forty vCPUs with hyperthreading on. OCI BYOL: forty OCPUs, roughly eighty vCPUs of capacity, plus BYOL service rates and Support Rewards on the spend, so OCI buys roughly double the capacity per license, by design. C, Azure eighty vCPUs, OCI forty, the hyperscaler is more generous. Or D, neither, EE licenses can't leave the datacenter. Pause here. Two vCPUs per license there, two OCPUs per license here. What's an OCPU worth in vCPUs?
The answer is B, and the unit arithmetic is the whole question. On Azure, the authorized cloud policy: two vCPUs per license, twenty licenses, forty vCPUs. On OCI, the BYOL ratio from session eight: two OCPUs per license, forty OCPUs, and here's where session six's unit discipline pays off, an OCPU is a full physical core with hyperthreading, presenting roughly two vCPUs, so forty OCPUs is on the order of eighty vCPUs of capacity. Same twenty licenses: forty vCPUs of capacity in Microsoft's cloud, eighty in Oracle's, before you add the BYOL rate advantage and before Support Rewards starts paying the support bill from the consumption. Double the capacity per license, by design, the pull end of the gradient stated as a number a CFO can hold. C has the worlds backwards, and D underestimates the policy entirely, the licenses travel fine, what changes is their purchasing power on arrival. This is the slide I'd want your leadership to see before any platform decision, and the homework makes you compute it for your own shelf.
The neighboring rules, because the vCPU conversion is the headline but five other rules travel with every workload. One, NUP minimums hold: Named User Plus licensing works in authorized clouds, and the twenty five NUP per processor minimum applies to the policy computed processor count. Eight vCPUs, hyperthreading on, is four processors, is a hundred NUP minimum, even for a database with twelve actual users. Two, options ride along, still: Partitioning, RAC, the packs, everything used in the cloud must be licensed at the instance's computed count. Session eight's rule, unchanged, and the feature usage views record everything, in every cloud, always. Three, one license one place, still: licenses counted on AWS stop covering the datacenter, the migration overlap needs cover, and session eight's check three applies word for word, license included for the overlap or a negotiated bridge. Four, DR counts: a standby instance in a second region or account is a running deployment, and the ten day failover rule is exactly as narrow in the cloud as the Mastery course taught, one passive node, ten separate days, and a replicated standby never qualifies. Pilot light DR still runs a database. And five, the cloud native one: autoscaling counts at peak. If the group can scale to thirty two vCPUs, the licensing exposure is thirty two vCPUs, however briefly it got there. Plan for the cap, or cap the plan.
The five traps, which are the five ways migrations become findings, and you've now met most of the ingredients. Trap one, the half count: the core factor instinct, check one's error, systematically undercounting by half, surfacing at audit with back support attached. Trap two, instance sprawl: dev, test, and proof of concept instances cloned from production images, each one a full installation carrying the full counting rule. The production estate is tidy and licensed; the clones around it aren't, and audit scripts find images as reliably as they find databases. Trap three, elasticity: autoscaling groups and console resizes change the license requirement live, in an afternoon, with no purchase order and no alert, unless you built the alert. Trap four, the DR mirror: the cross region standby doubles the estate, pilot light still runs a database, and both were sized once at launch and never recounted. And trap five, the one that spans clouds: license set confusion. The licenses covering the AWS estate get terminated in a support reduction, or counted at a ULA certification, or allocated to OCI BYOL, by a team that had no idea AWS was using them, because the allocation lived in someone's head. The common thread across all five: hyperscaler counting is per instance and dynamic, entitlements are static and finite, and only a ledger connects the two worlds. Which is why the discipline slide is coming.
Last check, an audit scenario built from traps two and three. The letter covers your AWS estate. Discovery finds: twelve production vCPUs, properly licensed. An autoscaling group that peaked at twenty four vCPUs during Black Friday week. And three test instances, cloned from the production image, running unlicensed. The exposure read: A, none, test instances and transient peaks don't count. B, the peak set the requirement at twelve licenses for the group, and each test instance needs its own count: both are real findings, priced at list plus back support in Oracle's opening position. C, only the test instances count, autoscaling is exempt. Or D, everything is covered by the AWS marketplace agreement. Pause here. What did the peak do to the requirement?
The answer is B, both findings are real. The autoscaling peak: installed and running counts, in every cloud, and twenty four vCPUs at two per license set the group's requirement at twelve licenses for the period it ran, however brief. Black Friday's revenue does not appear as a mitigating clause anywhere in the policy. The test instances: cloned from a production image means full installations, and the counting rule doesn't have a test discount, the same lesson the Mastery course taught about templates, now with cloud images. C's autoscaling exemption doesn't exist, and D misunderstands the paper stack from module one: the AWS agreement governs infrastructure, Amazon's obligations to you, and says precisely nothing about Oracle entitlements, which live in your Oracle orders. Now the defense, in order: challenge the pricing theory, opening positions price at list and negotiate like everything else. Resolve commercially, usually into a forward purchase. And fix the design so it can't recur: scaling caps matched to licensed capacity, licensed instance pools, and clone hygiene. But the real answer is a week earlier: both findings cost one sentence each in a design review. That's the entire economics of this session, settlements versus sentences.
The hyperscaler discipline, five habits, and by now you could write this slide yourself. One, count at design: every architecture review touching an Oracle workload on AWS, Azure, or GCP computes the license requirement with the policy's rule, at configured peak, before anything deploys. This is the advisor's meeting invitation, made standing. Two, cap the elasticity: autoscaling groups on Oracle instances get maximum sizes matched to licensed capacity, or Oracle workloads run in dedicated, licensed pools. An uncapped group is an unbounded liability with a nice dashboard. Three, one ledger, all clouds: session eight's entitlement ledger extends to name the cloud on every allocation. AWS instances, OCI BYOL, and the remaining datacenter all draw from one finite shelf, and the ledger is the only place that truth lives. Four, tag Oracle workloads: a dedicated tag on every instance running Oracle software, in every cloud, so the quarterly count is a query rather than an expedition, session ten's tagging discipline with a licensing purpose. And five, recount quarterly: instance inventory against the ledger, peaks included, folded into the same quarterly sitting as the BYOL reconciliation. One meeting, every cloud, one hour. The pattern hasn't changed since session two and it won't change by session thirty: owned, dated, repeated.
Session eleven, three sentences. One: the authorized cloud policy is another unsigned rulebook, but a workable one, two vCPUs per processor license with hyperthreading on, per instance, core factor off, and both sides count by it, so make it reflex and put it on the sticky note. Two: the same license is worth cluster pain on VMware, two vCPUs on a hyperscaler, and roughly four vCPUs of capacity on OCI BYOL, a deliberate gradient that is Oracle's migration strategy in arithmetic form, and it belongs in every platform decision your estate makes. Three: hyperscaler counting is per instance and dynamic while your entitlements are finite and static, so count at design, cap the elasticity, and run one ledger across every cloud, recounted quarterly in the sitting you already have. Next session we go from policy to practice: Oracle Database on AWS, the actual services. RDS with its license included option, RDS with BYOL, EC2 self managed, where each one wins, and the Multi AZ wrinkle that doubles more license counts than any other checkbox in the console. See you there.
Homework, about an hour, and it's a census. One, inventory the instances: every AWS, Azure, or GCP instance running Oracle software, with vCPUs, hyperthreading state, edition, and options in use. If the Oracle tag from the discipline slide exists, this is a five minute query; if it's an expedition through three consoles, write that down, because the expedition is finding number one. Two, apply the rule: compute the license requirement per instance, at configured peak for anything that scales, and total it. Three, reconcile against the ledger: match the requirement to allocated entitlements. A surplus is negotiating material; a deficit is this quarter's remediation, handled on your timeline, quietly, which beats an auditor's timeline at list. Four, check the clones: search for instances built from Oracle bearing images outside production, trap two lives in the sandbox account nobody reviews. And five, cap one group: find the largest uncapped autoscaling group that touches Oracle software and give it a maximum matched to licensed capacity. One console setting, one unbounded liability closed, today. That's the census. Next session assumes you know what's running where.
Five reads before next session, all free on redress compliance dot com. First, Oracle database licensing in cloud environments, today's policy in reference form, the counting rules with worked examples. Second, Oracle database licensing on AWS, the AWS specific version, which is exactly next session's terrain. Third, Oracle database licensing on AWS with BYOL, bringing your entitlements to Amazon's cloud, the retention rules and ratios. Fourth, OCI versus AWS for Oracle workloads, the three worlds comparison with prices attached, module three's running theme. And fifth, for contrast and for leverage, cracking the per core VMware licensing model, the hostile end of the counting gradient, worth keeping fresh because it's the alternative every hyperscaler and OCI conversation is implicitly priced against. That's session eleven: the rulebook is unsigned but workable, the gradient is deliberate, and the ledger now spans every cloud you run. Next time, RDS versus EC2, in practice. See you there.