T

VPS, managed cloud, and serverless aren't just different price points. They're different contracts about where operational responsibility sits and how costs scale with load. Most startups end up on the wrong tier not because they made a bad choice, but because they made a choice without understanding what they were buying. This post breaks down each model honestly, including the situations where each one actively hurts you.

VPS: You're Paying for a Computer You Control

A VPS (Virtual Private Server) is a slice of a physical machine. You get a fixed amount of CPU, RAM, and storage. You pay a flat monthly rate regardless of how much you use it. DigitalOcean, Hetzner, Linode, and Vultr are the common providers. AWS EC2 and Google Compute Engine sit in this category too, though their pricing is more granular.

What you're paying for: the machine, plus the operational burden of running it. You install the OS. You configure the firewall. You manage software updates, SSL certificates, monitoring, log rotation, database backups, and everything else that needs to run on that server. That's the deal. In exchange, you get full control and predictable pricing.

For a small team with a senior engineer who knows Linux, a VPS is often the most cost-efficient option at early scale. A €6/month Hetzner VPS can genuinely handle a surprising amount of traffic if your application is reasonably efficient. DigitalOcean's $24/month droplet (2 vCPU, 4GB RAM) running a well-tuned Node.js or Go service can serve thousands of requests per minute. The hardware isn't the bottleneck; the team's willingness to own the operations is.

The model breaks down in two ways. First, when you don't have the engineering capacity to maintain it properly — an unpatched server is a security incident waiting to happen, and if the person who set it up leaves, institutional knowledge leaves with them. Second, when you need to scale faster than you can provision machines. VPS scaling is manual and linear: you need more capacity, you spin up more servers, you configure load balancing. That takes time and attention your team might not have during a traffic spike.

The hidden cost of VPS that nobody puts in the budget: engineer time. Estimate conservatively 3-5 hours per month per server in ongoing maintenance. At a senior engineer's market rate in Indonesia (Rp 25-40 million/month), that's not free.

Managed Cloud: You're Paying for Someone Else's Operations Team

Managed cloud sits between VPS and serverless. You're still provisioning server-like resources — container instances, managed databases, load balancers — but the provider handles the underlying infrastructure operations. AWS ECS, Google Cloud Run, Heroku, Railway, Render, and Fly.io all live in this category, though they vary considerably in abstraction level.

The key shift from VPS: you stop thinking about servers and start thinking about containers and services. You define what your application needs (2 vCPU, 512MB RAM), and the platform handles where it runs, health checks, restarts on failure, and capacity allocation across physical infrastructure. You still pay for reserved capacity, but you're not managing the machines beneath it.

Managed databases are where this model pays for itself most clearly. PostgreSQL on RDS or Cloud SQL means automatic backups, point-in-time recovery, automated failover to a replica, and patching handled by the provider. Running that yourself on a VPS requires either significant expertise or accepting meaningful risk. For most startups, managed databases are worth the price premium from day one.

The trade-off is cost and abstraction overhead. Managed services add a markup over raw compute. An RDS PostgreSQL instance running on the same hardware as a self-managed EC2 instance costs roughly 20-40% more. You're paying for the operations team you didn't have to hire. Whether that's worth it depends on your team's size and where you want engineers spending time.

Managed cloud also introduces provider lock-in at the service level. ECS task definitions, RDS parameter groups, CloudWatch alarms — these are AWS-specific. Migrating between managed cloud providers isn't impossible, but it's not a weekend project either. That's worth knowing before you build deep into any provider's ecosystem.

AWS Singapore (ap-southeast-1) is the closest major region for Indonesian startups — roughly 15-25ms latency from Jakarta. AWS Jakarta (ap-southeast-3) covers services like EC2, RDS, and EKS. For user-facing applications serving primarily Indonesian users, the Jakarta region reduces latency to single digits. Worth the setup if your product is latency-sensitive.

Serverless: You're Paying Per Execution

Serverless means your code runs in response to events, and you pay only for the compute time consumed during execution. No idle servers. AWS Lambda, Vercel Functions, Cloudflare Workers, and Google Cloud Functions are the main options. The billing unit is typically 1ms of execution time plus memory allocated.

The appeal is obvious: you deploy a function, it scales from zero to millions of invocations without you provisioning anything. At low traffic, costs are negligible. For a startup doing 10,000 requests per day, serverless is almost certainly the cheapest option.

The model has real limits that tend to appear at the worst times. Cold starts are the most commonly cited: when a function hasn't been invoked recently, the runtime needs to initialise before it can handle the request. On AWS Lambda with a Node.js or Python runtime, cold starts add 200-500ms. For a TypeScript Lambda with significant dependencies, 1-2 seconds isn't unusual. For most API endpoints, that's a bad user experience. Provisioned concurrency (keeping functions warm) solves this but eliminates the cost advantage that made serverless attractive.

Execution time limits are a harder constraint. Lambda caps execution at 15 minutes. If you have a job that processes a large file, coordinates between services, or runs a complex computation, you either break it into smaller chunks or use a different infrastructure model. Trying to force long-running workloads into serverless creates architectural debt that compounds.

