WebLogic licensing on AWS in 2026: how vCPUs, editions and autoscaling set the count.

Oracle counts WebLogic on AWS by vCPUs under its cloud policy, with no core factor, and hyperthreading sets the conversion rate. The rest of the bill is set at design time by the edition your features need and how many instances autoscaling starts.

How does Oracle count WebLogic processor licenses on AWS?

Oracle counts vCPUs on AWS under its policy for authorized cloud environments, and the core factor table does not apply. Two vCPUs equal one processor license when the instance runs with hyperthreading enabled. One vCPU equals one license when it does not.

The EC2 console shows you a vCPU number but not the threading behind it. The instance type specification shows threads per core, and that figure decides whether 8 vCPUs cost 4 licenses or 8. The full policy text and its history are covered in our guide to authorized cloud core counting.

Why do the same cores cost twice as much after a migration?

On premises, Oracle multiplies an x86 server's physical cores by the 0.5 core factor, so a 16 core Intel host needs 8 processor licenses. Put that workload on a hyperthreaded EC2 instance with 16 physical cores and 32 vCPUs, and Oracle counts 16 licenses.

A migration plan sized from the on premises license count therefore starts with half the licenses it needs. Size it from the target instance list instead, one instance at a time. The core factor guide explains the on premises side of the comparison.

Which instance families run one thread per core?

AWS publishes the default and allowed threads per core for every instance type in its CPU options documentation. The 7th generation AMD families and the Graviton families run one thread per core and cannot be switched to two. Intel families such as m7i and r7i default to two.

That makes instance selection a license decision. A platform team that shifts WebLogic to the AMD 7a sizes or to Graviton for better price performance doubles the processor count for the same vCPUs.

How does EC2 Optimize CPUs reduce the WebLogic license count?

Optimize CPUs runs a large instance with fewer active cores, so Oracle sees fewer vCPUs. You keep the memory and network bandwidth of the bigger size, pay AWS the full instance rate, and show Oracle a smaller number. It works the same way as Azure's constrained vCPU sizes.

You set it at launch through the CPU options (core count and threads per core), or later on a stopped instance through the ModifyInstanceCpuOptions API. On memory bound WebLogic deployments it is routinely the largest single license saving available, and it costs one configuration setting.

A worked example: three WebLogic nodes on memory optimized instances

Say you run a three node WebLogic Server Enterprise Edition cluster, and each node needs the memory of an r7i.4xlarge, which has 16 vCPUs on 8 physical cores. Oracle's technology price list puts Enterprise Edition at $25,000 per processor, with first year support at $5,500, the standard 22 percent rate.

The default cloud design costs twice the on premises count, and the AMD 7a choice costs four times it. Optimize CPUs brings the cloud count back to the on premises figure, provided the application runs within 8 vCPUs per node. Load test that at peak before you commit the design.

Which WebLogic edition do your deployed features require?

The features you deploy decide the edition, whatever the order form says. Standard Edition covers the core server without cluster support. Enterprise Edition adds clustering, and WebLogic Suite adds Oracle Coherence Enterprise Edition and Active GridLink for RAC, capabilities many teams assume come with Enterprise Edition.

The edition sets the price of every license in that count. The 12 licenses from the example above cost $120,000 on Standard Edition, $300,000 on Enterprise Edition and $540,000 on WebLogic Suite. Standard Edition is not an option for that design, because a three node cluster needs cluster support.

The wider middleware family context sits in our Fusion Middleware licensing analysis.

What happens when the edition is too low?

The common failure is buying one edition and deploying features from a higher one. Typical cases are clusters configured on Standard Edition entitlements, and Coherence caching or Active GridLink data sources running on Enterprise Edition licenses. An audit reads the domain configuration, not the purchase intent, and prices the edition gap at list.

What happens when the edition is too high?

The reverse mistake costs money without any audit. Suite entitlements covering deployments whose features fit Enterprise Edition pay the Suite premium, plus 22 percent support on it, every year. On the 12 licenses above, that premium is $240,000 in license value and $52,800 a year in support.

Reducing licenses you already own runs into Oracle's support repricing rules, so a downgrade is a negotiation. The cheapest time to get the edition right is before the purchase or at the migration. Our Suite versus Standard Edition decision guide works through that choice.

How do you check which features a domain actually uses?

• Clustering. Look for cluster entries in each domain's config.xml, or open the Clusters page in the WebLogic Server Administration Console.
• Coherence. Look for a Coherence cluster system resource in config.xml and for managed Coherence servers. Our Coherence licensing guide covers how that usage is priced.
• Active GridLink. Check the JDBC data source descriptors for Fast Application Notification enabled and an ONS node list configured.
• Management packs. Fusion Middleware Control comes with every edition. Multi domain management in Enterprise Manager Cloud Control uses the WebLogic Server Management Pack, which is licensed separately.

Can you buy WebLogic license included on AWS?

