One workload, four platforms, every number this module taught: the TCO method you can rerun forever. 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 fifteen of thirty, the halfway mark of the course, and the module three capstone. Everything this module taught was building to one question, the question every Oracle estate faces at least once a year: where should this workload run? You now hold every number that answers it, the counting gradient, the BYOL ratios, the rewards napkin, the egress meters, the paths and the triangle. Today we assemble them into a method: five rows that make any platform comparison honest, worked end to end on a reference workload, plus the judgment factors that belong beside the spreadsheet and the estate profiles that tell you where your answer probably lands before you start. This is the session to bookmark, because the method reruns forever. Let's build it.
Five takeaways. One, the method: five rows, license capacity, service rate, support offset, data movement, and operations, and the claim that any comparison missing a row is biased, never randomly. Two, the worked case: a real shaped workload priced across OCI proper, AWS BYOL, Database at AWS, and the license included path, using only numbers this course already taught you. Three, the flip rows: which rows actually decide real comparisons, and why the headline service rate, the row everyone stares at, is almost never one of them. Four, the judgment: data gravity, skills, concentration, leverage, and reversibility, the factors that belong beside the model, in prose, never buried inside it as fudge factors. And five, the profiles: five common estate shapes and where each usually lands, so your comparison starts from an informed prior instead of a blank spreadsheet.
The five row method. Row one, license capacity: what your shelf covers on each platform, and after sessions eight and eleven you know this is a gradient, not a constant, the same license buys twice the capacity on OCI that it buys under the vCPU policy. Row two, the service rate: the metered cost of the actual service, BYOL or license included, at honest sizes, honest meaning right sized, not lifted datacenter habits. Row three, the support offset: Support Rewards where the platform earns them, zero where it doesn't, and against a seven figure support bill this row moves comparisons by itself. Row four, data movement: the egress and cross cloud tolls the architecture will actually pay, which punishes split designs and rewards colocation, whoever provides it. And row five, operations: the managed service premium versus the headcount it replaces, the RDS versus EC2 lesson generalized. Now the observation that makes this method more than a checklist: rows one and three are Oracle exclusive advantages, they simply don't exist on native hyperscaler paths. Row four punishes anyone who splits the stack across clouds. Rows two and five are where the hyperscalers genuinely compete. So when you see a comparison, and you will, that only shows rows two and five, or only rows one and three, you're not looking at an analysis, you're looking at an argument. Omissions are never random. Five rows, or no verdict.
The reference workload, deliberately ordinary, because the method is the product and your numbers will differ. The workload: an Enterprise Edition database estate needing thirty two vCPUs of capacity equivalent, running Partitioning, with a synchronized DR copy, so double the footprint, per every lesson about standbys this course has hammered. Crucially: the application tier already runs on AWS and is not moving, it's pinned, which you'll recognize from session fourteen as the condition that makes this interesting. The shelf: sixteen EE processor licenses plus matching Partitioning options, actively supported at three hundred fifty thousand a year, currently covering the on premises estate this migration retires. The context: an AWS EDP with headroom to absorb marketplace spend, a total Oracle support bill across the wider estate of one point two million, and no OCI footprint today. Four candidate homes: OCI proper, AWS BYOL on RDS or EC2, Database at AWS, and RDS license included, and the last one disqualifies itself immediately, session twelve's gate one, EE plus Partitioning doesn't rent. Three real columns. Row one first, and it's a knowledge check, because the capacity arithmetic is the foundation everything else stands on.
First check, row one. The sixteen EE licenses, and a total requirement of sixty four vCPUs, production plus the synchronized DR copy. What does the shelf cover on each platform? A, both platforms fully, sixteen licenses is sixteen licenses. B, on AWS BYOL: thirty two vCPUs, half the requirement, so sixteen more licenses must be found or bought. On OCI or Database at: thirty two OCPUs, roughly sixty four vCPUs, the full requirement including DR, on the same shelf. C, AWS fully, OCI half, hyperscalers count more generously. Or D, neither, DR copies can't be licensed with BYOL. Pause here. Two vCPUs per license there. Two OCPUs, about four vCPUs, per license here. Sixty four needed.
The answer is B, and it's the gradient from session eleven doing exactly what it was designed to do. On AWS, the authorized cloud policy: sixteen licenses, two vCPUs each, thirty two vCPUs, precisely half of what production plus DR requires. The AWS BYOL column therefore opens with a purchase: sixteen more EE licenses, plus their Partitioning, at street prices, plus twenty two percent support on all of it, forever. Six figures of annual cost before the first instance boots. On OCI or Database at: the same sixteen licenses convert at two OCPUs each, thirty two OCPUs, roughly sixty four vCPUs of capacity, the entire footprint, DR included, covered by the shelf as it stands. D's DR confusion needs retiring: DR licenses fine under BYOL on every platform, it simply counts in full, the synchronized standby lesson from sessions twelve and the Mastery course, platform independent physics. So row one alone opens a six figure annual gap between the columns, before anyone has compared a single hourly rate. That's why it's row one, and why comparisons that skip it, and they always skip it in a particular direction, aren't analyses.
The full table, row by row, three live columns. Row one, license capacity, just done: OCI and Database at, shelf covers everything; AWS BYOL, buy sixteen licenses plus options. Row two, service rate: OCI proper takes it on pure rates, BYOL prices on standard infrastructure. Database at pays the engineered systems premium, Exadata quality at Exadata prices. AWS instances carry no license premium but the row varies with RDS versus EC2 choices. Row three, the support offset, session nine's napkin: OCI consumption earns twenty five cents per dollar against that one point two million bill, a six figure annual offset at this workload's spend. Native AWS spend earns nothing, zero, this row simply doesn't exist for Amazon. Database at, per session fourteen: Oracle routed spend participates per the program terms, verify your route, but generally the offset substantially survives. Row four, data movement, and physics votes: the app tier is pinned to AWS, so OCI proper pays the cross cloud toll on every chatty round trip, forever, both in dollars and milliseconds. AWS native and Database at pay nothing, same cloud, same building. Plus Database at's purchase burns EDP through the marketplace, a row four bonus. Row five, operations: all three offer managed options, EC2 self managed being the outlier that costs headcount. Now the shape of the verdict: OCI wins rows one through three and loses row four to physics it cannot beat. AWS BYOL wins row four and bleeds in rows one and three. Database at takes row one, row four, and most of row three, and pays its premium in row two. For this specific workload, app pinned, real shelf, big support bill, hungry EDP, the middle path usually prices best, exactly as session fourteen's five conditions predicted. Let's hear the row that flips real comparisons.
Guest analyst I have built this five row comparison for maybe thirty clients now, and I keep a private tally of which row actually decided each one. The winner surprises people: it is almost never row two, the service rate, the row every meeting stares at, the row the cloud vendors publish calculators for. Rates between serious platforms differ by percentages. The deciding rows differ by multiples. Row one flips comparisons when the shelf is real: license capacity doubling or halving depending on platform is a swing no rate discount recovers. Row three flips them when the support bill is big: a two million dollar bill offset at twenty five cents per consumed dollar is money that simply does not exist in the other column. And row four flips them when architects underestimate how chatty their applications are, which is always; I have watched a comparison reverse entirely when someone finally measured the actual round trips per transaction. My advice for your own comparisons is a habit: after you fill the table, circle the row with the biggest absolute gap, and ask whether that number is measured or assumed. In every comparison that later turned out wrong, the circled row was an assumption. Measure the circled row. The rest can be estimates; the decider cannot.
Circle the row with the biggest gap and ask whether it's measured or assumed, because the decider can't be an assumption. Rates differ by percentages, the deciding rows differ by multiples. That habit alone upgrades every comparison your estate will ever run.
Check two, the biased table. A rival comparison for our reference workload shows AWS BYOL winning, and it's built on rows two and five only: instance rates and operations costs. What did omitting rows one, three, and four hide? A, nothing material, rates and ops are the real costs. B, sixteen EE licenses plus options to acquire, row one; zero support offset while OCI routed spend would earn against a one point two million bill, row three; and, in fairness to AWS, zero cross cloud toll, row four: the omissions cut both ways, and the comparison is invalid, not merely wrong. C, only small rounding effects. Or D, the comparison is fine because license costs are sunk. Pause here. Which platform do rows one and three favor, and which does row four favor?
The answer is B, and notice the phrasing it insists on: invalid, not merely wrong, and the omissions cut both ways. Rows two and five are precisely where AWS competes best, so a table built only on them didn't approximate the answer, it selected one. What's missing: row one's six figure license acquisition for the AWS column, row three's offset asymmetry, real money against the support bill on one side, structurally zero on the other, and, honestly, row four, which favors AWS, no cross cloud toll, and which a fair OCI column must carry as a cost. A complete table might still pick AWS, that's the point of a method, it can lose fairly. But this table can't tell you anything, because its rows were chosen by the conclusion. Now D, the sunk cost argument, because it sounds sophisticated: the shelf licenses are not free to this workload. Allocating them here un-allocates them from wherever else the ledger has them counted, session eight's one license one place rule, so the AWS column's sixteen extra licenses are a real acquisition regardless of what the shelf originally cost. Five rows, or no verdict. And when someone hands you fewer, ask, politely, which conclusion picked the rows.
Beyond the spreadsheet, the judgment factors, and the rule is that they sit beside the model in prose, never inside it as invented coefficients. One, data gravity: where the data's consumers live outweighs single workload math, because one database rarely moves alone, and your second workload inherits the first one's choice. The five rows price a workload; gravity prices a trajectory. Two, skills and standards: a team fluent in one cloud ships faster there, and velocity is worth money no TCO row holds. Price the ramp honestly, not just the rate. Three, exit and concentration: every platform choice adjusts vendor concentration somewhere, Database at deepens Oracle, native services deepen AWS, and session nine's lock in lesson generalizes: name the dependency you're purchasing, out loud, in the decision document. Four, leverage timing: a platform decision is negotiating capital, and it's spent the moment it's known. Announce it deliberately, time it to whichever renewal needs it, per session five's calendar, and never let it leak quietly through a rep's coffee chat with your infrastructure team. And five, reversibility, the tiebreaker: BYOL paths keep the licenses, they come home if you leave; rented paths build nothing. When two columns land close, take the one you can walk back. Judgment in prose, model in numbers, and the decision document contains both, signed, dated, and rerunnable.
The profiles, because your estate's answer usually rhymes with its shape, and starting from a prior beats starting from a blank page. Profile one, Oracle centric: a big shelf, a big support bill, apps flexible or already suffering. OCI proper or Database at, decided mostly by where the apps sit, rows one and three dominate, and the session nine napkin frequently decides it alone. These are the estates the entire gradient was engineered to move, and fighting it is expensive. Profile two, AWS native with light Oracle: an empty shelf, a handful of databases, no meaningful support bill. RDS license included for the SE2 shaped work, minimal BYOL elsewhere, and, hear this clearly, do not manufacture an Oracle relationship the estate doesn't need. Rows one and three barely apply when there's no shelf and no bill; simplicity wins, and that's a fine victory. Profile three, the split estate: apps pinned to a hyperscaler, a real Oracle database estate underneath. Session fourteen's triangle, the middle path, with the marketplace routing worked properly. It exists for exactly this shape, our reference workload's shape. And the two shapes in the footnote, briefly: ULA holders, where every platform decision waits on the certification timeline, because cloud deployments and certification counting interact, Mastery module three's lesson; and shrinking Oracle estates, which brings us to the last check, because the exit case deserves its own treatment.
Last check of the module. An estate is eighteen months from exiting Oracle databases entirely, a funded Postgres migration is underway, and its remaining Oracle workloads need a temporary cloud home. The platform call: A, Database at AWS, the best engineered stack for the transition. B, rent, don't deepen: license included where editions allow, minimal BYOL elsewhere, no new Oracle commitments, and support termination sequenced with the exit, because every construct this module taught is a form of staying. C, OCI proper, the ratios make even eighteen months cheaper. Or D, a three year MUC commitment at a deep discount. Pause here. What is this estate actually optimizing: the Oracle relationship, or its end?
The answer is B, and it's the most important check in the module precisely because it inverts everything the module priced. Look at what the constructs actually are: BYOL ratios, Support Rewards, Database at, MUC pools, every one of them is Oracle paying you to deepen the relationship, discounts in exchange for commitment, gravity dressed as generosity. For a staying estate, taking that trade eyes open is correct, we've spent five sessions optimizing it. For an estate eighteen months from the door, every one of those discounts is a hook. Renting through license included builds no asset, which is exactly right when the asset is being retired. Minimal BYOL keeps licenses off the cloud ledger so their support sets can terminate on the exit schedule, session eight's sequencing lesson, reversed. And D, the three year commitment against an eighteen month horizon, is session seven's forfeit with a countersignature, I hope it made you wince on sight. C's ratios are real and irrelevant: capacity per license doesn't matter when the licenses are being retired. The discipline of this course cuts both ways, and that's how you know it's a discipline rather than a sales pitch: the same five rows, honestly computed with an eighteen month horizon, tell this estate not to buy the discounts. Optimize the destination, not the layover.
The module three pack, stacking onto module two's, so the whole cross cloud estate is governed from one shelf of documents. The artifacts: the hyperscaler census with session eleven's counting rule applied, at configured peaks. The AWS path map, every database workload assigned license included, BYOL, or EC2, with Multi AZ priced honestly. The application stack review from session thirteen: grants retrieved, four patterns checked, layer two counted. The commitment triangle table from session fourteen: every obligation, every balance, every end date, one page. And today's five row comparison, built once, dated, and rerunnable. The disciplines, consolidated: count at design, cap the elasticity, one ledger across all clouds with the counting world column, licensing present in every migration design review, and the annual re run of the platform comparison inside session ten's portfolio review. And the two standing questions that now close every platform conversation in your estate, permanently: session twelve's, what would this cost on OCI BYOL with the rewards? And today's exit twin: is this construct deepening a relationship we actually mean to deepen? Module three, complete: the policy, the paths, the applications, the triangle, and the method. Oracle on every cloud, counted and chosen on purpose.
Session fifteen, three sentences. One: five rows make a platform comparison honest, license capacity, service rate, support offset, data movement, and operations, and an omitted row is never omitted at random, so five rows or no verdict. Two: for the classic app pinned Oracle workload the middle path usually prices best, OCI proper wins when nothing is pinned, native AWS wins the light estates, and exiting estates rent instead of deepening, because the same math that optimizes staying tells leavers not to buy the discounts. Three: the spreadsheet decides with measured numbers, circle the deciding row and measure it, and judgment sits beside it in prose, gravity, skills, concentration, timing, reversibility, so every platform is a choice made on purpose. That's half the course, and all of the infrastructure story. Next session we change worlds entirely: module four, Oracle SaaS. Fusion ERP, HCM, the hosted metrics, and the service descriptions where definitions quietly become money. No more counting vCPUs; now we count people, and it turns out that's harder. See you there.
Homework, about an hour, and it's the method on your own estate. One, pick the workload: your largest Oracle database workload with an open platform question, or, more uncomfortably, the last one that was decided without this method, because retro running the rows on a settled decision is how you find out what the decision actually cost. Two, build the columns: only the genuinely available platforms, gated first by session twelve's edition and entitlement gates, no fantasy columns. Three, fill the five rows: license capacity from the ledger, rates at honest right sized capacities, the rewards napkin from session nine, the egress the architecture will really pay, measured if it's the big gap, and the operations delta. Four, add the judgment lines below the table, in prose, one sentence each: gravity, skills, concentration, timing, reversibility. And five, date it and diary it: the comparison is valid for roughly a year, programs move, constructs mature, so the re run goes into session ten's annual review as a standing item. One hour now, and your estate owns a platform methodology instead of a pile of vendor calculators. That's the module. Well earned.
Five reads before next session, all free on redress compliance dot com. First, OCI versus AWS for Oracle workloads, the two column ancestor of today's method, useful as a worked reference. Second, the Support Rewards guide, row three's machinery, the offset that flips real comparisons. Third, Oracle database licensing in cloud environments, row one's counting rules across every platform, the gradient in reference form. Fourth, Multicloud Universal Credits, the commitment shape for estates that land on the middle path. And fifth, Oracle cloud negotiations, because a platform decision is negotiating capital, and module six will teach you to spend it, session fifteen just taught you to mint it. That's session fifteen, module three complete, and the halfway mark of Oracle Cloud Management. The infrastructure story is told: counted, priced, chosen. Next week, the SaaS estate, where the meters count people and the definitions are the negotiation. See you in module four.