Controller and executor, read apart.

The automation controller in Ansible Automation Platform 2.x is the renamed successor to Ansible Tower. It is the web user interface, the role based access control plane, the credential vault, the survey form for job templates, the workflow orchestrator, and the scheduler.1 A controller does not, in modern releases, execute the playbook in process on its own host as the default path. It dispatches the job to an execution node, which loads the appropriate execution environment image, and the playbook runs there. The controller observes, records, and reports. The work happens elsewhere.

The controller's input is a job request. Its output is a job record. Between those two endpoints sit the run record, the standard output stream, the host fact cache, and the artefacts the playbook chose to register. None of that activity is a metered metric. The controller can launch ten thousand jobs in an entitlement window and contribute zero to the managed node count, provided every one of those jobs targets a host already inside the existing inventory. The count is set at the far end of the connection, by the inventoried target system, not by the orchestration plane that dispatched the work.

The controller does require an underlying operating system. Where the controller runs on RHEL, the host carries a RHEL subscription. That subscription is a RHEL line on the order form, not an Ansible Automation Platform line. The distinction is structural rather than cosmetic. A buyer that adds a second controller for high availability adds a second RHEL host and, where the second host is colocated with operational data on a Satellite estate, perhaps a Smart Management add on. The buyer does not add a second Ansible Automation Platform tier. For the broader Ansible Automation Platform picture, see the Ansible Automation Platform practice hub; for the counting rule itself, see the managed node counting article.

The execution environment, introduced as a first class concept in Ansible Automation Platform 2.0, is the container image in which a job runs. It packages the Ansible runtime, the Python interpreter, the Ansible collections the job will load, and the system dependencies those collections require. It is built once, registered in the private automation hub or in an external container registry, and pulled by the execution node when a job needs to run inside it.2 The buyer can build many execution environments per controller. Different teams may use different images. Different playbooks may pin different versions.

The economic shape of the execution environment is the economic shape of a container image. It is storage at rest and compute at runtime. The storage sits on the registry that holds the image. The compute sits on the execution node, the RHEL host that pulls the image and runs the container. Neither line is an Ansible Automation Platform line. Both are RHEL lines, and on a Satellite estate the registry host may also carry a Smart Management add on. The Ansible Automation Platform agreement does not meter execution environments by image count, by registry size, or by image pull frequency. It meters the systems at the far end of the connections those images make.

This separation is sharper in 2026 than it was in earlier releases because the runtime fully decouples the controller from the executor in the default deployment path. A controller can dispatch to several execution nodes, those nodes can run on physically distinct hosts, the hosts can sit in different network zones, and the topology is invisible to the managed node count. The seller side that frames a topology decision as an Ansible Automation Platform purchase decision has misread the meter. The buyer side that pays for the topology as if it were the meter has accepted the misread.

The most expensive misreading at the renewal table is the assumption that an enlarged Ansible Automation Platform footprint requires an enlarged Ansible Automation Platform tier. A second controller for active passive high availability. A third execution node to absorb a busy quarter. A second private automation hub in a sister data centre. Each of these is a RHEL purchase and an operational decision. None of them is an Ansible Automation Platform purchase decision. The seller side that proposes them as bundled increments to the existing managed node tier has framed the conversation in a way that benefits the seller and that the buyer side should not accept on the framing alone.

There are three concrete consequences. The first is that high availability for the controller, conventionally a hot standby with a load balancer in front, can be modelled at the RHEL cost of the additional host rather than at any Ansible Automation Platform delta. The second is that scaling the executor across additional execution nodes, the modern path to horizontal scale for job throughput, requires additional RHEL hosts and not additional Ansible Automation Platform entitlement. The third is that the private automation hub, where the buyer chooses to host one rather than to pull execution environments from the public registry, is a single RHEL host and not a tier change.3

