Your serverless bill looked reasonable during launch, then your API settled into a steady 40 RPS, workers ran all day, and logs, egress, retries, and minimum instances kept adding line items.
For predictable workloads, compare the fully loaded serverless bill against fixed VPS capacity and operations costs.
Steady concurrency turns serverless into rented capacity
Stable request volume makes pay-per-request pricing resemble permanently rented infrastructure, often at a higher unit price.
Use p95 duration, not the average
A practical estimate is: concurrency = requests per second × p95 duration in seconds. An API at 20 RPS with a 400 ms p95 needs about 8 concurrent executions. At a 2-second p95, that same API needs about 40. That difference drives billed compute, provisioned concurrency, and timeout risk.
Account for minimum warm capacity
This works well in theory, but in practice provisioned concurrency can make an AWS Lambda, Google Cloud Functions, or Azure Functions deployment behave like an always-on service. If users need low first-byte latency, calculate the cost of minimum warm capacity for all 730 monthly hours, not only the minutes handling requests.
Apply a fast decision rule
If serverless costs less after a fair comparison with a VPS design that includes 30% to 50% headroom, keep it; if it costs 25% or more above that design for three consecutive months, review a VPS or container migration.
A workload with stable concurrency is not automatically a VPS workload. It becomes one when the extra serverless bill is larger than the value of managed scaling, lower operations work, and faster failure recovery.
Break-even table: total bill, not sticker price
The break-even point occurs when compute, requests, network, observability, and downstream charges exceed the fully operated cost of a fixed VPS.
| Monthly cost item | Serverless example | Fixed VPS example | Decision effect |
|---|
| Base compute | Lambda: $0.20 per 1M requests plus $0.0000166667 per GB-second before free tier | 2 GB VPS: about $10 to $12 per month at Vultr or DigitalOcean | Long runtimes favor VPS |
| HTTP entry point | AWS HTTP API: about $1 per 1M requests in the first tier | Nginx or Caddy included, load balancer extra | High request counts favor VPS |
| Logs | CloudWatch ingestion: about $0.50 per GB in US regions | Disk, log shipper, and retention policy | Verbose logs hurt both, often serverless first |
| Private outbound access | AWS NAT Gateway: about $0.045 per hour plus data processing in US East | Public egress or private network design | A NAT gateway can exceed a small VPS |
| Operations | Less host patching, more distributed tracing work | Patching, backups, alerting, restore tests | Labor can reverse the result |
Use this model: serverless total = compute + invocations + gateway + egress + NAT + logs + traces + queues + database + secrets + support. Then calculate: VPS total = server price + backups + monitoring + licenses + spare capacity + labor + high availability.
Test growth instead of guessing
Run the model at 25%, 50%, and 100% traffic growth. Serverless cost usually rises close to each extra request, while a VPS may absorb growth until CPU, RAM, disk IOPS, or bandwidth reaches its limit.
A break-even worksheet should also show the marginal cost of one more unit of steady traffic. For example, 20 steady RPS over 30 days equals 51.84 million requests. Using a conservative 400 ms planning duration and 1 GB of memory, that is 20.736 million GB-seconds, or about $345.60 of AWS Lambda compute at $0.0000166667 per GB-second, before free-tier effects. Add roughly $10.37 for Lambda requests, $51.84 for an AWS HTTP API, and $51.84 for 2 KB of CloudWatch logs per request: the subtotal is about $459.65 before egress, NAT, traces, queues, and database use.
At the same assumptions, each additional 1 steady RPS adds roughly $20.39 per month in compute, invocation, and gateway charges alone. Compare that slope with fully loaded fixed VPS hosting, rather than comparing only a low serverless pricing estimate with a VPS sticker price.
Serverless wins when idle time is genuinely high
Serverless is usually the better buy when workloads scale to zero for long periods, traffic arrives in sharp bursts, or demand cannot be forecast.
Good fits: bursts, crons, and events
An API with 2,000 requests during a five-minute promotion and near-zero demand afterward is a strong serverless fit. So are cron jobs that run for 2 to 10 minutes a few times per day, image conversions, webhook handlers, and event-driven tasks.
A common case is a small US retailer processing order webhooks. The system may have no work for 18 to 22 hours, then handle a short evening spike. Keeping a VPS warm is simple, but serverless can be cheaper because its idle compute cost approaches zero.
Managed integration has a real value
A team subject to SOC 2, PCI DSS, HIPAA, GDPR, or CCPA may also value provider controls and audit records. Those services do not remove your compliance duty, but they can reduce the amount of host administration you must document.
WebSockets and other persistent connections are often awkward fits because one connection may occupy capacity for minutes or hours. For these services, a fixed VPS, a container platform, or a managed real-time service is usually easier to price.
Portability has a cost even when the monthly bill is acceptable. AWS Lambda, Google Cloud Functions, and Azure Functions each use different IAM models, gateway integrations, event formats, retry behavior, observability tools, and concurrency controls. Provider-specific authentication policies, queue triggers, secret references, and database networking can turn a small function into a difficult migration project. Keep business logic separate from provider adapters, define versioned event schemas, and use infrastructure as code so the runtime boundary is explicit.
Serverless also does not eliminate security work: the team still owns least-privilege permissions, secret rotation, dependency patching, input validation, retention settings, and incident response. A VPS shifts more host security to the team, but serverless vendor lock-in can create a different long-term operational cost.
Fixed VPS wins when demand stays on all day
A fixed VPS usually wins for steady APIs, continuous workers, persistent connections, and predictable batch work because its capacity cost does not rise with every request until the machine is full.
Steady API and worker examples
A 20 RPS API with 400 ms p95 latency produces about 51.8 million requests in 30 days. Even modest per-request gateway, log, trace, and database costs can matter more than the function request line.
A continuous worker is clearer still. If it processes messages 24 hours per day, it is not really elastic work. It is an always-on service wearing a serverless label, and a $24 to $48 VPS with 4 GB RAM may offer lower total cost if one node meets the recovery target.
Price VPS operations without pretending
A production VPS budget must include daily or weekly backups, snapshots, monitoring, security patches, vulnerability response, and restore tests. A single $12 DigitalOcean Droplet or Amazon Lightsail instance can be suitable for internal tools, but it is not automatically a high-availability design.
The most frequent mistake at this point is calling VPS operations “free” because an existing engineer handles them. Assign an hourly cost or a realistic monthly allowance, even if it is only 2 to 6 hours for a mature, well-documented setup.
Know when a VPS is too small
Track CPU utilization, RAM allocation, disk latency, network saturation, and queue depth. If normal peak CPU is already above 70%, your VPS has too little room for a slow query, a deploy rollback, or a traffic increase.
Billing traps that make forecasts fail
Serverless forecasts fail when they count successful function runs but ignore retries, fan-out, network paths, and debug data.
Retries multiply more than compute
Use this adjustment: effective transactions = successful transactions × (1 + retry rate + duplicate rate). Then multiply every per-transaction charge by that result, not only compute time.
Set idempotency keys, which let a system recognize a repeated event and avoid repeating the business action. Also set dead-letter queues, timeout budgets, concurrency limits, and billing alerts before a failure reaches production.
Logs, egress, and NAT hide in plain sight
Logging and monitoring costs include ingestion, retention, query scans, custom metrics, and distributed traces. Debug logging can produce several KB per request; at tens of millions of requests, that becomes tens or hundreds of GB per month.
Data transfer costs can also surprise teams. Internet egress, cross-zone traffic, and NAT Gateway processing may be charged separately, depending on architecture and region. Check current regional terms on the Google Cloud pricing site or the equivalent provider page before approving a forecast.
A hybrid architecture is often best when a steady API needs stable capacity but occasional jobs spike sharply. Put the base API and continuous worker on a VPS or managed container, then send rare image processing, imports, or event bursts to serverless.
Choose this approach if your current estimate ignores failed requests, downstream calls, or operation time. Fix the model before migrating.
Monthly choice path for predictable load
1. Measure
RPS, p95 duration, retries, GB logs
2. Price
Compute plus gateway, egress, NAT, database
3. Match
Same backups, uptime, and labor on VPS
4. Decide
Stable floor: VPS. Long idle periods: serverless.
- Memory is not just a capacity setting in serverless pricing;
- it is a direct multiplier on GB-second billing and often changes the CPU share available to the function. Moving an AWS Lambda function from 1 GB to 2 GB doubles compute cost if duration stays at 400 ms, but it can reduce the bill if additional CPU lowers p95 duration enough. At 20 RPS, a 1 GB function running for 400 ms represents about 8 concurrent executions;
- a 2 GB function completing in 180 ms represents about 3.6.
Test several memory settings with production-like payloads, connection limits, and database latency. A faster function can reduce concurrent executions and downstream connection pressure, while an oversized function with no duration improvement simply increases the recurring cost of predictable workloads.
FAQs
Is serverless cheaper than a VPS for steady traffic?
Usually no when traffic holds steady for most of the month and functions cannot scale to zero. Compare p95 duration, gateway fees, logs, egress, retries, and a VPS with 30% to 50% spare capacity.
How do I calculate serverless concurrency?
Multiply requests per second by p95 request duration in seconds. At 50 RPS and 0.8 seconds p95, plan for about 40 concurrent executions before retry and burst allowance.
What hidden serverless cost surprises teams most?
NAT Gateway, API Gateway, log ingestion, traces, egress, and managed database calls commonly change the result. A NAT Gateway at roughly $0.045 per hour alone is about $33 per 30-day month before data processing.
Should I use average or p95 request duration?
Use p95 for capacity and cost planning, then test p99 for risk. Average duration hides slow requests that hold concurrency and create timeouts during real traffic.
When does a fixed VPS become risky?
A single VPS is risky when you need multi-zone recovery, strict uptime commitments, or cannot patch and restore it reliably. Add replicas and backups, or use a managed platform, before claiming it is cheaper.
Are WebSockets a good fit for serverless?
Usually not for long-lived connections because each connection needs persistent capacity or a specialized managed service. A VPS or container service is often easier to run when connections last minutes or hours.
Can a hybrid design reduce cloud costs?
Yes, when stable base traffic runs on a VPS and rare bursts run on serverless. This design works best when the two paths share clear queues, idempotency rules, and cost tags.
This comparison is less useful when demand is highly intermittent, workloads scale to zero for long periods, or demand cannot be forecast. It also does not replace a separate latency, compliance, security, or disaster-recovery review. If managed integrations remove a measurable operations burden, paying more for serverless may still be the correct business choice.
Make the choice with a 30-day cost test
For predictable workloads, favor a fixed VPS or managed container for the stable baseline, then use serverless for sharp and infrequent peaks.
Export 30 days of RPS by hour, p95 and p99 duration, memory allocation, retry rate, log GB, trace volume, egress GB, database operations, queue messages, and support charges. Record provisioned concurrency and minimum instances separately because they are capacity commitments, not burst spending.
For the VPS side, price CPU, RAM, storage, bandwidth, snapshots, monitoring, patching, backup restores, and at least 30% headroom. If a second node is needed for uptime, include it from the start.
Decide from the higher-confidence number
Run three cases: current traffic, 50% growth, and a failure case with retries. Keep the architecture whose cost, latency, and recovery design still make sense in all three cases, not only in the best month.
If the model is within 10% either way, do not migrate just to chase a small infrastructure saving. Keep the platform with lower operational risk for your team, then repeat the test after the next material traffic or architecture change.
Learn more
Here are some additional resources on this subject:
