Which to choose: AAP or AWX for your Ansible estate
Choose Ansible Automation Platform if your organization needs a vendor-backed support commitment for its Ansible control plane, and choose AWX if your team can own that support itself. The decision usually surfaces at a renewal, when an auditor or internal risk owner asks who fixes a defect in the controller, or when someone proposes self-hosting the control plane to cut subscription spend. AAP fits organizations that must show a support window to their own assurance functions. Red Hat states that AAP adds at least 18 months of enterprise support per release, certified content collections, and integrated tooling such as Event-Driven Ansible and a private automation hub. If your playbooks depend on certified collections, or you want event-driven triggers and a managed content hub rather than building those yourself, AAP is the simpler path.
AWX fits teams that tolerate community support, already run Kubernetes and can operate the AWX Operator, and want the same web interface, REST API and task engine without a subscription. It is also a sound choice for labs, sandboxes and internal tooling where an outage is an inconvenience rather than a compliance finding. Before committing, confirm three things. First, whether your organization can carry support and patching for a project that Red Hat does not support commercially. Second, the release cadence: the AWX repository states that releases are paused during a large-scale refactoring, and the latest release on the releases page is 24.6.1, from July 2, 2024. Third, which certified collections your playbooks import, and whether you can replace or vendor them yourself.
Use those three answers as a test rather than a preference. If the support owner, the release gap and the content dependencies all point to your team, AWX is viable and the cost moves from subscriptions to people and infrastructure. If any one of them requires a supported release or certified content on a fixed date, AAP is the safer default for that estate. Ask Red Hat for the current support dates and entitlements in writing, and ask your own platform team to name who would patch an AWX deployment within your change window. Those two written answers will settle most of the decision.
Which scenarios favor AAP and which favor AWX
This table maps common operating scenarios to the platform that fits better, with the reason tied to AWX's paused releases and the support window AAP adds. Read each row against your own constraints: if a scenario depends on paid support or certified content, AAP is the stronger choice, while AWX suits teams that can own upgrades and testing themselves.
| Scenario | Better fit | Reason |
|---|---|---|
| Regulated production with a support contract | AAP | Red Hat hardens selected releases and supports them for at least 18 months, while Red Hat provides no paid support for AWX. |
| Development and test environments | AWX | Low risk if an upgrade breaks, and the community release stream is free to use, though the install guide recommends the Operator over Docker. |
| Air-gapped estate needing a private hub | AAP | Private automation hub is part of AAP, so content can be mirrored internally; AWX has no equivalent bundled hub. |
| Teams relying on Red Hat certified collections | AAP | Certified content collections ship with AAP; AWX users must source and validate community collections themselves. |
| Strong Kubernetes operations team | AWX | Teams that already run the AWX Operator can own upgrades, but must accept that releases are paused, so plan for patching the gap. |
| Need for Event-Driven Ansible | AAP | Event-driven automation is bundled with AAP; AWX does not include it, so confirm any custom event integration before committing. |
| Long-term stability with no upgrade planning | AAP | An 18-month support window per release reduces forced upgrades, while AWX's pause means no new release has been published since 24.6.1. |
What the AWX Operator install asks of your team
Since version 18.0, the AWX Operator is the preferred way to install AWX, and it runs on Kubernetes. Running AWX in Docker is only recommended for development and test deployments, and it has no official published release, so a production instance means a cluster your team can operate. The operator manages the AWX components as Kubernetes resources, which means your team needs working knowledge of the cluster before the first job runs.
- Cluster ownership: Confirm who provisions, patches and upgrades the Kubernetes cluster, and whether that group already runs production workloads.
- Operator lifecycle: Plan how the AWX Operator itself is installed, pinned and upgraded, separately from the AWX instance it manages.
- Storage classes: Confirm the persistent volumes that the database and project data need, and who supports them.
- Network paths: Map the connections AWX needs to inventories, source control, credential stores and the managed hosts.
- Capacity: Size the nodes for controller, execution and database workloads with your own job volume, since the install guide does not give a sizing for your environment.
Before committing, ask a platform engineer to run the install in a non-production cluster and record every manual step.
Security reviewers need to see how the deployment handles identity, secrets and network exposure, because AWX holds credentials for every system it automates. The operator-based install puts those controls in Kubernetes objects, secrets and ingress settings, so the review sits in the cluster configuration as much as in AWX itself. Community-only support also means your team, not a vendor, owns the response when a flaw is disclosed.
- Secret handling: Review where the database credentials, the secret key and machine credentials are stored and who can read the Kubernetes secrets.
- Authentication: Confirm how users sign in and how role-based access is mapped to organizations, teams and job templates.
- Exposure: Check the ingress, TLS termination and which networks can reach the web interface and API.
- Vulnerability intake: Define how your team tracks upstream fixes, since AWX releases are paused and no paid support is available.
- Audit trail: Confirm which job, login and configuration events are logged, where they go, and how long they are kept.
Ask the implementation partner for a written list of these controls mapped to your own policy, and have your assessor review that list before the first production run.
Operators carry the work after go-live: backups, restores and upgrades. Because AWX releases are paused during a large refactoring and the latest release on the releases page is 24.6.1 from July 2, 2024, upgrade planning depends on what your team chooses to pin, test and adopt. The operator and the AWX instance have their own versions, and each change needs a rehearsal in a copy of the cluster.
- Backups: Back up the AWX database and the secret key together, and test a full restore into a separate namespace.
- Upgrade rehearsal: Run each operator and AWX change in a staging cluster with a copy of the data before production.
- Runbooks: Write steps for restarting components, rotating credentials and recovering a failed node.
- Monitoring: Alert on failed jobs, full volumes and unavailable pods, using the cluster tooling your team already runs.
- Ownership calendar: Assign who watches upstream changes and who approves each upgrade.
Before go-live, ask for a documented restore test and a dated upgrade runbook, so the first upgrade is not the first time the procedure is tried.
Teams moving from automation controller often assume the effort lies in carrying over playbooks and job templates. Those playbooks run the same way on AWX, so the migration effort is mostly in the platform underneath. The work sits in the cluster, storage, backups and upgrades, and it recurs for as long as AWX runs in your environment.
- Playbooks: Existing Ansible content generally runs unchanged, so review collection dependencies rather than rewriting tasks.
- Platform work: Cluster, storage, networking and backup tasks take the larger share of the effort and continue after launch.
- Content supply: Replacing certified collections and private automation hub content requires a sourcing decision that the install does not solve.
- Recurring cost: Staff time for patching, monitoring and upgrades is an ongoing cost, not a one-time setup fee.
- Skills: Confirm your team can debug Kubernetes failures, since a playbook error and a cluster error look different in logs.
Ask your team to estimate the platform hours separately from the playbook migration hours, because the two are priced and staffed differently.
Where your automation data lives under each option
Inventories, credentials, job logs and the controls around them move with the platform you choose. The cards below cover where that data sits, how each option is hosted and integrated with identity, who patches it, and what evidence a compliance review will ask for. Confirm each point against the exact release and subscription you plan to run.
Inventories, credentials and job logs
Both automation controller and AWX store inventories, credentials and job output in their own database, so the data stays in the environment where you deploy it. The question is what you hold in that database: secret values, host lists and job output can all contain sensitive detail. Confirm how each option encrypts stored credentials, where job logs are retained, and how you purge them. Check whether your backup copies follow the same rules.
Self-hosted Kubernetes for both
AWX is installed on Kubernetes through the AWX Operator, which Red Hat's install guidance for AWX names as the preferred method since version 18.0. Automation controller is also run on infrastructure you control, so the cluster, its storage class and its network policies become part of your evidence. Docker is only recommended for development and test, so treat it as out of scope for production records.
Identity integration
Whether a user signs in through a directory, an SSO provider or a local account decides who can launch jobs against production hosts. Check which authentication backends each option supports in your target version, and how role-based access maps to your existing groups. Record who can change credentials, because that change is often the most sensitive event in the platform.
Support and patch responsibility
Red Hat takes selected AWX releases and hardens them for long-term supportability inside Ansible Automation Platform, and states that AWX is community supported with no paid support from Red Hat. With AWX, your team owns vulnerability tracking, upgrades and the Operator and Kubernetes patch cycle. Ask whether your security policy accepts unsupported upstream components before you commit.
Evidence for compliance reviews
Auditors will ask for records of who ran which job, against which inventory, with which credential, and when the change was approved. Under AWX you must produce that evidence from job history, exported logs and your own change tickets. DeployOpen prepares the controls and evidence for a compliance assessment, but does not issue audit reports or certifications. Independent auditors and certification bodies make that determination.
How the paused AWX releases change the risk
The AWX repository states that releases are paused during a large scale refactoring, and the most recent release on the releases page is AWX 24.6.1, published on July 2, 2024. For a team deciding whether AWX can carry production automation, the practical consequence is that you cannot count on a new tagged build arriving to fix a security issue, a bug or a dependency problem. Any AWX deployment you adopt today is, in effect, frozen at a known release unless you take responsibility for building and patching it yourself. We do not know when releases will resume, and you should not plan around a date that no one has published.
Security patches are the first gap to plan for. Red Hat's FAQ states that it takes selected AWX releases and hardens them as part of Ansible Automation Platform, and that it provides no paid support for AWX itself. Because Red Hat does not ship AWX patches under a support contract, a vulnerability in the controller, the web interface or the operator would be fixed upstream only if the community acts on it. Ask your security team to map AWX, its operator, the container images it pulls and the PostgreSQL instance it depends on into your vulnerability management process, and decide who will apply and test any fix that has no upstream release.
Ansible core compatibility and dependency updates are the second gap. A frozen AWX release pins its execution environment, its Python dependencies and the Ansible versions it was tested against, so newer collections, modules or Ansible core releases may drift out of step with it. Confirm in the repository which Ansible core and execution environment versions the 24.6.1 release targets, and test your own playbooks and collections against them before committing. Also confirm whether the devel branch receives dependency changes in the meantime, because that branch is the only place you would find fixes that have not been tagged.
What moving from AAP to AWX involves at a high level
The sequence turns a supported controller estate into an AWX deployment that runs the same automation, with each object, collection and dependency accounted for before production cutover. Scope and timelines are agreed in writing before work starts.
Inventory controller objects and content dependencies
Someone on the platform team lists every job template, inventory, credential, schedule, workflow and RBAC grant in automation controller, then maps which playbooks depend on certified collections or private automation hub content. The output is a written inventory with each item tagged as portable, needs rework or needs a replacement source. Done when every production job template has an owner and a dependency entry.
Confirm AWX release and support position
Before any build, the team checks the current AWX release state on the project's GitHub releases page, since releases have been paused during a large refactoring, and records the decision on who supports AWX after go-live. Red Hat does not provide paid support for AWX, so the internal or partner support model must be named in writing. Done when the risk acceptance and support owner are signed off.
Stand up AWX with the Operator in a test cluster
The platform team installs the AWX Operator on a non-production Kubernetes cluster, since the install guide recommends the Operator over Docker for anything beyond development and test, and connects AWX to a test database, execution environments and a source for the playbook repositories. Sizing and cluster prerequisites should be confirmed against the current install documentation. Done when a sample playbook runs successfully from a test job template.
Export and re-create objects with the awx CLI
Using the awx command-line client, which talks to the AWX HTTP API, the team exports controller definitions where the export format allows, then recreates organizations, teams, inventories, credentials and job templates in AWX. Secrets are re-entered from the organization's vault, not copied from exports. Done when a diff of object counts and names matches the inventory from the first step, with exceptions documented.
Replace certified content and private hub dependencies
Collections that came from certified content or automation hub are sourced from a replacement, such as community collections or an internal Git-based mirror that the team vets and pins. Each replacement is tested against the playbooks that used it, and any module behavior changes are logged. Done when every job template runs against pinned sources and the dependency inventory has no open items.
Run both platforms in parallel
Selected non-critical jobs run on AWX and the same jobs on automation controller, and the team compares results, host changes, timing and failure output. Schedules remain on controller until the comparison is accepted. Done when parity results for each job category are recorded and approved by the service owners.
Cut over and decommission controller
The team moves schedules, webhooks and access grants to AWX in a planned change window, updates runbooks and notification targets, and keeps controller in read-only mode for a rollback period agreed in writing. Once the rollback window closes and AWX backups are verified, the subscription renewal is handled with procurement. Done when all production jobs run from AWX and the cutover record is signed by the platform and security owners.
Questions buyers ask before choosing AWX over AAP
How much does AWX cost to run compared with Ansible Automation Platform?
AWX has no license fee, so the cost is what you spend to run it: Kubernetes capacity, storage for the PostgreSQL database, backups, monitoring, and the engineering time to install, upgrade and patch it. AAP adds a recurring subscription that Red Hat quotes per support tier, so your comparison should put that quote next to your own run costs. The main cost drivers for AWX are the size of your cluster, how many jobs run in parallel, how many hosts you manage, and how much of your team's time goes to upkeep. Ask Red Hat for a written subscription quote for your node count and support level, and ask your own platform team to estimate hosting and staff time before you compare totals.
How long does it take to migrate from AAP to AWX?
The timeline depends mostly on how many objects you have and how much your automation depends on certified collections and automation hub. Job templates, inventories, credentials, schedules and RBAC rules can be exported and re-imported with the awx CLI, but each credential and survey needs checking by hand. Teams that use only community collections usually have a shorter path than teams that pull certified content from private automation hub, because those collections must be replaced with community or self-built sources. Confirm the object count, the collections in use and the cutover approach in a written scope before you plan dates, and treat any duration you hear before that as a guess.
Can our team run AWX without outside help?
Yes, if your team already runs Kubernetes and has working Ansible skills, though the answer depends on those two areas more than on AWX itself. The AWX Operator is the preferred install method, so someone must understand Kubernetes namespaces, persistent volumes, ingress, secrets and upgrades. Someone also needs to own the database, the credential store and the playbook repositories, and to diagnose failed jobs. Because AWX releases are paused during a large refactor and Red Hat provides no paid support for it, your team will also handle security fixes and version decisions alone. Assess these skills honestly before committing, and consider a fixed-scope engagement for the first install and hardening if the gaps are large.
Does AWX come with paid support from Red Hat?
No. Red Hat's Ansible collaborative FAQ states that AWX is supported by the community and that Red Hat does not provide any paid support for it. Red Hat takes selected AWX releases, hardens them for long-term supportability and ships them as part of Ansible Automation Platform, which is where its enterprise support sits. Red Hat also states that AAP adds at least 18 months of enterprise support per release. If your organization needs a vendor to answer for production incidents, you need either an AAP subscription or a contract with a third party, so confirm that requirement with your risk and procurement teams before the decision.
What do we need to provide during an AWX engagement?
The work moves faster when your side provides a few things early. You need named owners for the AWX instance, the Kubernetes cluster, the credential vault, the inventory sources and each job template's business owner. You also need access to the current AAP environment with read permissions for exports, network paths from the cluster to managed hosts, and a change window agreed with operations. Security teams should confirm how credentials, SSH keys and vault passwords will be stored and rotated. Ask for these items to be listed in the written scope so that responsibilities and handover points are clear before work starts.
Will AWX still work with newer Ansible content and collections?
Usually, but you must confirm it against your own collections and Ansible version. AWX is the upstream of automation controller, so the two share most of the same engine, job templates and collection handling, but AWX is not a version-locked copy of AAP. Newer collections may require a newer execution environment, and AWX releases have been paused since 24.6.1, which means the most recent fixes may not be in the release you install. Build a test project that runs your heaviest playbooks against the target AWX version, record any module or collection failures, and decide whether you need to pin versions or rebuild the execution environment before cutover.
Which AAP features do we lose when we move to AWX?
The main losses are the enterprise packaging and the integrated products around the controller. AAP provides certified content collections, Event-Driven Ansible for responding to events, and a private automation hub for hosting and governing collections, all of which Red Hat describes as additions on top of the community projects. Some teams also rely on Red Hat's support lifecycle and its hardened release cadence. In AWX you would replace these with community collections, your own collection repository, and a separate event tool if you need one. List every AAP feature you use today, mark which ones have a community equivalent, and confirm the gaps with your security and operations leads.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source automation platforms inside your own infrastructure, so the choice between Ansible Automation Platform and AWX rests on your requirements and your support model. Engagements start with a written scope, and the decision and the build follow from that scope.
How we scope
- We confirm which automation controller features your job templates, RBAC and schedules depend on before comparing options.
- We list the certified collections, private hub content and event-driven workflows you use today, and which of them you must replace.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy AWX in your own cluster using the AWX Operator, matching the install path the AWX project recommends.
- We document the Kubernetes, storage, database and network settings your AWX instance needs in your environment.
- We test imported inventories, credentials and job templates against a staging instance before any cutover.
How we hand over
- You receive architecture notes, runbooks, backup and restore procedures and an access model for your teams.
- We walk your operators through upgrades, credential rotation and job troubleshooting on your own instance.
- We record which collections are community-maintained, so your team knows what it owns after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Because AWX has no paid support from Red Hat, a retainer can cover patching and fixes that your own team will not handle.
- We can review release notes and plan upgrades when AWX publishes new versions, so your team is not guessing about timing.
