Module 6's synthesis: the constructs between datacenter and cloud. Exadata is the most license dense hardware Oracle sells, and Capacity on Demand plus the core factor keep it affordable, license the activated cores, not the installed ones. The same machine comes four ways, owned, Cloud at Customer, Exadata Cloud Service, and Dedicated Region, and the construct is chosen by the binding constraint, residency, latency, sovereignty, elasticity, or cost, with BYOL carrying licenses across all of them. This session places a whole estate across the spectrum, from owned iron to public cloud, and closes the cloud module.
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 48 core Exadata licensed at 8 for its 16 activated cores under Capacity on Demand, the residency bound bank routed to Cloud at Customer, and the elastic dev/test job kept off a committed on premises construct. It closes with one estate placed across five constructs, each chosen by its binding constraint, supplied by one BYOL license pool.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirty of forty, three quarters of the way through the course, and the session that closes module six. We've walked the whole cloud spectrum: session twenty six's credits and commits, twenty seven's BYOL, twenty eight's Support Rewards, and twenty nine's hyperscalers. Today we fill the middle of the spectrum, the constructs that sit between the datacenter and the cloud, where Oracle's hardware and Oracle's cloud economics arrive inside your own building. The star is Exadata, Oracle's engineered database machine, and the reason it closes the module is that it comes four different ways: you can own it outright and license it perpetually, you can take it as Cloud at Customer with the hardware in your datacenter but consumed as cloud, you can rent it as a pure cloud service in an OCI region, or you can have an entire private OCI region installed in your building. Same box, four commercial models, and the choice between them is the synthesis of everything this module taught. Today: how Exadata licenses, Capacity on Demand and why it matters, the four flavors compared, Cloud at Customer for the residency bound, dedicated regions for sovereignty at scale, and the decision framework that places every workload on the spectrum by asking one question, what actually binds. Module six's final piece. Let's assemble it.
Five takeaways. One, you'll license Exadata: the database per processor with the core factor, the options stack that engineered workloads accumulate, the storage cell software, and Capacity on Demand, the lever that lets you license activated cores instead of installed ones. Two, you'll read the four flavors: owned, Cloud at Customer, Exadata Cloud Service, and Dedicated Region, told apart by where the hardware lives, who owns it, and whether you license perpetually or consume. Three, you'll price Cloud at Customer: OCI economics, BYOL, and Support Rewards, on hardware physically in your datacenter, the construct built for data that cannot leave the building. Four, you'll weigh dedicated regions: a full private OCI region, when sovereignty at scale demands it, and when it's expensive overkill. And five, you'll close the module: every workload placed on the datacenter to cloud spectrum by its binding constraint, with harvested licenses flowing across all of it on BYOL. The throughline of the whole session, stated once so it echoes: the construct follows the constraint. Name what binds, residency, latency, sovereignty, elasticity, or cost, and the right home falls out. The stakes, next.
Four numbers, and they frame a synthesis rather than a new topic. Four: the ways to consume Exadata. Owned in your datacenter, Cloud at Customer in your datacenter, Exadata Cloud Service in an OCI region, and inside a full Dedicated Region on your premises. One machine, four commercial models, and the entire session is learning which fits when. Two: the license worlds that meet in this session. Perpetual licensing with the core factor, from module one, on owned iron, and consumption pricing, from module six, on the cloud variants. Every construct today is one, the other, or a bridge between them. Capacity on Demand, abbreviated CoD: license the cores you activate, not the cores installed, the engineered systems answer to the counting problem module one opened with, and the lever that keeps a machine shipping with dozens of cores affordable. And zero: the public cloud exit you need to get OCI economics. That's the quiet revelation of the hybrid constructs, BYOL, Support Rewards, consumption pricing, all available on hardware inside your own walls, for the estates that data residency or latency keeps out of the public cloud. This is module six's synthesis slide: everything counted across sessions twenty six to twenty nine, arranged on one spectrum from owned hardware to full public cloud, with your datacenter available as a location at every single point on it. Exadata itself, first.
Exadata, and how it licenses. First, what it is: a pre integrated database machine, compute, storage, and networking engineered together and tuned specifically for Oracle Database, sold as one appliance. The licensing follows the database, with engineered specifics. Five facts. The database licenses normally: Enterprise Edition per processor, the core factor from session two applied to the activated database cores. Oracle's own hardware, module one's arithmetic, no surprises there. Capacity on Demand, the crucial lever: the machine ships with all its cores installed, but you activate a subset and license only those, lighting up and licensing incrementally as the workload grows. A genuine buyer advantage, and the answer to the final knowledge check, so hold it. The options add up: Exadata workloads lean hard on RAC, Partitioning, Advanced Compression, and more, each separately licensed, and engineered estates carry heavy options bills, which is also why they carry heavy options audit exposure per session twenty three. The storage cells: Exadata storage server software licenses per disk, its own line item, so the all in cost exceeds the database licenses alone, count the whole stack, not just the database. And the owned model: buy the hardware, license perpetually, pay the twenty two percent support, a capital purchase with module four's annuity attached and module five's audit exposure alongside it. Owned Exadata is the most license dense hardware Oracle sells, and the core factor and Capacity on Demand are the two levers that keep it affordable. The four flavors, next.
Four ways to consume the same machine, in one table. Owned Exadata: lives in your datacenter, licensed with perpetual licenses, the core factor, Capacity on Demand, and twenty two percent support. The traditional capital purchase. Cloud at Customer: also lives in your datacenter, but Oracle owns the hardware and you consume it as an OCI service, either license included in the rate or BYOL your own licenses in. The hybrid heart, and its own slide next. Exadata Cloud Service: lives in an OCI region, fully managed, consumed as cloud, license included or BYOL, the pure cloud flavor for estates without a residency constraint. Dedicated Region: a full OCI region installed in your datacenter, consumption across the whole catalog, the largest construct, coming shortly. And the common thread running down the table: BYOL carries your licenses into any of them, per session twenty seven. That's the unifying insight, the same physical Exadata underlies all four flavors; what changes is who owns the iron, where it physically sits, and whether you pay perpetually or by consumption. Your harvested license pool from session twenty seven is portable across the entire row, which means the license strategy and the construct strategy are separable decisions. Choose the construct by constraint, supply it with BYOL where you hold licenses. The arithmetic that makes owned Exadata affordable, tested. Knowledge check one.
Knowledge check one. An owned Exadata ships with forty eight database cores installed. The workload needs sixteen. Under Capacity on Demand, how many Enterprise Edition processor licenses are required? A, twenty four, all forty eight installed cores at the zero point five factor. B, eight, only the sixteen activated cores count, times the zero point five core factor, because Capacity on Demand licenses activated cores not installed ones. C, sixteen, one license per activated core, no factor. Or D, forty eight, engineered systems have no core factor. Pause here. What does Capacity on Demand let you count?
The answer is B, and two levers stack to get there, both real. Capacity on Demand means you license the cores you activate, not the cores that shipped in the chassis, so the forty eight installed cores are simply irrelevant to the count, only the sixteen activated ones matter. Then session two's core factor applies normally, because this is Oracle's own hardware running on premises, and the authorized cloud policy from session twenty nine does not touch owned Exadata: sixteen activated cores times zero point five equals eight processor licenses. And the contrast with last session is exactly why this check sits here. In AWS, sixteen vCPUs cost eight licenses with no factor; on owned Exadata, sixteen activated cores cost eight licenses with the factor, and you can grow to forty eight cores in place as the workload grows, licensing incrementally, on hardware you control. Same license count at this size, but a completely different growth path and cost curve. The wrong answers each teach a real mistake. A licenses the installed capacity instead of the activated capacity, the classic engineered systems error, a threefold overcount on a machine that ships full, and a genuine line item that appears in first year Exadata budgets written by people who didn't know about Capacity on Demand. C strips the core factor that owned on premises hardware is entitled to, session twenty nine's rule applied in the wrong venue. D is just false; the factor table covers Exadata's processors like any Oracle hardware. And the discipline is module five's: activated core counts are a compliance position, Capacity on Demand configurations are auditable, and the evidence, which cores are lit and when they were activated, lives in the entitlement library. A gift with a ledger entry. Cloud at Customer, next.
Exadata Cloud at Customer, the hybrid heart of the module. The arrangement: Oracle installs and owns Exadata hardware inside your datacenter, and you consume it as an OCI service, metered, with Oracle managing the infrastructure layer. Cloud economics, cloud operations, on a box in your building. Why estates choose it, and it's always a specific why: data that cannot legally or contractually leave the premises, latency that cannot tolerate the round trip to a cloud region, regulatory constraints that pin the location, all satisfied while still getting OCI's consumption economics. The licensing: license included in the service rate, or BYOL your existing licenses at session twenty seven's ratios, which means the BYOL harvest reaches right into your own datacenter, your shelf licenses lighting up Oracle's hardware on your floor. Support Rewards apply: Cloud at Customer consumption earns the twenty five cents against your on premises support bill per session twenty eight, so hardware in your building subsidizes the support annuity for the rest of your estate. And the commitment shape, where the complexity lives: an OCI style consumption commit with all of session twenty six's mechanics, the expiry clock included, plus a hardware term underneath it. Two clocks and a lease, in one deal, all of which belong in the session twenty five calendar. The honest framing: Cloud at Customer answers one specific question, I want OCI economics but the data must stay here. If that's your question, it's excellent. If it isn't, it's an expensive way to buy what public OCI sells cheaper. The constraint test, applied. Knowledge check two.
Knowledge check two. A bank needs OCI's BYOL economics and Support Rewards, but by regulation cannot move customer data off premises. Which construct fits? A, standard OCI, the data residency rule can be waived for cloud. B, Exadata Cloud at Customer, OCI consumption, BYOL, and Support Rewards on Oracle hardware inside the bank's own datacenter, satisfying residency. C, owned Exadata only, consumption models cannot run on premises. Or D, AWS with a dedicated host, to keep the core factor. Pause here. Which construct puts cloud economics where the data must stay?
The answer is B, and Cloud at Customer exists for precisely this requirement; the bank's three constraints map onto it one for one. Data residency: the hardware sits in the bank's own datacenter, so customer data never leaves the building, and the regulator's line holds. BYOL economics: the bank's existing licenses carry in at session twenty seven's ratios. Support Rewards: consumption earns the twenty five cents against the on premises support bill per session twenty eight, even though the box is physically on site. One construct, all three needs, which is exactly why Oracle built it. The wrong answers are each instructive. A misreads a hard regulatory constraint as negotiable; a residency requirement written into banking regulation is not waived because a cloud model would be tidier, and suggesting it to a compliance officer ends the meeting. C is outdated, and its obsolescence is the entire innovation of the construct: consumption models now run on premises, that's the point of Cloud at Customer. D solves a different problem, the dedicated host preserves the core factor, genuinely useful per session twenty nine, but it's AWS, off premises, failing the residency test that dominates every other consideration here. And that's the lesson closing the cloud module: the construct follows the binding constraint. When residency binds, Cloud at Customer. When latency binds, the same. When neither binds but scale and sovereignty do, a dedicated region, coming next. And when nothing binds but cost, ordinary OCI or a right sized owned system. Name the constraint first, and the construct falls out of it, every time. Dedicated regions, next.
Dedicated Region, the largest hybrid construct, for the largest requirements. The construct: not one machine but an entire OCI region installed in your datacenter, the full service catalog, compute, storage, database, everything, run by Oracle, consumed as cloud, located in your building. Where Cloud at Customer gives you Exadata on premises, a dedicated region gives you all of OCI on premises. Who needs it: governments, banks, and telcos with sovereignty or scale requirements that rule out the public regions entirely but want the complete OCI experience, not just the database piece. The commercial floor: a large annual consumption commitment underwrites the region, because Oracle is installing a datacenter's worth of cloud in your building. This is an eight figure construct, and below that scale, Cloud at Customer or public OCI is the honest answer; a dedicated region for a modest estate is a category error. The licensing: consumption across the whole catalog, BYOL wherever you hold licenses, Support Rewards on the spend, module six's entire toolkit, running in a private region. And DRCC, Dedicated Region Cloud at Customer: the productized, smaller sibling that lowers the entry point while keeping the full region model, and the floor moves, so read the current threshold before assuming either is out of reach or necessary. The dedicated region is where the module's constructs converge, a private OCI, with BYOL and Rewards, sized for organizations that need the cloud and cannot use the public one. The decision framework, next.
Choosing the construct, by constraint, because the spectrum only sorts itself once you name what binds. Five cases. Cost binds only, nothing else: a right sized owned system if the load is steady and capital suits the balance sheet, or public OCI if consumption fits better. These are the cheapest homes, available whenever location is genuinely free. Residency or latency binds: Exadata Cloud at Customer, cloud economics delivered where the data must physically stay, the middle of the spectrum for the middle of the estate. Sovereignty at scale binds: a Dedicated Region, the whole catalog privately, for organizations that cannot touch a public region and are large enough to underwrite one. Elasticity binds: public OCI or a hyperscaler service, per sessions twenty six and twenty nine, because engineered systems reward steady load and punish spiky load, so match the metric to the shape rather than forcing elastic work onto committed iron. And running through all of them, the BYOL thread: whichever construct wins, harvested licenses carry in at session twenty seven's ratios and consumption earns Rewards, so your license pool is portable across the entire spectrum and never strands. The reality for real estates: one organization usually spans several constructs at once, owned for the steady core, Cloud at Customer for the regulated data, public OCI for the elastic edge, and that mixed portfolio, chosen constraint by constraint, is the correct answer, the same portfolio logic this course has reached in every module. The traps, next.
The hybrid traps, five of them, and the governance that catches each. Installed versus activated: Capacity on Demand licenses activated cores, but activations creep upward as workloads grow, quietly, and each activation is a licensing event that belongs in the diary. The machine makes it one click to light another core and zero clicks to tell licensing. The options stack: engineered systems invite RAC, Partitioning, and the packs, each a separate entitlement, and Exadata is precisely where options findings cluster in audits, per session twenty three, because the workloads that justify Exadata are the workloads that use every option. Two clocks on Cloud at Customer: the consumption commit expires annually and the hardware sits on a separate term, and both belong in the session twenty five calendar, or the one you forgot surprises you at renewal. The residency premium: Cloud at Customer and dedicated regions genuinely cost more than public OCI, and paying that premium without a binding residency or latency constraint is expensive comfort, buying a regulatory feature you don't need. And the exit question: owned Exadata is a capital asset you can run indefinitely, while Cloud at Customer is a lease with a commit and an end, so know the exit terms before the term starts, not at renewal under pressure, module four's banking discipline applied to hardware. Every trap has the same governance answer, the session twenty five gate and calendar: decide at deployment, diary the clocks, record the activations, review on cadence. The elasticity trap, tested one last time. Knowledge check three.
Knowledge check three. A team proposes Exadata Cloud at Customer for an elastic dev and test workload that runs six hours a day and idles nights and weekends, citing OCI economics. Is it sound? A, yes, Cloud at Customer always beats owned hardware. B, probably not, Cloud at Customer suits steady residency bound workloads, and an elastic dev and test job with no residency requirement belongs on public OCI or a license included service that bills only the hours it runs. C, yes, because dev and test never needs licenses. Or D, no, dev and test must always run on owned hardware. Pause here. What binds this workload, and does Cloud at Customer answer it?
The answer is B, and naming the workload's constraints settles it immediately. It's elastic, six hours on and two thirds of the day idle. It has no stated residency requirement. And it's dev and test, the least steady load profile in any estate. Cloud at Customer is optimized for the exact opposite: steady, residency bound production, underwritten by a consumption commit and a hardware term, both of which reward continuous use and penalize idle capacity. Put a workload that sleeps nights and weekends onto a committed on premises construct and you pay for capacity nobody consumes, session twenty six's breakage lesson relocated to your datacenter floor. The fit is public OCI or a license included service metering only the running hours, so nights and weekends cost nothing and the elasticity matches the metric, session twenty nine's closing rule. And notice B's honest hedge, probably not, because constraints decide, not defaults: if this dev and test data turned out to be regulated customer data that cannot leave the building, an unstated residency constraint, the calculus shifts and Cloud at Customer might earn its place after all. The wrong answers are each a dogma. A is the fashion answer, newest construct must be best, which the whole module has dismantled, there is no always on this spectrum. C is dangerously wrong and session twenty three already priced it: non production Oracle needs licensing, dev and test are installed and running, and the estates that assumed otherwise met the finding. D overcorrects into the opposite dogma, dev and test run wherever the constraints point, and for elastic no residency work they point at consumption, not capital. Module six closes on its throughline: every workload has a binding constraint, the construct follows the constraint, and the licenses carry across the whole spectrum on BYOL. The synthesis, next.
One estate, placed across the spectrum, the whole module in six rows. The core banking database, steady: the binding constraint is residency, the data stays on site, so Cloud at Customer, BYOL from the harvested pool, Support Rewards on the consumption. The large steady analytics platform: the binding constraint is cost and capital suits it, so owned Exadata with Capacity on Demand and harvested licenses, the activated cores growing as the platform does. The seasonal reporting workload, spiky: the binding constraint is elasticity, so public OCI, license included, metered by the hour, paying nothing in the off season. Dev and test: the constraint is cost with no residency, so public OCI, capped, switched off nights and weekends, exactly per knowledge check three. The regulated archive with sovereignty requirements: the constraint is sovereignty at scale, so a Dedicated Region, sitting alongside the bank's other regulated estate that justified building one. And the whole estate, the bottom row: five different constructs, chosen by five different binding constraints, supplied by one BYOL license pool flowing across all of them. No single construct won the estate, and none should have. Each workload's binding constraint chose its home, the harvested license pool from session twenty seven supplied BYOL to every one that took it, and the consumption everywhere fed Support Rewards back to the support bill. That is module six, fully assembled: not a cloud strategy or an on premises strategy, but a spectrum, navigated one constraint at a time. Recap, and the module closes.
Session thirty in three sentences, and with it, module six. One, Exadata is the most license dense hardware Oracle sells, and Capacity on Demand plus the core factor are the two levers that make owned engineered systems affordable, you license the activated cores, not the installed ones, on hardware you control. Two, the same machine comes four ways, owned, Cloud at Customer, Exadata Cloud Service, and Dedicated Region, and the construct is chosen by the binding constraint, residency, latency, sovereignty, elasticity, or cost, never by fashion, with BYOL carrying your licenses across all of them. Three, module six is complete: from universal credits through BYOL, Support Rewards, the hyperscalers, and now the hybrid constructs, one spectrum from owned iron to public cloud, harvested licenses portable across every point on it, and consumption everywhere feeding the support bill back down. Next session opens module seven, and the rulebook changes entirely: Oracle SaaS. Fusion applications, NetSuite, and the subscription world, where there are no processor licenses, no core factors, no BYOL, just users and transactions and subscription contracts with their own renewal economics and their own traps. Everything you've mastered about perpetual and consumption licensing meets a third model. Four sessions on the software as a service rulebook, starting with the portfolio and its metrics. Homework first.
Homework, about an hour, and it closes the cloud module's records. One, audit the Exadata: any owned engineered system, compare installed cores against activated cores against licenses held. Is Capacity on Demand configured, or is the estate paying to license dark cores it never lit, or worse, running cores it never licensed? Both happen. Two, inventory the options: on each engineered system, which options and packs are actually enabled, and is every one entitled? Exadata is where options findings live, per session twenty three, so this is a self assessment worth doing before an auditor does it. Three, name the constraints: for your largest workloads, write down what actually binds each one, residency, latency, elasticity, or cost. That one page is the document that chooses constructs, and most estates have never written it. Four, diary the two clocks: any Cloud at Customer deployment has a consumption expiry and a hardware term, both into the session twenty five calendar alongside the renewal seasons and the audit file. And five, map the spectrum: place your estate across the five constructs, owned, Cloud at Customer, cloud service, dedicated region, and public OCI, and ask whether each workload actually sits where its binding constraint would put it. The misplacements are where the money is. That's the hour, and that's module six. See you in session thirty one, in the world of SaaS.
Five reads, all free on redress compliance dot com. First, the Oracle Exadata guide: the engineered system, Capacity on Demand, the options stack, and the storage cells, at reference depth. Second, the CIO playbook on Exadata and engineered systems strategy: the four flavors decided as strategy, the boardroom version of today's decision framework. Third, the Oracle Cloud at Customer guide: the hybrid construct worked commercially and technically, the two clocks and the BYOL harvest included. Fourth, Cloud at Customer versus Dedicated Region: the two on premises cloud constructs compared by constraint, exactly the choice from today's decision slide. And fifth, licensing Cloud at Customer versus OCI: the counting across the spectrum, worked in full, the companion to session twenty seven's BYOL arithmetic. That's session thirty, and that's module six. The spectrum is complete: owned iron with Capacity on Demand and the core factor, Cloud at Customer and dedicated regions for the constrained, the hyperscalers for reach, public OCI for elasticity, and one portable license pool flowing across all of it on BYOL, with Support Rewards paying part of the bill wherever consumption runs. Thirty sessions down, ten to go. Module seven changes the rulebook to subscriptions: Fusion, NetSuite, users, and transactions. See you there.