The serverless cost model also inverts at high traffic. At 100 million requests per month with meaningful compute per request, Lambda can cost significantly more than a set of always-on containers. Vercel's pricing-at-scale surprises are a well-documented example of this — a topic covered in depth in our infrastructure pillar log.

Serverless works well for: event-driven processing (image resizing on upload, webhook handlers), scheduled jobs, APIs with genuinely unpredictable and spiky traffic patterns, and supplementary workloads that run infrequently. It works poorly for: latency-sensitive user-facing APIs, long-running jobs, anything with consistent high throughput.

The Part Most Teams Get Wrong: Mixing Models

The real answer for most startups isn't "pick one model." It's understanding which workload belongs on which model and running them together deliberately.

Your core API — the one handling user authentication, reading and writing primary data, serving your product's main flows — almost certainly belongs on managed cloud. You need predictable latency, connection pooling to your database, and the ability to tune memory and CPU to your actual workload. Serverless cold starts and execution limits make it a poor fit for this layer.

Your image processing pipeline, your email send queue, your nightly analytics aggregation — these are serverless candidates. They're event-driven, they run infrequently relative to your main API, and the cost model rewards exactly that pattern.

Your database is managed cloud by default unless you have a very good reason and a very senior DBA on staff. The cost of getting database operations wrong — corruption, data loss, extended downtime — is too high for most startups to absorb.

The mistake is applying the same infrastructure model to everything because it's simpler to reason about. It's simpler until you're paying $4,000/month in Lambda costs for workloads that would cost $400/month on two container instances, or until your managed database bill covers compute you're using 6 hours a day.

A Real Example: Indonesian SaaS Re-architecting Under Pressure

A B2B SaaS product serving Indonesian SMEs was running entirely on Heroku — three dynos for the API, Heroku Postgres on a standard plan. The monthly bill was around $400. When they crossed 2,000 active businesses, the Heroku Postgres connection limit became a hard ceiling. They were hitting it during business hours daily.

The migration they ran: move the API to AWS ECS (two t3.small instances behind an ALB, ~$80/month), move the database to RDS PostgreSQL with PgBouncer for connection pooling (~$120/month), and move their PDF report generation — previously running synchronously on the API — to a Lambda function triggered by SQS (~$15/month at their volume). They added a t3.micro for Redis on ElastiCache ($20/month) for session caching.

Total monthly compute: ~$235, down from $400, with meaningful headroom for growth. The win wasn't just cost — it was the connection pooling that solved the actual problem, and separating PDF generation so it stopped blocking API response time.

The lesson: the infrastructure model they started with made sense for their early stage. It stopped making sense when their usage pattern became clear. The important thing is recognising when the model stopped fitting — not picking the "right" model at the start.

FAQ

Q: Is serverless actually cheaper than VPS for early-stage startups?

A: At very low traffic, yes. A Lambda function handling 50,000 requests per month costs essentially nothing. A VPS costs $6-20/month whether you use it or not. But once you're doing consistent traffic — say 1 million requests per month with 100ms average execution — the economics shift and you should run the numbers for your specific workload before assuming serverless is cheaper.

Q: When does the AWS Jakarta region make sense versus AWS Singapore?

A: If your users are primarily in Indonesia and your application is latency-sensitive (real-time features, payment flows, anything where 20ms matters), use Jakarta. If you need services that aren't available in Jakarta yet, or if your user base spans Southeast Asia broadly, Singapore is the practical choice. Many Indonesian startups run primary infrastructure in Singapore and are fine.

Q: What's the actual cost difference between self-managed Postgres and RDS?

A: Roughly a 30-50% premium for RDS over an equivalent EC2 instance running Postgres yourself. On a db.t3.medium (2 vCPU, 4GB RAM), you're looking at around $60-80/month for RDS versus $30-40/month for EC2 plus your own time. For teams without a dedicated DBA, the managed option is almost always worth it.

Q: Can I mix Vercel for the frontend and AWS for the backend API?

A: Yes, and this is a common and reasonable pattern. Vercel is excellent for Next.js frontends with its edge network and deploy preview workflow. Your API on ECS or a VPS handles the compute-heavy or latency-sensitive backend work. The main consideration is CORS configuration and making sure your API is accessible from Vercel's edge regions without excessive latency.

Q: When should a startup move off serverless to container-based infrastructure?

A: Two clear signals: when cold starts are affecting user-visible latency and provisioned concurrency costs are eroding the serverless pricing advantage, or when your monthly Lambda bill exceeds what equivalent always-on containers would cost. A rough heuristic: if you're spending more than $200/month on Lambda for a single function or function group, model the container equivalent. You'll often find a migration pays for itself in 2-3 months.

There's no universally right answer here. A solo founder shipping an MVP should probably be on Railway or Render — managed enough to stay out of the way, cheap enough not to matter. A Series A startup with 50,000 daily active users and a two-person backend team should probably be on ECS with RDS and a tight eye on what's serverless versus containerised. The model should fit the team and the traffic, not the other way around.

If you're not sure which tier your current architecture belongs on, that's usually a signal worth acting on before the bill surprises you.