Serverless and Traditional VPS: When "Serverless" Architecture Costs More Than Servers

Serverless platforms like AWS Lambda promise revolution: pay only for actual code execution time, forget about server management, scale automatically. Sounds like every CTO's dream. But when the monthly bill arrives, many discover an unpleasant truth: "serverless" architecture can cost several times more than a regular VPS. Let's examine where the line is drawn between savings and overpayment.

Promise and Reality: What Serverless Actually Is

Serverless (Function-as-a-Service, FaaS) is a model where you upload code as functions that run on demand. AWS Lambda manages all resources needed for function execution, automatically scales from zero to thousands of concurrent executions, charging only for actual compute time.

Sounds perfect, right? But the devil, as always, is in the details.

Cold Starts: The Invisible Latency Problem

A cold start occurs when AWS Lambda must initialize a new container to execute code due to a lack of pre-warmed resources. This process involves allocating resources, setting up the runtime environment, and loading the deployment package, which can add significant latency—often several seconds for some languages like Node.js or Python, and even longer for others like Java or .NET.

Cold path: 150–800ms additional latency from serverless cold starts after idle periods. Warm path: nearly identical performance once functions stay hot.

Specific numbers by language:

• Python and Node.js typically have faster cold starts in the 200-400 millisecond range, while Java and C# have historically suffered from cold start delays in the 500-700 millisecond range
• VPCs make cold starts 4x worse. Large node_modules (>50MB) exacerbate delays

For user-facing APIs where every millisecond is critical, this can be catastrophic. Cold starts hurt the most when dealing with customer-facing flows where performance is critical, even for those 1% of customers. For example, if you have micro-services dedicated to authentication or authorization which are required to operate at high concurrency and finish execution in less than a dozen milliseconds, 1% of an extra 0.5-1 second can be a deal breaker.

Pricing: When Numbers Tell the Truth

AWS Lambda uses a pay-as-you-go model:

• $0.20 per 1 million requests ($0.0000002 per request)
• Monthly compute price is $0.0000166667 per GB-second
• Free tier: 1 million requests and 400,000 GB-seconds per month

Sounds cheap? Let's calculate a real example:

Suppose your application processes three million requests per month. Average function execution duration is 120 ms. You configured your function with 1536 MB of memory on an x86 processor. Total compute (seconds) = 3 million × 120ms = 360,000 seconds. Total compute (GB-s) = 360,000 × 1536MB/1024 MB = 540,000 GB-s. Total compute – Free tier = 540,000 GB-s – 400,000 free tier GB-s = 140,000 GB-s. Monthly compute charges = 140,000 × $0.0000166667 = $2.33

Looks profitable! But now let's compare with VPS:

A mid-sized SaaS app running 24/7 might cost $20–$60/month on a VPS while costing much more on serverless.

Critical Point: this calculation is for variable load. For constant load, the math changes dramatically.

When Serverless Becomes Expensive

A predictable workload is any application or service that needs to be consistently available and running. This describes the core of most web applications. Running these on a "pay-per-millisecond" serverless model is where the logic breaks down and the costs explode.

Lambda functions can run for a maximum of 15 minutes. They have memory limits and package size limits. You are locked into their specific way of doing things. A VPS is a blank canvas.

Hidden Costs: What Calculators Don't Account For

Egress Fees: The Tax on Your Data

The most painful "hidden" cost is egress fees (charges for transferring data out of the cloud).

AWS charges significantly more for data transfer than competitors, with outbound data costs starting at $0.09 per GB compared to DigitalOcean's flat $0.01 per GB rate for all data transfer types. AWS's complex pricing structure includes expensive inter-regional transfer fees of $0.02 per GB, meaning you pay extra just to move data between different AWS availability zones within your own infrastructure.

The real markup is striking: A Cloudflare study estimates that customers in the US, Canada, and Europe pay 80x Amazon's costs. Customers in South America pay 21x Amazon's costs. Customers in Japan and Singapore pay 17x Amazon's costs.

Provisioned Concurrency: Paying for No Cold Starts