No. AWS offers no license included WebLogic, so bring your own license is the only path, and your existing entitlement sets the ceiling for the whole design. There is no hourly marketplace rate to fall back on when the pool runs short.

That changes how design reviews should run. Every instance family choice, autoscaling policy and environment copy spends licenses from a fixed pool, so the pool's size belongs in the design document next to the VPC diagram.

How autoscaling overdraws the license pool

Every instance that launches from an AMI with WebLogic installed is a licensable deployment from the moment it starts. A scale out event at 2am counts in full, and no failover allowance covers it. A group that normally runs four instances but may scale to ten is exposed at ten.

The controls are mechanical, and each one is cheap to set up:

• Scaling caps. Set the group's maximum capacity to what the licensed pool covers for that instance type.
• WebLogic free AMIs. Build separate images for web, batch and utility tiers that do not run WebLogic.
• AWS License Manager. Create a self managed license counted in vCPUs, associate it with the WebLogic AMIs and enforce the limit so launches past the pool are blocked. License Manager counts vCPUs without Oracle's two for one conversion, so on hyperthreaded families set the limit at twice your processor licenses.
• Overdraft alerts. Treat a license overdraft like the budget event it is, with a named owner and an alarm.

What have we seen in WebLogic on AWS reviews since 2024?

Across roughly 25 to 35 WebLogic on AWS deployments we reviewed between 2024 and 2026, the count was wrong at design time in most of them. The errors ran in predictable directions:

1. The 2x thread per core surprise. Deployments on AMD 7a and Graviton families counted one license per vCPU where the design had assumed the two for one conversion.
2. The right sizing recovery. Correcting instance families, applying Optimize CPUs and matching editions to deployed features cut WebLogic license cost 30 to 45 percent.
3. Environment sprawl. Development, test and DR copies were launched from production AMIs, each carrying WebLogic, each licensable, and none of them in the pool count.

The customers that held their position treated the license pool as a budget with an owner, reconciled quarterly against running instances. That is the discipline our database on AWS guide sets out for the layer below.

On AWS, the instance family you pick for WebLogic can double the license bill before a single line of application code changes.

Why we advise against moving WebLogic to Graviton for price performance

The usual cloud cost advice is to move workloads to Graviton or the newest AMD sizes for better price performance. For WebLogic we disagree. Whatever the compute saving per instance, it is small next to 8 extra Enterprise Edition licenses on a 16 vCPU node: $200,000 at list plus $44,000 a year in support.

Keep WebLogic on hyperthreaded families and apply Optimize CPUs there. Move the tiers that carry no Oracle license to Graviton, where the saving is real and costs nothing on the Oracle side.

What will Oracle say about WebLogic on AWS, and how should you answer?

Once WebLogic runs on EC2, Oracle's account and audit teams usually challenge the CPU settings, the non production copies, the platform choice and ULA cloud counting. Answer each one with instance records and the contract text.

• "We license the instance type, not your CPU settings." The policy counts vCPUs, and the instance runs with the vCPUs you configured. Show the CpuOptions record for each instance and ask Oracle to point to the policy language that counts vCPUs the instance cannot use.
• "Your development and test servers need licenses too." Agreed. Show which instances run from WebLogic free AMIs and which sit inside the counted pool, so the discussion works from a list of named instances.
• "Move to OCI and these rules go away." OCI has its own counting rules and its own costs. Compare compute, support and migration effort in full, as our OCI versus AWS comparison does, before treating a platform change as a license fix.
• "Instances on AWS do not count toward your ULA certification." Check the certification clause before you accept that. Many ULA contracts limit how public cloud deployments count, and some exclude them unless the wording was negotiated. Our ULA on AWS guide covers the clause types.

What should you get in writing?

• CPU options. Written confirmation that the licensed count is the vCPU count configured through CPU options. It closes off the main argument against the setting in an audit.
• Edition mapping. A record, agreed at purchase, of which domains need Enterprise Edition and which need Suite. It stops a later audit from pricing the whole deployment at the higher edition.
• Cloud rights in any unlimited agreement. Explicit wording on how AWS vCPUs count at ULA certification. Without it, cloud growth during the term may not count toward your certified quantity.

What to do next

1. Audit threads per core. List every WebLogic instance, its family, and whether the two for one conversion actually applies to it.
2. Apply Optimize CPUs on memory bound instances. Show Oracle the smaller vCPU number that AWS allows you to expose, and store the CpuOptions record with your license file.
3. Map deployed features to editions. Check clustering, Coherence, Active GridLink and the management packs, and fix both directions of mismatch.
4. Cap autoscaling to the licensed pool. Strip WebLogic from AMIs on tiers that do not run it, and enforce the limit in License Manager.
5. Reconcile the pool quarterly. Count every running instance, environments included, before any Oracle measurement does it for you.
6. Bring in help before the audit letter. The Oracle practice runs the review with you, alongside the AWS and Azure BYOL analysis for the full stack.

Frequently asked questions