A cloud RADIUS server is an AAA (Authentication, Authorization, and Accounting) platform that runs in cloud infrastructure instead of your own data centre, authenticating and accounting subscriber sessions over the network rather than the LAN. The appeal is elastic capacity and less hardware to own. The constraint is physics: RADIUS was designed to sit next to the equipment it serves, so latency, Change-of-Authorization reachability, and data residency decide whether it works. Most operators land on a hybrid design, and many have it run as a managed service rather than staffing it themselves.
If you searched “cloud RADIUS” and got nothing but 802.1X for office Wi-Fi and how to replace an on-premises NPS box, you are not imagining it. That market is well served. Yours is not the same problem.
An enterprise cloud RADIUS deployment authenticates a few thousand laptops against a directory. The AAA belonging to a communications service provider (CSP) authenticates PPPoE and IPoE sessions on a broadband network gateway (BNG), EAP-SIM handsets moving on and off carrier Wi-Fi, mobile virtual network operator (MVNO) data sessions, and TACACS+ logins on network devices while producing the accounting records your billing runs on. When an office RADIUS server has a bad five minutes, people re-join the Wi-Fi. When an operator’s AAA has a bad five minutes, a region cannot get online.
What Is a Cloud RADIUS Server?
A cloud RADIUS server is a RADIUS-speaking AAA platform hosted in cloud infrastructure – a public cloud region, a private cloud, or a provider-operated environment – that your access equipment queries across a network path rather than a data-centre floor. The protocol does not change. RFC 2865 still defines the packet format, UDP 1812 still carries authentication, 1813 still carries accounting. What changes is where the server lives and who operates it.
Two things get bundled together here that are not the same decision. Hosting location is where the software runs: your rack, your private cloud, or a hyperscaler region. Operating model is who runs it: your NetOps team, or a vendor delivering it as a managed service. You can host in public cloud and operate it yourself, or keep the platform on-premises and have a vendor run it. Conflating the two is how procurement ends up buying a location when the team needed people.
“Managed RADIUS AAA” points at that second axis: someone else carries the upgrade cycle, the certificate rotations, and the 3 a.m. page. For a mid-size internet service provider (ISP) where one engineer has ever done a version upgrade, that is often the more valuable half of the deal.
The Term Means Two Different Things
In enterprise IT, “cloud RADIUS” means a hosted 802.1X service for WPA2/WPA3-Enterprise Wi-Fi and VPN, backed by a cloud directory. Modest transaction rates, straightforward use case.
In telecom, a cloud AAA server carries authentication for revenue-generating access: broadband session establishment, Wi-Fi offload, mobile data, and the accounting feed into billing. It needs Diameter alongside RADIUS, the full Extensible Authentication Protocol (EAP) family, and Change-of-Authorization (CoA) for live session control – the differences between RADIUS, Diameter, and TACACS+ are where that gap shows first. If a vendor’s cloud RADIUS documentation never mentions CoA, Diameter, or five-nines availability, it was built for the first market.
Cloud vs On-Premises AAA: Key Differences
Five differences matter in practice. Everything else, including the CAPEX-to-OPEX shift, follows from them.
| Dimension | On-premises AAA | Cloud RADIUS / AAA |
| Authentication latency | Sub-millisecond to low single-digit ms; server sits beside the BNG or wireless controller | Adds network round-trip time, and EAP methods multiply it across several exchanges |
| Capacity model | Sized for peak plus headroom; upgrades are procurement projects | Elastic; scale out for auth storms and back down after |
| CoA reachability | Server reaches the network access server (NAS) on the same routed network | Cloud-to-NAS path must be engineered through firewalls and NAT |
| Operational burden | Your team owns upgrades, patching, tuning, on-call | Shared or fully transferred under a managed service |
| Data residency | Wholly inside your jurisdiction and audit boundary | Depends on region selection and what the regulator accepts |
Latency is the one that surprises people. AAA is not a back-office system that can afford to be a little slow; it sits in the subscriber’s connection path. A customer power-cycling their router is waiting on your AAA response before the session comes up.
And EAP is not a single request. An EAP-AKA’ or EAP-TLS exchange involves several round trips between the access equipment and the AAA server, so added latency is not paid once. It is paid per round trip. Fifty milliseconds of extra path latency becomes several hundred milliseconds of added authentication time – invisible on a dashboard, very visible during a morning re-connect surge.
Cloud RADIUS Architecture and Deployment
Four patterns cover almost every operator deployment, and larger estates run more than one: cloud-hosted and operator-run, private cloud or virtualized, fully managed by the vendor, and edge-cached hybrid. The first three differ mainly in who holds the keys – the deployment table further down maps them.
The fourth is where most operators end up. Edge-cached hybrid serves authentication locally at each point of presence, with the cloud carrying control plane, profile master, analytics, and cross-region state. It resolves the latency and survivability problems, and gets its own section below. Whichever you pick, two design questions decide whether it works.
The Transport Question Nobody Asks Early Enough
Classic RADIUS was designed for a trusted network. It runs over UDP with a shared secret, and only the User-Password attribute is obscured – usernames and accounting detail travel in the clear. Acceptable in 1997 when the server was three racks away; a different proposition across a path you do not fully control. Pick one of three answers deliberately rather than inherit one:
- RadSec (RFC 6614), RADIUS over TLS on TCP 2083. Encryption, mutual certificate authentication, and a connection that recovers cleanly instead of silently dropping datagrams. It also introduces certificate lifecycle management, which is real work.
- IPsec or private interconnect between access sites and the cloud. Moves the problem to the network layer, where your team already has tooling.
- Neither, on a genuinely private path. Defensible on dedicated interconnect inside your own footprint. Not over the public internet, and an auditor will ask.
CoA is the other design-time item. CoA and Disconnect-Message (RFC 5176) are how the AAA server pushes changes into a live session: a policy change, a move to a captive portal after a quota trip, a termination. Unlike everything else in RADIUS, it is initiated by the server toward the NAS, usually on UDP 3799.
So your cloud AAA needs a routable inbound path back to every BNG, BRAS, and wireless controller in the estate, through whatever NAT and firewalling sits between. Operators tend to discover this after cutover, when authentication works perfectly and quota enforcement quietly does not.
Benefits of Cloud-Managed AAA
Capacity that matches demand instead of forecast. AAA load is spiky in ways that are hard to size for. A regional power event that drops tens of thousands of broadband lines produces a re-authentication surge when power returns, and a BNG maintenance window does the same. On-premises, you buy for that peak and let it idle – the problem self-scaling AAA solves from the other direction.
Operational load transfers. Under a managed model, upgrades, patching, tuning, and first-line diagnosis stop being your team’s problem. Operators undervalue this in the business case and appreciate it most a year in. Diagnosis gets easier too: operators report meaningfully faster fault-finding when AAA logs are queryable across the estate rather than tailed per node.
Limitations and Considerations
An honest list, because a cloud RADIUS design that ignores these fails in month three rather than week one.
1.Latency, again.
The most common reason a pure-cloud design gets revised. Measure the real round-trip from each access site to the candidate region, then multiply by the EAP round trips your dominant method requires.
2.Survivability when the path to cloud fails.
If the link between a site and your cloud region degrades, on-premises AAA would be unaffected and cloud AAA is unreachable – no new session can be established. Local authentication at the edge is what keeps a transport incident from becoming a service outage.
3.Data residency and regulatory posture.
Subscriber credentials, subscriber identities, and IP-to-subscriber mappings are exactly the data regulators care about, and lawful intercept obligations often assume a jurisdiction. This is a legal review, not an architecture review, and it should start early because it can eliminate options.
4.Dependencies that stay in the core.
A cloud AAA doing EAP-SIM or EAP-AKA’ still has to reach the home subscriber server (HSS) or unified data management (UDM) function over Diameter SWx for authentication vectors, per the 3GPP security architecture in TS 33.501. Interfaces to the policy control function (PCF) and online charging system (OCS) behave the same way. Moving the AAA to cloud does not move its dependencies, and each hop back spends the same latency budget.
5.Accounting volume and egress.
Interim updates across a large broadband base generate surprisingly large record volume, and those records have to reach mediation and billing. If mediation stays on-premises while AAA moves to cloud, model the egress cost before the design locks.
6.Shared secret and certificate sprawl.
A secret mismatch is the worst class of RADIUS failure: a packet that fails authenticator validation is dropped with no response, so nothing is logged as an error at either end and the records simply never exist.
Hybrid Cloud RADIUS Deployments
Ask an architect who has run this and the answer is consistent: keep the authentication decision close to the access network, and centralize everything that benefits from being central.
In practice that means local AAA nodes at each site handling authentication and accounting collection, with the cloud holding the profile master, policy definitions, cross-region session visibility, and analytics. Profiles and policy replicate outward. Accounting aggregates inward. If the cloud path drops, the local node keeps authenticating from its cached profiles and queues accounting for reconciliation later.
The decisions that matter here are the boring ones. How stale can a cached profile be before you stop trusting it? What is the degraded-mode authorization policy – deny, or allow with a default service profile? How long can a node buffer accounting before you risk losing billable usage? Answer those three in a document, not in an incident.
Alepo AAA Deployment Options
The Alepo AAA Server is a 3GPP-compliant platform that terminates RADIUS, Diameter, and TACACS+ on one stack, with the full EAP family – EAP-SIM, EAP-AKA, EAP-AKA’, EAP-TLS, EAP-TTLS, EAP-PEAP – plus PAP/CHAP and certificate-based authentication. The point relevant here: the same platform runs in every deployment model, so a hybrid design does not mean two products.
| Deployment | Where it fits |
| Containerized (Kubernetes) | Cloud-native operators, CI/CD, elastic scale, 5G core alignment |
| Private cloud (AWS, Azure, GCP) | Cloud-first operators with residency-controlled regions |
| Virtualized (VM) | Existing VMware or OpenStack estates, hyperscaler IaaS |
| Bare-metal | Highest-throughput, latency-sensitive packet-core deployments |
| On-premises | Regulatory or data-sovereignty mandates, existing data-centre commitments |
| Fully managed service | Operators who want Alepo to run it: people, process, and platform |
Deployments are built as active-active geo-redundant pairs, which is what makes the hybrid patterns above practical: the secondary is a peer, not a cold standby.
The Alepo AI Agent for AAA turns RADIUS, Diameter, and TACACS+ logs into an operational and security control plane rather than an archive – anomaly detection, brute-force and credential-stuffing detection, capacity trending, error-pattern root-cause analysis. It also decodes reject codes and EAP failure traces in plain language, which matters more in a distributed deployment than when everything sits in one rack – increasingly how operators use AAA as a security control plane.
Alepo has been building carrier-grade AAA for Tier-1 and Tier-2 operators across the Middle East, Europe, LATAM, Africa, and Asia – more than ten AAA deployments globally, including one running over 200,000 concurrent subscribers. Most of that work has been migrating operators off end-of-life or home-grown AAA rather than greenfield builds, which is usually the harder job.
That migration point deserves directness. Teams running a self-assembled open-source RADIUS deployment are usually not missing features – those protocol implementations are mature. What drives the evaluation is that Diameter and TACACS+ arrive as separate projects, and that knowledge concentrated in one or two engineers becomes a governance problem the first time an auditor asks who supports it.
FAQs
Q1. What is a cloud RADIUS server?
An AAA platform hosted in cloud infrastructure that authenticates, authorizes, and accounts network sessions over a network path instead of a local data-centre link. The protocol is unchanged from RFC 2865; what changes is where the server runs, how the transport is secured, and often who operates it.
Q2. Is cloud RADIUS secure enough for subscriber authentication?
Not by default. Classic RADIUS runs over UDP with only the password attribute obscured, so a cloud deployment needs RadSec (RADIUS over TLS, RFC 6614), IPsec, or a private interconnect, plus strict source-address controls and certificate rotation.
Q3. What is the difference between on-premises and cloud AAA?
On-premises gives the lowest authentication latency, direct CoA reachability, and a data boundary inside your jurisdiction, at the cost of hardware refresh cycles and full operational ownership. Cloud gives elastic capacity and the option to transfer operations, at the cost of added path latency and dependence on connectivity.
Q4. Can a cloud RADIUS server handle Change-of-Authorization?
Yes, if the network design allows it. CoA and Disconnect-Message (RFC 5176) are sent from the AAA server toward the NAS, typically on UDP 3799, so the cloud needs a routable inbound path to every BNG, BRAS, and wireless controller through any intervening NAT and firewalls. Confirm before cutover, not after.
Q5. How do we migrate from legacy AAA to a cloud-native platform?
Staged: stand the new platform up in parallel, replay live authentication traffic in shadow mode without acting on responses, then move traffic one NAS group or realm at a time with rollback ready. Migrate accounting last and reconcile against the legacy system first. The zero-downtime AAA migration checklist has the sequence.
Conclusion
Cloud RADIUS is not a lift-and-shift, because RADIUS was designed to sit next to the equipment it serves. Three questions decide the design: measured latency from your access sites to the candidate region, whether CoA can reach every NAS, and what happens to session establishment when the path to cloud degrades. Answer those and most operators arrive at a hybrid – and the operating model stays a separate decision from the hosting location, often the more consequential one.
Bring your own numbers. Measure the round-trip time from your two busiest access sites to the cloud region you are considering, and count the EAP round trips your dominant authentication method uses. That product is your added authentication delay, and it decides whether pure cloud, hybrid, or on-premises is right for you. We will walk the design through against that number, not a reference architecture.
