Licensing for Database@Azure and @AWS: BYOL Rules

The Database@ services are a placement innovation, not a licensing innovation. Oracle Database@Azure and Oracle Database@AWS put real Exadata hardware inside Microsoft and Amazon data centers, you buy them through the respective marketplace, and the spend retires the cloud commitment you already signed. What is not new is the logic underneath: the database software is still licensed under Oracle rules, and the choice between license included and BYOL moves more money than any infrastructure decision you will make on these platforms. We cover the strategic picture in our pillar on Oracle Database@Azure, @AWS, and @Google Cloud; this article goes deep on the licensing choice alone, because it is the part of the deal teams most often get wrong and the hardest to unwind later.

The two models, and what each one bundles

Every Database@ subscription runs on one of two licensing models, chosen per service and revisitable as the estate evolves.

License included bundles the Oracle Database license into the metered rate. You pay a higher price per unit of compute, and in exchange the entitlement question disappears: the database edition and, on the Exadata services, a broad set of options ride along with the meter. There is nothing to inventory, nothing to true up, no separate support contract to maintain for those workloads. For organizations with little or no existing Oracle estate, this simplicity is worth real money.

BYOL, bring your own license, applies entitlements you already own against the same service and pays a substantially lower metered rate. In exchange, you take on three obligations: own enough licenses of the right edition to cover the compute you enable, own every option and pack your databases actually use, and keep an active support contract on those licenses. BYOL is not a discount code; it is a contract position, and it has to be true on the day Oracle asks about it, not just on the day you chose it.

How entitlements map to the meters

The mapping between what you own and what you run is where the practical difficulty lives, because the two sides are denominated in different units: entitlements in Processor and Named User Plus licenses, the services in enabled cores and ECPUs.

For the Exadata database services on both Database@Azure and Database@AWS, the unit that matters is the enabled core. You reserve an Exadata system with a maximum core count, and you choose how many of those cores are switched on. Licensing follows the enabled number, not the maximum: an enabled core must be covered, a disabled core does not. Oracle publishes a conversion ratio, the cloud core factor, that defines how many enabled cores one Processor license covers on these services. The ratio is more favorable than the on premises core factor table for the same hardware, but always work from the current published BYOL policy document, because the definitions are precise and the document controls.

Named User Plus entitlements can also be brought, subject to the published minimums per processor equivalent. NUP only works for genuinely small, countable user populations; if your workload faces the internet or a large internal population, Processor licenses are the honest answer.

For Autonomous Database on either platform, the meter is the ECPU, and Oracle publishes a separate mapping that defines how many ECPUs one Processor license covers under BYOL. Autonomous adds a wrinkle: with auto scaling on, the service can burst above your baseline, and your entitlement position has to cover what the meter records, not the floor you intended to run at.

Options and packs: the second ledger

Under license included on the Exadata services, the bundled tier generally corresponds to a fully optioned Enterprise Edition: Real Application Clusters, Active Data Guard, partitioning, advanced security, and the diagnostics and tuning packs are part of what the higher rate buys. Under BYOL, none of that is automatic. Every option and pack your databases use must be separately owned, on the same metric and the same core count as the underlying database licenses.

This is where BYOL estates quietly go wrong. RAC is almost unavoidable on Exadata, because clustering across database servers is the point of the platform. Active Data Guard is distinct from plain Data Guard, and the moment a standby is opened for read traffic the option is in use. Partitioning is so common in Exadata workloads that many teams forget it is a paid option at all. Transparent data encryption sits inside the advanced security option for on premises licenses, and the management packs light up the moment someone opens the performance pages. A database that drifts from its entitlements is out of compliance on every enabled core, for every month the option was in use. The audit math multiplies, it never adds.

The discipline that works is a second ledger next to the core count: which options are licensed, for how many processor equivalents, mapped to which services, reviewed whenever a feature is switched on. Oracle's own feature usage views tell you what is actually in use, and running that check yourself is far cheaper than having Oracle run it for you.

Support: the quiet line that decides the math

BYOL economics are usually presented as the lower metered rate versus the license included rate. That comparison is incomplete, because BYOL carries a third number: the annual support stream on the licenses you bring. Support must stay active for the BYOL terms to hold, and Oracle's matching service levels policy means you cannot drop support on part of a license set while keeping it on the rest. In practice you pay for the whole shelf or none of it.

