AAP 2.7 Gateway-Only Architecture: Why All Traffic Now Goes Through One Ingress

Red Hat Ansible Automation Platform 2.7, announced at Red Hat Tech Day Netherlands 2026 in Bunnik on 3 June 2026, ships a structural change that will affect every AAP deployment far more quietly than a flashy new UI feature ever could: gateway-only architecture. From 2.7 onward, all inter-component traffic inside the platform is required to pass exclusively through the gateway. Direct service-to-service calls between controller, EDA, Hub, and other AAP components are no longer permitted, and Red Hat has stated this constraint is now enforced and regression-tested as part of the release process.

If you manage AAP at scale — multiple execution nodes, isolated network zones, strict change-control processes — this is one of the most consequential platform changes in the 2.7 release, even though it doesn't show up on a features slide next to Automation Portal or the new MCP Server. This article explains what gateway-only architecture actually means, why Red Hat made the change, and what it means for how you design, secure, and troubleshoot AAP deployments going forward.

What "Gateway-Only" Actually Means

In earlier versions of AAP, the platform's internal components — the automation controller API, Event-Driven Ansible (EDA) controller, automation hub, and supporting services — could, in various configurations, talk to each other directly. The gateway existed primarily as a unified authentication and routing layer for external, user-facing traffic.

AAP 2.7 closes that gap. Every request, whether it originates from a user's browser, an API client, or one internal AAP service calling another, now has to traverse the single gateway ingress. There is no longer a supported path for controller to call hub directly, or for EDA to reach the gateway's backing services without going through the gateway itself.

The practical effect is a single, well-defined choke point for:

• Authentication and session validation
• Authorization and RBAC enforcement
• Audit logging and request tracing
• TLS termination and certificate management
• Rate limiting and traffic shaping

See also: AAP 2.7 EE Builder Step 1: Choosing a Base Image

Why Red Hat Made This Change

Three drivers stand out from what was presented at Red Hat Tech Day Netherlands 2026:

1. Security surface reduction. Every direct service-to-service call is a potential lateral-movement path and an additional set of credentials or network rules to secure. Collapsing all traffic through one ingress means there is one set of TLS certificates to rotate, one set of firewall rules to audit, and one component whose authentication logic needs the deepest scrutiny.

2. Consistency of authorization. With multiple internal paths, it becomes possible for RBAC policy to be enforced differently — or not at all — depending on which route a request took. A gateway-only model guarantees that a permission check applied at the gateway is applied to all traffic, with no side door.

3. Operational clarity for large, distributed deployments. As AAP installations grow to include EDA, multiple execution environments, Hub, and now the new Automation Portal and hosted MCP Server, the number of possible service-to-service paths multiplies. A single ingress dramatically simplifies network diagrams, firewall rule sets, load balancer configuration, and — critically — troubleshooting, since there is now exactly one place to look when diagnosing connectivity or authentication issues between components.

Red Hat also emphasized that this isn't a soft recommendation: the gateway-only requirement is enforced in code and covered by regression tests, meaning a future release that accidentally reintroduced a direct service-to-service call would fail Red Hat's own test suite before shipping.

Before and After: What Changes for Operators

See also: AAP 2.7 EE Builder Step 2: Adding Collections from Private Automation Hub

A Practical Example: Confirming Gateway Routing Post-Upgrade

While gateway-only architecture is an internal platform behavior rather than something you configure via playbook, it's good practice to validate that automation workflows which call the AAP API still behave correctly after upgrading, since all calls — including those from your own automation — resolve through the gateway endpoint. Here's an illustrative example of a health-check play that confirms the gateway is correctly routing requests to the controller API after an AAP 2.7 upgrade:

---
- name: Validate AAP gateway routing after 2.7 upgrade
  hosts: localhost
  gather_facts: false
  vars:
    aap_gateway_url: "https://aap-gateway.example.com"
    aap_validate_certs: true

  tasks:
    - name: Confirm gateway responds and routes to controller API
      ansible.builtin.uri:
        url: "{{ aap_gateway_url }}/api/controller/v2/ping/"
        method: GET
        validate_certs: "{{ aap_validate_certs }}"
        status_code: 200
      register: gateway_ping

    - name: Confirm gateway routes to automation hub
      ansible.builtin.uri:
        url: "{{ aap_gateway_url }}/api/hub/v3/status/"
        method: GET
        validate_certs: "{{ aap_validate_certs }}"
        status_code: 200
      register: hub_ping

    - name: Report gateway routing status
      ansible.builtin.debug:
        msg: >
          Gateway routing OK — controller reachable in
          {{ gateway_ping.elapsed }}s, hub reachable in
          {{ hub_ping.elapsed }}s. No direct service endpoints queried.

Notice both API calls target the same gateway hostname — that's the point. There should be no separate hostnames or ports for controller and hub traffic once your load balancer and DNS are aligned with the gateway-only model.

Related Platform Changes Worth Knowing

Gateway-only architecture didn't ship in isolation. AAP 2.7 also brings PostgreSQL 16 and 17 support, an upgrade to Django 5.2 LTS, and a centralized OpenAPI spec that documents the gateway's unified API surface — a natural companion to routing all traffic through one place, since it's now feasible to describe the entire platform's API in one specification rather than several component-specific ones. Phase 1 of the ansible.platform configuration-as-code collection also lands in 2.7, letting teams codify gateway and platform configuration rather than clicking through the UI.

See also: AAP 2.7 EE Builder Step 3: Destination, Build, and Publish to Git

Key Takeaways

• AAP 2.7 mandates gateway-only architecture: all inter-component traffic — including internal service-to-service calls — must route through the gateway, with no direct paths permitted.
• This is enforced, not advisory: Red Hat regression-tests the constraint, so it won't silently regress in future releases.
• Security and auditability improve: centralized authentication, authorization, TLS termination, and logging replace fragmented per-component handling.
• Network-segmented deployments need a review: confirm only the gateway ingress needs cross-zone reachability before upgrading.
• It pairs with a centralized OpenAPI spec: one ingress and one documented API surface go hand in hand in 2.7.
• If you're planning the upgrade path, remember AAP 2.4 reaches end of life in June 2026, and Extended Update Support carries a 50% premium for the first 12-month term (75% for a second) — factor the gateway-only architecture review into that upgrade planning window now.