Provisioned Concurrency is a feature of AWS Lambda that allows developers to specify the number of function instances that are always initialized and ready to respond immediately to invocations. By maintaining a specified number of pre-warmed instances, Provisioned Concurrency eliminates cold starts for those instances, ensuring consistent and predictable performance. While Provisioned Concurrency can significantly reduce latency, it also incurs additional costs, as pre-warmed instances are billed regardless of whether they are actively processing requests.

1GB function with 10 concurrent executions, 5M monthly invocations at 200ms: Idle = $30.42, Execution = $97.22, Requests = $0.80 → Total = $128.44/month vs $17 standard Lambda.

Other Hidden Costs

VPC Networking Costs: Functions in VPCs require ENIs with potential charges: NAT Gateway ($0.045/hour + $0.045/GB), VPC endpoints for AWS services ($0.01/hour + $0.01/GB), and PrivateLink for third-party integrations. These can exceed Lambda compute costs for VPC-heavy architectures. CloudWatch Logs Storage: Lambda automatically logs to CloudWatch: $0.50/GB ingestion, $0.03/GB/month storage. Verbose logging for high-volume functions (10M+ invocations) can cost $50-200/month.

Vendor Lock-in: The Trap of Proprietary Services

Different serverless platforms, such as AWS Lambda, Google Cloud Functions, and Azure Functions, have their own runtime environments and APIs. Migrating serverless applications between these platforms can be complex and time-consuming. Serverless functions often rely on event triggers from other services within the same cloud provider (e.g., AWS S3, DynamoDB). Reconfiguring these triggers to work with another provider's services involves significant effort.

The true danger with lock-in, especially with serverless, is the potential for data lock-in. Data has gravity. It accumulates. Data is economically disincentivized to leave, by way of platform pricing. This is the single biggest threat to vendor choice.

DHH noted that it cost 37signals "hundreds of thousands of dollars" to move 6 to 7 petabytes of data from GCP, due to egress costs (though 37Signals was able to work a deal to use credits to pay for some of the costs). "This whole idea that the cloud is going to give you mobility was not really true," DHH said.

Case Study 37signals: $10M Savings Over 5 Years

The most prominent example of cloud migration is the story of 37signals (creators of Basecamp and HEY).

In 2022, 37signals CTO David Heinemeier Hansson (creator of Ruby on Rails) started to quit AWS after being horrified by an annual spend exceeding $3.2 million.

The results are impressive:

"Our cloud spend is down by 60% already, from around $180,000 a month to less than $80,000," wrote DHH. "We don't have to squint hard to see the eventual savings climb all the way up to about $2 million a year. That would be $10 million over five years."

In 2024 he shared the results of the compute repatriation project: after spending $700,000 on some Dell boxes that run workloads once hosted in AWS, cloud bills fell by some $2 million a year.

"We've been out for just over a year now, and the team managing everything is still the same. There were no hidden dragons of additional workloads associated with the exit that required us to balloon the team, as some spectators speculated when we announced it."

What's Critical in This Case

The convenience of the cloud positions you for growth with on-demand power, but does so at a significant cost. As the business matured, its infrastructure needs became more predictable and stable.

We still think the cloud has a place for companies early enough in their lifecycle that the spend is either immaterial or the risk that they won't be around in 24 months is high. Just be careful that you don't look at those lavish cloud credits as a gift! It's a hook. And if you tie yourself too much to their proprietary managed services or serverless offerings, you'll find it very difficult to escape, once the bills start to grow.

When Serverless Actually Makes Sense

Not everything is so bad. Serverless works brilliantly in the following scenarios:

1. Burst Traffic and Event-Driven Tasks

Serverless automatically scales functions per request, so scalability graphs favor FaaS during traffic spikes.

Examples:

• File upload processing
• Webhook handlers
• Periodic tasks (backup, reports)
• Image/video processing on demand

2. Low Stable Traffic

With low traffic an e-commerce app costs ~$1.6/month (free tier included), and a blog ~$0.5$. In comparison, the cost per month of the smallest EC2 VM, the t3a.nano, is $3.43. Result: Advantage serverless.

