Ansible Automation Platform 2.6 Architecture and Components: Complete Guide

What Is Ansible Automation Platform 2.6?

Ansible Automation Platform (AAP) 2.6 is Red Hat's enterprise automation solution that packages multiple components into a unified platform for managing automation at scale. Unlike standalone Ansible (the open source CLI tool), AAP provides a complete control plane with role-based access control (RBAC), a centralized UI, event-driven automation, content management, and distributed execution.

AAP 2.6 introduces significant architectural improvements over previous versions, with the Platform Gateway serving as the single entry point and the shift toward a fully containerized deployment model.

This guide covers every core component, how they interact, and practical configuration examples.

See also: Containerized Ansible Automation Platform 2024 Update

AAP 2.6 Architecture Overview

AAP 2.6 follows a service-oriented architecture where each component handles a specific automation concern:

┌─────────────────────────────────────────────────────┐
│                  Platform Gateway                    │
│          (Single Entry Point + Auth + UI)            │
├──────────┬──────────┬──────────┬────────────────────┤
│Automation│Automation│  EDA     │   Automation       │
│Controller│   Hub    │Controller│     Mesh           │
├──────────┴──────────┴──────────┴────────────────────┤
│            Execution Environments (EEs)              │
├─────────────────────────────────────────────────────┤
│                   PostgreSQL                         │
└─────────────────────────────────────────────────────┘

Data flow:

1. Users authenticate through Platform Gateway
2. Platform Gateway routes requests to the appropriate service
3. Automation Controller orchestrates job execution
4. Jobs run inside Execution Environments on Automation Mesh nodes
5. Collections and EE images are sourced from Automation Hub
6. EDA Controller listens for events and triggers automation
7. All services store state in PostgreSQL

Platform Gateway

The Platform Gateway is the most important architectural change in AAP 2.6. It provides:

• Single entry point into the entire platform
• Unified authentication and authorization across all services
• Platform UI — the main web interface users interact with
• Service routing — fronts access to Controller, Hub, and EDA

Why Platform Gateway Matters

Before Platform Gateway, each AAP component had its own URL, login, and user management. Platform Gateway eliminates this fragmentation:

# Platform Gateway configuration in AAP installer inventory
[automationgateway]
gateway.example.com

# Gateway settings
automationgateway_pg_host=db.example.com
automationgateway_pg_database=gateway
automationgateway_pg_username=gateway
automationgateway_pg_password='{{ vault_gw_pg_password }}'

# SSO configuration through Gateway
automationgateway_main_url=https://gateway.example.com
automationgateway_ssl_cert=/path/to/ssl/cert.pem
automationgateway_ssl_key=/path/to/ssl/key.pem

Key Platform Gateway Features

Automation Controller

Automation Controller (formerly Ansible Tower / AWX upstream) is the traditional control plane for running Ansible automation. It handles:

• Inventories — define and manage target hosts
• Credentials — securely store authentication secrets
• Job Templates — reusable automation job definitions
• Workflows — multi-step automation pipelines
• RBAC — fine-grained role-based access control
• Scheduling — cron-like job scheduling
• Job execution orchestration — dispatch jobs to execution nodes

Example: Job Template via Automation Controller API

# Create a job template using the ansible.platform collection
- name: Create patching job template
  ansible.platform.job_template:
    controller_host: "{{ gateway_url }}"
    controller_username: "{{ controller_user }}"
    controller_password: "{{ controller_pass }}"
    name: "Linux Patching - Production"
    organization: "Operations"
    project: "infrastructure-playbooks"
    playbook: "patch-linux.yml"
    inventory: "Production Servers"
    credentials:
      - "SSH Key - Production"
      - "Vault - Production Secrets"
    execution_environment: "ee-supported-rhel9"
    ask_limit_on_launch: true
    survey_enabled: true
    state: present

Automation Controller vs AWX

Automation Hub and Private Automation Hub

Automation Hub provides the content layer for AAP:

• Certified Collections — Red Hat tested and supported Ansible content
• Private Collections — internally developed automation content
• Execution Environment images — container images for job execution
• Content signing — GPG signature verification for collections

