RDS license included, RDS BYOL, and EC2 self managed: where each one wins, and the checkbox that doubles the count. 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 twelve of thirty. Last session gave you the rulebook for Oracle on the hyperscalers, the two vCPUs per license arithmetic and the gradient it sits inside. Today we go from policy to practice on the hyperscaler that hosts more Oracle databases than any other: AWS. And the practice comes down to a choice you'll make once per workload, three paths: RDS with the license included, RDS with your own licenses, or EC2 where you run everything yourself. Same database engine, three completely different commercial shapes, and along the way, the most expensive checkbox in the AWS console: Multi AZ, which doubles license counts faster than any other single click in this course. By the end you'll have a decision framework that routes any workload to its right path in three gates. Let's walk the map.
Five takeaways. One, the map: the three ways Oracle Database runs on AWS and the licensing model each carries, because the technology choice and the licensing choice travel together, and pulling them apart is where the money leaks. Two, the rental: RDS license included, what the hourly rate actually buys, its hard Standard Edition boundary, and the honest cases where renting beats owning. Three, the import: RDS BYOL, your entitlements on Amazon's managed service, counted exactly by session eleven's rule. Four, the doubling: Multi AZ, the high availability checkbox that doubles a BYOL license requirement in five seconds, silently, and what the discipline does about it. And five, the framework: three gates, edition, entitlements, operations, that turn portfolio triage into a repeatable meeting instead of a debate.
The three paths. Path one, RDS license included: Amazon's managed database service with the Oracle license rented into the hourly rate. You bring nothing: no entitlements, no Oracle support contract, no counting, the license question simply disappears into the instance price. The catch, and it's structural: Standard Edition 2 only, and we'll spend a whole slide on what that boundary means. Path two, RDS BYOL: the identical managed service, but running on your entitlements. Enterprise Edition and SE2 both allowed, session eleven's counting rule applies to the instance's vCPUs, support stays active on the shelf per session eight, and your ledger grows AWS rows. Path three, EC2 self managed: a virtual machine where you install and operate Oracle yourself. Full control, every feature, every version, and the full counting rule plus the full operational burden, the datacenter playbook, relocated to Amazon's hardware. One clarification that prevents a common confusion: on both RDS paths, Amazon manages the service, the patching, the backups, the failover machinery. The license included versus BYOL toggle changes whose license runs the engine, not who operates it. Management and licensing are separate axes, and the whole session is about keeping them straight.
Path one in depth: license included, renting by the hour. Fact one, the boundary: license included covers Standard Edition 2, full stop. Enterprise Edition is not offered on a rental basis, anywhere on AWS, which means every EE workload in your estate has already skipped this path before the conversation starts. Fact two, what the rate buys: infrastructure, management, and the license rental in one hourly number. For these instances there's no Oracle support contract to maintain, no NUP counting exercise, and essentially no Oracle audit surface, the instance price is the entire licensing story, and for teams exhausted by everything the Mastery course describes, that simplicity has genuine value. Fact three, the limits travel: SE2 on RDS is still SE2, no Partitioning, no packs, no EE options, the same edition boundary you know, now enforced by what the service will even let you provision. Fact four, the genuinely elegant part: elastic licensing. Resize the instance and the license rental resizes inside the rate, the one path in this entire course where elasticity is not a licensing event. Spiky workloads love this. And fact five, the exit math: renting builds no asset. Three years of license included fees buy you zero entitlements, which is fine for variable workloads and expensive as a permanent home for stable ones, the classic rent versus buy curve, and we'll put numbers on it in the homework.
First check, the boundary in action. A team wants RDS license included for a database that uses Partitioning and the Diagnostics Pack. The accurate response: A, proceed, license included covers whatever the instance runs. B, it doesn't fit: license included is SE2 only, and Partitioning and the packs are EE features, so this workload needs BYOL with the options brought, or honest refactoring to live within SE2. C, proceed but pay Amazon extra for the options. Or D, options are free on RDS. Pause here. Which edition does license included rent, and which edition do those features need?
The answer is B, and the gate logic matters more than the letter. License included rents Standard Edition 2. Partitioning and the Diagnostics Pack are Enterprise Edition features, they don't exist in SE2's world, and the service enforces this at provisioning, you cannot actually create the misconfiguration the team is imagining. So the workload faces a real fork: BYOL, bringing EE processor licenses plus the Partitioning and Diagnostics entitlements at the counted instance size, all of session eight's rules; or refactoring, genuinely re-engineering the workload to live inside SE2, dropping the partitioning scheme, living without the pack telemetry, which is sometimes worth it and always worth pricing. C fails on a fact worth internalizing: Amazon sells infrastructure and managed services, and cannot sell you Oracle options at any price, the companies' catalogs don't overlap there. And D is the eternal hope, and no: nothing about a managed service makes Oracle features free, in any cloud, ever. The takeaway that generalizes: the edition question is the first gate of every RDS decision, and it's binary. Ask it first and half the debate evaporates.
Path two: RDS with BYOL, your entitlements on Amazon's managed service, and this is where the estates with real license shelves usually land. Point one, EE unlocked: BYOL is the way, the only way, Enterprise Edition runs on RDS. Your EE processor or NUP entitlements, with active support, session eight's qualifying rules unchanged. Point two, counted by the policy: session eleven's rule against the instance's vCPUs. An eight vCPU RDS instance, hyperthreading on, four EE processor licenses. Same sticky note, new console. Point three, options at count: every option and pack the instance uses, Partitioning, the packs, advanced security, licensed at the same computed count. Hear the division of labor precisely: RDS manages the engine, it does not manage your compliance, and no AWS service ever will. Point four, the ledger extends: every RDS BYOL instance gets a row, instance identifier, vCPUs, computed count, source order, and the one license one place rule from session eight applies with full force, licenses covering RDS aren't covering the datacenter anymore. And point five, the practical boundary: RDS restricts some deep administration, no OS access, managed patching windows, a supported version list. Most EE workloads fit comfortably. The ones that don't, legacy versions, OS level agents, exotic configurations, point at EC2, or at RDS Custom, the halfway house that gives more control while keeping some management. Which sets up the Multi AZ conversation, because high availability is where BYOL surprises people.
The Multi AZ wrinkle, the most expensive checkbox in the AWS console. What Multi AZ does: provisions a synchronized standby instance in a second availability zone, with automatic failover. Operationally, it's excellent, one checkbox buys real resilience. Now the licensing table. Single AZ, eight vCPUs, BYOL: four EE licenses. Multi AZ, same eight vCPUs: eight licenses, because the standby is a full instance receiving synchronous replication, a running deployment that counts in full. The count doubled at a checkbox. On license included, the same doubling happens but stays inside the rate: the hourly price roughly doubles and the licensing remains Amazon's problem, which is tidy, and worth noticing as a point for the rental path on availability critical SE2 workloads. Add a read replica, that's a third instance, readable, running, its own full count on top. And the question everyone asks, answered once more with feeling: no, the ten day failover rule does not rescue Multi AZ. That rule covers one passive node that mounts the database only when production actually fails, ten separate days a year. A synchronized standby is running by definition, it's the Data Guard lesson from the Mastery course wearing an AWS checkbox. If your availability design includes a running copy, your license design includes it too. Every cloud, every session, same physics.
Check two, the checkbox in the wild. An eight vCPU RDS BYOL database gets flipped to Multi AZ during an availability review. Licensing owns four EE licenses for it. The consequence: A, nothing, Multi AZ is an infrastructure feature inside the same instance. B, the requirement doubled to eight licenses the moment the standby launched: the estate is four licenses short, and nobody sent licensing the checkbox. C, the standby qualifies for the ten day failover exception. Or D, AWS automatically bills the extra Oracle licenses. Pause here. What is a Multi AZ standby: passive hardware, or a running synchronized deployment?
The answer is B. The standby launched, it receives synchronous replication, it is a running deployment, and the BYOL requirement went from four licenses to eight in the time it took the console to say modifying. The estate is now four licenses short, and, the operationally important part, nobody told licensing, because an availability review doesn't think of itself as a procurement event. A misreads what Multi AZ provisions, it's a second instance, not a feature flag. C, the ten day rule, is excluded by the word synchronized, textbook Data Guard logic, and if you took the Mastery course you got this one before I finished the question. And D imagines a billing integration that doesn't exist: AWS bills its own doubled infrastructure happily, and has no mechanism, none, to transact Oracle entitlements on your behalf. The fix is session eleven's discipline, made specific: availability changes and resizes on Oracle tagged instances alert the license owner, automatically. Because this checkbox takes five seconds to flip, and unalerted, it's discovered by an audit script two years later, priced at list plus back support, with the finding named after whoever flipped it.
Path three: EC2, self managed, the datacenter playbook relocated. Point one, everything runs: any edition, every option, versions RDS dropped years ago, OS level agents, your exact backup tooling, full control. RAC is the notable exception, excluded by AWS's architecture rather than by policy. Point two, everything counts: session eleven's rule on the instance vCPUs, options at count, DR instances in full, and no managed service layer to blur any of it. EC2 licensing is honest in the way a datacenter is honest: it's all yours. Point three, everything is yours to run: the patching, the backups, the high availability engineering that Multi AZ gave RDS users as a checkbox. The operational cost RDS priced into its hourly rate comes back as engineering time, and that cost is real even though it never appears on an invoice. Point four, the specialist wrinkle: EC2 dedicated hosts, where you rent the entire physical server, allow per host licensing arithmetic in specific configurations, and for dense estates, many instances packed on few hosts, that math occasionally beats per instance counting. It's a genuinely specialist calculation, worth commissioning at scale, not worth improvising. And point five, the honest niche: EC2 is the right answer for workloads that truly cannot live in a managed service. In practice it's chosen too often by habit, teams recreating their datacenter because it's familiar, and too rarely for its actual reasons. The framework at the end exists to catch exactly that habit.
Before the last check, here's our advisor on how this decision actually gets made well, and the one question he adds at the end of every AWS review.
Guest analyst When I review an AWS database estate, I run every workload through three questions, in a fixed order, and the order is the method. First: what edition and features does it genuinely use? Not what it might use, what the feature views say it used. That question alone sorts the estate, because everything that is honestly SE2 shaped becomes a license included candidate, and everything with EE fingerprints goes down the BYOL road. Second: what does the shelf look like? Supported, unallocated entitlements make BYOL nearly free at the margin; an empty shelf makes the rent versus buy math real. And third: does anything about the workload actually require self management? Usually the honest answer is no, and half the EC2 estates I review are datacenters rebuilt from muscle memory, paying operational costs nobody priced. Then, when the AWS answer is settled, I ask the question that makes clients uncomfortable: what would this workload cost on OCI BYOL, with the rewards? Because the same licenses cover double the capacity there, and the rewards pay the support bill besides. Sometimes AWS still wins, data gravity, team skills, the rest of the stack, and that is a fine, informed answer. But I have never once asked that question and had the room already know the number. Ask the question. Know the number. Then choose AWS on purpose, not by default.
Three questions in fixed order, then the uncomfortable fourth: what would it cost on OCI BYOL? Choose AWS on purpose, not by default. That fourth question is session eleven's gradient made operational, and it closes every decision this module makes from here on.
Last check, portfolio triage. Three workloads: one, a spiky SE2 compatible workload, no options. Two, a steady EE database using Partitioning, with suitable entitlements sitting on the shelf. Three, an EE system needing OS level agents and a legacy version. The clean mapping: A, everything to EC2, for consistency. B, workload one to RDS license included, workload two to RDS BYOL with options brought, workload three to EC2 self managed, or RDS Custom if it fits. C, everything to RDS license included, for simplicity. Or D, one to EC2, two to license included, three to RDS BYOL. Pause here. Edition, entitlements, operations: three gates, three workloads.
The answer is B, and each workload walks the gates cleanly. Workload one is the license included profile drawn from a textbook: SE2 compatible, no options, and spiky, which makes elastic rented licensing genuinely optimal, resize freely, pay by the hour, build no asset you don't need. Workload two is the BYOL case: EE plus Partitioning fails gate one for renting, the shelf passes gate two, managed service passes gate three, so it lands on RDS BYOL with the Partitioning entitlements brought at count and the ledger updated. Workload three fails gate three's managed boundary, OS agents and a legacy version, so it self manages on EC2, with RDS Custom worth a look as the halfway house. Now the uniform answers, because they're the real world failure modes: A, everything to EC2 for consistency, buys operational burden for two workloads that didn't need it, the muscle memory datacenter from the clip. C, everything to license included, is actually impossible for two of the three, EE doesn't rent, and the provisioning gate would bounce them. And D scrambles the gates at random. The lesson is the method: uniformity is the anti pattern, the framework is the answer, and it takes about four minutes per workload once the census exists.
The decision framework, assembled. Gate one, edition and features: does the workload need EE, options, or packs, per the feature views, not per anyone's memory? If yes, license included is off the table, the fork is BYOL or EC2. If it honestly fits SE2, all three paths stay live, and renting is a real candidate. Gate two, entitlements: are there suitable licenses on the shelf, supported and unallocated in the ledger? If yes, BYOL competes hard, near free at the margin. If the shelf is empty or spoken for, it's rent versus buy, and session eight's three column model prices it. Gate three, operations and availability: is a managed service acceptable? RDS. Does the workload genuinely need OS access or exotica? EC2, or RDS Custom in between. Then, before anything signs, two closing disciplines. Price Multi AZ honestly, doubled entitlements on BYOL, doubled rate on license included, in the business case, not discovered later. And the advisor's fourth question, now mandatory: what would this workload cost on OCI BYOL with Support Rewards? Sometimes AWS wins anyway, and then you've chosen it on purpose. Session fifteen industrializes that comparison across the whole estate; for now, it's the last line of every individual decision. Three gates, two disciplines, four minutes per workload. That's the session.
Session twelve, three sentences. One: three paths, license included rents SE2 by the hour with zero counting and genuine elastic charm, BYOL puts your EE estate on the managed service under session eleven's rule with the ledger extended, and EC2 relocates the full datacenter playbook, control and burden together. Two: Multi AZ doubles the BYOL requirement at a checkbox, because a synchronized standby is a running deployment and the ten day rule never rescues one, so availability changes on Oracle instances alert the license owner, automatically, forever. Three: route every workload through the three gates, edition, entitlements, operations, price the availability honestly, and close every case with the OCI comparison, so AWS is always a choice and never a default. Next session, the application estates: JD Edwards on AWS, the pattern for lifting Oracle's on premises applications to hyperscalers, where the apps tier licensing meets the tech stack underneath, and the specific architectures auditors examine. If your estate runs JDE, EBS, or PeopleSoft, it's the session your migration plan has been waiting for. See you there.
Homework, about an hour, and it's triage on your real estate. One, list the paths: every Oracle database on AWS, tagged by path, license included, BYOL, or EC2, from the console plus session eleven's census. Two, audit Multi AZ: every BYOL instance with Multi AZ enabled, is the standby in the license count? Every miss you find is a hundred percent understatement on that instance, and finding it yourself costs nothing while an auditor finding it costs list. Three, gate the misfits: run the three gates on each database. Anything on EC2 that would fit RDS, anything BYOL without ledger rows, anything claiming license included with EE features, which should be impossible, and confirming impossibilities is exactly what audits are for. Four, price one rental: your largest stable license included instance, remodeled as BYOL if shelf licenses exist. Stable plus owned usually beats rented, and the delta is often five figures a year per instance. And five, set the alert: availability and resize changes on Oracle tagged instances notify the license owner. Five seconds of checkbox should never again produce two years of silent exposure. That's the AWS database estate, triaged. Next week we climb the stack to the applications.
Five reads before next session, all free on redress compliance dot com. First, Oracle database licensing on AWS, the RDS and EC2 rules in reference form, today's map in writing. Second, Oracle database licensing on AWS with BYOL, the import path in detail, ratios, retention, and the ledger discipline. Third, Oracle database licensing in cloud environments, session eleven's counting rule, which every path today builds on. Fourth, OCI versus AWS for Oracle workloads, the comparison the framework's last line demands, with prices. And fifth, the Oracle BYOL comprehensive guide, the entitlement rules underneath the BYOL path on any cloud, worth its third mention in this course because it keeps being load bearing. That's session twelve: three paths, three gates, one expensive checkbox, and a framework that chooses on purpose. Next time, JD Edwards goes to AWS. See you there.