IaaS, PaaS, and FaaS describe different operational boundaries. The useful question is not which acronym is most modern, but which responsibilities a team should own for a particular workload.
## Infrastructure as a Service (IaaS)
IaaS provides compute, storage, and networking primitives while leaving the guest operating system and application stack to the customer.
Amazon EC2, Azure Virtual Machines, and Google Compute Engine are familiar examples. This model fits workloads that require operating-system control, specialized networking, custom agents, or software that does not fit a managed platform. That control also brings patching, image management, capacity planning, and host-level observability.
## Function as a Service (FaaS)
FaaS runs event-driven functions without asking the application team to provision servers. AWS Lambda, Azure Functions, and Google Cloud Functions are examples.
FaaS is one form of serverless computing, not a synonym for every serverless service. It fits short-lived, event-oriented work with variable demand. Teams still own code, dependency security, concurrency behavior, retries, idempotency, observability, and service limits. Long-running processes, specialized runtimes, or predictable sustained loads may fit another compute model better.
## Platform as a Service (PaaS)
PaaS accepts an application or container and manages more of the runtime, deployment, routing, health, and scaling layer. Elastic Beanstalk, Azure App Service, and Google App Engine are examples, although current managed-container services also occupy similar territory.
PaaS is useful when a team wants a conventional long-running application without owning hosts or building an orchestration platform. The tradeoffs are platform constraints, less control over the runtime, service-specific deployment behavior, and possible migration cost.
## Choose by responsibility
| Question | IaaS | PaaS or managed containers | FaaS |
| --- | --- | --- | --- |
| Need guest OS control? | Strong fit | Usually no | No |
| Conventional long-running service? | Possible, more operations | Strong fit | Usually not |
| Event-driven, bursty execution? | Possible, more capacity work | Possible | Strong fit |
| Team owns patching the guest OS? | Yes | Usually no | No |
| Main constraints | Operations and capacity | Platform contract | Runtime, duration, concurrency, event semantics |
Real systems commonly mix these models. A web application might run on a managed container platform, use functions for asynchronous event handling, and retain a small VM for software that requires host access. Decide per component using latency, execution duration, scaling pattern, compliance, portability, team skills, failure recovery, and total operational cost.
The service-model definitions remain useful, but provider catalogs increasingly form a spectrum rather than three clean boxes. Document the responsibility boundary for the selected service instead of relying on the acronym alone.
References: [NIST SP 800-145, The Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final) and [AWS Cloud Adoption Framework: platform perspective](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/platform-perspective.html). Verified 2026-08-01.
IaaS, PaaS, and FaaS describe different operational boundaries. The useful question is not which acronym is most modern, but which responsibilities a team should own for a particular workload.
Infrastructure as a Service (IaaS)
IaaS provides compute, storage, and networking primitives while leaving the guest operating system and application stack to the customer.
Amazon EC2, Azure Virtual Machines, and Google Compute Engine are familiar examples. This model fits workloads that require operating-system control, specialized networking, custom agents, or software that does not fit a managed platform. That control also brings patching, image management, capacity planning, and host-level observability.
Function as a Service (FaaS)
FaaS runs event-driven functions without asking the application team to provision servers. AWS Lambda, Azure Functions, and Google Cloud Functions are examples.
FaaS is one form of serverless computing, not a synonym for every serverless service. It fits short-lived, event-oriented work with variable demand. Teams still own code, dependency security, concurrency behavior, retries, idempotency, observability, and service limits. Long-running processes, specialized runtimes, or predictable sustained loads may fit another compute model better.
Platform as a Service (PaaS)
PaaS accepts an application or container and manages more of the runtime, deployment, routing, health, and scaling layer. Elastic Beanstalk, Azure App Service, and Google App Engine are examples, although current managed-container services also occupy similar territory.
PaaS is useful when a team wants a conventional long-running application without owning hosts or building an orchestration platform. The tradeoffs are platform constraints, less control over the runtime, service-specific deployment behavior, and possible migration cost.
Choose by responsibility
Question
IaaS
PaaS or managed containers
FaaS
Need guest OS control?
Strong fit
Usually no
No
Conventional long-running service?
Possible, more operations
Strong fit
Usually not
Event-driven, bursty execution?
Possible, more capacity work
Possible
Strong fit
Team owns patching the guest OS?
Yes
Usually no
No
Main constraints
Operations and capacity
Platform contract
Runtime, duration, concurrency, event semantics
Real systems commonly mix these models. A web application might run on a managed container platform, use functions for asynchronous event handling, and retain a small VM for software that requires host access. Decide per component using latency, execution duration, scaling pattern, compliance, portability, team skills, failure recovery, and total operational cost.
The service-model definitions remain useful, but provider catalogs increasingly form a spectrum rather than three clean boxes. Document the responsibility boundary for the selected service instead of relying on the acronym alone.