Oracle runs in AWS, Azure, and Google Cloud under a published policy with sharp arithmetic: two vCPUs per processor license, no core factor, which roughly doubles the per core cost against on premises and quietly flatters OCI's BYOL ratios. This session reads the authorized cloud policy for what it is, a non contractual document your estate now relies on, runs the vCPU counting against real instances, walks the traps, autoscaling maxima, threading toggles, warm DR, and the ULA certification exclusion that has cost estates eight figures, and closes with the dedicated host exception that restores the core factor and the three homes comparison that keeps the estate choosing.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the 16 vCPU workload that doubles from 4 licenses on premises to 8 in AWS, the ULA certification exclusion that strips cloud deployments from the count, and the autoscaling group licensed for its average instead of its configured maximum. It closes with one workload counted four ways, on premises, EC2, dedicated host, and OCI BYOL, the comparison that decides the home.
The full narration of this session, section by section, for reading and reference.
Welcome back, session twenty nine of forty. So far, module six has lived inside Oracle's own cloud: the credits, the BYOL ratios, the Support Rewards flowing back to the datacenter. Today we cross the boundary, because most enterprises run most of their cloud somewhere else, and Oracle software runs there too: on AWS, on Azure, and on Google Cloud, legally, commonly, and under counting rules that surprise every single first timer. Here's the surprise, stated up front so it never surprises you: the same database workload that needs four processor licenses on premises needs eight in a hyperscaler. Not because the policy is hidden, it's published, but because the core factor, the friendly zero point five multiplier from session two that every on premises estate takes for granted, does not exist in the authorized clouds. The counting basis changes at the cloud boundary, and the change costs real money. Today: the authorized cloud environment policy, what it is and pointedly what it isn't. The vCPU counting rules, run against real instances. The three clouds and what each offers an Oracle estate. The traps, autoscaling, threading toggles, cloud DR, and a ULA certification exclusion that has burned estates for eight figures. The dedicated host exception that brings the core factor back. And the governance that keeps all of it inside session twenty five's records. The boundary, mapped. Let's cross it.
Five takeaways. One, you'll read the policy: the authorized cloud environment document, what it covers, AWS, Azure, and Google Cloud, and what it is, a published policy rather than a contract term, a distinction this course has taught you to notice, and which cuts differently this time. Two, you'll count vCPUs correctly: two vCPUs per processor license with hyper threading, one without, four per socket equivalent for Standard Edition, and no core factor anywhere, the rules run against real instance shapes until they're reflexive. Three, you'll price the premium: why the same workload roughly doubles its license requirement crossing into a hyperscaler, and what that does to every migration business case and every harvest calculation from session twenty seven. Four, you'll dodge the traps: the autoscaling maximum that licenses the peak you never run, the threading toggle that silently doubles the count, RAC's absence, cloud DR, and the ULA certification exclusion, the single most expensive footnote in this module. And five, you'll govern the estate: hyperscaler Oracle inside the gates, tags, caps, and allocations of the session twenty five operating model, because the position is now per environment, and untracked clouds are unpriced risk. The stakes, next.
Four numbers. Two: vCPUs per processor license, with hyper threading enabled, the authorized cloud counting rule that replaces everything module one taught about counting cores. Simple, published, and the foundation of every calculation today. Zero: the core factor in authorized clouds. The zero point five multiplier from session two's table simply does not apply, and its absence roughly doubles the license cost per core of compute. Hold that: the policy giveth a countable basis, and taketh away the factor. Three: the authorized environments, AWS, Azure, and Google Cloud, the last added most recently. Everything else, the regional clouds, the hosting providers, the colo down the street, sits outside the policy, where the contract's default rules count physical hosts you cannot see, which is effectively unusable. Authorization is what makes hyperscaler Oracle finite. And one: one more policy document, because like session twenty three's partitioning paper, the cloud policy is non contractual, published, changeable, incorporated by no OMA. The difference, and it's philosophically delicious: this time your estate is the one relying on the policy, not resisting it. And the module's hidden punchline lives in this slide: OCI's BYOL ratio, one license per two OCPUs, effectively preserves your core factor. The hyperscalers don't. That gap is Oracle's cloud strategy, written in arithmetic. The policy itself, next.
The authorized cloud environment policy, properly read. Its name: Licensing Oracle Software in the Cloud Computing Environment, one document, publicly posted. What it does: defines how processor and Named User Plus licenses count in AWS, Azure, and Google Cloud, by virtual CPU, at fixed ratios, instead of by the cloud provider's physical hardware. Why estates need it, and this is worth feeling: without the policy, your contract's default counting applies, physical cores, on multi tenant hosts you cannot see, cannot bound, and cannot inventory. Unusable. The policy is what makes hyperscaler Oracle licensable at all, and that is its genuine gift. What it is not: a contract term. No OMA incorporates it. Oracle publishes it, and Oracle can change it, the same legal status as the partitioning paper from session twenty three, except this time you're the one leaning on the policy rather than fighting it. Sit with that asymmetry for a second, because it belongs in your risk register. Who it covers: the named environments only. That regional sovereign cloud, that managed hosting provider, that colocation deal, none are authorized environments, and Oracle software there is counted under default rules. Check before assuming, always. And the stability record, honestly: the policy has held for years, Google was added rather than anyone removed, and the market relies on it at massive scale. But the mature posture is the session eight posture: use the policy, record your reliance, and for material hyperscaler footprints, negotiate the counting into the contract, where terms belong. The rules themselves, next.
The counting table, five rows that replace the core factor. Row one, the workhorse: Enterprise Edition with hyper threading enabled, two vCPUs per processor license. A sixteen vCPU instance needs eight licenses. Simple division, no factor, no exceptions. Row two, the expensive corner: hyper threading disabled, and the divisor halves, one vCPU per license. The same sixteen vCPU instance now needs sixteen licenses. Threading is an instance setting, sometimes changed for performance tuning, and every change to it is a licensing event nobody tells licensing about. Know the state; record the state. Row three, Standard Edition Two: four vCPUs count as one socket equivalent, translating SE2's socket limits from session three into cloud shapes, with SE2's caps still applying. For small databases, this row plus license included services is genuinely economical. Row four, the named user metrics: NUP licensing works in the clouds on the same vCPU basis, and session two's user minimums follow the count. The users still get counted at the front end, multiplexing rules intact. And row five, the boundary: non authorized clouds get the contract default, physical host counting, which is the polite way of saying don't run Oracle there without contractual terms. One habit ties the table together: every hyperscaler Oracle instance gets its vCPU count, threading state, and license allocation recorded at deployment time in the session twenty five library. The count, tested against on premises. Knowledge check one.
Knowledge check one. A sixteen vCPU EC2 instance, hyper threading enabled, runs Enterprise Edition Database. On premises, the same workload ran on eight Intel cores at the zero point five core factor. How many processor licenses does each deployment need? A, four on premises and four in AWS, the counting is the same everywhere. B, four on premises, eight cores times zero point five, but eight in AWS, sixteen vCPUs divided by two with no core factor: the cloud move doubles the license requirement. C, eight on premises and four in AWS. Or D, sixteen in AWS, one per vCPU. Pause here. Which multiplier exists on premises and vanishes in the cloud?
The answer is B, and this pair of calculations decides more cloud business cases than any other arithmetic in the module, so run it slowly once. On premises: eight Intel cores, times the zero point five core factor from session two's table, equals four processor licenses. In AWS: sixteen vCPUs, hyper threading on, divided by two per the policy, equals eight. The core factor does not apply in the cloud; the policy's ratios replace the factor table entirely. Same workload, same underlying silicon, twice the licenses. Price it: four extra Enterprise Edition licenses is a hundred ninety thousand dollars at list, plus nearly forty two thousand a year of support, per instance, forever. And now connect it to the module's architecture, because this is not a drafting accident: the doubled hyperscaler count is exactly what makes OCI's BYOL ratio, one license covering two OCPUs, which preserves core factor parity, look generous. Oracle's cloud strategy is written in this table, and now you can read it. The practical consequences: every lift and shift business case must count licenses at the destination's rules, and session twenty seven's harvest arithmetic must be rerun for hyperscaler destinations, the surplus that covered a workload on premises covers half of it in EC2. And D deserves its warning label: one license per vCPU is what this instance becomes if someone disables hyper threading for performance, a tuning change that doubles the count silently. Check the threading state; alert on changes to it. A and C assume a portability the policy never granted. The environment is now part of the license position, and the counting is per environment, always. The three clouds themselves, next.
The three authorized clouds, briefly, because the counting is common but the packaging differs. AWS: EC2 for self managed Oracle, everything this session has counted so far, plus RDS for Oracle, the managed database service, offered license included on Standard Edition Two tiers or bring your own license for the rest. The biggest installed base of Oracle in the cloud outside OCI itself, and the default destination in most migration conversations. Azure: virtual machines for self managed deployments under the same counting, plus something structurally new, Oracle Database at Azure, actual Oracle hardware and services placed inside Azure datacenters, sold on OCI style commercial constructs. The multicloud era's flagship arrangement. Google Cloud: the newest authorized environment, added to the policy with an Oracle partnership mirroring the Azure model. Same counting rules since its addition, same due diligence required. RDS license included deserves its own mention: SE2 in the hourly rate, genuinely convenient for small databases, bounded by SE2's limits from session three, and often the honest answer for the workloads that fit it, per session twenty seven's license included logic. And the multicloud reality, worth a beat: Oracle now sells its database inside its rivals' datacenters, which means the OCI commercial constructs from sessions twenty six and twenty eight follow you into Azure and Google. For your own deployments, though, today's counting governs. Strategic note: these clouds are your OCI alternative, and OCI is your lever against them. Keep both quotes current, per module four. Now, the trap with module three consequences. Knowledge check two.
Knowledge check two. A ULA estate deploys heavily on AWS during the term, planning to count those cloud deployments at certification, per session fourteen. What does the playbook say now? A, nothing changes, deployments are deployments. B, danger: standard ULA terms have historically excluded or restricted counting authorized cloud deployments at certification, so check the contract now, and negotiate cloud counting before relying on it. C, cloud deployments count double at certification. Or D, ULAs cannot be used in the cloud at all. Pause here. What does the certification clause actually say about where deployments live?
The answer is B, and this is the module six trap with module three consequences, the single most expensive footnote in the cloud licensing world. The standard pattern in ULA agreements: deploying in authorized clouds during the term is fine, the unlimited grant covers it. But the certification clause, the mechanism from session fourteen that converts usage into perpetual licenses at exit, has historically excluded or sharply restricted cloud deployments from the count. Some agreement generations allow a cloud average, some require deployments on premises at the certification date, some are silent, and silence in a certification clause is never your friend. Now price guessing wrong. An estate migrates aggressively to AWS during the ULA term, feeling clever, unlimited deployment, why not. Certification arrives, the clause counts only the shrunken on premises footprint, and the estate walks away with a fraction of the licenses its actual usage justified. Then it must license its entire AWS estate from scratch, at this session's doubled vCPU rates, at list, immediately. The module three nightmare and the module six arithmetic, compounding. Eight figures of exposure, born in one unread clause. The playbook, amended: read the certification clause now, not at month thirty three. If the cloud roadmap overlaps the ULA, negotiate explicit cloud counting language at entry or renewal, when leverage exists. And if the clause can't be fixed, sequence around it: certify first from the on premises peak, then migrate on the certified licenses. A is the assumption that costs eight figures. C is folklore. D overcorrects, deployment is permitted; counting is the issue. The permanent lesson: the grant clause and the exit clause are different clauses, and module three taught you which one gets drafted more carefully. The rest of the traps, next.
The traps, five patterns that generate hyperscaler findings, every one preventable at design time. Autoscaling: licenses must cover the configured maximum, not the average, because capacity metrics license what can run. An autoscaling group that can reach thirty two vCPUs is a sixteen license requirement, however rarely it peaks, and we'll price exactly this in the final check. The threading toggle: disabling hyper threading halves the divisor, one vCPU per license instead of two, doubling the count. It's a performance setting, changeable by any engineer with console access, and every change is a silent licensing event. Alert on it. RAC and clustering: Real Application Clusters is not generally supported on native hyperscaler infrastructure, and architectures that assume RAC in EC2 should be caught at session twenty five's architecture gate, not discovered mid migration. The engineered systems session next week covers where RAC actually lives in the cloud era. Cloud DR: session twenty three's three postures apply verbatim across the boundary. Backups at rest are fine; a warm standby in AWS is installed and running, and needs licenses at cloud counting rates. The DR sizing that was affordable at the on premises factor doubles in the cloud, which changes designs. And the tooling blind spot: discovery tools tuned for datacenters miss cloud instances entirely, so the deployment baseline must ingest the cloud providers' own inventories, or session twenty five's position is fiction with a dashboard. Notice the shared shape: elastic, tunable, ephemeral cloud behaviors meeting license metrics that assume none of those things. One gate question catches all five: what does this do to the license position? The exception that helps, next.
Dedicated hosts, the exception where the core factor comes home. The construct: AWS Dedicated Hosts and their equivalents rent you an entire physical server, yours alone, cores visible, hardware controlled, sitting inside the hyperscaler's datacenter. The counting consequence: with the physical hardware under your control, the standard on premises rules can apply, physical cores times the core factor, session two's table restored, the halving recovered. The sixteen vCPU workload that needed eight licenses on shared EC2 needs four on a dedicated host with eight physical cores. When it wins: large, steady Oracle footprints, where halving the license requirement outweighs the dedicated host premium, which is real but fixed. Run both counts; the crossover is genuine, and for big estates it arrives quickly. Below it, shared instances stay simpler and cheaper. The virtualization echo, and enjoy this one: you now own a host running virtual machines, which means session four's containment discipline, affinity, boundaries, evidence, applies inside your own dedicated fleet in the cloud. The oldest rules in the course, in the newest venue, unchanged. And the record: host identifiers, core counts, the factor applied, licenses allocated, filed in the evidence layer, because a dedicated host counting position is exactly the kind of thing session twenty one's machine eventually verifies, and exactly the kind of thing clean records make boring. Dedicated hosts are the arbitrage between today's vCPU rules and module one's core rules. At scale, the arbitrage pays for the architecture. The governance that holds it all, next.
Running hyperscaler Oracle cleanly, five habits, all extensions of machinery you already own. Gate the deployments: Oracle in any cloud routes through session twenty five's architecture gate, where the vCPU count, the threading state, and the license source get decided before launch, not reconstructed after. The gate question is unchanged: what does this do to the license position? Tag and inventory: every Oracle instance tagged as Oracle at creation, with the cloud provider's inventory APIs feeding the deployment baseline automatically. Manual cloud inventories die in a sprint; automated ones join session twenty five's quarterly delta pass and live. Cap the elasticity: autoscaling maxima set to the licensed capacity, documented in the evidence layer, with alerts firing when anyone raises them. One template line, and the entire autoscaling trap disappears from your estate. Allocate explicitly: which licenses cover which instances, recorded in the entitlement library, exactly the discipline session twenty seven built for OCI BYOL, extended to every cloud. An unallocated license position is an argument waiting to happen; an allocated one is a lookup. And rerun the TCO annually: the three homes comparison, hyperscaler at doubled counts, OCI at BYOL ratios, dedicated hosts at restored factors, refreshed as the estate, the discounts, and the roadmap move. The answer genuinely changes year to year, and the estate that reruns it keeps choosing rather than being chosen for. The elasticity trap, priced properly. Knowledge check three.
Knowledge check three. An autoscaling group running Enterprise Edition can scale to thirty two vCPUs but averages eight. The team licensed for the average: four processor licenses. What is the position? A, fine, licensing follows average consumption. B, a twelve license gap: the configured maximum of thirty two vCPUs needs sixteen licenses, so cap the group at the licensed eight vCPUs, buy up, or move the workload to a license included or OCI service. C, fine if the peak is rare. Or D, a problem only during an audit. Pause here. What does the metric license: the usage, or the capacity?
The answer is B, and the principle is as old as module one: the metric licenses capacity, not consumption. Session one counted the cores in the server, not the CPU utilization graph; the cloud version counts the vCPUs the configuration can reach, not the average it happens to run. Thirty two vCPUs at two per license is sixteen licenses. Four are held. The gap is twelve, which at Enterprise Edition list is over half a million dollars of exposure, resident in an autoscaling policy setting. The fixes, evaluated in order. First, cap the group at eight vCPUs, matching the licenses held. If the average tells the truth about the need, this is one configuration change, documented in the evidence layer, and the exposure closes today at zero cost. Most estates discover the cap costs them nothing operationally. Second, buy up to sixteen licenses, if the elasticity genuinely earns its keep, priced honestly: is the ability to quadruple worth four hundred thousand dollars of licenses plus support? Sometimes yes; make it a decision. Third, and this is the deep answer: move the workload somewhere the metric matches the behavior. License included RDS if it fits Standard Edition's limits, or an OCI service where the meter charges for what runs. Elastic workloads and capacity metrics are structurally mismatched, and the elegant fix is changing the model, not the number. A and C are the same wish at different volumes; the policy counts the configured maximum, and a rare peak is still configured. D, for the last time in this module: the position exists whether anyone measures it, the measurement always eventually comes, and session twenty one's machine sends no warnings. The governance slide already wrote the standing answer: maxima set to licensed capacity, alerts on change, decided at the gate. The comparison that closes the arithmetic, next.
One workload, three homes, the honest comparison that closes module six's arithmetic. The workload: the Enterprise Edition database from knowledge check one. Home one, on premises: eight Intel cores at the core factor, four licenses, owned, with thirty five thousand a year of support. The baseline. Home two, AWS EC2 at sixteen vCPUs: eight licenses, double the baseline. Four more licenses than you own, a hundred ninety thousand at list plus support, or twice the draw against session twenty seven's harvest. The migration business case must carry that line, and the ones that skip it are fiction. Home three, an AWS dedicated host: physical cores restored, core factor restored, four licenses again, counting parity recovered, in exchange for the dedicated host premium. At sustained scale the crossover favors dedication, and the containment habits from session four come along. Home four, OCI at sixteen OCPUs BYOL: eight licenses at the two OCPU ratio, numerically the same count as EC2, but attached to roughly seventy five percent off the service rate per session twenty seven, plus Support Rewards flowing on every consumed dollar per session twenty eight. The counting matches the hyperscaler; the economics don't. And the decision row: there isn't one answer. Steady and large favors dedicated hosts or OCI. Elastic favors license included services. Small and simple favors RDS. But counted, always, at the destination's rules, before the migration, in the library. The estate that runs this table before moving chooses its licensing. The estate that moves first gets chosen for. Recap, next.
Session twenty nine in three sentences. One, the authorized cloud policy makes AWS, Azure, and Google Cloud licensable at two vCPUs per processor license with hyper threading, one without, and no core factor anywhere, which roughly doubles the per core license cost against on premises, quietly flatters OCI's BYOL ratios, and rests on a policy document your estate now relies on rather than resists. Two, the traps are cloud behaviors meeting capacity metrics: autoscaling maxima that license the peak, threading toggles that double counts silently, warm DR that needs licenses at cloud rates, and the ULA certification exclusion that has converted aggressive cloud migrations into eight figure exposures, every one preventable at the gate and expensive after it. Three, the counting position is per environment now: recorded at deployment, capped where elastic, restored to the core factor on dedicated hosts where scale pays for it, and rerun annually against the OCI alternative, because the three homes table keeps changing and the estate should keep choosing. Next session closes module six with the constructs between datacenter and cloud: Exadata and the engineered systems, Cloud at Customer, and the dedicated regions, Oracle's hardware in your building on cloud commercial terms, with licensing questions all their own. Homework first.
Homework, about an hour, and it completes the cloud column of your position. One, inventory the hyperscaler Oracle: every Oracle instance in AWS, Azure, or Google Cloud, with its vCPU count, threading state, and allocated licenses. If the list doesn't exist, this hour creates the most important missing record in your estate. Two, audit the autoscaling: every group or scale set running Oracle, configured maximum against licensed capacity. Close the gaps you find deliberately, cap, buy, or migrate, per knowledge check three, and set the alerts so new gaps announce themselves. Three, check the ULA clause: if a ULA is live anywhere in the estate, read what certification says about cloud deployments, this week, not at month thirty three. If the answer is unclear, that ambiguity goes on the risk register today and into the next negotiation. Four, run the three homes table: your largest hyperscaler Oracle workload counted all four ways, shared instance, dedicated host, OCI BYOL, and its current home. Does the current answer still win? The table takes twenty minutes and occasionally saves six figures. And five, feed the baseline: the cloud provider inventory APIs wired into session twenty five's deployment baseline, so the clouds join the position automatically and the quarterly delta pass sees everything. That's the hour. See you in session thirty, where module six closes.
Five reads, all free on redress compliance dot com. First, Oracle Database licensing on AWS: the vCPU rules, RDS options, and instance mechanics, worked in full detail. Second, Oracle on Microsoft Azure: the Azure paths from plain virtual machines to Oracle Database at Azure, and the counting for each. Third, Oracle RAC on AWS, the licensing reality: the clustering trap from today's slide, and what actually works instead. Fourth, Oracle ULAs and AWS: the certification exclusion at full depth, the read that should precede any migration under a ULA, per knowledge check two. And fifth, OCI versus AWS for Oracle workloads: the counting comparison that powers the three homes table, kept current as the policies move. That's session twenty nine. The boundary is mapped: two vCPUs per license, no core factor, three authorized clouds, one policy everyone leans on, five traps with one gate question, and a dedicated host exception that brings the oldest arithmetic in the course back home. One session left in module six: the engineered systems, Cloud at Customer, and the dedicated regions, where Oracle's cloud arrives in your datacenter and the module's constructs meet in the middle. See you there.