When Not to Use IaaS

Last Updated on May 8, 2026 by Arnav Sharma

IaaS isn’t the cloud. It’s a data center you rent. And renting the wrong thing is expensive.

That sounds blunt, but it’s the honest framing that most cloud architecture conversations skip. EC2 instances, Azure VMs — these are powerful, flexible, and genuinely the right choice in many situations. But they’ve also become a reflex. “We need compute? Spin up some VMs.” And that reflex, repeated across thousands of teams and millions of workloads, is quietly burning through budgets and engineering cycles.

The global IaaS market is on track to hit $1.25 trillion by 2030. AI workloads, edge compute, and cloud-native applications are driving the bulk of that growth. Yet McKinsey’s 2024 research found that fewer than 10% of cloud transformations actually capture their full expected value. The investment is there. The results often aren’t. And a big reason is the gap between what teams are running and what they should be running.

This post is about that gap. Specifically: nine situations where IaaS is the wrong call, what to use instead, and how to think about the trade-offs clearly.

The Problem With Defaulting to IaaS

With IaaS, you pay for the potential to run. A VM is running whether your app is handling requests or sitting idle at 3am. The instance costs money either way.

With serverless or managed platforms, you pay for actual work being done. That’s a fundamentally different cost model, and for the right workloads, it changes the economics completely.

The deeper issue is operational overhead. IaaS hands you the keys to the infrastructure, which means you’re responsible for the OS, patching, runtime configuration, networking, security hardening, scaling logic, and more. That’s the right trade-off when you genuinely need that control. But a huge proportion of workloads don’t.

Here’s a look at the scenarios where IaaS creates more problems than it solves.

Scenario 1: Your Workload Is Event-Driven, Bursty, or Stateless

The clearest signal here is a traffic pattern that spikes and dies. A data job that runs for a few minutes every hour. An API that gets hammered during business hours and sits quiet overnight. A function triggered every time a user uploads a file.

These workloads are genuinely terrible fits for always-on VMs. You’re paying for 24 hours of compute to do maybe four hours of real work.

A classic example: a user uploads a product image and something needs to resize it into thumbnails. It’s event-driven (triggered by the upload), stateless (each image is independent), and brief. Serverless handles this perfectly. An AWS Lambda function or Azure Function fires on the S3/Blob event, processes the image, writes the output, and stops. You pay for the seconds it ran. Not the 23 hours and 57 minutes it didn’t.

Compare that to an order processing workflow that checks inventory, processes payment, coordinates with shipping, and sends notifications. That’s stateful, long-running, and involves multiple failure scenarios. That’s a better fit for containerised microservices.

For bursty, event-driven workloads, use:

• AWS: Lambda, Fargate, Step Functions, SQS
• Azure: Azure Functions, Logic Apps, Event Grid, Container Apps

The savings are real. For the right workloads, serverless can cut compute costs by 70 to 90% compared to a continuously running VM.

Scenario 2: You Don’t Have a Platform Engineering Team

This one gets overlooked constantly. IaaS gives you full control over the OS, runtime, and networking. That power comes with a maintenance burden. OS patching, security hardening, monitoring, scaling rules, incident response — all of that lands on your team.

If you have a dedicated SRE or platform engineering function, that’s manageable. If you’re a four-person dev team trying to ship features, it’s a different story. I’ve seen small teams spend more time fighting infrastructure than building product. The opportunity cost is brutal.

When your primary concern is application code, not Kubernetes plumbing, managed services change the equation significantly. EKS Managed Node Groups, for example, handle OS patching and security updates automatically. Azure AKS does the same. You still have Kubernetes, but the control plane and node management overhead shrinks dramatically.

The decision logic is worth keeping simple:

• Need minimal infrastructure management? Use serverless.
• Need a managed platform with more flexibility? Use PaaS.
• Need full OS and runtime control? Then use IaaS, but know what you’re signing up for.

Scenario 3: You’re Building a Standard Web App

If you’re running a conventional web application with a database backend, and someone is seriously proposing you self-manage EC2 instances or Azure VMs for it, worth asking: why?

The “lift and shift” instinct makes sense as a quick migration path. But in practice, it trades a short-term time saving for long-term overhead. You end up maintaining infrastructure that a fully managed platform would handle automatically, at a higher base cost, with more operational complexity.

Azure App Service, AWS Elastic Beanstalk, and similar PaaS options handle deployment, auto-scaling, load balancing, and health monitoring without you provisioning a single server. Azure SQL Database brings a 99.99% availability SLA out of the box, plus active geo-replication at no extra cost over the primary instance. Most self-managed SQL deployments on VMs can’t realistically match that without significant additional investment.