That changes the arithmetic in two directions. If you were paying that support anyway, BYOL lets an existing cost do new work, and the effective rate is excellent. But if a meaningful share of your shelf is shelfware, licenses bought for projects that shrank or died, then the BYOL decision is also a decision to keep funding that shelfware indefinitely. Sometimes the honest answer is to right size the support contract first, where contract structure permits, or to accept license included and let unused entitlements lapse. The worst position is paying full support on a large shelf while also paying license included rates in the cloud: two licensing bills for one estate, with nobody owning the overlap.

Database@Azure versus Database@AWS: same logic, different wrapper

Commercially the two services rhyme almost perfectly. Both are purchased through the respective marketplace, typically as a private offer negotiated for your deal. Both retire the cloud commitment you hold with that provider, which is why procurement teams who would fight a new Oracle contract will wave through the same spend wearing a marketplace badge. And underneath both wrappers, the licensing logic is the same Oracle logic: the same license included and BYOL election, the same enabled core meter, the same ECPU mapping, the same options ledger, the same support obligations.

The differences sit at the edges: private offer mechanics, how the spend interacts with your commitment program, and how the surrounding network costs land. We walk through the platforms in our complete guide to Database@Azure and the complete guide to Database@AWS, and the billing decomposition in Database@AWS pricing applies with minor translation to the Azure side. For the licensing decision itself, analyze once and apply everywhere.

The audit angle

A license included estate is, for the bundled workloads, essentially unauditable: the entitlement travels with the meter, and there is nothing to verify. A BYOL estate is an auditable position. You have asserted to Oracle that your entitlements cover your consumption, and Oracle retains every right to test that assertion, on the cloud estate just as it does on premises.

The meter that matters is enabled cores, and the meter has a memory. Scale up events count. If your team enabled extra cores for a quarter end close, a migration cutover, or a load test, those cores were licensed consumption for the period they were on, and a BYOL position sized to the steady state does not cover the peak. The same applies to Autonomous auto scaling bursts. None of this makes BYOL dangerous for a well run estate; it makes BYOL dangerous for an unmanaged one. The teams that do well can produce, on a normal Tuesday, entitlements on one side and enabled cores and active options on the other, with headroom between them.

License included versus BYOL at a glance

The table below compresses the decision into the dimensions that actually move it. Few estates land entirely in one column.

A 7 step decision framework

This is the sequence we use with clients deciding the licensing model, ideally before the marketplace offer is signed.

Common failure modes

The same handful of mistakes accounts for most of the licensing pain on these platforms.

• Double paying. Running workloads on license included rates while still paying full support on the entitlements those workloads used to consume, with nobody reconciling the overlap.
• BYOL without enough cores covered. Electing BYOL on a count that covers the planned baseline but not the cores actually enabled after go live.
• Options enabled that nobody licensed. Partitioning, Active Data Guard, or the management packs in daily use on a BYOL service whose entitlements cover only the base edition.
• Forgetting standby licensing. A Data Guard standby is licensable consumption under the rules that apply to it, and a design that ignores this fails its first audit, not its first failover.
• Unowned scale up events. A migration team enabling cores to hit a cutover window without telling the license owner, leaving a peak on the meter that the position never covered.

Where independent help fits

Everything above is checkable work, and it is much cheaper to check before signature than after a soft audit letter arrives. The pattern that works is a fixed fee licensing review before the offer is signed: entitlements verified, workloads mapped, both models priced at honest core counts, a written position you can defend later. Ongoing oversight then fits a Managed Monthly arrangement, where enabled cores, option usage, and the support ledger are reviewed as part of running the estate, or our cost optimization practice, where the fee is paid only on verified savings and licensing is usually one of the largest levers found. How the licensing model feeds the wider financial picture is covered in building the Database@ business case.

For the entitlement analysis itself, and for the Oracle negotiation that often follows it, independent Oracle licensing specialists earn their fee. Verifying what you actually own, separating contractual fact from sales narrative, and structuring the Oracle conversation is specialist work, and having it done by a party with no stake in the deal is what makes the position defensible.

Bringing it together

Licensing on Database@Azure and Database@AWS is the same Oracle decision it has always been, wearing a marketplace badge. License included buys simplicity at a higher rate and suits new or small estates. BYOL buys a better rate at the cost of an auditable position: entitlements mapped to enabled cores, every option owned, support kept current, peaks covered as well as baselines. Decide per workload, write the position down, review it annually, and put a name on the enabled core count. Do that, and the licensing line becomes a managed cost like any other. Skip it, and the cheapest rate on the table becomes the most expensive decision in the program.