Private Automation Hub

Private Automation Hub (also called HA Automation Hub when deployed with high availability) lets organizations:

• Host internal collections behind the firewall
• Mirror certified collections for air-gapped environments
• Serve custom execution environment images
• Enforce content approval workflows

# Configure ansible.cfg to use Private Automation Hub
[galaxy]
server_list = private_hub, certified_hub

[galaxy_server.private_hub]
url=https://hub.example.com/api/galaxy/content/internal/
token={{ hub_token }}

[galaxy_server.certified_hub]
url=https://hub.example.com/api/galaxy/content/rh-certified/
token={{ hub_token }}

Syncing Collections from Ansible Galaxy

# Sync community collections to Private Hub
- name: Configure community remote
  ansible.platform.collection_remote:
    hub_host: "{{ gateway_url }}"
    hub_username: "{{ hub_user }}"
    hub_password: "{{ hub_pass }}"
    name: "community"
    url: "https://galaxy.ansible.com/api/"
    requirements:
      - name: community.general
      - name: community.crypto
      - name: community.postgresql
    state: present

Event-Driven Ansible (EDA) Controller

EDA Controller adds event-driven automation to the platform. It:

• Connects to event sources (webhooks, message queues, log streams, monitoring tools)
• Evaluates rulebooks — YAML-defined event-condition-action logic
• Triggers actions — run playbooks, call APIs, send notifications

EDA Rulebook Example

---
- name: Respond to ServiceNow incidents
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000

  rules:
    - name: Auto-remediate disk full alert
      condition: event.payload.priority == "P1" and "disk" in event.payload.description
      action:
        run_job_template:
          name: "Disk Cleanup - Emergency"
          organization: "Operations"
          job_args:
            extra_vars:
              target_host: "{{ event.payload.host }}"
              threshold: 90

    - name: Log low-priority events
      condition: event.payload.priority == "P4"
      action:
        debug:
          msg: "Low priority event: {{ event.payload.description }}"

EDA Event Sources

EDA supports multiple event source plugins:

Automation Mesh

Automation Mesh separates control capacity from execution capacity, enabling distributed automation across networks, sites, and security zones.

Key Automation Mesh Concepts

• Control nodes — run the Controller services, manage job scheduling
• Execution nodes — run the actual Ansible playbooks inside EEs
• Hop nodes — relay traffic between control and execution nodes without running jobs
• Peer-to-peer mesh routing — nodes communicate directly, with hop nodes bridging network boundaries

Mesh Topology Example

┌─────────────┐
│  Control     │
│  Plane       │
│  (Data       │
│   Center)    │
└──────┬───────┘
       │
  ┌────┴────┐
  │ Hop     │         ← DMZ / Firewall boundary
  │ Node    │
  └────┬────┘
       │
  ┌────┴──────────────┐
  │                    │
┌─┴──────┐    ┌───────┴─┐
│Exec    │    │Exec     │
│Node    │    │Node     │
│(Site A)│    │(Site B) │
└────────┘    └─────────┘

Mesh Installer Configuration

# AAP installer inventory for mesh topology
[automationcontroller]
controller1.example.com
controller2.example.com

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]
exec-dc1.example.com node_type=execution
exec-dc2.example.com node_type=execution

[execution_nodes:vars]
peers=hop_nodes

[hop_nodes]
hop-dmz.example.com node_type=hop

[hop_nodes:vars]
peers=remote_execution

[remote_execution]
exec-remote1.example.com node_type=execution
exec-remote2.example.com node_type=execution

When to Use Hop Nodes

• DMZ traversal — execution nodes in a restricted network zone
• Multi-site deployments — reduce direct connections between sites
• Latency optimization — hop nodes as regional relay points
• Security boundaries — limit which nodes can reach the control plane

Automation Execution Environments

Execution Environments (EEs) are container images that package everything needed to run Ansible automation:

• Ansible core
• Python dependencies
• System packages
• Ansible collections
• Custom modules and plugins

Why EEs Replace Python Virtual Environments

Before EEs, managing Ansible dependencies across control nodes was painful — conflicting Python packages, missing system libraries, inconsistent collection versions. EEs solve this by containerizing the entire execution context.

Building a Custom EE

# execution-environment.yml
---
version: 3

images:
  base_image:
    name: registry.redhat.io/ansible-automation-platform-26/ee-minimal-rhel9:latest

dependencies:
  galaxy:
    collections:
      - name: ansible.netcommon
        version: ">=7.0.0"
      - name: cisco.ios
        version: ">=9.0.0"
      - name: arista.eos
        version: ">=10.0.0"
  python:
    - paramiko>=3.0
    - netaddr>=1.0
    - jmespath>=1.0
  system:
    - iputils [platform:rpm]
    - openssh-clients [platform:rpm]

additional_build_steps:
  prepend_base:
    - RUN whoami
    - RUN cat /etc/os-release
  append_final:
    - RUN pip3 freeze | grep -i ansible
    - COPY custom_filter_plugins/ /usr/share/ansible/plugins/filter/

Build with ansible-builder:

ansible-builder build \
  --tag registry.example.com/ee-network:1.0 \
  --container-runtime podman \
  --prune-images

Red Hat Provided EEs

Ansible Galaxy

Ansible Galaxy serves as the community content hub:

• Browse and download community collections
• Publish your own collections and roles
• Search for automation content by platform, category, or keyword

See also: Ansible Automation Platform Architecture: Components, Ecosystem, and Integration Guide

Automation Content Navigator

Automation Content Navigator (ansible-navigator) is the developer tool for AAP:

# Run a playbook inside an EE
ansible-navigator run site.yml \
  --eei registry.example.com/ee-network:1.0 \
  --mode stdout

# Explore collection documentation
ansible-navigator collections --eei ee-supported-rhel9

# Inspect an EE's contents
ansible-navigator images --eei ee-supported-rhel9

Navigator replaces multiple CLI tools:

PostgreSQL

PostgreSQL is the backing database for all AAP services:

• Platform Gateway — session and routing data
• Automation Controller — jobs, inventories, credentials, RBAC
• Automation Hub — collection metadata, approval workflows
• EDA Controller — rulebook activations, event logs

PostgreSQL Requirements for AAP 2.6

# External database configuration in installer inventory
[all:vars]
gateway_pg_host=externaldb.example.org
gateway_pg_database=gateway
gateway_pg_username=gateway
gateway_pg_password=<set your own>

controller_pg_host=externaldb.example.org
controller_pg_database=controller
controller_pg_username=controller
controller_pg_password=<set your own>

hub_pg_host=externaldb.example.org
hub_pg_database=hub
hub_pg_username=hub
hub_pg_password=<set your own>

eda_pg_host=externaldb.example.org
eda_pg_database=eda
eda_pg_username=eda
eda_pg_password=<set your own>

Red Hat Tested Deployment Models

Red Hat tests AAP 2.6 with specific reference architectures across three installation modes. Using a tested topology ensures the highest level of support, uptime, and scalability.

Installation Modes

> Important: The RPM installer is deprecated and will be removed in AAP 2.7. It is supported on RHEL 9 during the AAP 2.6 lifecycle only for migrations. See our AAP 2.6 RPM Deprecation and Containerized Migration guide.

System Requirements (Per VM)

Container Growth Topology (Single Node)

All components on one VM. Suitable for getting started and evaluation:

# Container growth topology — single VM
[automationgateway]
aap.example.org

[automationcontroller]
aap.example.org

[automationhub]
aap.example.org

[automationeda]
aap.example.org

[database]
aap.example.org

[all:vars]
ansible_connection=local
postgresql_admin_username=postgres
postgresql_admin_password=<set your own>
registry_username=<your RHN username>
registry_password=<your RHN password>
redis_mode=standalone

gateway_admin_password=<set your own>
gateway_pg_host=aap.example.org
gateway_pg_password=<set your own>

controller_admin_password=<set your own>
controller_pg_host=aap.example.org
controller_pg_password=<set your own>
controller_percent_memory_capacity=0.5

