Running licensed software in containers does not change the count: Oracle, IBM, and Microsoft license the full underlying physical host, and on a mobile Kubernetes cluster that can mean every node, which multiplies a 4-node cluster's bill by 8 to 20 times unless you contract sub-capacity terms. Containers change how software is packaged and scheduled, not how vendors count cores. The buyers who get hurt are the ones who assume a small container footprint means a small license footprint. This guide sets the rule, then the per-vendor specifics and the terms that cap exposure.
The default position for legacy per-core licensing is that you license the physical cores where the software can run, not the cores it happens to use at a moment in time. Kubernetes schedules pods across nodes and reschedules them on failure, so the set of nodes where a licensed container can run is, by default, every node the scheduler can place it on. That default is what turns a modest deployment into a cluster-wide liability. The broader contract framing is in the software contract negotiation guide.
The core rule in one line
License follows the largest set of cores the workload can occupy, not the cores it currently occupies. On a 4-node cluster of 32-core hosts, an unrestricted licensed container is exposed to 128 cores even if it runs on 8. Restricting where the container can be scheduled, through node selectors, taints, and dedicated node pools, is what shrinks the licensable footprint back to reality.
| Vendor | Default container rule | Sub-capacity path |
|---|---|---|
| Oracle | License all hosts the container can run on; no contractual container metric | Hard isolation to dedicated nodes; written agreement required |
| IBM | Per-core (PVU / VPC); full capacity by default | Sub-capacity with ILMT or container licensing add-on |
| Microsoft (SQL Server) | Per-core, minimum 4 cores per container; license the cores allocated | Software Assurance enables flexible container licensing |
| VMware (Broadcom) | Per-core subscription on Tanzu / vSphere hosts | Cluster-scoped subscription; cores counted per host |
Oracle in containers
Oracle has no container-specific licensing metric, which means the standard processor rules apply and the cluster is treated like any other environment where the software can run. Oracle's position on soft partitioning is that scheduling restrictions enforced only in software do not reduce the licensable footprint, so namespace limits or pod resource caps do not shrink the count. The only reliable reduction is hard isolation onto dedicated nodes that the Oracle workload alone can use, documented and ideally written into the agreement. Without that, a single Oracle container on a large cluster carries the whole cluster's core count.
IBM and sub-capacity
IBM licenses most middleware per Processor Value Unit or per Virtual Processor Core, and the default is full capacity of the underlying hardware. IBM does offer sub-capacity licensing, but it is conditional: the customer must run IBM License Metric Tool or an approved container licensing mechanism and report eligible consumption on schedule. Miss the reporting requirement and IBM can reassess at full capacity for the entire period. The discipline that protects an IBM container estate is keeping the metric tool current and the reports filed, the same discipline that governs IBM virtualization generally.
The audit trigger: The most expensive container findings come from workload mobility that the buyer never deployed deliberately. A licensed container marked schedulable across an entire 20-node cluster is, on paper, deployed on 20 nodes. Pin licensed workloads to a small, named node pool with selectors and taints, prove the restriction in configuration, and the licensable footprint is the node pool, not the cluster. This single control routinely cuts exposure by 70 percent or more.
Microsoft SQL Server in containers
SQL Server is licensed per core with a four-core minimum per container, and you license the cores allocated to the container rather than the whole host, provided the deployment meets Microsoft's container terms. Software Assurance is the enabler: with active Software Assurance, SQL Server supports flexible container and virtualization licensing that lets the count follow allocation; without it, the count reverts to physical cores. The per-core mechanics and CAL interactions are detailed in SQL Server licensing.
Model the cost before you deploy
Container licensing decisions belong in the total cost of ownership model before a workload moves, not after an audit. The variables are the licensing metric, whether sub-capacity is available and what it requires, the isolation architecture, and the support implications of running a vendor's product on an unsupported orchestration pattern. The method is in software TCO modeling, and the contract language to secure sub-capacity rights is in contract terms that matter. For estates that also have consolidation opportunities, pairing isolation with vendor consolidation compounds the saving.
The container licensing question is not academic for finance, because the difference between full-cluster and isolated licensing on a single large cluster can run into seven figures a year for a heavily licensed product. A buyer who assumes a small container footprint means a small bill, and budgets accordingly, can face an audit finding that exceeds the annual licensing budget for that product several times over. Treating container deployments as a licensing decision at design time, not an infrastructure decision discovered later, is what keeps that surprise off the table and the budget defensible.
VMware Tanzu and the Broadcom subscription
Under Broadcom, VMware container platforms moved to a per-core subscription counted across the hosts in the cluster, which changed the math for Tanzu and vSphere container workloads in 2024 and 2025. The subscription is sized to the cores in the cluster, not the cores a container uses, so the same full-capacity principle that governs Oracle and IBM applies, now as a recurring subscription rather than a perpetual license plus support. Organizations that adopted Tanzu when it was bundled into older VMware agreements have seen the renewal price rise sharply as Broadcom repackaged the portfolio into a smaller number of subscription bundles. The control is the same as elsewhere: keep licensed container workloads on a defined, smaller set of hosts rather than spread across a large cluster, and model the per-core subscription against the actual host count at renewal.
Cloud-managed Kubernetes services
Running a vendor's database or middleware inside a managed Kubernetes service such as a hyperscaler's elastic Kubernetes offering does not transfer the licensing obligation to the cloud provider, and many buyers assume it does. The cloud provider licenses the Kubernetes control plane and the underlying infrastructure, but the third-party software running in the pods remains the customer's licensing responsibility under that vendor's standard terms. An Oracle or IBM workload in a managed Kubernetes cluster is licensed exactly as it would be on owned hardware, against the nodes it can run on. The one place this shifts is where the software vendor sells a first-party managed service of its own product, in which case the licensing is folded into the service fee. Outside that case, treat managed Kubernetes as your environment for licensing purposes and apply node isolation accordingly.
Documenting isolation for an audit
Node isolation only reduces the count if you can prove it, which makes the documentation as important as the configuration. An auditor confronted with a cluster will, by default, assess every node a licensed container could run on, and the burden is on the customer to demonstrate that scheduling was restricted. The evidence that holds up is the configuration itself: node selectors, taints and tolerations, dedicated node pools, and admission policies that prevent the licensed workload from being scheduled outside its assigned nodes, captured as point-in-time configuration exports and retained over the audited period. A verbal assurance that a workload was pinned does not survive an audit; an exported policy that shows it could only ever be scheduled on four named nodes does. Keeping this evidence current is the operational habit that converts an architectural control into a defensible licensing position, the same evidentiary discipline covered in contract red flags.
The reassessment risk: If isolation cannot be proven for the full audited period, vendors reassess at full capacity for that entire period, not just the moment of the audit. A cluster that was correctly isolated for ten months but undocumented for two can be billed as fully exposed for all twelve. Continuous configuration capture, not a one-time snapshot, is what closes this gap.
The support dimension
Beyond the license count, running a vendor's product on a container platform the vendor does not formally support creates a separate risk that surfaces during an incident rather than an audit. Some database and middleware vendors certify only specific orchestration patterns, and a production outage on an uncertified configuration can meet a support refusal at the worst possible moment. The terms to confirm are which container and orchestration configurations the vendor supports, whether your deployment matches, and what the support commitment is if it does not. This belongs in the same review as the licensing analysis, because a configuration that is licensed correctly but unsupported is still a liability. The total picture, license plus support plus infrastructure, is what a software TCO model is for.
Building a container licensing inventory
You cannot control container licensing exposure without an inventory that maps every licensed product to the cluster and the node pool it can run on, and most enterprises do not have one because the container estate changes faster than the licensing record. The inventory needs four fields per workload: the vendor and product, the licensing metric, the cluster and the set of nodes the workload can be scheduled on, and whether sub-capacity terms apply. Built once and maintained, it turns an unknowable audit exposure into a managed number, and it is the artifact that lets you prove isolation when an auditor asks. Without it, the default assumption is full-cluster exposure for every licensed product, which is almost always far more than the buyer actually owes.
The inventory also surfaces the consolidation opportunities that lower the bill: licensed workloads scattered across many nodes that could be concentrated onto a small dedicated pool, or products running in containers that could move to a licensing-friendlier deployment. Reviewing it quarterly, in step with how often the cluster changes, keeps the licensing position current rather than discovering drift during an audit. This inventory pairs with the total cost view in software TCO modeling.
Negotiating container rights
The terms worth securing at contract are an explicit container or sub-capacity metric, recognition of node-pool isolation as a valid boundary, a defined audit measurement method for containers, and support commitments for the orchestration platform you actually run. Vendors grant these more readily at new purchase or renewal than mid-term, so the time to ask is when you hold the advantage. Our software licensing advisory and cloud contract negotiation teams secure these terms across Oracle, IBM, and Microsoft estates. The one number to remember: an unrestricted licensed container on a 4-node, 32-core cluster is exposed to 128 cores, and node-pool isolation can bring that back to the 8 it actually uses.