OCI hardware inside the hyperscalers, bought through their marketplaces: the multicloud constructs, and when they beat both worlds. 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 fourteen of thirty, and today the map gets genuinely strange, in the best way. Everything so far in module three assumed a clean division: Oracle's cloud over here, the hyperscalers over there, your licenses converting differently depending on which side of the line a workload lands. Today the line moves. Oracle Database at AWS, at Azure, at Google Cloud: Oracle's own engineered hardware, physically installed inside the hyperscalers' datacenters, running Oracle's database services, purchased through the hyperscalers' marketplaces. It's the newest construct in this course, it changes answers this module already gave you, and it introduces the most interesting piece of commercial plumbing in the whole Oracle relationship: a purchase that touches three contracts at once. By the end you'll know exactly when this middle path wins and how to route the dollars when it does. Let's go somewhere strange.
Five takeaways. One, the construct: what these services physically and commercially are, because the marketing name undersells how unusual the arrangement is. Two, the purchase: three routes to the same service, marketplace private offers, Multicloud Universal Credits, and classic OCI orders, and why the routing decision is worth real money. Three, the licensing: OCI's machinery follows the service into Amazon's building, BYOL ratios, license included, the works, which creates two counting worlds inside one cloud region. Four, the comparison: Database at against RDS, EC2, and OCI proper, honestly, because this construct has one specific estate shape where it wins and it should not be chosen outside it. And five, the triangle: the commitment interaction, your AWS or Azure obligation, your Oracle credits, and your support bill, all touched by one purchase, and almost nobody prices the interaction.
What these services actually are, in three facts. Fact one, the hardware is Oracle's: Exadata and Autonomous Database infrastructure, built, owned, and operated by Oracle, physically racked inside AWS, Azure, and Google Cloud datacenters. Not adjacent, not interconnected, inside. Which means your application tier in AWS talks to the database across the room: single digit millisecond latency, and, materially, no cross cloud egress toll on that traffic, because it never leaves the building. Fact two, the service is OCI: Autonomous Database, Exadata Database Service, the same services module two taught you, with OCI's units, ECPUs, OCI's rate logic, and OCI's licensing constructs, BYOL and license included, intact. It's not a hyperscaler service with an Oracle logo, it's an OCI region cell that happens to share an address with Amazon. And fact three, the relationship is triangular: you, Oracle, and the hyperscaler, with the purchase typically routed through the hyperscaler's marketplace. Three contracts touch one workload. Now the strategic read, because it explains everything else today: Oracle looked at the world, conceded that the application estates live on AWS and Azure and aren't coming back, and moved the database to where the apps are, on Oracle's terms, on Oracle's hardware. Amazon keeps the apps, Oracle keeps the database, both vendors win. Whether you win depends entirely on how you buy it, which is the next slide.
How they're bought, three routes to one service, and the routing is where the money is. Route one, the marketplace private offer: a negotiated Oracle deal, real negotiation, session five's whole playbook applies, transacted through the AWS, Azure, or GCP marketplace. The consequence that matters: marketplace purchases typically count toward your hyperscaler spend commitment, the AWS EDP, the Azure MACC, at or near full value depending on your agreement's terms. Route two, Multicloud Universal Credits, MUC, the construct from the further reading lists finally taking center stage: one Oracle credit pool spendable on OCI proper and on the Database at services, wherever they physically run. One commitment, every Oracle venue. Route three, the classic path: a standard Universal Credits order with Database at consumption drawn from it, like any other OCI service. Same service all three ways; what differs is which obligation your dollars retire. And that's the choice that matters, bottom row of the table: which commitment is hungriest this year? An underconsumed EDP staring at a shortfall? Route through the marketplace and feed it. An Oracle commitment at risk of forfeit, session seven style? Route through the credits. The same database dollars, pointed at whichever obligation would otherwise hurt you. One sentence to carry out of this session: money you owed Amazon anyway can buy Oracle database services. That sentence, priced correctly, funds the hour.
First check, that sentence with numbers. An estate owes four million dollars of unspent AWS EDP commitment this year, and plans one and a half million of Oracle Database at AWS consumption. Routing the purchase through the AWS Marketplace means: A, nothing changes, marketplace purchases sit outside commitments. B, the one and a half million of Oracle database spend counts toward retiring the four million AWS obligation, per the EDP's marketplace terms, while the service itself runs under Oracle's constructs. C, the purchase double counts against both the AWS and Oracle commitments automatically. Or D, AWS becomes the licensor of the Oracle database. Pause here. Whose obligation does a marketplace dollar retire?
The answer is B. Marketplace private offers count toward hyperscaler spend commitments, that's a core feature of the EDP and MACC constructs, typically at or near full value, and your specific agreement's marketplace clause states the exact treatment, which the homework has you read. So this estate retires a million and a half of an AWS obligation it owed no matter what, using database spend it also needed to make, one dollar doing two jobs. That's not a loophole, it's the design, all three vendors built this plumbing deliberately, and the only question is whether the buyer notices. Now the eliminations. A was true of nothing: the entire point of marketplace procurement, from the hyperscaler's side, is pulling third party spend inside the commitment tent. C's automatic double counting doesn't happen, the routing decision picks a lane, which is exactly why the decision needs an owner who can see every commitment at once, session ten's estate level view paying off again. And D, one more time with feeling, session twelve's boundary: the marketplace transacts, Oracle licenses. The invoice path never changes who governs the software. The triangle has three corners, but the Oracle corner always holds the license.
The licensing machinery, and the headline is continuity: OCI's rules follow the service into the hyperscaler's building. BYOL applies: session eight's ratios and rules travel intact, your EE licenses convert at the same rates as on OCI proper, support stays active, and the allocation goes in the ledger. License included applies: the same per instance toggle, renting the license where the shelf is empty, and session eight's three column model prices the choice without modification. The counting is OCI's: ECPUs, Autonomous sizing, Oracle's units, not the authorized cloud policy. And here's the sentence that earns its own knowledge check: session eleven's vCPU rule governs Oracle software you run on the hyperscaler's own compute, while Database at runs on Oracle's units, which means one AWS region can contain two different Oracle counting worlds simultaneously. The rewards question, handled carefully because the program terms evolve: Support Rewards keys to Universal Credits consumption, and Database at spend routed through Oracle's credit constructs participates per the program's current terms. Before you bank the offset in a business case, verify in writing how your specific purchase route treats accrual, marketplace routed spend and credit routed spend can differ, and session nine's napkin is only as good as its accrual assumption. And finally the ledger grows a column: every BYOL allocation now names its counting world, vCPU policy or OCI ratios, because a license allocation valid under one rulebook is a different number under the other.
Check two, the two worlds in one region. A single AWS region runs: an EC2 instance with self managed Oracle EE, and a Database at AWS Autonomous instance on BYOL. Which counting applies to each? A, the vCPU policy for both, they're both in AWS. B, the EC2 instance counts under the authorized cloud policy, two vCPUs per license, while Database at AWS counts under OCI's constructs, ECPUs and the BYOL ratios, because the service is OCI regardless of the building. C, ECPUs for both, Oracle software always counts in ECPUs now. Or D, neither needs counting, BYOL exempts both. Pause here. What decides the rulebook: the building, or the service?
The answer is B, and the principle is the session's most exportable idea: the service picks the rulebook, not the building. Self managed Oracle on Amazon's compute is exactly what the authorized cloud policy was written for, two vCPUs per license, session eleven, sticky note. Database at AWS is an OCI service with an unusual postal address: OCI units, ECPU sizing, session eight's BYOL ratios. Same region, two rulebooks, and both are correct simultaneously. Which makes the ledger's new column mandatory rather than fussy: twenty EE licenses allocated to EC2 cover forty vCPUs under the policy, while the same twenty allocated to Database at cover a very different capacity under OCI ratios, and an auditor will absolutely check that each allocation is counted under its actual construct. C's universal ECPU world doesn't exist, ECPUs are Oracle service units, not a general counting reform. And D earns the strongest correction: BYOL is never an exemption from counting, it's a conversion of counted licenses into counted capacity, and the count is precisely how you know what the conversion consumed. The two worlds coexist. The ledger keeps them apart. That's the discipline.
Now the honest comparison, the full database menu for an AWS centric estate. RDS license included: unbeatable simplicity, zero Oracle relationship, and two hard edges, SE2 only, and years of rent building no asset. RDS or EC2 BYOL: uses the shelf, stays native, and pays the vCPU counting rate, half the capacity per license that OCI grants, plus RDS's feature ceilings or EC2's operational burden. Database at AWS: the full Oracle stack, Exadata, Autonomous, RAC, physically beside the apps with no egress toll, OCI ratios on your shelf, marketplace burn down on the purchase, and its own catches, a triangle of contracts to govern, a deepening Oracle relationship exactly when some estates are trying to shallow it, and premium engineered systems pricing. OCI proper: the best license capacity and rates, Support Rewards uncontested, and physics against it, the apps aren't there, and chatty traffic pays the cross cloud toll forever. The note under the table is the placement rule: Database at exists for one estate shape, apps committed to a hyperscaler, database workloads that genuinely want Oracle's engineered stack. For that shape it's often the honest winner. Outside that shape it's an expensive way to avoid a decision. Let's hear the advisor on the triangle, because the buying is where this construct is won or lost.
Guest analyst The first Database at Azure deal I advised on, the client almost left half the value on the table, and the half they almost missed was not the technology. Their situation: apps on Azure, an Exadata estate on premises approaching a hardware refresh, a two hundred million dollar Azure MACC running behind schedule, and an Oracle support bill they resented. The infrastructure case for Database at Azure wrote itself. But the first draft of the deal bought it as a direct Oracle order, classic credits, because that is how the team had always bought Oracle. Three redirections changed the economics. First, we routed the purchase through the Azure Marketplace, and eleven million a year of Oracle database spend started retiring a MACC shortfall that was otherwise heading to a true up conversation with Microsoft. Second, we ran the BYOL conversion on their Exadata entitlements at OCI ratios instead of buying license included, which the shelf covered almost entirely. And third, we timed the whole signature to Oracle's Q4 inside the same week as the Azure renewal conversation, and let each vendor know the other was at the table. The triangle is not a complication, it is leverage: three parties want this deal, and the buyer is the only one who can see all three ledgers. Price every corner. The corners are where the money is.
Three redirections: route through the marketplace, convert the shelf at OCI ratios, and time the signature so both vendors feel the other at the table. The triangle is leverage, and the buyer is the only party who sees all three ledgers. That's the sentence to keep.
So when does the middle path win? Five conditions, and I want you to treat them as a checklist, not a mood. Condition one, the apps are staying: the application estate is committed to AWS or Azure for reasons that are settled, skills, data gravity, the surrounding stack, and the database question is being answered inside that constraint, not alongside it. If the apps could move, the comparison is different and OCI proper re enters. Condition two, the workload wants the Oracle stack: Exadata performance, Autonomous, RAC, capabilities RDS and EC2 genuinely cannot offer. Be honest here, because if SE2 on RDS would do the job, you're in the wrong aisle reading premium price tags. Condition three, latency matters: real, measured, chatty app to database traffic that can't survive a cross cloud round trip. Colocation is the construct's entire physical reason to exist; workloads that batch or tolerate latency don't need the room sharing. Condition four, a commitment is hungry: an underconsumed EDP or MACC that marketplace routed spend can feed, the triangle's arbitrage pointed at your own obligations. And condition five, the shelf is real: BYOL entitlements that convert at OCI ratios, making the service economics work. An empty shelf pays the full premium, and the comparison tightens considerably. Count your conditions honestly. Five out of five, the middle path likely wins. Two out of five, you're buying someone else's use case.
Last check, the checklist applied. An estate's apps are locked to Azure. Its Oracle EE databases need RAC. Its Azure MACC is underconsumed. It holds a full shelf of supported EE licenses. The database platform call: A, Azure VMs with self managed Oracle, keep it native. B, Database at Azure on BYOL, purchased through the Azure Marketplace: RAC on Oracle's stack beside the apps, OCI ratios on the shelf, and the MACC fed by the spend. C, OCI proper, best ratios win regardless of where the apps are. Or D, RDS on AWS, add a third cloud for the database. Pause here. Walk the five conditions: how many does this estate hit?
The answer is B, and this estate is the checklist scoring five for five: apps immovably on Azure, check. RAC required, which rules out RDS entirely and makes self managed VM architectures a fragile science project, check. Latency implied by the app coupling, check. An underconsumed MACC that the marketplace purchase feeds directly, check. And a real shelf converting at OCI ratios, check. When all five align, the middle path isn't a compromise, it's simply the answer. The alternatives each fail on their own terms: A, Azure VMs, surrenders RAC pragmatically and counts the shelf under the vCPU policy at half its OCI purchasing power, paying more license for less database. C, OCI proper, wins every ratio and loses to physics, the chatty app tier pays the cross cloud toll every millisecond, forever, and the MACC shortfall stays hungry. And D, adding a third cloud to sidestep a two cloud decision, multiplies every ledger, commitment, and counting problem this module has taught, in exchange for nothing. One more time, because it's the module's recurring chorus: choose platforms on purpose, with the conditions counted, never by default or by aisle habit. Next session makes that chorus into a spreadsheet.
The multicloud discipline, five habits for living in the triangle. One, route dollars deliberately: before any Database at purchase, list every commitment it could feed, the EDP, the MACC, the Oracle credits, with balances and end dates, and route the spend where the obligation is hungriest. The routing alone is worth points on the deal. Two, verify the rewards treatment per route, in writing: how does this purchase path accrue Support Rewards, if at all? The program's terms evolve, marketplace routed and credit routed spend can differ, and session nine's napkin math inherits whatever assumption you make here, so make it verified rather than hopeful. Three, mark the construct in the ledger: every BYOL allocation names its counting world, vCPU policy or OCI ratios, because one region now legitimately contains both and an unlabeled allocation is a future finding. Four, negotiate the triangle once: Database at purchases touch the Oracle relationship and the hyperscaler relationship simultaneously, so time them to whichever renewal needs the leverage, and per the advisor, let each vendor know the other is at the table. Session five's calendar, now with three parties on it. And five, re run the comparison annually: these constructs are young, their terms and coverage move quarterly, and the option that lost last year's evaluation may win this year's. The annual portfolio review from session ten now includes the middle path as a standing line.
Session fourteen, three sentences. One: Database at AWS, Azure, and Google Cloud is OCI inside the hyperscaler's building, Oracle's hardware, Oracle's services, Oracle's licensing constructs, sitting beside your applications with no cross cloud toll, because Oracle moved the database to where the apps went. Two: the purchase is a triangle, marketplace routes retire hyperscaler commitments with Oracle spend, the service counts in OCI units while EC2 next door counts in vCPUs, and the ledger must name which world every license serves. Three: the middle path wins when five conditions align, apps locked, Oracle stack needed, latency real, a commitment hungry, a shelf ready, and for exactly that estate shape it beats both native AWS and OCI proper, on purpose. Next session closes module three with the capstone this whole module has been building toward: one workload, four platforms, every counting rule, every ratio, every reward, in one total cost comparison you can rerun on your own estate forever. Bring a calculator. See you there.
Homework, about an hour, and it maps your own triangle. One, list the commitments: every spend obligation in force, AWS EDP, Azure MACC, Google CUD, Oracle credits, with remaining balance and end date, in one table. Most estates have never seen them side by side, and the table alone changes the next routing decision. Two, read the marketplace terms: how your EDP or MACC treats marketplace private offers, the percentage that counts toward the commitment, from the actual paper. That number prices every routing decision this session described. Three, find the candidates: database workloads on hyperscalers that want Oracle stack capabilities they can't currently have, RAC they gave up, Exadata performance they miss, Autonomous features they read about. That list is your Database at shortlist, and for most estates it's short but not empty. Four, price one candidate three ways: current state, Database at with BYOL through the marketplace, and OCI proper, carrying the license capacity, the service rates, and the commitment burn down in each column. And five, update the ledger: if any multicloud allocation already exists, add the counting world column today. Two rulebooks in one region, one ledger keeping them honest. Next session, that three way pricing becomes a full methodology.
Five reads before next session, all free on redress compliance dot com. First, Oracle Multicloud Universal Credits, the credit pool spanning OCI and the Database at services, today's route two in full. Second, MUC versus Universal Credits, choosing the pool shape when your estate spans clouds, the commitment structure question this session raised. Third, Oracle database licensing in cloud environments, both counting worlds side by side in reference form. Fourth, OCI versus AWS for Oracle workloads, the two ends of the spectrum today's middle path sits between, and next session's raw material. And fifth, the Oracle BYOL comprehensive guide, the ratios that followed the service into the hyperscaler's building. That's session fourteen: the line moved, the triangle has three corners, and the buyer is the only one who sees all three ledgers. Next time, the capstone: four platforms, one spreadsheet, no defaults. See you there.