3. Prototypes and MVPs

For startups in the idea validation phase, serverless is ideal:

• Zero infrastructure costs before launch
• Fast deployment
• Automatic scaling on success
• Free tier covers most experiments

4. Unpredictable Load

Such unpredictability is where the cloud shines, providing resources when it's unclear how many servers you need. For example, when launching HEY an unexpected influx of 300,000 users within three weeks defied their six-month forecast of 30,000.

When VPS Is the Right Choice

1. Constant 24/7 Load

A service that's always running is racking up billable milliseconds every second of every day. Your monthly bill becomes a terrifying variable that can spike without warning. A high-RAM VPS has a fixed monthly cost. It's the ultimate in predictable pricing.

2. Long-Running Processes

Lambda functions can run for a maximum of 15 minutes. They have memory limits and package size limits. A VPS is stateful by nature, meaning your applications can hold data in memory and run for as long as you want. Need to run a data analysis script that takes 3 hours? No problem.

3. WebSockets and Persistent Connections

Serverless functions are stateless by definition. If your application needs:

• WebSocket connections
• Long-lived HTTP connections
• In-memory caches
• Shared state between requests

VPS is the only option.

4. High Data Volume

With large data volumes, egress fees become critical:

A major, often overlooked cost of cloud platforms is "data egress"—the fee they charge you to send data out of their network. If your application serves large files, generates reports, or provides data-heavy API responses, these egress fees can easily eclipse your compute costs.

For applications serving:

• Video content
• Large files
• APIs with large payloads
• Backup/restore operations

VPS with unlimited (or cheap) outbound bandwidth will be much more cost-effective.

Practical Recommendations

For Serverless Architecture

Monitor Cold Starts:

• Use AWS X-Ray to track function duration with cold start
• Optimize package size
• Minimize dependencies

Control Egress:

• CDNs not only help with faster data transfer but also reduce total cost. Amazon Cloudfront is a content delivery network that transfers data fast, under low latency
• Use VPC Endpoints for AWS services
• Keep related services in the same availability zone

Avoid Vendor Lock-in:

• Use Hexagonal architecture, where your application is isolated from external concerns. Your migration cost will be reduced as your application core code won't change during migration, and you'd only need to write and plug new adapters to it
• Avoid proprietary services for critical logic
• Use standard languages and protocols

For VPS Architecture

Automation:

• Use IaC (Infrastructure as Code)
• Set up CI/CD pipelines
• Automate monitoring and alerting

Managed Services:

• Use managed database services
• Delegate backup to the provider
• Consider managed Kubernetes for containers

Hybrid Approach:

• Stable core on VPS
• Burst workloads on serverless
• Static assets on CDN
• Critical data on own servers

Hybrid Approach: Best of Both Worlds

The smartest 2025 cloud architectures rarely pick a side. They blend microservices hosting VPS serverless stacks: Keep API edge handlers in Functions for elasticity. Route heavy crunching to a container pool on a cloud VPS. Share auth tokens via a central Redis instance. This pattern balances scalability trade‑offs and caps the monthly bill.

Example distribution:

• VPS: main database, application server, cache
• Serverless: image processing, webhook handlers, background tasks
• CDN: static files, media content

Conclusions: Math Decides Everything

Serverless is neither a panacea nor a scam. It's a tool, and like any tool, it has its application area.

Serverless wins when:

• Load is unpredictable or spiky
• Low traffic volume (within free tier)
• Event-driven architecture
• Short tasks (<15 minutes)
• Zero operational overhead needed

VPS wins when:

• Stable 24/7 load
• Long-running processes
• High data volume
• Persistent connections needed
• Budget predictability is critical

If you're running VMs or Kubernetes in the public cloud, you're almost certainly doing it wrong. In the cloud, we should be renting services, not servers.

Main rule: do the math for your specific case. 37signals initially anticipated operational savings of $7 million over the next five years, but your numbers may be completely different.

The cloud services market has matured. Now the choice between serverless and VPS is not a question of technological fashion, but a question of cold TCO (Total Cost of Ownership) calculation. And often that calculation points to the good old VPS.