hub_admin_password=<set your own>
hub_pg_host=aap.example.org
hub_pg_password=<set your own>
hub_seed_collections=false

eda_admin_password=<set your own>
eda_pg_host=aap.example.org
eda_pg_password=<set your own>

Container Enterprise Topology (Multi-Node HA)

Full redundancy with external database and HAProxy load balancer:

# Container enterprise topology — multi-node HA
[automationgateway]
gateway1.example.org
gateway2.example.org

[automationcontroller]
controller1.example.org
controller2.example.org

[execution_nodes]
hop1.example.org receptor_type='hop'
exec1.example.org
exec2.example.org

[automationhub]
hub1.example.org
hub2.example.org

[automationeda]
eda1.example.org
eda2.example.org

[redis]
gateway1.example.org
gateway2.example.org
hub1.example.org
hub2.example.org
eda1.example.org
eda2.example.org

[all:vars]
postgresql_admin_username=<set your own>
postgresql_admin_password=<set your own>
registry_username=<your RHN username>
registry_password=<your RHN password>

gateway_admin_password=<set your own>
gateway_pg_host=externaldb.example.org
gateway_pg_database=<set your own>
gateway_pg_username=<set your own>
gateway_pg_password=<set your own>

controller_admin_password=<set your own>
controller_pg_host=externaldb.example.org
controller_pg_database=<set your own>
controller_pg_username=<set your own>
controller_pg_password=<set your own>

hub_admin_password=<set your own>
hub_pg_host=externaldb.example.org
hub_pg_database=<set your own>
hub_pg_username=<set your own>
hub_pg_password=<set your own>

eda_admin_password=<set your own>
eda_pg_host=externaldb.example.org
eda_pg_database=<set your own>
eda_pg_username=<set your own>
eda_pg_password=<set your own>

> Note: Redis HA requires 6 VMs. Redis can be colocated on any AAP component VM except execution nodes or the PostgreSQL database. External Redis is not supported for containerized AAP.

Operator Topology (OpenShift)

For OpenShift deployments, AAP uses a Kubernetes Operator with Custom Resources:

Growth (Single Node OpenShift): 32 GB RAM, 16 CPUs, 128 GB disk, 3000 IOPS.

# Operator growth topology — Custom Resource
apiVersion: aap.ansible.com/v1alpha1
kind: AnsibleAutomationPlatform
metadata:
  name: aap
spec:
  eda:
    automation_server_ssl_verify: 'no'
  hub:
    storage_type: 's3'
    object_storage_s3_secret: '<s3-secret-name>'

Enterprise (Multi-Node OpenShift): Red Hat OpenShift on AWS (ROSA) with Hosted Control Planes, 2 worker nodes (t3.xlarge) across 2 availability zones, external PostgreSQL (RDS), external Redis (ElastiCache), S3 object storage for Hub.

See also: AAP 2.6 Execution Environments: Build, Manage, and Deploy Custom EEs

How Components Interact

Understanding the data flow between components is critical for troubleshooting and capacity planning:

Job Execution Flow

1. User submits job via Platform Gateway UI or API
2. Gateway authenticates and routes to Automation Controller
3. Controller resolves inventory, credentials, and EE image
4. Controller dispatches job to an execution node via Automation Mesh
5. Execution node pulls EE image (from Automation Hub registry)
6. Job runs inside the EE container
7. Results flow back through Mesh to Controller
8. Controller stores results in PostgreSQL
9. User views results via Gateway UI

Event-Driven Flow

1. External event arrives at EDA Controller (webhook, Kafka, etc.)
2. EDA evaluates event against active rulebook activations
3. If a rule matches, EDA calls Automation Controller API
4. Controller executes the triggered job template
5. Results available in both Controller and EDA event logs

Network Port Requirements

Red Hat Ansible Automation Platform uses these ports for inter-component communication. All must be open and not blocked by firewalls.

Core Service Ports

Data and Mesh Ports

Internal NGINX Ports

Best Practices

Sizing Guidelines (Red Hat Tested)

Red Hat tests each VM with these minimum requirements:

• 4 vCPU, 16 GB RAM
• max_connections: 1024 minimum
• 200 GB storage on a volume capable of 3000+ IOPS

