How to Compare AAA Server Architectures

To compare AAA server architectures, score six structural choices: redundancy model, protocol convergence, session and data model, scaling approach, deployment flexibility, and operational tooling. These decide how an AAA (Authentication, Authorization, and Accounting) platform behaves under load and during failure. The vendor diagram does not.

• Redundancy model and data model dominate the outcome. Active-active sites with externalized session state survive node loss as a capacity event. Active-passive with per-instance state turns a failure into an outage.
• One request settles the redundancy question. Ask the vendor to kill a node under representative load with the authentication success-rate graph on screen, and watch whether they treat it as routine.
• Burst throughput and sustained throughput are not the same number. Only sustained figures, with accounting enabled and a stated latency, predict behavior in a re-authentication storm.
• Score it in writing. One to five per dimension, right after each technical deep-dive, weighted to your own risk profile. The table below is built to drop into an RFP.

For instance, put three vendor architecture slides side by side and they are nearly interchangeable: two sites, a load balancer, a database cylinder, arrows pointing the right way. Every diagram survives the sales call. The architectures behind them separate two years later, at 2 a.m., when a regional power failure sends every subscriber in a city reconnecting at once.

Those six choices, not the diagram in the sales deck, are what decide how the platform behaves that night. This guide turns each of them into an evaluation framework, with strong and weak answers for every dimension and a scoring table you can lift into an RFP. It is written for the technical evaluator with a shortlist and a deep-dive call on the calendar.

Redundancy model: active-active or active-passive

The redundancy model is the single biggest architectural lever on uptime. Active-active designs run every node and site live against production traffic, so a failure changes capacity headroom instead of triggering a recovery event. Active-passive designs concentrate risk in a failover that is rarely rehearsed.

The weak pattern looks reassuring on paper: a primary site, a standby site, replication between them, a documented failover procedure. But the standby has never carried production load. Idle systems accumulate configuration drift, the failover path gets exercised at acceptance testing and then annually if the change board allows it, and when the real event comes, the recovery itself becomes the incident. The same pattern also has to defend against split-brain, where both sites decide they are primary after a network partition.

The strong pattern has no promotion step. Both sites carry live traffic every day, state replicates continuously, and losing a site means the survivor absorbs load it was sized to absorb. In a demo, one question separates the two: ask the vendor to kill a node under representative load with the authentication success-rate graph on screen, and watch whether they treat the request as routine.

Protocol convergence: one stack or three

Convergence is the difference between one platform and three products behind one logo. Ask how many AAA-adjacent products sit on the vendor’s own price list, then ask which of them share a codebase, a data model, and an upgrade train, because a portfolio can be assembled as easily as it can be engineered.

This matters because your protocol mix will not stand still. RADIUS (RFC 2865) still carries broadband and Wi-Fi authentication. Diameter (RFC 6733) carries the mobile-core interfaces, and it is where 5G shows up in an AAA evaluation: the same platform that terminates S6b and SWx for 4G data and Wi-Fi calling should have a credible answer for 5G subscriber authentication rather than a separate product for it. TACACS+ governs administrative access to the network estate itself. A converged architecture terminates all three on one stack with one subscriber view, one policy engine, and one upgrade train; our breakdown of RADIUS, Diameter, and TACACS+ in CSP environments covers what each protocol is actually doing in your network.

The test question: does a subscriber authenticated over RADIUS and a policy decision made over Diameter read from the same live data store, or from two stores connected by a synchronization job? Synchronization jobs are where converged diagrams quietly become integration projects.

Session and data model: where state lives

When an AAA instance dies, the architectural question is what dies with it. Platforms that hold session state inside each server instance lose that state with the process; subscribers re-authenticate in a thundering herd, and any accounting the instance had not flushed is unbilled revenue. Platforms that externalize state to a replicated data layer treat instances as disposable: any node can serve any request, and a process death costs capacity, not sessions.

The data model shapes more than failure behavior. A centralized, replicated subscriber and session store is what makes horizontal scaling coherent, since new instances attach to shared state without fragmenting it. It is also what makes a distributed AAA architecture possible: state synchronized across nodes and sites, no longer pinned to one box. Fragmented per-instance state is the unadvertised reason some platforms can only scale by making one machine bigger.

Read the vendor diagram with one question: is the database drawn inside the server box or outside it? Inside means the state and the failure domain are the same thing.

Scaling approach: horizontal or vertical

Sizing an AAA platform on average load is the common mistake here. The real capacity requirement is the re-authentication storm: a regional outage recovers, every optical network terminal (ONT) and customer premises device in the area reconnects within minutes, and authentication traffic spikes to a large multiple of the daily peak.

