Concurrent and named Ansible entitlements, read at renewal.

A concurrent Ansible entitlement counts the seats that are actively in use on the platform at a measured moment, with the entitlement count set at the peak concurrent user count or at a defined percentile across a measurement window. A named Ansible entitlement counts every individual who has been provisioned with platform access, regardless of whether the individual is active in any given measurement window. The two models exist because they fit different deployment shapes and different access patterns, and the contract that carries one of the two models on a deployment that fits the other model is the contract that produces the renewal overpayment1.

The concurrent model fits estates where a broad user base accesses the platform intermittently. A team of two hundred engineers across infrastructure, security, and operations, where any given day sees perhaps thirty to fifty engineers active on the platform, fits the concurrent model cleanly. The peak concurrent count is materially lower than the provisioned user count, and the concurrent entitlement prices the smaller number.

The named model fits estates where each provisioned user is materially active on the platform. A team of forty platform engineers, where each engineer is on the platform daily, fits the named model. The peak concurrent count and the provisioned user count are close to each other, and the named entitlement avoids the overhead of measuring concurrency.

The counting mechanics on the two models are different in three respects, and each respect is a renewal lever. The first respect is the measurement window. Concurrent entitlements measure across a defined window, frequently a calendar quarter or a calendar year, with the entitlement set at the peak observed count or at a high percentile of the distribution. Named entitlements have no measurement window; the count is the count of provisioned users at the renewal snapshot date, full stop. The measurement window on concurrent entitlements is a negotiable line, and the percentile cutoff is a negotiable line. Both are frequently set to vendor preferred defaults that the buyer can change at renewal2.

The second respect is the deactivation policy. Named entitlements count every provisioned user, including users who have left the organisation, users who have transferred to teams that no longer use the platform, and users who were provisioned for a one off project and never offboarded. A clean deactivation policy reduces the named count materially on most estates. The practice has observed deactivation hygiene exercises produce reductions of fifteen to thirty percent on the named count on accounts that had not run the exercise in the prior renewal cycle.

The third respect is the role separation. Both models price by role on most current Red Hat contract templates, with administrative roles, operator roles, and read only roles carrying different unit rates. A user provisioned with administrative access counts at the administrative rate even if the user actually uses the platform only at the operator or read only level. The role assignment is recoverable at renewal through a clean access audit, and the role reread frequently produces a per role count distribution that prices materially differently from the existing distribution.

The two access models are not interchangeable accounting units for the same scope. They fit different deployment shapes, and the buyer who picks the model that fits the deployment produces a materially lower renewal cost than the buyer who carries the inherited model from a prior agreement. The pick is a buyer side decision before it is a vendor side decision, and the field team's preference for one model over the other is rarely aligned with the buyer's deployment shape3.

Three deployment shapes fit the concurrent model. The first is the broad user base with intermittent access, where the peak concurrent count is materially below the provisioned user count. The second is the seasonal estate, where concurrency spikes around specific calendar events and the named count would force the buyer to license for the peak period across the whole year. The third is the regulated industry account where access provisioning is rigid and rarely deprovisioned, but actual usage is concentrated on a small subset of provisioned users.

Three deployment shapes fit the named model. The first is the focused platform team where each provisioned user is materially active. The second is the estate where access provisioning is closely controlled, with cleanup running on a regular cadence, and the provisioned user count is consistently close to the active user count. The third is the multi tenant estate where measurement of concurrency across tenant boundaries is technically difficult and named counting avoids the measurement overhead.

The model that fits is the model that produces the smaller count on the same deployment, with the smaller unit rate weighted in. A buyer who is on the wrong model can frequently switch at renewal, with the new model written into the order form and the old model retired. The switch is a renewal lever rather than a contract architecture change, and the field team has accepted the switch on signed renewals in the trailing twelve months where the buyer has presented the deployment data that supports the change.

The Ansible entitlement reread runs in four steps that the buyer can complete without vendor cooperation. The first step is the deactivation audit on the named count, pulling users who have left the organisation, transferred to teams off the platform, or were never offboarded from one off project access. The audit produces a cleaned named count that is the floor of the legitimate named entitlement on the renewal.

The second step is the concurrency measurement across a defined window, using the platform's own usage telemetry. The measurement produces a peak concurrent count and a distribution of concurrent counts across the window, with the percentile cutoff at the seventy fifth, ninetieth, or ninety fifth percentile depending on the noise level in the distribution and the buyer's risk tolerance on usage spikes4.

The third step is the role audit, which categorises each user by the role actually exercised on the platform rather than by the role provisioned at the access record. The role audit frequently moves a meaningful fraction of administrative role users to the operator or read only role, with the corresponding unit rate adjustment on the renewal.

The fourth step is the model comparison on the cleaned numbers. The cleaned named count multiplied by the per role named rate is compared against the cleaned concurrent count multiplied by the per role concurrent rate. The model that produces the smaller renewal total is the model to request in the next contract, with the supporting deployment data documented and the model switch written into the order form. The reading sits inside the broader managed nodes versus executors read for the platform's wider pricing axes, and connects to the Ansible Automation Platform practice hub for the broader product context.

A defended posture on the Ansible user and access entitlement at renewal carries four lines. Each is independent of the others, and each has produced a measurable reduction on signed Ansible renewals in the practice's observation across the trailing twelve months. None requires the buyer to give up any access capability that the deployment requires.

First, the deactivation audit on the named count is run before the renewal opens. A clean named count is the precondition for any further conversation about the model that fits. The audit is a recurring exercise rather than a one off, and the buyer who runs it on a fixed cadence between renewal cycles avoids the bloat that the once a renewal cycle audit cannot fully reverse.

Second, the concurrency measurement is run across a defined window before the renewal opens. The peak concurrent count and the percentile distribution are documented, and the percentile cutoff is selected before the vendor opens the renewal frame. A percentile cutoff selected after the vendor has framed the renewal is harder to negotiate than a cutoff selected before.

Third, the model comparison is documented and the model switch, if the comparison supports one, is requested explicitly in the opening renewal terms. The field team will accept the switch where the buyer has supplied the deployment data; the switch will not be offered if the buyer has not requested it.

Fourth, the user and access entitlement is read against the broader renewal negotiation posture and the pricing axes documented in the wider Ansible practice. The user and access line is one of three pricing axes on a typical Ansible renewal, alongside the managed node axis and the executor axis, and the three axes interact in ways that a single axis reread cannot capture5. The opening contact for an Ansible renewal in progress sits at contact.

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.