AAA server capacity planning comes down to one decision, size for sustained transaction throughput, not the burst peak a datasheet quotes. AAA (authentication, authorization, and accounting) sizing has four steps: measure your current baseline (sustained average transactions per second and your peak-to-average ratio), forecast subscriber and traffic growth over 12–24 months, add a 30–50% headroom buffer above the forecasted peak, and revisit the plan on a fixed cadence. Sizing for today’s average traffic is how AAA platforms end up undersized long before their planned refresh.
Ask a vendor what their AAA server can do and you will usually get a burst number: the highest rate the platform survived for a few minutes in a lab. Ask your network what it needs and the answer is a sustained number, the load the platform must carry hour after hour at your busiest, with authentication latency flat the whole time. Most AAA sizing mistakes come from confusing the two.
AAA server capacity planning means sizing infrastructure for sustained transaction throughput based on current baseline load, forecasted subscriber growth, and a headroom buffer, not today’s average traffic alone. This guide walks through that methodology step by step, with a worked example, for network architects and capacity planners sizing RADIUS and Diameter infrastructure.
Sustained TPS vs. Burst TPS
Sustained transactions per second (TPS) is the rate an AAA server holds continuously, for hours, while meeting its latency and availability targets. Burst TPS is a short-lived ceiling: what the platform absorbs for seconds or minutes before queues build and response times climb. Sustained TPS is the real sizing input, because AAA load at a busy hour is not a spike; it is a plateau.
A transaction here means any request the server must answer. That includes an authentication exchange, opened by an Access-Request in the RADIUS terms of RFC 2865. It also includes an accounting start or stop as defined in RFC 2866, an interim accounting update as specified in RFC 2869, a re-authentication, a change-of-authorization, and a TACACS+ (Terminal Access Controller Access-Control System Plus) command authorization on the device-administration side.
Every subscriber session generates a stream of these across its lifetime. AAA traffic therefore scales with both subscriber count and session behavior, and RADIUS server capacity planning that counts only logins under sizes the accounting load riding on top of them.
Burst capacity still matters. Reconnect storms after a regional outage can push instantaneous load to many times the norm, but that is a separate question, answered by scale-out behavior and storm testing rather than by the baseline sizing math. Plan sustained capacity first; validate storm behavior second.
Step 1: Establish Your Current Baseline
The baseline step answers two questions from measured data: what is your sustained average TPS today, and what is your peak-to-average ratio? Both come out of your existing AAA and network access server (NAS) logs, not from estimates.
A common mistake is to skip measurement and derive load from subscriber count alone. Two operators with identical subscriber bases can differ several-fold in AAA load, depending on interim accounting intervals, re-authentication timers, Wi-Fi offload behavior, and device churn. The arithmetic is unforgiving: a five-minute interim accounting interval produces twelve accounting transactions per session-hour where a one-hour interval produces one. If you have a running network, measure it, pull transaction counts per hour across at least two full weekly cycles, so that weekday, weekend, and evening-peak patterns are all in the data.
From that dataset, record three numbers:
- Sustained average TPS — the mean across the measurement window.
- Sustained peak TPS — your busiest sustained hour, not the single worst second.
- The peak-to-average ratio between them.
The ratio is the number you will reuse every time you re-plan, because growth forecasts predict average load and the ratio converts an average into a design peak. Split the counts by transaction type as well as by hour: authentication and accounting volumes grow on different curves, and an accounting-heavy profile sizes differently from an authentication-heavy one.
For a greenfield network with no logs to measure, model per-subscriber behavior explicitly, sessions per day, accounting interval, re-authentication interval and validate the model against reality in the first quarter of operation.
Step 2: Forecast Subscriber and Traffic Growth
Growth forecasting turns today’s baseline into the load you are actually buying for. Model 12–24 months out: any shorter and you re-procure constantly, any further and the forecast is guesswork.
Tie the forecast to plans, not trend lines. Marketing’s subscriber targets, planned footprint expansion, a new mobile virtual network operator (MVNO) agreement, a public Wi-Fi rollout, an Internet of Things (IoT) onboarding program, each lands on the AAA layer as a specific traffic increment. Some increments carry far more transactions per subscriber than others. A million low-churn broadband subscribers generate a different AAA profile than a million Wi-Fi offload devices re-authenticating as they move.
Factor in per-subscriber intensity changes too, because AAA server traffic forecasting is not just subscriber arithmetic. 5G raises session volumes, and depending on how much of the estate is standalone versus non-standalone, keeps Diameter in play for non-3GPP access and interworking alongside service-based signaling (the Diameter base protocol is defined in RFC 6733). Shortening interim accounting intervals to tighten revenue assurance multiplies accounting traffic with no new subscribers at all.
Apply the growth factor to your sustained average TPS, then reapply your measured peak-to-average ratio to get the forecasted sustained peak.
Step 3: Build In Headroom
Headroom is the buffer between your forecasted sustained peak and the capacity you actually deploy. A common planning buffer is 30–50% above the forecasted peak: toward the lower end when growth is predictable and scale-out is fast, toward the upper end when growth is volatile, procurement is slow, or the platform scales in large increments.
The buffer absorbs three specific things. The first is forecast error, since subscriber growth rarely lands on plan. The second is event-driven surges: seasonal peaks, promotions, and weather-driven reconnect waves that sit above even a well-measured peak hour. The third is performance behavior near saturation, because authentication latency does not degrade linearly. A server run close to its ceiling can meet its TPS number while quietly blowing its latency budget.
Elastic scale-out shortens the reaction time but does not remove the need for a buffer the scaling trigger still has to fire before the peak, not during it. Undersized AAA shows up as authentication delays and failures under peak load; the operational fallout, and the risk register that goes with it.
A Worked AAA Server Capacity Planning Example
A worked AAA server capacity planning example runs the four steps in order: measured baseline, growth forecast, headroom buffer, target sustained TPS.
The figures below are illustrative, chosen to show the arithmetic. They are not a sizing recommendation for any specific operator; run the steps against your own measured data.
Take a hypothetical regional broadband operator. Log analysis over two weekly cycles shows a sustained average of 800 TPS across authentication and accounting traffic, with the busiest sustained hours running at 2,000 TPS: a peak-to-average ratio of 2.5.
The business plan projects 15% annual subscriber growth over a 24-month horizon, with per-subscriber behavior unchanged. Applied to the sustained peak, 2,000 × 1.15 × 1.15 ≈ 2,645 TPS of forecasted sustained peak.
Growth is moderately predictable but procurement cycles are slow, so the operator picks 40% headroom: 2,645 × 1.4 ≈ 3,700 TPS. The capacity plan therefore calls for a platform validated at roughly 4,000 sustained TPS, with storm behavior tested separately above that line.
For context on what a candidate platform should give you at the top end, look at the architecture rather than the headline number. The Alepo AAA Server deploys in containers (Docker and Kubernetes), on virtual machines, on bare metal, in private or public cloud, and on-premises, with N+1 and N+N redundancy and real-time database replication, engineered for 99.999% availability. Session state is held in stateless storage with database persistence, so added capacity is a scheduling decision rather than a rebuild.
Whatever platform you shortlist, insist on a sustained throughput number measured under your own peak authentication and accounting profile, with the test conditions, accounting load, and latency percentile stated. That is the number this method produces, and it is the only one worth sizing against. The takeaway for a capacity planner is not a vendor’s headline number but the margin you can prove: a platform that adds capacity by scheduling instances turns future growth into a configuration change instead of a re-procurement cycle.
Revisiting Your Capacity Plan Over Time
A capacity plan is a forecast, and forecasts decay. Compare fresh baseline measurements against the plan every six months, and re-run the full sizing exercise annually or whenever the network changes shape.
Define scaling triggers in advance, so capacity decisions are made by threshold instead of by incident: when the measured sustained peak crosses an agreed-upon fraction of deployed capacity, the next scaling step begins. On a cloud-native AAA platform that step is scheduling more instances; on appliance-era infrastructure it is a procurement cycle, which is what the headroom buffer was sized to cover. Either way, AAA server growth planning works best as a standing review with named owners, not a one-time spreadsheet.
Getting the sizing right protects revenue as well as connectivity. Every accounting record an overloaded server drops is unbilled usage, a failure mode unpacked in how AAA reduces revenue leakage.
Sizing an AAA deployment now? Walk your measured baseline and growth plan against the Alepo AAA Server in a working session, storm scenarios included.
Frequently Asked Questions
Q1. How do I do capacity planning for an AAA server?
Follow four steps: measure your current baseline (sustained average TPS and peak-to-average ratio from live logs), forecast subscriber and traffic growth over 12–24 months, add a 30–50% headroom buffer above the forecasted sustained peak, and revisit the plan on a fixed cadence with predefined scaling triggers.
Q2. How do I calculate the TPS I need from an AAA server?
Base it on sustained peak load, not burst spikes. Take your measured sustained average TPS, multiply by your measured peak-to-average ratio, apply your growth forecast, then add headroom. The result is the sustained TPS figure a candidate platform must hold for hours under test, not merely touch for seconds.
Q3. How much headroom should I plan for AAA server capacity?
A common buffer is 30–50% above your forecasted sustained peak. Use the lower end when growth is predictable and the platform scales out quickly; use the upper end when growth is volatile, procurement is slow, or capacity is added in large increments.
Q4. What inputs are needed for an AAA sizing exercise?
Three measured numbers and one plan: sustained average TPS, sustained peak TPS, and the peak-to-average ratio between them all pulled from your own AAA and network access server logs across at least two weekly cycles plus a 12–24 month subscriber and service plan to apply against them.
Q5. How do I forecast subscriber growth for AAA sizing?
Use 12–24 month subscriber projections tied to concrete business and network plans (marketing targets, footprint expansion, MVNO or Wi-Fi programs) rather than trend extrapolation. Convert subscribers to transactions using measured per-subscriber behavior, since different service types generate very different AAA loads.
Q6. What’s the difference between average and peak load in AAA capacity planning?
Average load is your typical transaction rate across the measurement window; sustained peak is the rate at your busiest hours, and it is what determines required capacity. The ratio between them, measured from your own logs, is what converts a subscriber growth forecast into a design peak.
Q7. How does 5G affect AAA capacity planning?
5G raises session volumes per subscriber, which increases sustained TPS requirements. Depending on how much of the estate is standalone versus non-standalone, it also keeps Diameter signaling in play for non-3GPP access and interworking alongside service-based interfaces. If a 5G core milestone sits inside your planning horizon, model it as a per-subscriber intensity increase, not just a subscriber-count increase.
Q8. How often should AAA capacity plans be revisited?
Compare fresh baseline measurements against the plan every six months, and re-run the full sizing exercise annually or sooner if the network changes shape through an acquisition, a new access technology, an accounting-interval change, or a 5G core milestone.
Q9. What happens if an AAA server is undersized?
Authentication slows and then fails under peak load, which subscribers experience as being unable to connect, and accounting records can be dropped, which becomes unbilled usage. Latency degrades sharply near saturation, so an undersized server can look healthy at average load and fail when traffic matters most.
