The private automation hub, licensed straight.

The Ansible private automation hub licensing question begins, as most Red Hat licensing questions do, by separating a service from the metered metric it appears to require. The hub is a local mirror of certified content collections, validated content bundles, and execution environment images, served to controllers and to operators inside the enterprise boundary. It is a service. It runs on a host. The host carries a RHEL subscription. The hub itself does not carry a separate Ansible Automation Platform line on the order form, and the managed node count on which the platform meters is unaffected by the presence or absence of one hub, two hubs, or a hub per region.1

This is the cleanest statement of the rule, and it is the one most frequently overwritten on the buyer side by a seller side preference for talking about hub as if it were a tiered product with its own entitlement count. It is not. The hub is included with Ansible Automation Platform 2.x agreements at all standard tiers, and the cost of operating it is the cost of the RHEL on the host or hosts that run it. Where high availability is required, the cost of the hub is the cost of the RHEL on three hosts. Where geographic redundancy is required, the cost is the cost of the RHEL on the additional regional hosts. Nothing on the Ansible Automation Platform line itself moves.

For the broader picture of how the platform meters and what the controller and the executor cost is, see the Ansible Automation Platform practice hub. For the benchmarking on which the host count assumptions in this article rest, see the benchmarking service hub. The hub is a RHEL cost wearing an Ansible question.

Four hub topologies recur across enterprise estates. Each carries a different RHEL cost. None of the four changes the Ansible Automation Platform line on the order form. The choice between them sits with infrastructure economics and operational resilience, not with platform licensing.

The first topology is the single hub. One host. One RHEL subscription. One synchronisation source upstream to Red Hat. Suitable for estates of fewer than one thousand managed nodes that operate in a single region and have no severe recovery time objective on the content layer. The hub is a single point of failure, and a hub outage interrupts new playbook runs that depend on freshly synced content. Existing controllers continue to operate against cached collections.

The second topology is the highly available trio. Three hub hosts behind a load balancer, shared object storage on the backend, three RHEL subscriptions. The hub layer survives the loss of one host and tolerates rolling maintenance windows on each. This is the default recommendation for estates between one thousand and ten thousand managed nodes and the default for any estate that runs change windows around the hub itself.2

The third topology is the regional federation. A primary hub in one region, secondary hubs in each additional region, each synchronising from the primary on a defined cadence. The cost is the RHEL on the additional hosts and the egress on the inter region synchronisation traffic. Latency on collection install drops substantially in non primary regions; the operational complexity rises with the number of synchronisation pairs.

The fourth topology is the edge cache. A read only mirror at an edge site that does not synchronise from upstream Red Hat directly but pulls from the regional hub on demand. Useful for telecom or retail estates with constrained connectivity at the edge. Cost is the RHEL at the edge and the storage to hold the cached content. The cache is not a hub in the formal sense and does not appear on the order form.

The hub itself is a stable RHEL cost. The cost that drifts is everything that accumulates around it. Three patterns produce most of the unexpected hub spend the practice observes between renewals.

The first pattern is storage growth on the hub backend. Execution environment images, particularly those packaged with large Python dependency trees or with embedded model artefacts, can grow beyond a hundred gigabytes per image. A hub that holds a dozen versions of each of twenty execution environments quickly carries terabytes of object storage. Where the backend is Red Hat OpenShift Data Foundation, the storage cost is metered separately and accumulates as the image catalogue grows. For the storage counting mechanics, see the storage and middleware reconciliation notes and the broader storage entitlement context.3

The second pattern is uncontrolled hub proliferation. Business units that operate Ansible independently sometimes stand up their own hub instances rather than negotiate access to a central hub maintained by another team. Each unauthorised hub is a RHEL host that the central license inventory does not see. Each is also an integration point with upstream Red Hat content that is sometimes configured outside the central content governance. The reconciliation here is operational rather than financial; the hub proliferation surfaces during the subscription assessment exercise and is rolled into the next renewal.

The third pattern is backup and snapshot growth. Hub content is large, deduplicates poorly across versions, and accumulates fast in backup storage. The backup footprint of the hub layer is often larger than the live footprint within eighteen months of standing up the service. Backup storage is rarely a Red Hat cost, but it is a hub cost and the buyer side reading should net it into the total cost of the hub layer rather than letting it accumulate in a separate budget line.

Three classes of content flow through the private automation hub. Each has a different licensing posture even though all three appear in the same hub web interface. Confusing them creates the order form errors that surface at renewal.

The first class is the certified content collection. These are the Red Hat tested and supported collections published through the certified content channel. Entitlement to certified collections is included with Ansible Automation Platform. The hub mirrors them locally. For the boundary between certified and community content, see the certified versus community collections note.

The second class is the validated content bundle. These are opinionated reference implementations for common automation domains, packaged with execution environments, playbooks, and roles. Validated content carries different licensing posture across release lines and across the standalone validated content subscription that some buyers carry; for the specifics, see the validated content licensing note.

The third class is the execution environment image. The runtime in which a playbook actually executes is a container image, built from a base, layered with collections and Python dependencies, and stored in the hub. Execution environments do not count as managed nodes, do not consume a separate platform entitlement, and do flow through the hub's image registry. The deeper mechanics live in the execution environments deep dive.

A fourth and increasingly relevant question is the relationship between the hub and any container image registry security tooling that the enterprise operates. Where Red Hat Advanced Cluster Security is scanning images pulled from the hub or pushed into it, the scanning entitlement is independent from the hub and is governed by its own pricing surface; see the Advanced Cluster Security pricing note for the bridge between Ansible image content and the broader container security posture.

At renewal, the seller side question on the hub is almost never whether the hub is correctly licensed; the hub is included and the RHEL on the host is a separate ledger. The question that does arrive at renewal is whether the buyer is willing to migrate the hub from a self managed footprint onto Red Hat's hosted equivalent, the Ansible Automation Platform on Red Hat Cloud Services offering, or onto a public cloud marketplace variant. For the marketplace economics specifically, see the Ansible on public cloud marketplace note.

The buyer side reading is that the hosted offering changes the cost from a RHEL line into a platform line, and the platform line at the hosted tier is materially higher than the self managed equivalent at most enterprise scales. The hosted offering is the right answer for estates without the operational capacity to run the hub layer themselves, and the wrong answer for estates that already operate Satellite, OpenShift, or any other Red Hat infrastructure at scale. Migrating a hub to hosted to save operational effort is a real benefit; selling it as a license simplification is a category error.

The second renewal question is whether to consolidate multiple hubs that have proliferated during the prior term. The consolidation reduces the RHEL footprint and the storage footprint at the cost of one short integration project. The consolidation does not change the Ansible Automation Platform line. Where the order form does change is the hub host count moving from, for example, six hosts down to three; the RHEL detail on those hosts shifts. The Ansible managed node count does not.

The third renewal question is whether the validated content subscription is on the order form, has been on the order form, or will be added. This is a distinct line from the platform itself and is sometimes bundled as a promotional add and then quietly priced into the next renewal. The cleanest moment to remove or to add this line is at the renewal table, with the prior usage data in hand.

Where the renewal sits inside the next ninety days and the hub layer is a meaningful part of the spend, the buyer side reading is to run the hub reconciliation alongside the managed node reconciliation, surface the proliferation, and present the consolidation as a credible alternative to renewing the prior hub footprint as is. Where the renewal is more than six months out, the equivalent posture is to engage the advisory desk on a retainer basis through the planning window. For the broader advisory pattern, see the advisory retainer hub.

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.