Security Recommendations

• Enable TLS everywhere — all component-to-component communication
• Use external certificate authority — not self-signed certs in production
• Configure LDAP/SAML/OIDC through Platform Gateway for enterprise SSO
• Rotate database credentials and API tokens regularly
• Enable audit logging on Platform Gateway

FAQ

What is the difference between AAP and Ansible Core?

Ansible Core is the open source command-line tool for running playbooks. AAP wraps Ansible Core with enterprise features: a web UI, RBAC, job scheduling, audit logging, event-driven automation, distributed execution, and certified content. AAP is a Red Hat subscription product; Ansible Core is free.

Can I run AAP 2.6 without Platform Gateway?

No. Platform Gateway is a required component in AAP 2.6. It provides the unified authentication layer and UI that all other services depend on. You cannot deploy Controller, Hub, or EDA independently in AAP 2.6.

What happened to Ansible Tower?

Ansible Tower was renamed to Automation Controller starting with AAP 2.0. The functionality is the same — job templates, inventories, workflows, RBAC — but it now operates as one service within the broader platform rather than a standalone product.

Is AWX the same as Automation Controller?

AWX is the open source upstream project for Automation Controller. They share the same codebase, but Automation Controller includes Red Hat support, tested releases, certified content integration, and Platform Gateway SSO. AWX is community-supported only.

How does Automation Mesh differ from isolated nodes in Tower?

Automation Mesh replaces the legacy isolated node concept from Ansible Tower. Mesh provides peer-to-peer communication (not just control→isolated), hop node routing for complex network topologies, automatic failover, and better scalability. Mesh nodes use the Receptor protocol (TCP 27199) instead of SSH.

Can I use AAP 2.6 in air-gapped environments?

Yes. Deploy Private Automation Hub to host collections and EE images internally. Mirror certified content and container images before disconnecting. The containerized installer supports fully disconnected installation with pre-downloaded images.

What is the recommended database for production?

PostgreSQL 15 (managed) or PostgreSQL 15, 16, or 17 (external with ICU support). For HA, use a managed service like Amazon RDS or Azure Database for PostgreSQL. The Operator-deployed database has a default max_connections limit of 100 and maximum size of 100 GB — use an external database if running more than 1 replica of any component, exceeding 100 concurrent Controller jobs, or expecting more than 100 GB of data in 30 days.

Is RPM installation still supported?

The RPM installer was deprecated in AAP 2.5 and will be removed in AAP 2.7. It is supported on RHEL 9 during the AAP 2.6 lifecycle only to support migrations to containerized or Operator-based topologies. All new deployments should use the containerized installer or the OpenShift Operator.

What CPU architectures does AAP 2.6 support?

AAP 2.6 supports x86_64, AArch64 (ARM), s390x (IBM Z), and ppc64le (IBM Power). This applies to container, Operator, and RPM deployment modes on RHEL 9.4+ or RHEL 10+.

Conclusion

AAP 2.6's architecture represents a mature, service-oriented approach to enterprise automation. The Platform Gateway unifies access, Automation Controller handles orchestration, EDA adds event-driven capabilities, Automation Mesh distributes execution, and Execution Environments ensure consistency.

Understanding how these components fit together is essential for planning deployments, troubleshooting issues, and scaling automation across your organization.

Related Articles

• AAP 2.6 RBAC and Gateway API
• AAP 2.6 Event-Driven Ansible Enhancements
• AAP 2.6 RPM Deprecation and Containerized Migration
• AAP 2.6 Automation Dashboard Guide
• AAP 2.6 Security Best Practices
• AAP 2.6 Configuration as Code with ansible.platform
• AAP 2.6 New Collections and Integrations
• AAP 2.6 Lightspeed Intelligent Assistant
• AAP 2.6 Upgrade Guide from 2.5
• AAP 2.6 vs 2.5 Comparison

Related: Ansible Builder & Execution Environments

Related: Ansible Cisco UCS Automation

See also

• Ansible Event-Driven Automation (EDA): Complete Guide with Rulebooks and Examples