Vertically scaled platforms answer the storm with bigger hardware, which makes capacity a procurement decision taken months in advance and re-taken at every growth step. Horizontally scaled platforms run stateless instances on Kubernetes or an equivalent orchestrator against the shared data layer from the previous section, and answer the storm by adding instances, turning the capacity ceiling into something you expand in software.

Two claims to separate in every datasheet: burst throughput and sustained throughput. A platform that quotes transactions per second should be able to say for how long, at what latency, and with accounting enabled. Sustained figures with the write load included are the ones that predict storm behavior.

Deployment flexibility: cloud, on-prem, or hybrid

Deployment questions are really two questions wearing one label. The first is where the platform can run today: containers on Kubernetes, virtual machines, bare metal, private or public cloud, or as a managed service the vendor operates. The second is whether those are the same software. Some architectures ship a cloud edition built on a different codebase from the on-premises product, which means your deployment choice silently becomes a product choice, with separate feature sets and upgrade cadences.

The strong answer is one artifact deployed anywhere: identical software in your data center or your cloud tenancy, so latency budgets, data-residency obligations, and a future migration all stay open. The full decision is bigger than one section; our cloud-native AAA on Kubernetes guide covers it in depth, including when on-premises wins.

Operational tooling: the dimension the diagrams leave out

No architecture diagram shows you the 3 a.m. experience of operating the platform, and that is where evaluations most often go wrong. A distributed AAA architecture without deep observability is a distributed debugging problem; the operational surface is what converts architectural sophistication into uptime you can collect.

Four things to inspect, not take on faith. APIs: is every configuration and provisioning action available programmatically, or do some paths exist only in a GUI? Config-as-code: can configuration live in version control and deploy through a pipeline, so changes are reviewable and reversible? Observability: are metrics exposed per realm and per network access server (NAS) group, at the level of subscriber authentication success rather than process health? Upgrades: are they rolling and zero-downtime, or does planned work still spend the availability budget through maintenance windows?

A vendor confident on this dimension will show you the API documentation and a live dashboard. A vendor weak on it will show you a slide about automation.

Scoring your shortlist: how to compare AAA server architectures side by side

A framework only helps if it ends up in the RFP. Score each shortlisted vendor 1–5 per dimension, in writing, right after each technical deep-dive, and weight the dimensions by your own risk profile: an operator planning a cloud migration weights deployment flexibility differently from one running a single national data center.

Where does Alepo land on its own framework? Alepo AAA Server is built as the left-hand column: RADIUS, Diameter, and TACACS+ converged on one stack with one subscriber view, session state externalized to a replicated data layer, active-active redundancy across sites with real-time database replication, engineered for 99.999% availability, and horizontal scaling in containerized deployment on Docker and Kubernetes, with the same software running on virtual machines, bare metal, private cloud, on-premises, or as a managed service.

The framework, though, is yours to run on everyone, including us. Book a demo our team will get in touch.

Frequently asked questions

Q1. What architectural factors matter most when comparing AAA servers?

Six dimensions separate platforms in practice: redundancy model, protocol convergence, session and data model, scaling approach, deployment flexibility, and operational tooling. Redundancy and data model dominate availability outcomes; the scoring table above turns all six into RFP questions.

Q2. What is the difference between active-active and active-passive AAA architecture?

Active-active runs all nodes and sites against live traffic, so a failure reduces headroom without a recovery step. Active-passive keeps a standby that must be promoted on failure; the practical differences are failover time, data loss during the transition, and the drift that accumulates on a system that never carries production load.

Q3. Is cloud-native AAA architecture better than on-premises?

Neither wins universally; latency budgets, data-residency obligations, and your existing operations model decide. The architectural question is whether the platform runs the same codebase in both, so the choice stays reversible.

Q4. What is a carrier-grade AAA server architecture?

A carrier-grade AAA architecture is one engineered for 99.999% availability with redundancy across nodes and sites, sustained (not burst) high transaction throughput with accounting enabled, convergence of RADIUS, Diameter, and TACACS+ on one platform, and proven operation at multi-million-subscriber scale.

Q5. How does AAA server architecture affect uptime?

The redundancy model is the largest single lever: active-active designs make node loss invisible and site loss survivable, while active-passive designs stake availability on a rarely rehearsed failover. Session-state externalization and zero-downtime upgrades decide how much of the remaining budget planned work consumes.

Q6. What is a distributed AAA server architecture?

A distributed AAA architecture is one in which session and subscriber state is replicated and synchronized across nodes and sites instead of pinned to a single instance, so any node can serve any request and failures move load without dropping sessions. It requires an externalized data layer and observability to match.

Q7. What architectural questions should I ask in an AAA vendor demo?

Ask for a live failover: a node killed under representative load with the authentication success-rate graph visible, before you accept a diagram walkthrough. Then ask where session state lives, whether the protocols share one data store, and whether cloud and on-premises deployments are the same software.