Ansible Automation Platform 2.6 Architecture and Components: Complete Guide
By Luca Berton · Published 2024-01-01 · Category: installation
Complete guide to AAP 2.6 architecture and components: Platform Gateway, Automation Controller, Hub, EDA Controller, Automation Mesh, Execution Environments, and PostgreSQL. Understand how each component fits together.
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.
AAP 2.6 Architecture Overview
AAP 2.6 follows a service-oriented architecture where each component handles a specific automation concern:
Data flow: Users authenticate through Platform Gateway Platform Gateway routes requests to the appropriate service Automation Controller orchestrates job execution Jobs run inside Execution Environments on Automation Mesh nodes Collections and EE images are sourced from Automation Hub EDA Controller listens for events and triggers automation 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:
Key Platform Gateway Features
| Feature | Description | |---------|-------------| | Unified login | Single sign-on across all AAP services | | RBAC integration | Central role and permission management | | Service discovery | Automatic routing to Controller, Hub, EDA | | API gateway | RESTful API access to all platform services | | Audit logging | Centralized authentication and access logs |
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
Automation Controller vs AWX
| Feature | Automation Controller | AWX | |---------|----------------------|-----| | Support | Red Hat supported | Community only | | Updates | Tested release cycle | Rolling upstream | | Clustering | Full HA support | Basic clustering | | RBAC | Enterprise RBAC | Basic RBAC | | Certifications | FIPS, FedRAMP eligible | None | | Integration | Platform Gateway SSO | Standalone auth |
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
Syncing Collections from Ansible Galaxy
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
EDA Event Sources
EDA supports multiple event source plugins:
| Source | Plugin | Use Case | |--------|--------|----------| | Webhooks | ansible.eda.webhook | ServiceNow, GitHub, PagerDuty | | Kafka | ansible.eda.kafka | Stream processing, log aggregation | | AWS SQS | ansible.eda.aws_sqs | Cloud event processing | | Alertmanager | ansible.eda.alertmanager | Prometheus/Grafana alerts | | File watch | ansible.eda.file_watch | Config file changes | | URL check | ansible.eda.url_check | Endpoint health monitoring |
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
Mesh Installer Configuration
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
Build with ansible-builder:
Red Hat Provided EEs
| EE Image | Contents | Use Case | |----------|----------|----------| | ee-minimal-rhel9 | Ansible core + minimal deps | Lightweight automation | | ee-supported-rhel9 | Core + Red Hat certified collections | General enterprise use | | ee-29-rhel9 | Core 2.16+ supported collections | Latest features |
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
In AAP 2.6, Galaxy integrates with Private Automation Hub to sync approved community content into your internal content pipeline.
Automation Content Navigator
Automation Content Navigator (ansible-navigator) is the developer tool for AAP:
Navigator replaces multiple CLI tools:
| Old Tool | Navigator Equivalent | |----------|---------------------| | ansible-playbook | ansible-navigator run | | ansible-doc | ansible-navigator doc | | ansible-inventory | ansible-navigator inventory | | ansible-config | ansible-navigator config |
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
| Requirement | Specification | |-------------|---------------| | Managed databases | PostgreSQL 15 | | External databases | PostgreSQL 15, 16, or 17 (ICU support required) | | External DB minimum | 4 vCPU, 16 GB RAM, 200 GB storage, 3000 IOPS, max_connections: 1024 | | Backup/restore | PostgreSQL 16/17 require external backup processes (utilities depend on PG 15) |
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
| Mode | Infrastructure | Description | |------|---------------|-------------| | Containers (Recommended) | VMs and bare metal | Podman-based containers on RHEL. Recommended for new deployments. | | Operator | Red Hat OpenShift | Kubernetes Operator on OpenShift. Managed via Custom Resources. | | RPM (Deprecated) | VMs and bare metal | Traditional RPM packages on RHEL. Deprecated in 2.5, removed in 2.7. |
Each mode offers a growth topology (single-node or minimal, no redundancy) and an enterprise topology (multi-node with HA and redundancy).
> 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)
| Requirement | Minimum | |-------------|---------| | RAM | 16 GB (32 GB for growth bundled installs with hub_seed_collections=true) | | CPUs | 4 | | Local disk | 60 GB total available | | Disk IOPS | 3000 | | OS | RHEL 9.4+ or RHEL 10+ | | CPU architecture | x86_64, AArch64, s390x (IBM Z), ppc64le (IBM Power) | | ansible-core | RHEL 9: 2.14, RHEL 10: 2.16 (platform bundles 2.16 separately) | | Database | PostgreSQL 15 (managed) or 15/16/17 (external) | | IP | IPv4, IPv6 (single-stack and dual-stack) |
Container Growth Topology (Single Node)
All components on one VM. Suitable for getting started and evaluation:
Container Enterprise Topology (Multi-Node HA)
Full redundancy with external database and HAProxy load balancer:
| VM Count | Purpose | |----------|---------| | 2 | Platform Gateway with colocated Redis | | 2 | Automation Controller | | 2 | Private Automation Hub with colocated Redis | | 2 | Event-Driven Ansible with colocated Redis | | 1 | Automation Mesh hop node | | 2 | Automation Mesh execution nodes | | 1 | Externally managed database | | 1 | HAProxy load balancer (externally managed) |
> 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.
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.
| Component | Pod Count | |-----------|-----------| | Controller web | 1 | | Controller task | 1 | | Hub web | 1 | | Hub API | 1 | | Hub content | 2 | | Hub worker | 2 | | EDA API | 1 | | EDA activation worker | 2 | | EDA default worker | 2 | | EDA event stream | 2 | | EDA scheduler | 1 | | Platform Gateway | 1 | | Mesh ingress | 2 |
> Important: You can only install a single AAP Operator instance per namespace. Multiple instances in the same namespace cause improper operation.
How Components Interact
Understanding the data flow between components is critical for troubleshooting and capacity planning:
Job Execution Flow User submits job via Platform Gateway UI or API Gateway authenticates and routes to Automation Controller Controller resolves inventory, credentials, and EE image Controller dispatches job to an execution node via Automation Mesh Execution node pulls EE image (from Automation Hub registry) Job runs inside the EE container Results flow back through Mesh to Controller Controller stores results in PostgreSQL User views results via Gateway UI
Event-Driven Flow External event arrives at EDA Controller (webhook, Kafka, etc.) EDA evaluates event against active rulebook activations If a rule matches, EDA calls Automation Controller API Controller executes the triggered job template 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
| Port | Protocol | Source | Destination | Purpose | |------|----------|--------|-------------|---------| | 80/443 | TCP HTTP/HTTPS | Platform Gateway | Controller | Gateway → Controller communication | | 80/443 | TCP HTTP/HTTPS | Platform Gateway | Hub | Gateway → Hub communication | | 80/443 | TCP HTTP/HTTPS | Platform Gateway | EDA | Gateway → EDA communication | | 80/443 | TCP HTTP/HTTPS | Controller | Hub | Pull collections and EE images | | 80/443 | TCP HTTP/HTTPS | EDA | Controller | Launch Controller jobs | | 80/443 | TCP HTTP/HTTPS | EDA | Hub | Pull decision environments | | 80/443 | TCP HTTP/HTTPS | HAProxy | Gateway | External load balancer (enterprise) |
Data and Mesh Ports
| Port | Protocol | Source | Destination | Purpose | |------|----------|--------|-------------|---------| | 5432 | TCP PostgreSQL | All components | Database | Database access | | 6379 | TCP Redis | Gateway, EDA | Redis node | Session/job data storage | | 16379 | TCP Redis | Redis node | Redis node | Redis cluster bus (enterprise HA) | | 27199 | TCP Receptor | Controller | Exec/Hop nodes | Automation Mesh communication | | 27199 | TCP Receptor | Hop node | Exec node | Mesh relay through hop nodes |
Internal NGINX Ports
| Port | Service | Configurable Via | |------|---------|-----------------| | 8080/8443 | Controller NGINX | controller_nginx_http_port, controller_nginx_https_port | | 8081/8444 | Hub NGINX | hub_nginx_http_port, hub_nginx_https_port | | 8082/8445 | EDA NGINX | eda_nginx_http_port, eda_nginx_https_port | | 8083/8446 | Gateway NGINX | gateway_nginx_http_port, gateway_nginx_https_port |
Best Practices
Sizing Guidelines (Red Hat Tested)
Red Hat tests each VM with these minimum requirements:
| Requirement | All Components | |-------------|---------------| | RAM | 16 GB minimum | | CPUs | 4 | | Local disk | 60 GB | | Disk IOPS | 3000 |
For Operator enterprise topology on OpenShift, the external database minimum is: • 4 vCPU, 16 GB RAM • max_connections: 1024 minimum • 200 GB storage on a volume capable of 3000+ IOPS
> Tip: Database storage consumption depends on job frequency, playbook task count, output verbosity, and managed hosts per job. Higher verbosity levels increase storage by 3-5x. Configure automated cleanup jobs to prevent unbounded growth.
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
Category: installation