Managed Cloud vs. Raw IaaS: Pick One Before You Scale

For: A CTO or lead engineer at a 15–80 person B2B SaaS company who just hit the wall on their current infra setup — either their hand-rolled EC2/VPC stack is eating two engineers' weeks every month in ops toil, or their managed PaaS bill just crossed $30K/month and their CFO wants a justification before renewal

Pick managed cloud (Render, Railway, Fly.io, Cloud Run, Heroku, Vercel) when your scarcest resource is engineering time. Pick raw IaaS (AWS, GCP, Azure with self-managed Kubernetes or EC2) when your scarcest resource is gross margin. The mistake almost every 15–80 person SaaS makes is optimizing for the resource they already have plenty of — CTOs with cash burn managing YAML, and CTOs with tight unit economics paying 3× for compute they could operate themselves.

This post gives you a decision framework that ignores per-vCPU pricing and deployment speed comparisons, because those aren't what you'll regret in 18 months.

The decision, stated crisply

You are choosing between two infrastructure philosophies:

• Managed cloud / PaaS: Someone else runs the control plane, the load balancer, the autoscaler, the certificate rotation, the container orchestration. You push code, they run it. Examples: Render, Railway, Fly.io, Google Cloud Run, AWS App Runner, Heroku, Vercel, Netlify, Supabase for data.
• Raw IaaS: You rent compute, network, and storage primitives and assemble everything above. Usually AWS/GCP/Azure with either EC2 + custom scripts, ECS, or self-managed Kubernetes (EKS/GKE/AKS still counts here — the control plane is managed, everything else isn't).

Both work. Both scale to nine figures of ARR — Shopify runs on hyperscaler IaaS, Notion ran on Heroku-style managed services for years. This is not a technical capability question. It's a resource allocation question dressed up as a technical one.

The five axes that actually matter

1. Which resource is scarcer: engineer-hours or infrastructure margin?

This is the axis. Everything else is secondary.

If two engineers are spending a combined week per month on infra toil — debugging Terraform drift, rotating certificates, tuning HPA, tracking down noisy neighbors, updating base images, patching CVEs — that's roughly 25% of two salaries plus the opportunity cost of the features they aren't shipping. For most B2B SaaS at this stage, that's more expensive than a managed platform bill would be, even at 2–3× the compute cost.

Flip it: if your gross margin is already 60% and infrastructure is a meaningful line item, moving to a managed platform that charges 2.5× for the same workload can compress margin by 5–10 points. At scale, that shows up in your Series B valuation. Nobody funds a 55% gross margin SaaS at a premium multiple.

Ask honestly: which of these two is the constraint on your next 12 months? Not both. One.

2. Workload shape

Managed platforms are priced and tuned for stateless HTTP workloads with bursty traffic. They're great at that. They get progressively worse as your workload shape diverges:

• Long-running background jobs: Cloud Run has request timeout limits. Fly machines work but you're basically doing IaaS with nicer ergonomics. Fine on Render workers, expensive at volume.
• GPU inference: Managed platforms are catching up (Modal, Replicate, RunPod) but the pricing gap vs. spot GPUs on AWS is enormous.
• Stateful data infra: If you're running Kafka, ClickHouse, or your own Postgres with heavy replication, managed platforms will nickel-and-dime you on egress and network. Raw IaaS wins.
• Multi-region with strict data residency: Managed platforms have fewer regions. If a customer needs Frankfurt-only data storage, check the compliance region list before you commit.

3. Compliance and audit surface

SOC 2 Type II, HIPAA, PCI, ISO 27001 — managed platforms shrink your audit surface dramatically. You inherit their controls for the infrastructure layer. That's real work you don't do.

On raw IaaS you own everything above the hypervisor: patching, logging, IAM boundaries, encryption key rotation, network segmentation. Doable, but it's a full quarter of engineering work the first time and ongoing overhead after.

If you're selling into regulated buyers (health, fintech, gov) and don't already have a security engineer, managed cloud pays for itself in audit prep alone.

4. Exit cost and lock-in

The honest tradeoff: managed platforms lock you in more, but the lock-in cost is usually overstated for stateless services.

• If your app is containerized 12-factor code with Postgres, moving off Render or Cloud Run takes weeks, not quarters. The lock-in is mild.
• If you've built on platform-specific primitives — Vercel Edge Functions, Supabase RLS policies, Firebase Realtime DB, Cloudflare Durable Objects — you have real lock-in. Migration is a rewrite.
• Raw IaaS has its own lock-in through IAM, VPC architecture, and managed database choices. "AWS is portable" is a myth once you've built anything real on it.

Rule: keep your business logic in portable containers. Use platform primitives for undifferentiated glue (auth, queues, cron) where the lock-in is cheap to unwind.

5. Team shape 18 months from now

You are not making this decision for today's team. You are making it for the team you'll have after two more hires and one senior departure.

• Managed cloud lets a team of full-stack engineers ship without an infra specialist. If you don't plan to hire an SRE or platform engineer in the next 18 months, don't sign up for infrastructure that requires one.
• Raw IaaS with Kubernetes assumes at least one person whose job includes the platform. If that person leaves, you have a bus-factor problem within a quarter.

Scoring the options honestly

Managed cloud / PaaS

Good at: Time-to-first-deploy. Certificate management. Autoscaling stateless services. Reducing audit surface. Preview environments. Reducing bus-factor risk on ops.

Bad at: Cost efficiency at scale (usually 2–3× raw compute). GPU workloads. Stateful data infrastructure. Custom networking. Fine-grained cost attribution across teams. Egress-heavy workloads (video, large file transfer). Exotic regions.

Failure mode: You grow, the bill grows superlinearly, and you have no leverage to negotiate because you're locked into a platform-specific deploy model. You end up doing a forced migration under time pressure at Series B.

Raw IaaS (AWS/GCP/Azure + Kubernetes or EC2)

Good at: Unit economics at scale. Workload flexibility. Multi-region and compliance edge cases. Reserved capacity discounts, savings plans, spot instances. Fine-grained cost controls. Negotiating leverage with the hyperscaler once you're spending real money.

Bad at: Engineering overhead. Onboarding new hires. Security posture without a dedicated owner. Preview environments (doable, but you build them). Anything that requires production-grade defaults.

Failure mode: Two engineers become half-time platform engineers. Feature velocity drops. You interview an SRE for six months without hiring one. Meanwhile competitors ship.

The middle path: managed Kubernetes (EKS/GKE/AKS)

Tempting, but honest read: it inherits most of the operational cost of raw IaaS with a slightly nicer control plane. Choose it only if you already have Kubernetes expertise on the team or you're deliberately investing in a platform team. Do not pick EKS because it feels like a compromise. It's not — it's raw IaaS with a managed etcd.

The framework: what to do in your specific situation

Situation A: You're burning engineer-weeks on infra toil

Symptoms: your Terraform PRs sit for days, you have a Slack channel called #on-call that pings hourly, deploys take 45 minutes and half fail, nobody wants to touch the VPC peering config.

Move to managed. Specifically:

• Stateless services → Cloud Run or Render. Both handle 90% of B2B SaaS workloads.
• Background jobs → same platform, worker services.
• Postgres → Neon, Supabase, or the platform's managed offering. Don't self-host until you have a real reason.
• Queues → SQS or the platform's built-in queue. Don't run RabbitMQ yourself.

Yes, your compute bill will go up. Compare it against the fully-loaded cost of the two engineers you're currently spending on infra. It's almost always cheaper, and you get feature velocity back as a bonus.

Situation B: Your managed bill is compressing gross margin

Symptoms: you crossed $30K/month on Heroku, Render, or Vercel. Your CFO is asking questions. Your gross margin dropped 4 points over the last year and infrastructure is the main culprit.

Move to raw IaaS — but only if you can commit to one platform hire.

• Hire (or contract) one platform engineer before you migrate. Not after.
• Start with ECS or GKE Autopilot, not full Kubernetes. Raise the complexity ceiling only when you hit it.
• Use reserved instances / committed use discounts aggressively. That's 30–40% of the savings.
• Keep your data plane portable. Postgres via RDS or Cloud SQL is fine — the SQL is portable, the operational overhead is minimal.

Do not attempt this migration if you can't dedicate one senior engineer to it for a full quarter. A half-baked IaaS migration is worse than the managed bill you were trying to escape.

Situation C: You're pre-product-market-fit or under 15 engineers

Managed. Not a close call. The compute cost differential is a rounding error compared to the opportunity cost of any engineer-hour spent on infrastructure. Revisit the decision when you cross $20K/month in platform spend or 25 engineers, whichever comes first.

Situation D: You're a regulated-industry SaaS (health, fintech, gov)

Default to managed unless you already have a security engineer. The audit inheritance alone justifies the premium. If your buyer requires you to be in their VPC or a specific region, verify managed coverage before you commit — otherwise raw IaaS is forced on you.

Two things people get wrong

"We'll start on managed and move to IaaS when we scale." This works, but only if you keep discipline about platform-specific primitives. Teams say this and then build on Vercel edge functions and Supabase RLS. Now the migration is a rewrite. If you plan to migrate, containerize everything from day one and treat the managed platform as a runtime, not an SDK.

"Kubernetes is the industry standard, so we should learn it now." Kubernetes is a platform for running platforms. If you're not building a platform, you're paying its complexity tax for benefits you won't use for two years. Cloud Run and ECS handle 90% of what SaaS teams actually need.

How CodeNicely can help

We've done this migration in both directions. For GimBooks, a YC-backed fintech accounting SaaS, the situation looked like your Situation B: real usage growth, managed platform costs compressing margin, and a small team that couldn't spare a founding engineer to run a Kubernetes migration solo. We came in as the platform engineering bench — sized the migration, moved services onto a leaner AWS footprint, kept the data plane portable, and handed it back with runbooks the internal team could own. The point wasn't cheaper hosting for its own sake; it was buying back gross margin without pulling product engineers off the roadmap.

If your situation is closer to A — an infra setup that's eating engineering weeks — we work the other direction: audit the toil, move stateless workloads to a managed runtime, and consolidate the sprawl. Either way, you keep the IP and there's no lock-in to us. See how we approach infrastructure and platform work or the broader services overview.

Frequently Asked Questions

Is managed Kubernetes (EKS/GKE) considered managed cloud or raw IaaS?

Raw IaaS, for decision-making purposes. The managed control plane saves you from running etcd, but you still own node pools, autoscaling, networking, ingress, observability, and security patching. Operationally it's closer to EC2 than to Cloud Run. Only pick it if you've already committed to a platform engineering function.

At what revenue or team size should we move off managed cloud to IaaS?

There's no clean threshold, but two triggers matter more than revenue: your platform bill crossing roughly $25–30K/month with clear growth, or your team crossing ~30 engineers with at least one senior person who wants to own platform. Below both triggers, managed almost always wins. Above both, run the math on fully-loaded engineer cost vs. IaaS savings.

Can we run a hybrid — some workloads on managed, some on IaaS?

Yes, and it's underrated. GPU inference on raw IaaS with spot capacity, stateless API on Cloud Run, batch jobs on ECS. The cost is operational complexity — two deploy pipelines, two monitoring stacks, two on-call rotations. Worth it once one workload class dominates your bill and doesn't fit the managed model.

How do we estimate the cost of migrating from managed to IaaS?

The rewrite of the deploy pipeline and IaC is the smaller part. The bigger costs are observability parity (logs, metrics, traces), security posture (IAM, secrets, network), and the on-call knowledge transfer. Any estimate that doesn't include those three is understated by half. Talk to CodeNicely for a personalized assessment based on your actual workload shape and team.

What about Vercel or Netlify specifically — same framework?

Same framework, sharper lock-in warning. Vercel and Netlify are excellent for frontend and edge workloads, but their platform-specific primitives (edge functions, ISR, middleware) create meaningful migration cost. Use them for frontend delivery, keep backend logic in portable containers on a separate runtime you control. That decoupling preserves your optionality.

The one-line summary

If engineering time is your scarce resource, pay the managed premium and ship features. If margin is your scarce resource, invest in one platform hire and go raw IaaS. Do not pick based on what feels technically respectable — pick based on which resource you actually don't have enough of.