Achieve elastic scalability for voice communications using Ribbon SBC on Amazon EKS

Introduction

Voice communications infrastructure remains a critical challenge for organizations migrating to the cloud. While IT workloads successfully move to AWS, Session Border Controllers (SBCs) often stay anchored to legacy hardware platforms that cannot scale dynamically or integrate with modern cloud operations.

Ribbon’s SBC Cloud Native edition (CNe) on Amazon Elastic Kubernetes Service (Amazon EKS) delivers a containerized, cloud-native approach to voice security infrastructure. This post explains how the solution minimizes overprovisioning, automates lifecycle management, and aligns SBC operations with customers’ existing cloud governance requirements.

Many enterprises, communications service providers (CSPs), and Unified Communications as a Service (UCaaS) providers have hesitated to migrate Session Border Controllers (SBCs) to the cloud. The reluctance isn’t about resistance to modernization. Rather, cloud-native SBC solutions that fully satisfy the demanding requirements of mission-critical voice security workloads have only recently begun to emerge. Some traditional virtualized SBCs simply moved legacy architectures onto cloud infrastructure without embracing cloud-native principles offering no elastic scaling, no automated lifecycle management, no integration with Kubernetes-native tooling.

Through a Strategic Collaboration Agreement, Ribbon and AWS have addressed this gap by delivering a cloud-native SBC solution on Amazon Elastic Kubernetes Service (Amazon EKS). It is designed to meet carrier-grade performance requirements while providing the automation, resiliency, and cost efficiency that organizations expect from cloud infrastructure.

Ribbon’s SBC Cloud Native edition (CNe) solution on Amazon EKS can transform voice security infrastructure. It delivers elastic scalability that minimizes overprovisioning and multi-Availability Zone (AZ) resiliency. Automated lifecycle management through GitOps practices and AWS-native integration improve operational efficiency. The solution also aligns with enterprise cloud governance, meeting security and operational requirements established by customers’ cloud operations teams. This helps organizations to move away from expensive hardware refresh cycles to pay-as-you-go cloud economics while maintaining the reliability and security needed for real-time voice communications.

Why is Moving Voice Security Workloads to the Cloud Challenging?

Legacy on-premises SBC infrastructure presents challenges with manual scaling and overprovisioning. Some organizations cannot dynamically adjust capacity for fluctuating traffic demands. They often overprovision capacity to handle peak traffic, leaving additional hardware capacity idle during normal operations.

Traditional deployments (on-premises/virtualized) often require geographic redundancy through 1:1 active-standby configurations, thereby maintaining infrastructure across separate data centers with one system actively processing traffic while the standby remains idle but likely still requiring full investment and ongoing maintenance costs.

Additionally, some current SBC deployments have limited or no support for infrastructure-as-code, GitOps based automated rollouts, or canary deployments and modern CI/CD practices.

Without integration into cloud-native observability, monitoring, and security tools, operations teams often manage voice infrastructure with separate tooling, dashboards, and expertise from their broader IT environment. This can create inefficient operational silos that increase overhead.

AWS infrastructure supports high throughput, real-time workload requirements through high-performance networking and optimized compute instances. AWS addresses data sovereignty concerns by giving customers full control over where their data is stored and processed through AWS Regions (choose specific geographic locations), AWS Dedicated Local Zones and encryption with customer-managed keys, ensuring data never leaves a chosen AWS Region unless the customer explicitly moves it.

Ribbon SBC CNe (Cloud Native edition) Architecture on AWS

Ribbon’s cloud-native SBC solution on Amazon EKS address voice security through a modern microservices architecture that changes how organizations deploy and manage real-time communications infrastructure. The solution architecture is designed for the four pillars of voice infrastructure: resiliency, efficiency, scalability, and high availability.

Microservices Architecture for Independent Scaling

Ribbon’s containerized architecture, as shown in Fig 1, decomposes traditional monolithic SBC functions into independent microservices – signaling, transcoding, routing, OAM and media processing, each running as Kubernetes pods orchestrated by Amazon EKS. This disaggregation enables organizations to scale each component independently. For example, Session Control pods scale based on concurrent voice calls, whereas Registration Services pods scale based on SIP registration load.

Fig 1: Ribbon SBC CNe Microservices Architecture

Multi-Availability Zone Resiliency

Ribbon SBC CNe uses AWS geographic infrastructure to deliver N:K resiliency. Ribbon SBC deployment distributes microservices across multiple AZ’s within an AWS Region, with Amazon EKS automatically redistributing pods when failures occur, as shown in Fig 2. Unlike legacy deployments that maintain additional idle standby hardware, Ribbon’s cloud-native architecture eliminates dedicated standby instances, therefore all resources actively process traffic. In the event of failure, Kubernetes reschedules affected pods to healthy nodes in an alternate AZ.

This multi-AZ architecture is designed to provide high availability with recovery times less than 6 seconds. When an EKS Worker node (Elastic Compute Cloud EC2 instance), pod, or entire AZ fails, Amazon EKS orchestrates automatic failover, maintaining service continuity for voice traffic, thereby achieving the reliability required by most carriers.

Fig 2: Ribbon SBC CNe – High Availability and Resiliency

Automated Elastic Scaling

Ribbon’s integration with Amazon EKS Cluster Autoscaler enables dynamic infrastructure scaling to match real-time traffic demands. During off-peak hours, the solution automatically scales down EKS (EC2) worker nodes and SBC pods. When traffic surges occur (for example, when holiday calling spikes, emergency events occur, or viral marketing campaigns launch), the Cluster Autoscaler provisions additional EC2 instances while Kubernetes scales out SBC microservices to handle increased load as depicted in Fig 3.