For standard web workloads, the IaaS approach adds time to market and raises the barrier to ship new things. PaaS removes those barriers. Unless there’s a specific reason you need OS-level access or custom runtime configuration, it’s hard to justify the overhead.

Scenario 4: Your App Is Containerised But You’re Still Provisioning VMs Manually

There’s a common antipattern where teams do the work of containerising their applications and then undo half the benefit by running those containers on self-managed EC2 nodes or Azure VMs. You’ve built for portability and then bolted on the management overhead you were trying to escape.

AWS Fargate is the obvious counter here. It’s a serverless compute engine for containers. You define CPU and memory requirements, and Fargate allocates the resources. No node management, no patching, no cluster capacity planning. In 2025 performance tests, ECS with Fargate scaled from 1 to 1,000 tasks in under 30 seconds with sub-15ms latency. That’s not bad for something you didn’t have to configure.

Azure Container Apps and Azure App Service occupy similar ground on the Microsoft side.

That said, there are legitimate reasons to stay on IaaS for containers:

• Custom AMIs or hardened images: If your compliance environment requires a specific OS image or custom kernel modules, Fargate won’t give you that
• Host-level access: Deep debugging, forensic auditing, or host-level daemon agents sometimes require SSH to the underlying node
• GPU workloads: Fargate doesn’t support GPU instances; if you’re running ML inference at scale, you’ll need EC2

These are real edge cases. But if none of them apply, you’re probably just adding operational work for no gain.

Scenario 5: The Hidden Costs Will Eat Your Budget

Base compute pricing is only part of the bill. This is the scenario where a lot of cloud projects quietly go sideways.

Public cloud pricing looks straightforward until you add up all the components. Load balancers are metered separately. CloudWatch or Azure Monitor costs scale with the number of metrics you collect. Backups and snapshot storage carry their own fees, with potential early deletion penalties for archival tiers. Data egress charges accumulate whenever you move data out of a region. API call fees are small per-request but compound rapidly at scale. Idle resources — unattached volumes, stopped instances with storage still running — keep accruing charges unless someone actively hunts them down.

Healthcare organisations are a good benchmark here. Cloud TCO tends to run roughly 27% above initial estimates once PHI compliance requirements are factored in. Encryption at rest and in transit, access controls, audit logging, BAA management — none of this is reflected in base compute pricing, and all of it adds real cost. Financial services see a similar dynamic: infrastructure savings of around 24% in raw compute, partially offset by roughly 15% in compliance overhead.

The honest upfront question before any IaaS deployment: what’s the actual monthly cost at steady state? Not just the instance cost. The full picture.

Scenario 6: Data Sovereignty and Compliance Are Non-Negotiable

In 2025, sovereignty isn’t a compliance checkbox. It’s a geopolitical issue.

More than 120 countries now enforce data protection laws, up from 76 in 2011. GDPR fines totalled 2.3 billion euros in 2025 alone, a 38% increase year over year. The European Banking Authority’s cloud outsourcing guidelines require regulated entities to be able to audit all outsourced data, maintain continuity independent of the cloud provider, and demonstrate that data never leaves authorised jurisdictions without explicit regulatory approval. DORA, which came into full force in January 2025, extends those requirements to critical third-party technology providers.

The complicating factor: over 92% of data in the Western world sits on servers owned by US-based companies, according to the World Economic Forum. That concentration creates real exposure for regulated industries in other jurisdictions. Under laws like the US CLOUD Act, foreign governments may be able to scrutinise data held by US providers regardless of where the data physically resides.

Standard hyperscaler IaaS deployments may not give you the controls you need here. The sovereign cloud market is currently valued at around $154 billion and projected to grow to $823 billion by 2032 — those numbers reflect how seriously regulated industries are taking this problem.

If you’re in finance, healthcare, government, or any sector operating under strict data residency rules, the architecture decision isn’t just “which cloud service.” It’s “can I prove to a regulator where this data lives and who can access it.” IaaS on a major hyperscaler might still be the right answer, but it needs to be an informed choice rather than a default.

Scenario 7: Your Team Doesn’t Have a Strong Cloud Security Practice

More than 60% of enterprise cloud incidents trace back to customer misconfigurations, not provider vulnerabilities. IaaS creates the most surface area for those misconfigurations to occur.

The problem compounds as environments grow. The more services, interfaces, environments, and assets you’re managing, the harder it becomes to keep every configuration correct. One misconfigured security group. One storage bucket with overly permissive ACLs. One IAM role with broader permissions than intended. These are common, and they’re almost always operator errors, not platform failures.

There’s also a visibility limitation that’s worth being honest about. Cloud providers control the physical infrastructure and virtualisation layer. Even with logging, monitoring, and CSPM tools in place, you won’t have the same observability into what’s happening at the hypervisor level that you’d have in an on-premises data centre. Providers are understandably reluctant to expose those details. That’s a real constraint on your ability to detect and respond to certain classes of threats.

