Solutions
Alepo AAA Solutions
Telco Type
FTTH Broadband Provider
Country
North America
Cloud-Native AAA in Practice: An Alphabet Company’s FTTH Deployment
A case study of how an Alphabet company operating a fast-growing FTTH broadband business modernized its AAA layer: why it moved off appliance-based platforms, how the cloud-native deployment was architected, and what changed operationally. Prepared for operators evaluating AAA modernization.
Cloud-native
containerized, in the operator’s own cloud
Elastic
horizontal autoscaling, no fixed-capacity ceiling
API-first
subscriber operations run end to end via secure APIs
Near real-time
service-state changes: barring, restoration, speed
Background
The operator runs a cloud-first technology model, and needed its AAA layer to match. As the subscriber base grew, AAA became too critical to run on traditional appliance-based platforms or lightweight open-source alternatives. Neither could deliver the availability, integration depth, or programmability the business required. It moved its AAA layer to a cloud-native platform deployed inside its own public cloud environment.
The Requirements
The program was framed around four requirements, the same ones any operator faces when moving a critical control function to cloud infrastructure:
Can it scale elastically?
Support a rapidly growing subscriber base with high availability, absorbing growth and traffic peaks without a fixed-capacity ceiling.
Does it integrate cleanly?
Work with the surrounding estate (BNG, OSS, BSS, IPAM, and identity infrastructure) rather than operating as an isolated silo.
Is it programmable?
Control provisioning, service barring, speed changes, and live sessions through secure APIs rather than manual operational workflows.
Is it operable in production terms?
Demonstrate failover, monitoring, and day-to-day manageability on public cloud, not just functional correctness.
The Architecture
The AAA stack was deployed as containerized workloads on Kubernetes inside the operator’s own public cloud environment: horizontal autoscaling to absorb growth and traffic peaks, dedicated TACACS+ services for secure device administration, and a managed cloud database service for subscriber data.
What Changed Operationally
Subscriber operations that previously required manual workflows now run end to end through token-secured REST APIs:
Subscriber lookup and visibility
Records retrieved by username, IP, or filtered attributes, speeding troubleshooting.
Provisioning and updates
Profiles, service groups, and speed plans created or changed via API.
Static IP service delivery
IPv4 and IPv6 assignment for SMB business-grade connectivity.
Walk-in / walk-out states
Service restricted or restored on account status, supporting revenue assurance.
Bridge mode
SMB subscribers use their own router, service logic preserved.
Session control
Active sessions terminated and new service states applied in near real time.
Why the API Layer Matters
The program’s defining choice was treating AAA as a programmable platform rather than a closed backend. External systems call it directly through token-authenticated REST APIs, making AAA an active participant in workflow orchestration across BSS, OSS, and IPAM, rather than a box those systems work around.
Programmability separated the platform from a backend: an API-first AAA is orchestrated by BSS, OSS and IPAM instead of worked around.
Elasticity came from the architecture: containerized workloads with autoscaling removed the capacity ceiling that appliance sizing fixes at procurement.
Failover, monitoring and day-to-day manageability were proven before production commitment, not after.
What to Verify When Selecting a Cloud-Native AAA
Checks drawn from this deployment, useful regardless of vendor or cloud provider:
Which subscriber operations still require manual intervention, and what do they cost in time and errors?
Can your AAA scale horizontally under load, or is capacity fixed at procurement time?
How would AAA integrate with your IPAM, OSS/BSS, and identity systems: native APIs or custom glue?
Are service-state changes (barring, restoration, speed) enforceable in near real time?
Can failover, monitoring, and day-to-day manageability be demonstrated before production commitment?
