Back to Blog
Architecture
Nov 01, 20253 min read

Why We Don’t Use Managed PaaS (And When You Should)

PaaS feels like magic until the bill hits $10k. We analyze the 'PaaS Tax', the observability black box, and when it makes sense to migrate to your own ECS or K8s clusters.

Why We Don’t Use Managed PaaS (And When You Should)
Share:

Managed PaaS platforms (like Heroku, Vercel, or Render) promise simplicity. "Just push git, we handle the rest." For early-stage startups, this is a godsend.

But we have seen the same story play out dozens of times: A company scales, the PaaS bill explodes to $10k/month, and the engineering team hits a "black box" limit they can't debug.

We often migrate companies off PaaS—but sometimes we recommend staying. Here is the technical reality of that decision.


1. The PaaS "Tax" Curve

PaaS pricing is not linear; it is exponential. You aren't paying for resources; you are paying a markup for convenience abstraction.

The Markup Breakdown

ResourceAWS/Raw CostTypical PaaS CostMarkup
vCPU$30/mo$50-$100/mo3x
RAM$5/GB$20/GB4x
Bandwidth$0.09/GB$100/100GB+10x+
Databases$15/mo$50/mo3x

At $500/month, this markup is irrelevant compared to an engineer's salary. At $50,000/month, you are burning the equivalent of two senior engineers' salaries on markup alone.


2. The "Black Box" Problem

The real cost of PaaS isn't money; it's observability.

When your API latency spikes to 500ms on a PaaS, you check their dashboard. It says "Status: Green." What now?

  • You can't SSH into the hypervisor.
  • You can't inspect the kernel networking stack.
  • You can't tune sysctl parameters.
  • You can't attach a tailored eBPF probe.

Case Study: We had a client on a major PaaS whose WebSocket connections were dropping every 60 seconds. The PaaS support took 3 days to reply, "It's a load balancer timeout, we can't change it." On Kubernetes/AWS: We would have changed the ALB idle timeout in 1 minute via Terraform.


3. When PaaS Is Actually the Right Choice

We are not anti-PaaS. We are anti-blind-adoption.

Stick with PaaS if:

  1. Orchestration Logic is Simple: A stateless Node.js app + a Postgres DB.
  2. Team Size < 5: You don't have a dedicated DevOps engineer.
  3. Traffic is Bursty & Low Volume: You aren't pushing TBs of data (which kills you on bandwidth).
  4. Time-to-Market is Critical: You need to launch tomorrow.

Migrate Off when:

  1. Bill > $2k/month: The ROI of owning your infra usually flips here.
  2. Compliance Needs: HIPAA/SOC2/PCI often require network isolation (VPCs) that PaaS charges a premium for (e.g., "Enterprise Plans").
  3. Complex Topology: You need microservices to talk via gRPC over a private mesh.

4. The Migration Path: It's Not "Kubernetes or Bust"

Migrating off PaaS doesn't mean building a complex EKS cluster from day one.

Step 1: The "Lift and Shift" to ECS (or Cloud Run) AWS ECS (Elastic Container Service) is the middle ground. It runs containers (like your PaaS did) but inside your VPC.

  • Pros: Cheaper compute (Fargate), full networking control, standard IAM.
  • Cons: You have to write Terraform.

Step 2: The Data Layer This is the hardest part. Migrating a live database from Heroku Postgres to AWS RDS requires:

  1. Setting up a read replica (or using CDC tools).
  2. Syncing data over a secure tunnel.
  3. Promoting the replica.

Step 3: Kubernetes (EKS) Only go here if you need the ecosystem (Helm charts, operators, specific scaling logic).


5. Our Philosophy

Infrastructure should be boring.

  • PaaS is boring content, expensive scale.
  • Kubernetes is exciting content, cheap scale.

The goal is to find the balance where you own the problems you can fix, and outsource the problems you ignore.

Thinking of migrating? Check out our Migration Playbook.

Tagged with

ArchitecturePaaSIaaS

Need help with your infrastructure?

Book a free architecture review and get expert recommendations.

Book Architecture Review
Share:
CL
CloudOpsPro Team

Cloud Infrastructure & DevOps

Nov 01, 20253 min read

Read Next