Moving Telecom Switching to the Cloud
Cloud infrastructure can give wholesale VoIP operators more flexibility over where they deploy switching resources and how they scale their operations. However deploying a Class 4 softswitch on Amazon Web Services (AWS) requires telecom-specific planning because voice traffic depends on predictable network behavior and reliable signaling and media delivery.
For operators considering DeNovoLab’s Class 4 Fusion the objective should be to combine cloud infrastructure with effective routing, billing, security and monitoring. AWS provides the infrastructure building blocks but operators must still design and validate the telecom environment.
Assess Your Traffic Requirements Before Choosing AWS Resources
The first deployment decision is not the instance type. It is understanding the traffic your softswitch must handle.
Measure Concurrent Calls and Calls Per Second
Two metrics are particularly important for wholesale VoIP:
Concurrent calls: The number of active calls being handled at the same time.
Calls per second (CPS): The rate at which new calls are established.
A switch handling 500 concurrent calls with modest call setup activity may have different resource requirements from one processing frequent call attempts across large dialer campaigns.
Estimate normal and peak traffic separately. Include expected growth and account for the processing overhead of routing decisions, CDR generation, monitoring and billing.
Match Compute Resources to the Workload
AWS EC2 instance families differ in their balance of CPU, memory and network performance. Select resources based on the softswitch vendor's requirements and your own load-test results rather than assuming that a larger instance automatically delivers better call quality.
For example a wholesale operator expecting traffic spikes during business hours should test whether the selected instance can sustain peak CPS without excessive CPU usage or delayed call processing.
Practical recommendation: Establish a baseline for CPU utilization, memory consumption, network throughput, concurrent calls and CPS before moving production traffic.
Design AWS Networking for SIP Signaling and RTP Media
Telecom networking deserves particular attention because SIP signaling and RTP media serve different purposes.
Separate Signaling from Media Considerations
SIP manages call establishment and control while RTP commonly carries the actual voice media. A call may connect successfully but still experience one-way audio, jitter or packet loss if media routing is incorrect.
Your AWS network design should account for:
SIP signaling ports and transport protocols used by your switch.
RTP port ranges configured for media.
Public and private IP address assignments.
Return routes for inbound and outbound traffic.
Connectivity with upstream carriers and customer networks.
AWS security groups are stateful virtual firewalls that control permitted inbound and outbound traffic. Configure them to allow only the required sources, destinations, ports and protocols. Avoid opening broad port ranges to the public internet without a clear operational reason. AWS security group guidance.
Evaluate Latency and Media Paths
Choose an AWS Region based on the location of your customers, carrier interconnections and operational requirements. Physical distance is not the only factor but it can influence latency.
Consider a provider serving customers in North America while connecting to carriers in Europe. Hosting every component in one region may simplify administration but could introduce longer network paths for some traffic.
Measure real call performance from representative locations. Monitor round-trip latency, jitter and packet loss rather than relying only on the availability of the EC2 instance.
AWS identifies Network Load Balancers and AWS Global Accelerator as options for certain TCP and UDP workloads that need Layer 4 connectivity. However these services should not be inserted into a SIP or RTP path without checking protocol behavior, source-IP requirements and the softswitch architecture. AWS networking guidance.
Build Security into the Deployment from Day One
A cloud-hosted softswitch is still a telecom endpoint exposed to risks such as SIP scanning, credential compromise, toll fraud and denial-of-service attacks.
Restrict Access to the Switching Environment
Apply security controls at several levels:
Limit SIP access to approved carrier and customer IP addresses where possible.
Restrict administrative interfaces to trusted management networks.
Use strong authentication and unique credentials.
Apply operating system and software security updates.
Separate management access from public signaling traffic.
Store credentials and API secrets securely.
AWS security groups should be configured alongside any host-level firewall and application-specific access controls. A secure cloud network does not automatically protect against weak SIP credentials or unsafe routing rules.
Add Fraud Controls and Usage Limits
Security should also include controls over how calls are authorized and billed. Apply destination restrictions, customer credit limits and appropriate concurrent-call or CPS thresholds.
For example if a compromised account suddenly begins sending high-cost international traffic the system should be able to identify the abnormal activity and trigger an alert or protective action.
DeNovoLab's Class 4 Fusion is positioned as an integrated wholesale VoIP switching platform with routing, billing, reporting and monitoring capabilities. Operators should validate the exact fraud controls available in their selected version and configure them for their traffic profile.
Plan High Availability, Recovery and Data Protection
A cloud deployment is not automatically highly available simply because it runs on AWS. Reliability depends on the complete architecture including the softswitch, its data stores, carrier connectivity and operational procedures.
Avoid Single Points of Failure
Determine which components are essential for call processing and which can be recovered separately. Depending on the product architecture this may include the switching application, databases, management interfaces and supporting services.
For production systems consider whether multiple instances or Availability Zones are appropriate and confirm that the softswitch supports the proposed deployment model. Do not assume that launching duplicate instances alone creates a working active-active cluster.
AWS Regions and Availability Zones offer infrastructure options for resilience but application-level state and telecom session handling still require careful design.
Create a Tested Recovery Plan
Back up configuration files, routing policies, rate tables and billing data. Define recovery objectives for both service restoration and data loss.
A backup is useful only if it can be restored. Test recovery procedures and document how carrier connections, IP addresses, routing rules and billing records will be restored after a failure.
For example an operator should know how long it would take to restore a failed switching instance and whether the recovery process preserves the configuration needed to resume carrier traffic.
Control AWS Costs Without Compromising Call Quality
Cloud infrastructure can reduce the need to purchase and maintain physical servers but ongoing costs need active management.
Calculate the Full Cost of Deployment
Budget for more than EC2 compute. Depending on your architecture costs may include:
Compute instances and attached storage.
Data transfer and public IPv4 addresses.
Load balancing and network services.
Backup storage and monitoring.
Support, licensing and operational administration.
Voice traffic can generate substantial network usage. Estimate data transfer costs using expected call volumes and media paths, then validate those estimates against actual AWS billing data.
Use Load Testing to Guide Optimization
Avoid selecting the cheapest instance solely on hourly price. An undersized instance may increase packet-processing delays or limit call setup performance during traffic spikes.
Instead test representative call loads and compare cost per supported workload. Review instance utilization and network metrics to identify resources that are consistently underused or overloaded.
AWS cost management tools can help track spend by environment or project. Separate development and testing resources from production so that experimental workloads do not become an unmonitored expense.
Compare Deployment Models and Softswitch Providers
AWS supplies infrastructure rather than a complete wholesale telecom operating system. Operators must choose a softswitch platform and deployment model that match their technical capacity and business goals.
DeNovoLab Class 4 Fusion
DeNovoLab offers Class 4 Fusion for wholesale VoIP operations with capabilities including routing, switching, billing, reporting and monitoring. Its platform is relevant to operators who want to coordinate core switching and commercial workflows in one environment.
When planning an AWS deployment confirm the supported installation method, system requirements, licensing, backup procedures and any vendor-specific networking constraints. These details should be verified for the exact version and architecture rather than inferred from general cloud compatibility.
Sippy Software
Sippy offers Class 4 and Class 5 softswitch capabilities with routing, billing, network protection and border-control functions. Its website also lists AWS hosting options and describes its cloud deployment experience. This may appeal to operators who want a telecom-focused solution with a defined hosting offering. Sippy Softswitch.
PortaOne PortaSwitch
PortaOne documents a cloud-based PortaSwitch deployment model designed to reduce hardware procurement and maintenance responsibilities while allowing processing capacity to be adjusted. This is a different purchasing and operating model from independently managing a softswitch installation on EC2. PortaOne cloud deployment documentation.
The best choice depends on how much infrastructure control your team needs, whether you prefer vendor-managed hosting and how each platform fits your routing, billing and operational requirements. Compare the total cost of ownership and support responsibilities rather than comparing software features alone.
Test the Deployment Before Moving Production Traffic
A structured validation process helps identify problems before they affect paying customers.
Run a Telecom-Specific Acceptance Test
Test inbound and outbound calls across representative carriers and destinations. Verify SIP signaling, two-way audio, DTMF behavior, call release and CDR accuracy.
Load tests should cover expected concurrent calls and CPS as well as short periods of peak traffic. Test failure scenarios such as a carrier becoming unreachable, a switching service restarting or a network path being interrupted.
Monitor the System After Launch
Track call setup success, answer-seizure ratio (ASR), average call duration (ACD), CPU usage, network performance and billing discrepancies. These metrics help distinguish infrastructure problems from carrier or destination issues.
Move traffic gradually where possible. Start with a controlled test group, review the results and expand only after the critical functions perform as expected.
Conclusion: Build Your AWS Softswitch Around Telecom Requirements
Deploying a Class 4 softswitch on AWS can provide wholesale VoIP operators with flexible infrastructure and greater control over their deployment strategy. Success depends on matching compute resources to real traffic, designing reliable SIP and RTP paths, securing access, preparing for failures and monitoring both performance and cost.
Before deployment confirm your softswitch's AWS compatibility and test its behavior under realistic traffic conditions. Infrastructure choices should support the telecom platform rather than dictate how it must operate.
DeNovoLab's Class 4 Fusion combines core wholesale switching capabilities with routing, billing and monitoring workflows. Visit www.denovolab.com to explore the platform and discuss the deployment requirements for your network.
0 Comments