The same logic flips the other way at de scoping. A buyer that consolidates two controllers into one, retires a redundant execution node, or moves from a private automation hub to the upstream public hub does not reduce the Ansible Automation Platform tier on the order form. The tier is set by the managed node count. The infrastructure decisions move RHEL lines, not Ansible Automation Platform lines. Conflating the two on the way out leaves recoverable budget on the table; conflating them on the way in leaves recoverable budget on the order form.

The reconciliation discipline that surfaces this cleanly is the same discipline that surfaces drift in the managed node count. A two ledger reading separates RHEL hosts under Ansible orchestration from inventoried managed nodes under Ansible jobs. The first ledger sits with the RHEL subscription record. The second sits with the Ansible Automation Platform tier. They cross at the controller and at the execution node, but they do not stack. For the assessment engagement that produces both ledgers, see the subscription assessment hub.

Four topology decisions recur in renewal conversations as if they were Ansible Automation Platform purchase decisions. They are not. They are operational decisions that the buyer side should evaluate on their operational merits and price on their RHEL footprint, separately from the managed node tier.

The first is controller high availability. Active passive is the conventional choice in 2026. Active active is supported in some deployment topologies and complicates state in others. The right answer turns on recovery time objectives, on the cost of operational data loss in a controller failure, and on the engineering capacity of the team. None of those inputs is in the Ansible Automation Platform agreement. The capacity decision sits with the buyer; the entitlement remains the managed node tier.

The second is execution node scale out. Where the controller dispatches more jobs than a single execution node can absorb inside its scheduling window, the answer is more execution nodes. Each additional execution node is a RHEL host. The aggregate of execution nodes is invisible to the Ansible Automation Platform meter, which still reads the managed node count at the far end of the connections.

The third is private automation hub deployment. The hub is the internal mirror for certified content collections and for execution environment images. Buyers who want curated control over the supply chain stand one up; buyers who are comfortable pulling from the upstream Red Hat content do not. Either choice is a content supply chain decision, not an Ansible Automation Platform tier decision.

The fourth is execution environment proliferation. Different teams may want different images, pinned to different versions, with different collection sets. The proliferation is a build pipeline decision and a content governance decision. The number of distinct execution environments in the registry is not a metered metric.4

A renewal that proposes to expand the Ansible Automation Platform tier on the basis of controller or executor growth should be read closely before signature. The buyer side reading proceeds in four steps. First, list the proposed line items and tag each with the surface it actually sits on: RHEL host, container storage, managed node tier, or Lightspeed. Second, audit the existing managed node count against a reconciled inventory ledger and against the controller activity register. Third, separate the topology proposal from the metered metric so each can be priced on its own surface. Fourth, sign the Ansible Automation Platform line at the tier the managed node count supports, and treat the topology lines as RHEL decisions priced separately.5

Across recent practice engagements, this discipline has produced a recoverable correction band in the low to mid double digit percent of proposed Ansible Automation Platform increments where the increment was justified on controller or executor footprint and where the underlying managed node count had not grown to match. Where the managed node count had grown, the correction is smaller and the conversation moves to whether the growth is real, in the sense that it reflects production inventory, or whether it reflects ephemeral build pipeline activity that is recoverable through reshape.

The corollary is the audit defense reading. Where a Red Hat compliance inquiry has landed and the seller side finding cites controller scope or executor scope as a contributing factor, the buyer side response is to separate the surfaces before the response is filed. The finding that conflates RHEL infrastructure under orchestration with Ansible Automation Platform managed nodes is a finding that does not survive a clean two ledger reconciliation, and the practice closes against the reconciled position. For the engagement that does this work under a live inquiry, see audit defense; for the renewal posture engagement, see renewal negotiation; for direct contact, see the contact page.

The discipline is not novel. The discipline is the discipline that reads the meter on its own terms, not on the seller side's preferred framing. Ansible Automation Platform meters the managed node. The controller and the executor are how the meter gets read, not what the meter reads. A buyer that signs at the topology will pay at the topology. A buyer that signs at the meter will pay at the meter, and the meter is materially smaller than the topology in nearly every estate the practice has worked on.

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.