AAP vs AWX: when to choose each one

AWX is the community project that Ansible Automation Platform (AAP) builds on. AAP is Red Hat's product, with a subscription, support and a published lifecycle. If you need someone to answer for the platform and support dates you can plan around, choose AAP. If your team can maintain the service on its own and accepts that there is no vendor behind it, AWX may be enough. The decision is about who carries the risk, not about features.

What each one is

The AWX README describes it as "one of the upstream projects" of Ansible Automation Platform: it provides the interface, the API and the task engine for automating with Ansible. AAP adds a commercial support model and a broader enterprise platform. The same README warns that the repository's latest release was published on 2 July 2024 and that releases are paused during a large-scale refactor (accessed on 9 October 2026). Before adopting AWX, check in the repository whether that status has changed.

The numbering does not match either: when people talk about moving from 2.4 to 2.6, they mean AAP, not an equivalent AWX upgrade.

Comparison

Sources for the table: the AAP lifecycle page, the Red Hat article on what the subscription includes and the AWX README.

What each AAP phase covers

According to Red Hat's lifecycle page, Full Support includes critical, important and moderate security fixes, plus bug fix errata. Maintenance Support 1 keeps the critical and important ones, and only critical bugs. Maintenance Support 2 has only critical security fixes. There is also an optional extended support with qualified critical security fixes. Those phases are what you do not have with AWX.

When AWX may be enough

• It is a lab, a test environment or an internal use where an outage does not hurt.
• You have people who know how to run and upgrade the platform and accept that work.
• You do not need support dates from a vendor.

An example: I would recommend AWX to a university lab that runs reproducible, non-critical automation. If the team already manages Kubernetes, can diagnose its own problems and tolerates interruptions, AWX gives it centralised scheduling and execution without the AAP subscription. Even so, its repository says releases are paused during a refactor, so I would only recommend it where that maintenance uncertainty is explicitly accepted.

When to choose AAP

• Your team needs a vendor to go to when something fails.
• An audit or a customer asks you for supported versions and known dates.
• The automation touches critical systems and you cannot depend on a project whose releases are paused.
• You already hold Red Hat subscriptions and the marginal cost is acceptable.

An example: I would recommend AAP to a bank that automates production patching and network changes. Escalation to the vendor, supported upgrade procedures and certified automation content justify the subscription when an outage affects customers. Coverage depends on the tier you buy: Standard is 8x5 and Premium is 24x7, according to the Red Hat article on the subscription.

How to measure the operating effort

No licence does not mean no cost, and the effort of running each platform is better measured than assumed. Run comparable workloads for 90 days and note the versions, infrastructure, job volume and team experience. For each platform, record:

• Administration hours per month: maintenance, backups, certificates, troubleshooting and upgrades.
• Platform incidents per month, classified by severity.
• Recovery time and minutes during which automation was unavailable.
• Platform-caused failures per 1,000 jobs, separated from playbook errors.
• Restore tests passed and hours spent on support cases.

Include the Kubernetes maintenance that comes with AWX and the equivalent infrastructure work in AAP. Support can shorten diagnosis, but it does not remove administration. The documentation reviewed sets no universal figure for hours per month, so compare the subscription, the infrastructure, the team's work and the cost of outages together.

If you upgrade AAP from 2.4 to 2.6

According to the AAP 2.6 upgrade guide, you first need to be on the latest 2.4 release. Red Hat supports a direct upgrade for RPM deployments on RHEL 9 and on OpenShift. An RPM installation on RHEL 8 first has to be backed up and restored onto new RHEL 9 hosts, because upgrading the operating system to a new major version on the same host is not supported. Upgrading from the containerised 2.4 deployment that was released as a Technology Preview is not supported either.

For an RPM deployment that meets the requirements, the flow documented in the upgrade procedure is, in broad terms: a backup with the existing installer (./setup.sh with the -b option) and then ./setup.sh from the 2.6 installer with its inventory configured, including the platform gateway requirements. This illustrates the process; it is not a complete procedure.

One documented failure affects SAML authentication: encrypted private keys prevent the authenticators from being migrated, so they must be replaced following Red Hat's guide before upgrading. Measure preparation, backup, installation, validation, downtime and recovery separately. As a reference, the upgrade guide states that migrating 4,000 users, 400 teams and 40 organisations can take about two hours; it is an example, not an estimate for the full upgrade.

Upgrading pays off when the support requirements, the fixes or the features you need outweigh the cost of a tested migration. Moving from RPM to containers also prepares you for later versions: according to the same guide, 2.6 is the last version for RPM installations. Rehearse first, prove that the restore works, and validate authentication, permissions, integrations and representative jobs before the production change.

If you want an inventory of versions, support dates and risks in your environment, the RHEL and AAP lifecycle review covers exactly that.