Carrier-grade AAA (Authentication, Authorization, and Accounting) can run on Kubernetes in both public cloud and on-premises environments, and Alepo has a production deployment at Tier-1 scale doing exactly this. The architecture requires stateful session management that goes well beyond standard Kubernetes patterns, comprehensive Diameter and RADIUS protocol support, and uptime disciplines that demand careful pod scheduling and active session replication design.
This guide covers the deployment options, how modern AAA coexists with a 5G core deployment, and the operational realities architects need to evaluate cloud-native AAA for their network. Ask most AAA vendors in 2026 whether their platform runs on Kubernetes and you will get a confident yes. Ask them to describe their production deployment, the actual architecture running in a live operator network at carrier scale and the conversation changes quickly.
Alepo runs containerized AAA in production at a Tier-1 US fiber operator, at carrier scale, on Kubernetes. That deployment answered engineering questions that no generic Kubernetes documentation could: how to keep RADIUS and Diameter session tables consistent across pod restarts, and how to achieve 99.999% uptime, that is, less than six minutes of unplanned downtime per year, when the orchestration layer is explicitly designed to kill and restart containers.
This guide covers what that deployment taught us, what the architecture actually looks like across deployment options, and where the transition to 5G Standalone complicates the picture in ways that generic cloud-native content does not address.
Why Do Modern Telecom Architectures Require AAA That Runs on Kubernetes?
What changes in 5G SA that makes legacy bare-metal AAA architecturally incompatible?
In a 4G EPC or legacy fixed-access architecture, AAA lives on dedicated hardware: a pair of servers, active-active clustered, static IP addresses, manually scaled. When traffic grows, you buy more hardware and configure the cluster. This works because subscriber counts grow slowly and traffic patterns are predictable.
A 5G Standalone core is built differently. The 5G core is a collection of containerized Network Functions (NFs)—AMF, SMF, UPF, PCF, AUSF, each running as microservices on Kubernetes, each expected to scale horizontally in response to demand.
A bare-metal AAA server sitting outside this architecture creates two concrete problems for operators running mixed access networks (e.g., 5G mobile + FTTH or Wi-Fi). First, it cannot scale elastically with network events. Second, it cannot integrate cleanly with the operator’s new lifecycle management, rolling software updates, horizontal scaling, observability pipelines because it has no Kubernetes operator managing it. The result is an island of legacy infrastructure inside an otherwise cloud-native environment.
Why does a cloud-native infrastructure require AAA that is orchestrated the same way?
The operational argument is clear: a network team running a cloud-native 5G core wants one orchestration plane, one way to deploy, monitor, update, and scale every network function. A bare-metal AAA server breaks that model. It has its own update cycle, its own monitoring tooling, and its own scaling procedure. Every time the team runs a core software update, they have to account for the AAA server separately.
There is also a CI/CD alignment requirement. Teams running cloud-native networks have shifted to continuous delivery pipelines for software. AAA software updates need to follow the same model: zero-downtime rolling deployments managed by Kubernetes, not maintenance window reboots of physical servers.
What Are the Deployment Options for Cloud-Native AAA in a Telecom Environment?
How does AAA run on Kubernetes on a public cloud?
The public cloud deployment model for carrier AAA uses a managed Kubernetes service as the orchestration layer, with Alepo AAA running as a containerized workload across a dedicated node pool. Node pools are sized for network workload characteristics memory-optimized instances for session table storage, network-optimized for packet throughput rather than the general-purpose compute pools used for stateless applications.
Alepo AAA supports deployment on GCP, AWS, and Azure. Public cloud networking for AAA deployments uses VPC peering between the operator’s core network and the cloud project running AAA, with SCTP (Stream Control Transmission Protocol) support required at the kernel level for Diameter protocol connectivity.
Production proof point: Alepo runs containerized AAA in production at a Tier-1 US fiber operator, at carrier scale, on Kubernetes, handling carrier-grade subscriber authentication across RADIUS and Diameter interfaces.
What does a private cloud AAA deployment look like?
Private cloud deployments run Alepo AAA on on-premises Kubernetes clusters, bare-metal Kubernetes, OpenShift, or VMware Tanzu using COTS hardware with SR-IOV (Single Root I/O Virtualization) where packet throughput requirements justify direct NIC access. The architecture is functionally identical to the public cloud model at the AAA container level; what changes is the underlying infrastructure and the tooling stack managing it.
Private cloud makes more sense than public cloud for carrier AAA in three scenarios: data-sovereignty mandates that require subscriber authentication data to stay within a specific jurisdiction, low-latency requirements where the round-trip to a public cloud region adds unacceptable authentication delay, and existing CAPEX commitments to on-premises data center infrastructure.
When does a hybrid cloud model make sense for telecom AAA?
The hybrid model runs latency-sensitive authentication functions on-premises while placing analytics, policy update pipelines, and observability infrastructure in the cloud.
This model is also the natural migration path for operators replacing legacy systems like Cisco CPAR. CPAR is a bare-metal AAA installation. A direct jump from bare-metal CPAR to full public-cloud AAA is a large architectural leap. Hybrid gives operators a stepping stone: replace CPAR with containerized Alepo AAA on-premises first, add cloud-side analytics and policy tooling, then migrate the authentication functions to public cloud when the operational model is proven.
How Does Containerized AAA Coexist with the 5G Core?
How do RADIUS and Diameter coexist with a 5G Core deployment?
This is the protocol mediation reality for every operator running a mixed fixed-and-mobile network in 2026. While the 5G Standalone core handles mobile authentication via the AUSF (Authentication Server Function) using HTTP/2 SBA interfaces, operators still rely heavily on RADIUS and Diameter for Fixed Wireless Access (FWA), Wi-Fi offload, and legacy FTTH broadband.
Alepo AAA terminates RADIUS, Diameter (S6a, S6b, SWx, SWm, Sh, Gx, Gy, Sd, STa, SWa, SWd), and TACACS+ natively on a single platform. By deploying Alepo AAA as a containerized workload on the same Kubernetes infrastructure as the 5G Core, operators achieve a single, unified orchestration plane. Network teams can manage, scale, and monitor their AAA infrastructure using the exact same cloud-native tooling they use for their 5G Network Functions, bridging the gap between legacy access protocols and modern cloud operations.
What Are the Operational Considerations for Running AAA at Carrier Scale on Kubernetes?
How do you achieve 99.999% uptime with AAA running as Kubernetes pods?
99.999% availability means less than six minutes of unplanned downtime per year. For an AAA server handling every subscriber authentication event in an operator network, that number is not aspirational, it is a contractual SLA. The tension with Kubernetes is real: pods can and do restart. The default Kubernetes model assumes stateless workloads where any pod restart is transparent. AAA is not stateless. A pod restart that discards in-flight authentication sessions, active accounting records, and CoA (Change of Authorization) state causes dropped sessions, revenue leakage, and subscriber-visible service disruption.
Active-active redundancy is the architecture-level answer. Both AAA nodes process traffic simultaneously; session state is continuously replicated between them at the application layer. A pod failure causes a brief re-authentication event for in-flight sessions, not a service outage. The SLA is maintained at the architecture level, not by trying to prevent pod failures (which is operationally impractical).
How does stateful session management work in a containerized AAA?
AAA session tables are deeply stateful: each entry contains the subscriber IP address, session start timestamp, accumulated accounting bytes, in-flight CoA state, and the current policy context.
Active-active replication at the application layer has the highest complexity but gives the lowest recovery time—no volume mount, no external dependency. Both K8s nodes maintain a full copy of the session table and replication happens in real time.
How does horizontal pod autoscaling work for carrier AAA workloads?
Kubernetes Horizontal Pod Autoscaler (HPA) scales pod replicas based on metrics. For carrier AAA, standard CPU/Memory signals are the wrong metrics—an authentication spike does not necessarily cause linear CPU growth.
Carrier AAA autoscaling uses custom metrics: authentication events per second, Diameter message rate, and active session count. These are exposed via the Prometheus metrics endpoint on the AAA pod and consumed by the HPA. When authentication throughput exceeds a defined threshold, the HPA adds pods before the existing pods reach saturation.
How Does an AI Control Plane Fit into a Cloud-Native AAA Architecture?
What can AI add to AAA policy management in a cloud-native context? Static RADIUS and Diameter policy is configured at provisioning time: the subscriber gets a profile, the profile maps to a QoS policy, the policy is applied at session establishment. The policy does not change unless an operator manually modifies it.
An AI control plane changes that model. Rather than waiting for a human-initiated policy change, an AI agent continuously analyses the telemetry stream that AAA generates—authentication events, session metrics, accounting records—and generates policy signals in near-real time. The signals feed back into the AAA via CoA, adjusting mid-session policy in response to detected conditions.
Alepo’s AI Agent for AAA implements this model, acting as a cybersecurity and performance control plane that runs on top of the AAA infrastructure to turn RADIUS, Diameter, and TACACS+ telemetry into real-time threat detection (like quota bypass attacks or APN tunnelling) and operational intelligence.
Frequently Asked Questions
Q. Can a carrier-grade AAA server run on Kubernetes without compromising the 99.999% uptime SLA?
Yes. Achieving 99.999% availability requires active-active session replication, Pod Disruption Budgets, and node affinity rules that separate replica pods across physical nodes. Alepo’s production deployment at a Tier-1 US fiber operator demonstrates that Kubernetes is a viable operational platform for carrier-grade AAA.
Q. What cloud platforms support cloud-native AAA for telecom?
Alepo AAA deploys on GCP, AWS, Azure, and on-premises Kubernetes environments including bare-metal K8s, OpenShift, and VMware Tanzu. The containers are platform-agnostic.
Q. How does cloud-native AAA coexist with a 5G network?
While the 5G Core uses the AUSF for mobile authentication, fixed-access broadband, FWA, and Wi-Fi offload rely on RADIUS/Diameter-based AAA. Alepo AAA supports these legacy protocols while running on the same Kubernetes orchestration layer as the 5G core, giving network operators a unified management plane for mixed-access networks.
Q. What happens to in-flight AAA sessions when a Kubernetes pod restarts?
In a properly architected active-active deployment, session state is continuously replicated between both AAA nodes at the application layer. If one pod restarts, the surviving node holds the complete session table and continues processing without subscriber-visible disruption.
Q. How does cloud-native AAA help operators migrating off Cisco CPAR?
CPAR reached end-of-life. Alepo’s containerized AAA offers a safe migration: operators can deploy on-premises Kubernetes as a CPAR replacement with no public cloud requirement, then add cloud-side analytics and policy tooling in phase two.
Planning a Cloud-Native Deployment?
Alepo’s cloud AAA team has run containerized AAA in production at Tier-1 carrier scale. If you are evaluating cloud-native AAA for a CPAR migration, a mixed fixed-and-mobile architecture, or Wi-Fi offload, the conversation is worth having before you commit to an architecture direction.”
