The Ansible managed node, counted closely.
Ansible managed node counting under Ansible Automation Platform looks like a one number problem and behaves like a three ledger problem. The metered metric is the inventoried system on which a job has executed inside the entitlement window. The automation controller does not count. The execution environment does not count. The inventory does, and the inventory drifts. This note sets out the counting rule, the controller and executor scope, the drift patterns that produce most renewal surprises, and the reconciled inventory ledger the practice closes against.
What the managed node actually is.
Ansible managed node counting starts from a single rule, and the rule is older than most of the contracts that carry it. Ansible Automation Platform meters by the inventoried system on which an Ansible job has executed inside the entitlement window.1 The metered metric is the system at the end of the SSH session, the WinRM connection, or the API call, not the host that issued the command and not the runtime in which the playbook executed. Every system that has been the target of at least one job during the entitlement period is counted. Systems that were inventoried but never targeted are not counted. Systems that were targeted once and never again are counted for the full period in which they remained on inventory.
The corollary is structural. The managed node count is bounded above by the inventory and below by the activity register, and Red Hat reads both. A clean inventory and a quiet activity register produce the smallest count. A bloated inventory and a noisy activity register produce the largest count. Most enterprises operate somewhere in between, with an inventory larger than the activity register would justify and an activity register that quietly retains hosts long after the operational interest in them has ended. The contract reads the inventory. The inventory rarely reads itself.
This article concerns the counting mechanics specifically. For the broader Ansible Automation Platform licensing picture, including controller pricing tiers, Lightspeed posture, and the end of life trajectory of legacy Tower agreements, see the Ansible Automation Platform practice hub. For the entitlement reconciliation work in which a managed node count is one of several deliverables, see the subscription assessment hub.
| Component | Counted | What the buyer pays |
|---|---|---|
| Inventoried target system | Yes, on activity. | Managed node tier. |
| Automation controller host | No. | RHEL entitlement on the host. |
| Execution environment | No. | Nothing additional; runtime image. |
| Private automation hub | No. | RHEL entitlement on the host. |
| Ansible Lightspeed users | Separate. | Add on, billed independently. |
The controller and the executor are out of scope.
The most consequential misread of the Ansible managed node counting rule, and the one most expensive to carry into a renewal, is the assumption that scaling controllers requires more Ansible Automation Platform entitlement. It does not. The automation controller, formerly Ansible Tower, is the orchestration plane. It dispatches jobs. It does not contribute to the managed node count. Scaling controllers, adding additional controller hosts for high availability, or partitioning controllers by business unit, are infrastructure decisions and not Ansible Automation Platform purchase decisions.2
The execution environment is also out of scope for counting. An execution environment is the containerised runtime in which a playbook actually runs, packaged with its collections and its Python dependencies. Buyers may build many execution environments per controller. Each is a container image, not a metered metric. The buyer pays for the RHEL on the underlying host that runs the executor and for the storage on which the image sits. The buyer does not pay an additional Ansible Automation Platform line for the executor itself.
The private automation hub, the local mirror of certified content collections and execution environment images, sits in the same category. It is a service on a RHEL host. It carries a RHEL subscription on its host. It does not carry its own managed node entitlement. Where Satellite is also in scope, the Smart Management add on may apply to the hub host as a RHEL detail rather than as an Ansible Automation Platform detail. For the Smart Management surface specifically, see the Satellite and Insights practice hub.
This separation matters at the renewal table because the conventional opening move from a seller side that wants to scale the agreement is to introduce more controllers, more executors, and a hub, and to frame the resulting infrastructure footprint as an Ansible Automation Platform scope expansion. It is not. It is a RHEL scope expansion. The two count on different rules and price on different tiers. The buyer side reading is to keep them apart on the order form and to count them apart in the inventory ledger.
Where the inventory drifts.
If the managed node count is the inventory in motion, the question is what shape the inventory takes between renewals. Four drift patterns recur across recent practice engagements. Each is technically defensible. Each is also recoverable through reshape rather than through settlement, on the condition that the reshape happens before the count is read by Red Hat.
The first drift pattern is the decommissioned host that was never deregistered. A system retires from production. The configuration management database may or may not record the retirement. The Ansible inventory file or dynamic inventory source frequently retains the entry. The first job that targeted the system in the entitlement window, even if it failed, even if the host no longer exists, is enough to count the system for the period. Buyers who run a quarterly inventory sweep against the activity register typically remove between four and twelve percent of a managed node count this way alone.3
The second drift pattern is the ephemeral host that lived for one playbook run. Cloud build pipelines that spin up a host, run an Ansible role to configure it, and tear the host down again, contribute to the managed node count for the entitlement period in which they ran. The host is gone within minutes. The count is for the year. Where the build pattern is heavy, ephemeral activity can produce a managed node total that overstates the steady state estate by a multiple. The reshape is to register short lived hosts under a separate inventory pattern or, in some operational contexts, to run their configuration through a non Ansible path entirely.
The third drift pattern is the rebuilt host counted twice. A system is rebuilt, the hostname changes, the unique identifier in the inventory changes with it, and the activity register now shows two distinct systems where one operationally exists. This is the most frequent source of dispute when the buyer believes the count is wrong and the seller side believes the count is correct. Both are reading their own data correctly. The reconciliation is a deduplication exercise against the configuration management database, and it is mechanical rather than negotiated.
The fourth drift pattern is the development and quality assurance host counted as production. Many enterprises run development and quality assurance estates under the same Ansible Automation Platform agreement as production. The contract does not distinguish. The estate frequently does, in language and budgeting but not in counting. Where development hosts are short lived, ephemeral, and built fresh each sprint, they generate inventory entries at a faster rate than production. Reshape options here include separating the development inventory under a different organisation in the controller hierarchy, or moving development orchestration onto upstream AWX where the organisation has the engineering capacity to support it.
| Drift pattern | Observed contribution | Reshape window |
|---|---|---|
| Decommissioned, never deregistered | +4% to +12% | Quarterly |
| Ephemeral build hosts | +5% to +18% | Pre renewal |
| Rebuilt, double counted | +3% to +9% | Continuous |
| Dev and QA in production tier | +6% to +20% | Pre renewal |
The reconciled inventory ledger.
The output of an Ansible managed node counting exercise is a reconciled inventory ledger that names, for the current entitlement period, the number of systems that have been the target of at least one Ansible job, deduplicated against the configuration management database, with drift patterns surfaced and tagged. The ledger is read against the managed node tier on the order form. The delta is signed. A positive delta is recoverable excess. A negative delta is exposure.4
Three sources of truth carry the count. The first is the Ansible controller activity register itself, exported either through the controller user interface or through the controller API. The second is the buyer's own configuration management database, the canonical record of which hosts the enterprise believes it owns. The third is the deployment record, the build pipeline log, or the cloud account inventory that distinguishes long lived production systems from short lived ephemeral systems. None of the three is reliable on its own. All three read in parallel produce a ledger that survives a Red Hat inquiry intact.
The ledger is internal. It is not filed with Red Hat. It is not volunteered to the account team without an explicit decision to do so. Its purpose is to set the buyer's posture into renewal negotiation or, if a compliance inquiry has already landed, into audit defense. The audit defense engagement reads the ledger first and the seller side finding second, in that order. The order matters.
Across recent practice engagements, the reconciled ledger has produced a recoverable excess band on Ansible Automation Platform agreements in the mid double digit percent of the prior managed node tier where the inventory has not been cleaned in eighteen months or longer, and a single digit percent where the inventory is actively maintained. Exposure on the other side is rarer on Ansible than on RHEL, in part because the metered metric is a single number rather than a topology, but it is not unknown, and where it appears it is typically a development estate that was never registered as a separate organisation in the controller hierarchy.
The common failure modes.
Five failure modes recur on Ansible managed node counting. The first is counting against the controller activity register alone. The activity register is authoritative for what the controller saw. It is not authoritative for what the enterprise actually operates. A reconciliation that does not also read the configuration management database will miss every rebuilt host and every retired host that was never deregistered.
The second is conflating the controller scope with the managed node tier. Buyers frequently arrive at the renewal table assuming that an additional controller will require additional Ansible Automation Platform entitlement. It does not. The seller side has every incentive to leave this assumption uncorrected. The buyer side reading is to correct it before the order form is drafted, not after.
The third is carrying a Tower era contract assumption into the Ansible Automation Platform agreement. Some legacy Tower agreements contained user counts, concurrency caveats, and tier definitions that are absent in the current Ansible Automation Platform schedule by default. Buyers who carry the older agreement language unchanged into the renewal frequently find later that the protections they assumed are not present in the document they signed.
The fourth is leaving Ansible Lightspeed on the order form after a trial. Lightspeed, the generative integration introduced into Ansible Automation Platform, is metered and billed separately from managed nodes. Where it was enabled for a trial period, the order form typically continues to carry it after the trial ends unless an explicit removal is negotiated. The trial close is the cheapest moment to remove it; the renewal is the next cheapest; mid term is the most expensive.
The fifth is treating the inventory ledger as a one off deliverable. The Ansible managed node count drifts continuously. A ledger built once and never refreshed loses its operational value within twelve to eighteen months on a stable estate and faster on an estate that is integrating an acquisition or scaling its build pipelines. The ledger that holds up at the next renewal is the one that has been refreshed against the prior ledger rather than rebuilt from scratch.5
Where a counting exercise surfaces material exposure, the next engagement is normally audit defense if a Red Hat inquiry has already landed, or renewal negotiation if the renewal sits inside the next ninety days. Where it surfaces material recoverable excess, the next engagement is renewal negotiation, and the recovered budget funds the reshape. For the engagement form, see § 6 below or write the desk directly via the contact page.
Notes & references
- 1. The managed node metering rule for Ansible Automation Platform applies across the 2.x release line in current commercial agreements. The entitlement window is the agreement term recorded on the order form, typically twelve months on a one year subscription and twelve months rolling on a multi year subscription, with the count taken against the high water mark of inventoried systems that have been the target of at least one job inside the window.
- 2. The automation controller, the former Ansible Tower, requires a RHEL subscription on the host on which it runs. The same applies to the private automation hub and to the host that serves as execution node for any execution environment that runs out of process from the controller. None of these are metered against the Ansible Automation Platform managed node tier; they are RHEL entitlements on the host.
- 3. The four to twelve percent observation on decommissioned hosts left on inventory reflects the practice's experience across recent Ansible Automation Platform reconciliations. The band sits at the low end on estates that run a quarterly hygiene pass and at the high end on estates that have not cleaned the inventory across a renewal cycle. The observation is a recoverable correction, not a settlement variable.
- 4. The reconciled inventory ledger is an internal artefact. The practice does not file it with Red Hat. The ledger exists to set the buyer's posture at renewal or, where a compliance inquiry has landed, to inform the audit defense response. The ordering matters. The ledger reads first; the seller side finding reads second.
- 5. The cadence for refreshing an Ansible managed node ledger sits at twelve to eighteen months on a stable estate, compressed where the estate is integrating an acquisition or is scaling its build pipelines into ephemeral host territory at a fast rate. The refreshed ledger reads against the prior ledger as a delta rather than against a clean sheet, which is materially faster.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.