Pay As You Go versus Universal Credits, OCPU versus ECPU, and the services that actually dominate real bills. 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 six of thirty, and welcome to module two. Module one gave you the paper: the master, the orders, the policies, and the money. This module gives you the machine the paper wraps: OCI itself, the meter, the credits, BYOL, Support Rewards, and the governance that keeps all of it honest. Today is the foundation session: how you actually pay for OCI, the three commercial wrappers around one identical meter, the unit change that quietly happened under everyone's estates, OCPUs to ECPUs, and the anatomy of a real bill, because I promise you, the services that dominate real OCI bills are not the ones anyone was watching in the sizing meeting. If you did session five's homework you know your net rate. Today you learn what the meter does with it. Let's go.
Five takeaways. One, the models: Pay As You Go, Annual Universal Credits, and the funded variants, how each one meters, bills, and, most usefully, how each one fails, because every model has a signature failure and you want to recognize yours early. Two, the units: OCPU versus ECPU, what actually changed, the conversion between them, and why a unit migration is a commercial event, not a technical footnote. Three, the bill: where the money actually goes in a real OCI estate, family by family. Four, the meters that surprise: five charges that ambush almost every first year estate, egress, storage performance, license toggles, cross region traffic, and idle shapes, the checklist that explains most mystery bill jumps. And five, the decision: a clean rule for choosing your model based on estate maturity, and when switching models is the right move rather than a distraction.
The three ways to pay, and hold this frame: every OCI service meters identically underneath, per hour, per gigabyte, per unit consumed. What differs between the models is only the price per unit and what you promised to spend. Model one, Pay As You Go: no commitment, rate card prices, billed monthly on whatever you consumed. PAYG is your control group, and I mean that formally: every commitment you ever sign must beat PAYG multiplied by realistic consumption, or the commitment should not exist. It's also simply the right answer for experiments and genuinely unpredictable estates, and we'll defend that in the last check. Model two, Annual Universal Credits, the one you know from sessions one and three: prepay a yearly amount, earn a discount tier for it, draw it down by consuming, forfeit what's left at period end, pay overage past it. Right for measured, steady estates, and the forfeit math is the standing caveat that never goes away. Model three, the funded variants: migration funding, promotional credit pools, the rescue restructure when a migration stalled. Real money, genuinely worth taking, and always wearing strings: consumption deadlines, workload conditions, and the same meter running underneath. One more property that genuinely helps: the credit pool is fungible. Compute, storage, database, AI services, one pool covers all of it. But fungibility doesn't repeal the forfeit: only spend that actually happens earns its discount.
Now the units, because Oracle changed the measuring stick under everyone's estates and plenty of teams haven't noticed yet. The OCPU, the legacy unit: one physical core with hyperthreading enabled, presenting as two vCPUs. Solid, hardware anchored, and it's how older database services and legacy baselines are quoted. The ECPU, the current unit: an abstracted compute measure with no fixed core mapping, which is what Autonomous Database and the newer database services meter in today. The conversion, per Oracle's own guidance: one OCPU corresponds to roughly four ECPUs. Notice what that ratio does to every naive comparison: an ECPU price that looks like a quarter of an OCPU price is the same price, and a sizing sheet that moved from OCPUs to ECPUs without normalizing is speaking a different language than last year's budget. Why this is commercial and not just technical: your BYOL ratios and your old baselines are quoted in OCPUs, your new quotes and rate cards arrive in ECPUs, and the boundary between them is exactly where confusion, and occasionally a quietly worse deal, slips through. The rule, and it's the whole slide: any comparison across the unit boundary gets normalized first, to dollars per unit of actual capacity. Otherwise the comparison is theater, and theater in a budget meeting costs money.
First check, straight into that trap. A sizing sheet prices Autonomous Database at eight ECPUs, against last year's baseline of four OCPUs, and a stakeholder objects: capacity doubled, eight is twice four. Using Oracle's guidance, the accurate read is: A, the objection is correct, the estate doubled. B, eight ECPUs is roughly half the capacity of four OCPUs under the four to one guidance, so the sheet describes a smaller footprint, not a larger one. C, the units are identical, both measure vCPUs. Or D, nothing can be said without benchmarks. Pause here, and normalize before comparing: four OCPUs is how many ECPUs?
The answer is B. Four OCPUs, at roughly four ECPUs each, is about sixteen ECPUs of capacity. The new sizing of eight ECPUs is therefore around half the old baseline, which is the exact opposite of the stakeholder's objection, and this misreading happens in real budget meetings in precisely this form, someone comparing raw numbers across a unit boundary with total confidence. Now, D deserves a fair hearing: benchmarking your own workload is genuinely wise before finalizing a sizing, abstraction ratios are guidance, not physics. But commercially, the four to one guidance is where every comparison starts, and the discipline stands regardless: normalize to capacity, then to dollars per unit of capacity, then compare. And C, for the record, is how the confusion was born: OCPUs relate to vCPUs, ECPUs deliberately don't, that's what abstracted means. If your estate still carries OCPU baselines anywhere, this week's homework converts them once, properly, so nobody has this meeting again.
The anatomy of a real bill, because real estates converge on the same shape, and it's rarely the shape the sizing meeting drew. Family one, database services: Autonomous, Base Database, Exadata service. In an Oracle centric estate this is typically the largest family on the invoice, and it's also where the rate is most sensitive to a single setting, BYOL versus license included, which changes the same service's price dramatically. Session eight is entirely about that lever. Family two, compute and block storage: the workhorse VMs and their disks. Two watch items here: shape sizes that were generous on day one and never revisited, and block volume performance tiers, because volumes bill for capacity and performance separately, and the balanced default is not the cheap one. Family three, the long tail: object storage, load balancers, networking, logging, the AI services someone tried in March. Individually small, collectively fifteen to thirty percent of real bills, and it's exactly where unmonitored growth hides, because nobody owns the tail. Which is why the one non negotiable habit is tagging from day one, owner, project, environment, on everything, enforced by policy. And the good news that makes all of this manageable: the bill is queryable. Cost analysis by compartment and by tag sits in the console. The estates that get surprised aren't the ones with complicated bills. They're the ones that never look. Here's our advisor on what that looks like when it goes wrong.
Guest analyst A client called me in because their OCI bill had grown forty percent in a year while their workload count, they insisted, had not changed. They wanted help preparing a billing dispute. We did not file a dispute. We read the bill, properly, for the first time in the account's life. Here is what forty percent turned out to be. About a third of it was block volume performance units on the default tier, across hundreds of volumes cloned from one template that nobody had ever tuned. Another third was a license included toggle on a database template, so every clone of that template had been paying the with license rate when the client owned BYOL entitlements the whole time, that one setting was worth six figures. And the rest was a development compartment where stopped instances had been accumulating orphaned volumes for eighteen months, plus an analytics export that shipped data across regions nightly. Not one dollar of it was a billing error. Every dollar was the meter doing exactly what the configuration told it to do. The fix took two weeks, the bill dropped by a third, and the uncomfortable lesson was that it had all been visible in cost analysis the entire time. Nobody had looked. My rule since: the first billing dispute you file should be with your own configuration.
Not one dollar was an error, and every dollar was visible the whole time. Keep that story next to the five meters we're about to walk, because his forty percent was made of exactly these.
Check two. An OCI bill jumped eighteen percent with no new workloads deployed. From experience, the three most likely culprits are: A, Oracle raised the rate card mid commitment. B, egress traffic growth, block volume performance tier defaults, and a license included toggle left on where BYOL was intended. C, currency fluctuation on the credit pool. Or D, a billing system error, OCI bills are frequently wrong. Pause here. What grows without a deployment?
The answer is B, and the principle behind it is worth keeping: consumption grows without deployments. Egress scales with how the business uses what's already deployed, a new report, a new integration, a chattier client. Block volume performance units follow defaults that nobody chose deliberately and nobody revisits. And the license toggle, the single most common finding in first year OCI cost reviews, silently doubles a database service's rate when it's set to license included while your BYOL entitlements sit unused. All three were in the advisor's forty percent. Now the eliminations, because they teach the contract. A, a mid term rate rise: your committed rates are locked for the commitment period, that's part of what the commitment buys, so the rate card isn't the story. C, currency: fixed by the credit contract's terms. And D, the billing error hypothesis: disputes exist, but wrong bill is the hypothesis you test last, after the three meters you can check in an hour, because his rule holds, the first dispute you file should be with your own configuration. Eighteen percent has a boring explanation far more often than an outrageous one.
The five meters that surprise, your mystery bill checklist. One, data egress: traffic leaving OCI bills per gigabyte past the free allowance. Oracle's egress pricing is genuinely generous compared to the other clouds, module three will show you just how generous, but generous times a nightly analytics feed is still a line item that needs an owner. Two, block volume performance: capacity and performance bill separately, the balanced default is rarely right for everything, and auto tune exists precisely for this, most estates simply never enable it. Three, the license toggle, one more time because it's the expensive one: BYOL or license included, per database service instance, and a wrong default on a template propagates the double rate across every clone forever. Four, cross region and cross availability domain traffic: replication, DR, and chatty architectures pay networking meters that no sizing sheet ever included. Ask your architect one question, what crosses regions, then price the answer. And five, the idle shape: stopping an instance stops its compute billing, but its boot volume and block volumes bill on, and orphaned volumes from deleted instances bill on indefinitely. The forgotten dev estate is the classic quiet leak. None of these five is exotic. All five are in the console. The difference between estates is only whether somebody checks.
So which wrapper do you choose? Match the model to the estate's maturity, five situations. Experimenting, first workloads: Pay As You Go, full stop. The premium is tuition, and there's no forfeit risk while consumption is unknowable. Six plus months of measured, steady usage: Annual Universal Credits, sized at the measured baseline, ramped for defensible growth. The discount beats PAYG once the baseline is real, and not one day before. Large migration with funding on offer: credits plus negotiated program money, take the funding, and size the commitment to the migration you will actually execute, not the one on the steering committee slide. Spiky or seasonal workloads: a smaller credit base committed to the floor, with peaks billing as overage, at overage rates you negotiated in advance, session seven's topic. And the fifth situation, the uncomfortable one: consumption collapsed or plans changed mid term. The honest answer is that mid term relief needs a clause you probably don't have, so the model gets resized at renewal, and the job until then is minimizing the damage and documenting the case. The whole table compresses into one line, and it's the module's motto: PAYG until you can measure, commit to what you measured, structure for what you hope.
Last check. A team wants to sign a nine hundred thousand dollar annual credit commitment for a brand new estate, zero measured consumption, because PAYG rates look thirty percent worse. The disciplined call: A, sign, a thirty percent saving is a thirty percent saving. B, run PAYG for one to two quarters to build a measured baseline, then commit at measured size with a ramp, because the PAYG premium on a small early estate is far cheaper than a forfeit on a guessed commitment. C, never commit to anything, PAYG forever. Or D, sign, but deliberately keep consumption low to stay safe. Pause here. What does that thirty percent saving actually apply to, if consumption is unknown?
The answer is B, and the reasoning is the module motto with numbers on. A thirty percent discount applies to consumption; if consumption is a guess, the discount applies to a guess, and the forfeit applies to reality. Run the scenario: the new estate consumes three hundred thousand in year one against a nine hundred thousand commitment, and the team has donated six hundred thousand to save ninety. Meanwhile, a quarter or two of PAYG on a small early estate costs a premium on a small number, low tens of thousands, and buys the one thing money can't shortcut: a measured baseline. That's the cheapest market research in cloud. C overcorrects into a different error, perpetual PAYG overpays permanently once usage is steady, commitment discounts exist for good reason and disciplined estates capture them. And D is my favorite wrong answer in the whole course so far: throttling the business to protect a contract, deliberately consuming less value to avoid admitting the commitment was oversized. If you ever hear D proposed in a meeting, and you will, you'll know exactly what happened eighteen months earlier. Measure, commit, structure. In that order, always.
The consumption discipline, five habits, and none of them is clever, they're just owned and repeated, which by now you'll recognize as this course's entire theory of management. One, tag at birth: owner, project, environment on every resource at creation, enforced by policy so it can't be skipped. Untagged spend is unexplainable spend, and unexplainable spend is unmanageable spend. Two, review monthly: one named owner, one hour, cost analysis by compartment and tag. Committed versus consumed, the burn trajectory, and the five surprise meters walked. The advisor's client skipped this meeting for eighteen months; that was the whole story. Three, budget with alerts: console budgets with thresholds at eighty and a hundred percent of the monthly run rate, routed to a human who acts, not a distribution list that archives. Four, audit the toggles quarterly: every database service checked BYOL versus license included against intent, every stopped instance checked for orphaned volumes. An hour a quarter, six figures a year in some estates. And five, the number that actually matters: distance to commit. Not spend, the gap between your trajectory and your commitment, in both directions, forfeit ahead or overage ahead. That single number is the input to every conversation in session seven, where we turn sizing into contract language.
Session six, three sentences. One: three wrappers, one meter. PAYG is the control group every commitment must beat, Universal Credits is the discount with a forfeit attached, funded deals are real money with strings, and the meter runs identically under all three. Two: normalize units before comparing anything, an OCPU is roughly four ECPUs, and every comparison across that boundary converts to dollars per unit of capacity or it's theater. Three: real bills are dominated by database, compute, and storage, ambushed by egress, performance tiers, and license toggles, and kept honest by tags, a monthly hour, and one number, the distance to commit. Next session takes that number into the negotiating room: sizing and negotiating the OCI commitment itself. Ramps that track the real migration, carryover language that survives a slipped quarter, overage at your discount instead of list, and the true up as a full negotiation rather than a rubber stamp. Bring the distance number from this week's homework. It's the opening line of that conversation. See you there.
Homework, about an hour, and this one pays for itself more reliably than any other in the course so far. One, pull the bill: last month's cost analysis, by service family, rank the top five lines, and hold them against today's anatomy. Anything in your top five that surprised you is your first finding. Two, check the toggles: every database service instance, BYOL or license included, against what was intended. Fixing a wrong one is a setting, not a project, and it might be the fastest six figures this course ever saves you. Three, hunt orphans: stopped instances and unattached block volumes, delete or justify each one, and write down what the leak was costing, because that number funds the discipline going forward. Four, normalize your units: if any baseline anywhere still speaks OCPUs, convert it to ECPUs at the guidance ratio, once, so every future comparison is like for like. And five, compute the distance: trailing three month consumption trajectory against the annual commitment. Forfeit ahead, overage ahead, or on track. One number, written down. Session seven opens with it.
Five reads before next session, all free on redress compliance dot com. First, the OCI licensing and BYOL cost guide, the full commercial model behind today's meters, units, and credits, the module two companion text. Second, Multicloud Universal Credits, the newest wrapper, one pool spendable across OCI and the Database at services, which changes the fungibility story again. Third, MUC versus Universal Credits, when the multicloud pool beats the classic annual commitment, worth reading before you renew either. Fourth, the Oracle BYOL comprehensive guide, today's most expensive toggle in full detail, and the required warm up for session eight. And fifth, OCI versus AWS for Oracle workloads, the consumption comparison across clouds, previewing module three. That's session six. You can read the meter, you know the units, and you know where the money actually goes. Next time, we take your distance to commit number into the negotiation. See you there.