Red Hat Ansible Automation Platform Licensing.

A subscription, not a core count.

Red Hat Ansible Automation Platform, often shortened to AAP, is licensed as a subscription rather than by processor capacity. The unit that matters is the managed node, broadly the systems the platform automates against. This is closer in spirit to a usage based Resource Value Unit count than to the core based Processor Value Unit math that governs WebSphere or Db2.

Why the counting basis matters.

Because AAP is counted by managed nodes, the exposure does not come from processors or virtualization at all. It comes from how many systems the platform touches over the term, and how that figure is measured against what you purchased. A platform that quietly grows its inventory of managed systems can drift past its subscription without anyone provisioning a single new server.

Where audit risk concentrates.

• Managed node inventories that expand as automation spreads across teams
• Transient or ephemeral systems counted inconsistently between you and the auditor
• Subscriptions that lapse on part of the estate while automation continues
• Bundled entitlements assumed to cover scope they do not actually cover

Keeping the count defensible.

The defensible position starts from your own measurement of managed nodes, reconciled against your subscription entitlements, before the auditor offers their version. Define what counts as a managed node in your environment, document it, and hold that definition through the review. As with the rest of the IBM estate, the side that arrives with reconciled evidence sets the terms. AAP rarely travels alone, so pair this with container licensing non compliance and our sub-capacity defense work.

What this means under audit.

AAP is counted by managed nodes, so its audit risk lives in inventory accuracy, not processor math. Define what a managed node is in your environment, evidence it, and reconcile against your subscription before the auditor reconstructs the count for you.