Consider a large U.S. enterprise call center fronted by an SBC. Call volumes range from zero outside normal business hours to 30,000 simultaneous sessions during peak periods, all requiring transcoding for audio compatibility between customers and agents.

In an Amazon Virtual Private Cloud (VPC) deployment, the SBC CNe automatically scales EC2 instances to match workload. Off-peak hours (14 hours every business day plus weekends and holidays) require as few as 3 instances, versus 33 instances at peak. On-premises, you would need at least 33 servers to handle peak traffic, despite those servers sitting idle 58% of the year. With typical overprovisioning of 15% to guard against unforeseen traffic spikes, that number climbs to 38 servers drawing power, cooling, and data center real estate costs around the clock. The resulting inefficiencies compound:

Servers drive continuous power and cooling costs year-round
Data center real estate costs persist regardless of utilization
Intra-day variability (lunch hours, shift transitions) leaves additional capacity underutilized

In an Amazon VPC, the Ribbon SBC CNe reduces these costs by automatically scaling compute to match demand.

Fig 3: Ribbon SBC CNe Automated Elastic Scaling

Session State Handling During Failover

Voice sessions are stateful and real-time, requiring special handling for mid-call failures. When a pod fails mid-call, the system must preserve active SIP dialogs and RTP media streams without dropping calls. Ribbon SBC CNe addresses this through three mechanisms:

Standby call processing pods preconfigured and ready to take over SIP signaling and RTP media from any failed active pod
A resilient Redis DB that stores call state (SIP identifiers and associated RTP stream information) reported by all active call processing pods across the cluster
A role management pod that continuously monitors the health of all active call processing pods

Upon detecting a pod failure, the role management pod selects a standby pod, instructs it to take over as the active pod, and supplies the identity and IP addresses of the failed pod. The newly active pod reads all stored call state from Redis and resumes both SIP signaling and RTP media services to all steady-state calls previously handled by the failed pod.

All calls are preserved successfully. Far-end peers and clients receive no redirection or notification of the failover. The system is designed so that they experience less than 6-seconds of interruption in media before full resumption. During recovery, the SBC’s SIP load balancer forwards new calls to other active pods across the multi-AZ VPC while the newly active pod signals ready for service.

High-Performance Networking for Real-Time Media

Ribbon’s architecture addresses the networking requirements of real-time voice through AWS infrastructure. The solution leverages compute-optimized EC2 instances that deliver the high packets-per-second throughput required for SIP signaling and RTP media processing. Additionally with the ongoing innovations and new release of AWS EC2 instance families, there are further opportunities to improve cost performance without application changes.

Amazon EKS support for Multus CNI enables multiple network interfaces per pod, allowing Ribbon to separate signaling traffic from media streams for optimal performance and security.

Unified Observability and Operations

Integration with observability tools like Amazon CloudWatch, Amazon Managed Prometheus, and Amazon Managed Grafana unifies monitoring across voice and IT infrastructure. Operations teams gain comprehensive visibility into SBC performance metrics, capacity utilization, and system health using the same dashboards that monitor their broader AWS environments. This operational alignment can eliminate the “swivel-chair management” of traditional voice infrastructure, where specialized tools and expertise isolate voice operations from IT workflows.

The SBC CNe enables AI-driven operations by integrating with Ribbon Acumen, an AIOps platform. Acumen provides analytics, AI/ML models, automation, low-code workflows, and RAG-based knowledge to deliver fast, contextual insights. It also includes a unified Deployment Ops framework that automates onboarding, configuration, and lifecycle management across AWS through policy-driven pipelines and continuous validation. This combination of Deployment Ops with AI analytics supports outcome-based operations aligned with SLA, performance, reliability, and cost objectives, enabling a closed-loop approach to deployment, monitoring, and remediation with AWS-native and Amazon Bedrock-powered services. This allows teams to shift from reactive to proactive AI-assisted network management.

GitOps-Driven Lifecycle Management

Ribbon’s SBC solution uses GitOps based automation for lifecycle management, helping organizations manage voice infrastructure using the same CI/CD pipelines that govern their broader AWS environments. Infrastructure-as-Code (IaC) definitions stored in Git repositories serve as the single source of truth for SBC configurations, with tools like Flux or ArgoCD automatically synchronizing desired state to Amazon EKS clusters. This declarative approach transforms software updates and security patches from risky manual operations into automated, repeatable processes. Ribbon’s canary deployment strategy progressively rolls out new SBC versions, first deploying a single pod running the updated software, validating performance and stability, then gradually migrating traffic from baseline pods to updated versions. If issues arise, the system automatically rolls back to the previous stable version. This capability enables organizations to test updates in virtual replicas before production deployment, reducing upgrade cycles from weeks to hours.

Conclusion/Call to Action

Modernizing voice infrastructure with Ribbon’s cloud-native SBC on Amazon EKS is designed to improve operational economics while maintaining required reliability and security. Organizations may eliminate hardware refresh cycles, compared to dedicated hardware-based deployments and might achieve savings up to 60% in infrastructure capacity buildout through pay-as-you-go economics, it is possible that the time needed to apply software updates will reduce from weeks to hours and deploy frequent updates through GitOps automation. Multi-Availability Zone deployment is designed to deliver resiliency and high availability with recovery times less than 6 seconds. Automated scaling helps resources match real-time demand, minimizing overprovisioning waste.

By managing voice security using the same Kubernetes orchestration and CI/CD pipelines as their IT workloads, organizations can unify operations and eliminate infrastructure silos. This cloud-native foundation enables voice communications to evolve alongside digital transformation initiatives rather than constraining them.

Ready to transform your voice infrastructure? Check out the Ribbon SBC solution on AWS Marketplace.

Learn more:

AWS for Industries