Ansible Automation Platform, counted by the node.
Ansible Automation Platform licenses by the managed node, not by the controller and not by the execution environment. The accounting is conceptually simple. In practice, inventory drift, executor topology, and contract assumptions inherited from the Tower era produce three predictable counting traps. This hub sets them out, with the protocol for engagement at the foot of the page.
What Ansible Automation Platform actually counts.
When Ansible Tower became Ansible Automation Platform in the 2.x release line, the entitlement model consolidated. Tower licensed by users and by managed nodes. Ansible Automation Platform licenses by managed nodes alone.1 The control plane, now called the automation controller, and the execution environment, the containerised runtime in which playbooks actually run, are not the metered metric. The metered metric is the inventoried system on which an Ansible job has executed inside the entitlement window.
This is a friendly model to read and a punishing model to count. Friendly, because there is one number to track. Punishing, because the number is whatever your inventory says it is, and the inventory is rarely a quiet file.
The Red Hat that sold Ansible Tower in 2018 treated managed node bundles as a relationship matter. The Red Hat that sells Ansible Automation Platform in 2026 treats them as a revenue matter. The same buyer, with the same fleet, with the same playbooks, will not see the same renewal in 2026 that they saw in 2022. The contract reads identically. The posture behind it does not.
For the buyer the immediate practical consequence is this. The inventory is the contract. Systems on the inventory are entitled and counted. Systems off the inventory are neither. The audit exposure on Ansible Automation Platform, when it surfaces, almost always reduces to a disagreement about which systems were inside the entitlement window and which were not.
The three counting traps.
Three patterns recur across managed node accounting engagements. They are independent traps technically but reinforcing financially: an inventory that has drifted will almost always also be paired with unclear controller topology, because both reflect the same gap between automation activity and contract structure.
The first trap is inventory inflation. Decommissioned systems sit on the inventory long after they were retired. Systems built for a single automation run sit on the inventory long after the run completed. The contract counts what the inventory shows, not what is actually being managed today. A clean inventory is the cheapest concession a buyer ever hands themselves. It is also the most rarely performed.2
The second trap is controller and execution environment confusion. The buyer pays for managed nodes. The buyer does not pay extra for additional automation controllers, and does not pay extra for execution environment containers. The buyer does pay, separately, for the RHEL hosts those components run on, and frequently for Smart Management entitlements on top of Satellite if the deployment uses it. The frequent misread is to assume that scaling controllers requires more Ansible Automation Platform entitlement. It does not. Scaling managed nodes does. The cost of additional controllers is an infrastructure cost, not an Ansible Automation Platform cost.
The third trap is contract assumption inherited from the Tower era. Some legacy Tower agreements contained concurrent execution caveats and named user provisions. Some buyers carry the assumption that the current Ansible Automation Platform contract permits the same concurrency or the same user counts. In contracts observed across signed Ansible Automation Platform agreements through 2026, those caveats are absent by default. Reading the renewal as if it were the prior contract is the most frequent cause of a quiet entitlement gap discovered later in an audit.3
| Trap | Frequency | Observed correction band |
|---|---|---|
| Inventory inflation | Frequent | −18% to −34% |
| Controller and executor confusion | Typical | −9% to −22% |
| Tower era contract carryover | Frequent | −12% to −28% |
A second observation worth recording. Ansible Lightspeed, the generative integration introduced into Ansible Automation Platform, is a separately metered add on at present, billed independently from managed node entitlement. Buyers who enable it as part of a trial frequently leave it inside the contract long after the trial ended.4 The trial is the cheapest moment to remove it.
Engagement across the six services.
Ansible Automation Platform questions cross all six services. The lead service is audit defense when an inventory dispute is already on the table. Renewal negotiation and subscription assessment are the standard entries when the renewal is approaching and the inventory has not been reconciled. Benchmarking informs the size of the ask. Exit planning, in this practice area, addresses the rarer but consequential question of moving off Ansible Automation Platform toward open source AWX or a third party orchestrator.
Reading list.
Working notes on Ansible Automation Platform licensing mechanics. Each article is independent and may be read in any order. Read alongside the JBoss and middleware practice hub if Ansible Automation Platform sits inside a broader Red Hat middleware estate.
Notes & references
- 1. See "Tower to Ansible Automation Platform, what changed at the contract layer", practice memo, March 2026. The 2.x release line consolidated the entitlement model around managed node counts; the consolidation is the source of most carryover confusion.
- 2. Inventory inflation is the single most frequent finding in subscription assessment engagements that touch Ansible Automation Platform. Decommissioned and ephemeral nodes are routinely the largest line.
- 3. Concurrent execution language in legacy Tower agreements is contract specific. The presence or absence of the caveat in any individual buyer's prior agreement should be read against the actual text on record, not against a remembered conversation with a prior account team.
- 4. Ansible Lightspeed is metered separately from managed node entitlement at present. Posture on Lightspeed at renewal is treated under renewal negotiation, not under managed node reconciliation.
- 5. All concession band figures referenced on this page reflect observation across signed Ansible Automation Platform agreements in the trailing twelve months. Bands are stated as ranges to preserve the observational character of the data.