The AAP 2.7 Architecture, Port by Port

A firewall request that says “allow AAP” is not a firewall request. It is a small cry for help.

AAP 2.7 has enough moving parts that a flat list of ports hides the useful questions: Which machine starts the connection? Which services share a machine? Does Redis dispatch the job? Where does the gateway stop and Controller begin?

The map below answers those at the boundary a firewall actually sees. Each box is a component, and the enterprise topology runs a pair of every core one, so the boxes are badged ×2 and stacked like a small deck. Hover a box to follow what it dials out. Click a box to see what you open on it, the inbound rules that go straight into a security group. The scenario buttons trade the whole port mesh for one traffic story at a time.

Every rule on this map traces to the defaults and firewall tasks in the shipped AAP 2.7 containerized installer bundle. Node-local listeners stay inside their box and deliberately do not become edges.

One Front Door Changes the Map

Platform Gateway is not an optional facade in 2.7. Supported browser and API access enters through Gateway, then Gateway routes the request to Controller, Private Automation Hub, or Event-Driven Ansible. The old habit of pointing an integration directly at a component API no longer matches the platform shape.

That is why a customer-provided load balancer sits in front of the gateway pair. It gives clients one address, while each Gateway stays a real routing and authentication boundary. Envoy listens on 443, with 80 for redirect, and dials three distinct component listeners:

Those are not interchangeable “HTTPS ports.” Each names the component endpoint the gateway is dialing, and the reverse rule is separate: Controller, Hub, and EDA each dial the gateway back on 443 for JWT and resource-server synchronization.

That split is easy to lose in a spreadsheet, and it is exactly what the two interactions pull apart. Click Automation Controller and the panel lists what to open on it: 8443 from the gateway, plus 27199 from its twin. Hover it instead and you see everything it dials out: 5432 to Postgres, 27199 to the mesh, and 443 back to the gateway. Trace the one wire the two of them share and the lesson lands: 8443 in, 443 out, the same two machines, opposite directions, two rules, one on each firewall.

The Boxes Matter More Than the Logos

Each box is one component, and the ×2 badge is the HA pair. The two machines in a pair open the same ports to the rest of the platform, so the map draws one and lets the stacked deck stand in for the second. Drawing the twin’s wires would double the ink and teach nothing new.

Gateway handles authentication and routing. Controller schedules jobs and owns automation state. Hub serves collections and execution-environment content. EDA turns events into automation. PostgreSQL is the shared durable state. Execution nodes run the work through Receptor.

Redis takes two deliberately different shapes, and only one is a firewall rule:

• Controller and Hub each run a local Redis on a Unix socket. It never leaves the VM, so it draws no edge and opens no port.
• Gateway, Hub, and EDA each host a member of the shared six-node Redis cluster. That is the one Redis that crosses machines.

The cluster is where a collapsed map has to be careful. Six members meshing is fifteen links, so the map collapses them into three VM-level wires (gateway to hub, gateway to EDA, hub to EDA), dashes the member cards to mark them, and keeps the full member-to-member rule in the panel: click a gateway, hub, or EDA box and it reads 6379 + 16379 from every other member, with all six lit. 6379 is the data and client port; 16379 is the cluster bus, the node-to-node channel for gossip and failover that Redis defaults to at the data port plus ten thousand (the cluster-port is configurable). The installer opens both on each member (6379 always, 16379 only in cluster mode), but only on the host firewall, so the perimeter rule your network team writes is 6379 + 16379 between the members. Miss the bus port and the cluster never forms or fails over.

The nasty version of that failure is the quiet one. Open 6379 but leave 16379 blocked and the cluster comes up looking healthy, reads and writes flowing, right until the first time a node drops and nothing is allowed to vote on its replacement.

Co-location is doing real work here. If a service talks over a Unix socket, inventing a network edge for it would create a firewall requirement the installer does not have. The same test excludes the tempting internal listeners: Gateway 8052 and 50051, Controller 8050 and 8051, Hub 24816 and 24817, EDA 8000 and 8001. They exist, but they are not cross-VM rules.

Read the Arrow as a Firewall Rule

A TCP session carries bytes both ways once it’s established. That doesn’t make every firewall rule bidirectional.

Receptor makes the difference concrete. The installer default gives Controllers their execution-node peers, so the Controller opens the TLS connection down to the execution node’s 27199 listener. Results return over that same session; they need no execution-node-initiated rule back.

The peer direction is configurable. If your inventory assigns the peer the other way, reverse the arrow and the rule with it. Don’t copy a diagram’s arrow after changing the inventory that drew it. The two Controllers also peer on 27199, and there’s no hop node in this shape; adding one because “mesh diagrams usually have a hop” would be drawing a product feature, not this deployment.

The execution nodes are not only receptor endpoints, either. When a job pulls its execution-environment image or a collection, that traffic is HTTP, and in 2.7 all HTTP goes through the gateway, so each execution node also dials the gateway on 443. Even the workers use the front door.

PostgreSQL is the cleanest one-way case. Gateway, Controller, Hub, and EDA all dial 5432 into externaldb, and the database dials no one back. It’s a pure listener, which is why hovering it lights nothing: it makes no outbound connection. Click it instead and every rule points in, 5432 from each component. That list is the whole security group for the database.

Four Paths Through the Same Platform

The resting map shows every rule at once. Scenario mode answers a smaller question, one path at a time.

Press UI login. The path is short: client to the load balancer, then 443 to Gateway. Gateway owns the authentication decision. A login doesn’t begin by choosing a Controller or Hub API.

Press Job launch. The request enters Gateway, crosses to Controller on 8443, and the Controller hands the work to an execution node over its Receptor connection on 27199. Notice what the trace leaves out: the database. Every component talks to Postgres constantly, so drawing it as a hop would add a line to every path and teach nothing. And notice what never enters the path at all: Redis. The job runs out to the mesh over Receptor; the cluster’s busy red lines carry cache and quorum, not the job. That is the thing people get wrong, because the Redis lines look the busiest.

Press EDA event. A rulebook activation reacts to its source-specific event, then EDA drives the same Gateway-to-Controller path to launch a job on an execution node. The source adapter is not assigned a made-up universal port here.

Finally, Content sync. Controller calls Gateway on 443, and Gateway routes it to Hub’s 8444. Even content stays behind the one front door instead of becoming a special direct-API exception.

Why the Front Door Is Worth It

One mandatory ingress looks like extra plumbing when the direct URL already worked. It earns its keep by putting authentication, RBAC, TLS policy, and API routing at a single boundary. Integrations get one supported address, and the public firewall surface ends at the gateway pair.

Behind that boundary the topology stays highly available without pretending every service is stateless. A pair each of Gateway, Controller, Hub, and EDA share an external PostgreSQL as the source of truth. Gateway, Hub, and EDA contribute the six Redis cluster members for quorum. A generic load balancer keeps both gateways reachable, and two execution nodes give the mesh somewhere to run work.

The useful final artifact isn’t a memorized list of numbers. It’s a rule you can say in one sentence: open the listener from the VM that initiates the connection, and do not turn a co-located socket into a network problem.