Why Hyper-Threading Matters for Oracle Licensing on AWS

Why Hyper-Threading Matters for Oracle Licensing on AWS

Hyper-threading directly affects how Oracle licensing counts AWS instance vCPUs. Understanding this relationship helps avoid over-licensing and unnecessary costs.

This article explains why hyper-threading matters, illustrates scenarios where hyper-threading impacts licensing, and provides practical advice for Oracle deployments on AWS.

Read Oracle on AWS Licensing FAQs 1 of 4

What is Hyper-Threading and Why It Matters for Oracle Licensing?

Definition of Hyper-Threading:

• Hyper-threading allows a single physical CPU core to run two threads simultaneously.
• AWS EC2 instances with hyper-threading show two vCPUs per physical core.

Oracle explicitly recognizes hyper-threading in cloud environments, using a simplified formula:

• 2 vCPUs (hyper-threaded) = 1 Oracle Processor license
• 1 vCPU (non-hyper-threaded) = 1 Oracle Processor license

Understanding this distinction directly impacts your license count and cost efficiency.

How Hyper-Threading Affects Oracle Licensing on AWS

Hyper-threading significantly impacts Oracle licensing scenarios on AWS in several ways:

1. Risk of Double-Counting (Over-Licensing)

Common Mistakes:

• Misunderstanding vCPUs as physical cores, resulting in unnecessary license purchases.

Example Scenario:

• AWS EC2 instance type: m5.2xlarge (8 vCPUs with hyper-threading enabled):
  • Mistakenly licensing as if eight vCPUs were eight cores leads to 8 licenses purchased.
  • Clearly, with hyper-threading enabled, you only need 4 Oracle Processor licenses.

Clearly Explained Impact:

• Misinterpreting vCPUs significantly inflates Oracle licensing costs.
• Understanding hyper-threading avoids this common and costly mistake.

2. Impact of Disabling Hyper-Threading (Increased Licensing Cost)

Some AWS offerings or customizations explicitly disable hyper-threading. When hyper-threading is off:

• Each vCPU directly equals one physical core.
• Licensing costs effectively double for the same compute power compared to hyper-threading scenarios.

Example Scenario (Hyper-Threading Disabled):

• AWS EC2 Metal instance with eight physical cores:
  • Hyper-threading ON: shows 16 vCPUs → 8 licenses required (16 ÷ 2).
  • Hyper-threading OFF: shows eight vCPUs → 8 licenses required (1 license per vCPU/core).

Clearly Explained Impact:

• Turning hyper-threading off provides no Oracle license savings—it simply reduces performance.
• In fact, license costs might increase because you lose hyper-threading’s “2-for-1” efficiency.

Read Counting Oracle Processor Licenses on AWS EC2.

AWS Hyper-Threading Best Practices for Oracle Licensing

To optimize Oracle licensing efficiency and compliance on AWS:

1. Keep Hyper-Threading Enabled by Default

• AWS typically enables hyper-threading by default on Intel and AMD-based instance families.
• Oracle explicitly accepts hyper-threading, granting a licensing advantage (2 vCPUs = one license).
• There is no downside to Oracle licensing to having hyper-threading enabled.

2. Avoid Disabling Hyper-Threading Unless Necessary

• Only disable hyper-threading for specific performance or technical reasons justified.
• Understand that disabling hyper-threading will likely increase your Oracle licensing costs (or at minimum not reduce them).

Special Considerations: AWS Graviton (ARM) Instances

AWS Graviton processors (ARM-based CPUs) do not support hyper-threading. Oracle licensing on Graviton is less explicitly defined by Oracle’s cloud policy:

• With no hyper-threading, each AWS Graviton vCPU might count as one Oracle Processor license.
• Oracle has not explicitly provided guidance for Graviton; consult Oracle Licensing or assume the worst case (1 vCPU = 1 license).

Practical Example:

• AWS Graviton instance with 8 vCPUs:
  • Likely, it requires 8 Oracle Processor licenses.

Clearly Explained Impact:

• Review Oracle’s latest guidance or proactively contact Oracle if deploying Oracle software on AWS Graviton instances.

Practical Summary: Hyper-Threading Impact on Oracle Licensing

Oracle Licensing Compliance Checklist for AWS Hyper-Threading

✅ Verify hyper-threading status on AWS EC2 instance types before Oracle deployment.
✅ Clearly apply Oracle’s explicit policy: 2 vCPUs = 1 processor license (with hyper-threading).
✅ Keep hyper-threading enabled to optimize license efficiency.
✅ If disabling hyper-threading is required, clearly document the rationale and budget-increased licensing costs.
✅ Seek Oracle guidance or assume worst-case licensing for AWS Graviton instances.

Read Reducing Oracle Licensing Costs by Limiting AWS vCPUs or Disabling Cores.

Common Misunderstandings Corrected

• Misconception: “Disabling hyper-threading saves Oracle licensing costs.”
  • Reality: Does not—typically doubles licensing cost per CPU.
• Misconception: “AWS vCPUs always equal one Oracle processor license.”
  • Reality: Incorrect—usually two vCPUs = 1 license when hyper-threading is enabled.
• Misconception: “Oracle’s Core Factor Table applies in hyper-threaded AWS scenarios.”
  • Reality: It does not apply. Oracle explicitly uses only vCPU counting for the cloud.

Conclusion

Recognizing the relationship between hyper-threading and Oracle licensing on AWS ensures compliance and optimal license efficiency. You maximize Oracle license value by enabling hyper-threading (the default) (2 vCPUs per license). If special circumstances require disabling hyper-threading, clearly document the licensing impact to avoid compliance surprises.

Adhering clearly to these guidelines helps avoid costly over-licensing and audit challenges, making Oracle deployments on AWS straightforward, cost-effective, and compliant.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit