Every VICIdial guide assumes you have a rack and a data center contract. That made sense in 2014. In 2026, the first question we hear from new operators is: can I run this in the cloud?
Yes. But VICIdial and cloud infrastructure make very different assumptions about networking, CPU scheduling, and storage I/O. Spin up an EC2 instance without understanding those differences and you'll spend a week debugging one-way audio.
When Cloud Makes Sense (and When It Doesn't)
Cloud works well for seasonal operations that swing from 20 agents in January to 150 during open enrollment. Insurance, tax prep, political campaigns — these verticals benefit from elasticity. Cloud also works for geographic redundancy across regions and for teams that don't want to deal with drive replacements at 3 AM.
Cloud does not make sense for sustained high-density operations. If you're running 100+ agents on a stable, predictable workload 12 hours a day, bare metal is cheaper — 2-3x cheaper at scale. And for ultra-low-latency requirements where every millisecond of AMD detection matters, dedicated hardware wins.
For a budget-constrained 10-agent shop, a Hetzner AX-series for $50-80/month outperforms a $200/month cloud instance.
The Three Problems That Break Cloud VICIdial
SIP NAT traversal. SIP embeds IP addresses inside the protocol payload. Behind cloud NAT, the SIP INVITE contains your server's private IP (10.0.1.45) instead of its public IP. Your carrier tries to send RTP audio to an unreachable address. Result: one-way audio or silence.
The fix in /etc/asterisk/sip.conf:
externip=<YOUR_ELASTIC_IP>
localnet=10.0.0.0/8
localnet=172.16.0.0/12
localnet=192.168.0.0/16
nat=force_rport,comedia
directmedia=no
Also tell your carrier you're behind NAT. Most need you to enable NAT keep-alive or SIP Comedia on their portal.
Shared vCPU performance. Asterisk needs consistent sub-millisecond CPU access for RTP audio processing. On shared/burstable instances, your Asterisk process competes with other tenants for CPU time. The symptoms are subtle: intermittent choppy audio, occasional one-way audio that self-resolves, AMD accuracy that varies hour by hour.
Do not run VICIdial on t3/t2 instances (AWS), e2 instances (GCP), or basic Droplets. Use compute-optimized instances: c5 series on AWS, c2 series on GCP. GCP's c2-standard-8 runs on dedicated 3.1 GHz processors with no CPU overcommit — as close to bare metal as cloud gets.
Latency to your SIP carrier. The VICIdial-to-carrier path should be under 100ms. If your instance is in us-east-1 and your carrier's nearest POP is in Chicago, you'll see 15-25ms — fine. If your instance is in Asia and your carrier is US-only, you're looking at 180-250ms, which destroys AMD accuracy and creates noticeable agent delays. Deploy in the same region as your carrier's nearest point of presence.
AWS: The Specifics
Instance sizing: c5.2xlarge (8 vCPU, 16 GB RAM, ~$245/month) is the minimum for telephony serving up to 25 predictive agents. Database server should be m5.xlarge (memory-optimized, ~$140/month). Web servers can use c5.xlarge (~$124/month).
Storage: Use EBS gp3, not gp2. gp3 gives you 3,000 IOPS baseline independent of volume size. Separate your database onto its own EBS volume at /var/lib/mysql and recordings at /var/spool/asterisk/monitor/ for independent I/O paths.
Networking: Put your telephony server in a public subnet with an Elastic IP. Assign it and never release it — your carrier has whitelisted this IP, your Asterisk externip points to it, and changing it means updating everything. Open UDP 10000-20000 to 0.0.0.0/0 for RTP media. Yes, it feels wrong. It's how SIP works.
GCP: The Slight Edge
GCP's c2-standard-8 runs on dedicated 3.1 GHz Intel Cascade Lake with no CPU overcommit. For Asterisk's real-time audio processing, this provides measurably more consistent performance than AWS c5 instances.
GCP also applies sustained use discounts automatically when an instance runs more than 25% of the month — roughly 30% off for 24/7 instances. No commitment required, no Reserved Instance planning. For a VICIdial server running around the clock, this saves about $80/month on a c2-standard-8 without you doing anything.
Use pd-ssd for database storage and pd-balanced for recordings. GCP's tag-based firewall rules are actually cleaner than AWS security groups for multi-server VICIdial setups.
The Bare Metal Alternative
Here's the math that matters: a full 500-agent VICIdial cluster on Hetzner bare metal (AX-series servers) costs roughly $860/month for 14 servers. That's $1.72 per agent per month for compute. Compare that to equivalent cloud instances at 3-5x the cost, or to hosted dialers like Convoso at $120-225/agent/month.
Cloud makes sense for elasticity and geographic redundancy. Bare metal makes sense for sustained operations where you know your agent count. ViciStack deploys on dedicated bare-metal infrastructure optimized for real-time telephony — no shared vCPUs, no noisy neighbors, no NAT headaches.
Originally published at https://vicistack.com/blog/vicidial-cloud-deployment/
Top comments (0)