Managed services shift a significant portion of that security surface area back to the provider. That’s not a silver bullet — you still need to configure managed services correctly — but the attack surface is narrower and the configuration model is simpler.

One concrete benchmark: Datadog’s 2025 report found that more than 80% of container spend goes to waste when resources are misconfigured. That’s a downstream cost of a security practice gap, not just a financial inefficiency.

Scenario 8: Vendor Lock-In Is a Strategic Concern

IaaS gets marketed as the more portable option. VMs are VMs, the reasoning goes. But in practice, it doesn’t play out that way.

The tooling ecosystem around IaaS creates its own lock-in. AMIs are provider-specific. VPC configurations, IAM structures, security group models, and proprietary networking features all vary significantly between providers. A workload that runs on AWS EC2 isn’t cleanly portable to Azure VMs without meaningful rework.

The irony is that serverless approaches, which are often criticised for vendor lock-in, at least make the coupling explicit. When you build on Lambda, you know you’re building on Lambda. With IaaS, the assumption of portability can mask how deeply the tooling has integrated you into one provider’s ecosystem.

Accenture found that 58% of CIOs now cite dependency on a single hyperscaler as a key strategic risk. That’s a governance-level concern, not just a technical one.

The practical takeaway: if multi-cloud portability is actually a business requirement, evaluate your architecture honestly against that requirement. IaaS isn’t automatically the safer bet.

Scenario 9: You’re Running Workloads That Have a Fully Managed Equivalent

This is the simplest scenario but also the most common. Running a mail server on EC2 when Microsoft 365 or Google Workspace exists. Running MySQL on a VM when RDS or Azure SQL Database is available. Hosting WordPress on an Azure VM when Static Web Apps or AWS Amplify would do the job. Running a CI/CD pipeline on a self-managed Jenkins VM when GitHub Actions or Azure DevOps handles it natively.

Every one of those VM deployments is operational overhead you’re choosing to own when you don’t have to. The managed SaaS or PaaS equivalent usually brings better availability, automated patching, built-in backups, and no OS to maintain.

There are reasons to self-host — specific compliance requirements, customisation needs, cost at very high scale. But those should be explicit decisions, not defaults.

When IaaS Is the Right Call

This is worth being clear about. IaaS isn’t the wrong answer. It’s the wrong answer for a lot of common workloads. There are genuine scenarios where it’s exactly right:

• Custom AMIs or hardened OS images: Compliance environments requiring specific kernel configurations, STIG-hardened images, or legacy software that won’t run on managed runtimes
• Full-stack control: Applications needing specific OS configurations, custom networking stacks, or runtime environments that managed services can’t accommodate
• High-utilisation steady-state workloads: If your app runs at 70 to 90% CPU utilisation continuously, reserved EC2 instances or Azure Reserved VMs become very cost-effective. The always-on cost works in your favour
• GPU and HPC workloads: AI/ML training that requires specific GPU instance types — P3, P4, or NDv4 class hardware that Fargate doesn’t offer
• Dedicated compliance isolation: Scenarios requiring dedicated hosts for regulatory reasons (some PCI DSS and HIPAA implementations, for example)

The Decision Framework at a Glance

Scenario	Skip IaaS	AWS Alternative	Azure Alternative
Event-driven, bursty traffic	EC2	AWS Lambda	Azure Functions
Standard web app	Azure VM / EC2	Elastic Beanstalk	Azure App Service
Containerised app, no custom OS	EC2 nodes	AWS Fargate / ECS	Azure Container Apps
Managed database	SQL on VM	AWS RDS / Aurora	Azure SQL Database
ML inference at scale	EC2	AWS SageMaker	Azure ML
Small team, no DevOps	EC2	EKS Managed Node Groups	AKS
Simple CRUD APIs	EC2	API Gateway + Lambda	Azure API Management + Functions

The Bottom Line

IaaS is a power tool. The right power tool, used in the right context, is indispensable. A drill is not inferior to a screwdriver. But if you’re driving a standard screw, the drill is overkill, and you’ll strip the head before you’re done.

The question isn’t whether IaaS is good or bad. It’s whether the capabilities it provides justify the operational cost, security surface area, and management overhead for the specific workload you’re running. For custom hardware requirements, steady-state high-utilisation workloads, compliance-driven isolation, and full-stack control scenarios, the answer is often yes. For event-driven functions, standard web apps, containerised workloads without custom OS requirements, and anything with a fully managed equivalent, the answer is usually no.

The teams getting this right are the ones asking the question explicitly at architecture time, rather than defaulting to VMs out of habit.