一文看懂 IaaS、PaaS、SaaS：云计算三大服务模式的边界、起源与选型
结论先行： IaaS 卖「基础设施」，你自己装系统、部署中间件和应用；PaaS 卖「开发运行平台」，你主要写代码和管数据；SaaS 卖「现成软件」，你直接登录使用。 一句话记忆：你越想自己做主，就越靠近 IaaS；越想少管运维、快交付，就越靠近 PaaS；越想开箱即用，就越靠近 SaaS。 多数企业的最佳实践不是「三选一」，而是组合使用。
写在前面：为什么今天还要谈这三个词
IaaS、PaaS、SaaS 是云计算最经典的三种服务模型。早在 2011 年，NIST（美国国家标准与技术研究院）就在《The NIST Definition of Cloud Computing》（SP 800-145）中把它们正式归纳为云计算的三大服务模式。
十几年过去，这组概念不但没有过时，反而变得更重要了：容器、Serverless、AI 平台不断涌现，新产品的宣传话术五花八门，但只要回到「技术栈里的哪一层由谁来管」这个原点，绝大多数云产品都能被迅速定位。这篇文章就从这个原点出发，把三种模式的定义、职责边界、历史起源、当前主流产品和选型思路一次讲清。
一、三种模式到底是什么：本质是「技术栈谁来管」
先看一个完整的技术栈，从下往上依次是：物理数据中心、服务器与网络设备、虚拟化层、操作系统、运行时与中间件、应用代码，最上面是数据与业务配置。三种模式的差别，本质上就是云厂商替你管到哪一层。
最终用户 / 业务部门
│
▼
┌──────────────────────────────┐
│ SaaS：现成应用 │ ← CRM / 邮箱 / 协同办公
├──────────────────────────────┤
│ PaaS：托管运行平台 │ ← Web App / 容器平台 / 函数计算
├──────────────────────────────┤
│ IaaS：计算 / 存储 / 网络 │ ← 云主机 / 云硬盘 / VPC
├──────────────────────────────┤
│ 物理数据中心 / 服务器 / 网络 │
└──────────────────────────────┘- IaaS（Infrastructure as a Service）：云厂商提供虚拟化的计算、存储、网络资源。操作系统以上的一切——装系统、打补丁、部署中间件和应用——都由你自己负责。它最像「租云上的机房」。
- PaaS（Platform as a Service）：云厂商把操作系统、运行时、数据库/中间件等托管好，你主要负责写代码和管理数据。它最像「租一间带全套厨具的厨房」——你只需要带食材来做菜。
- SaaS（Software as a Service）：云厂商直接交付可用的软件，你登录即用。剩下要操心的只有账号、数据、权限和业务流程配置。它最像「直接去餐厅点菜」。
用做饭打个完整的比方：自建机房相当于从买地盖房开始全部自己来；IaaS 是租一间水电煤齐全的毛坯厨房，锅碗瓢盆自备；PaaS 是租带全套厨具的厨房，只管带食材下厨；SaaS 则是直接去餐厅，菜端上来就能吃。
二、职责与管理边界：控制力和运维负担同步递减
下表按 Azure 与 AWS 的共享责任模型（Shared Responsibility Model）整理。具体产品会有例外，但大方向非常稳定：从 IaaS 到 SaaS，用户的控制力递减，运维负担也递减。
| 层级/职责 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 物理数据中心、硬件、网络 | 厂商 | 厂商 | 厂商 |
| 虚拟化层 | 厂商 | 厂商 | 厂商 |
| 操作系统 | 用户 | 厂商 | 厂商 |
| 运行时/中间件/数据库平台 | 用户 | 厂商为主 | 厂商 |
| 应用代码 | 用户 | 用户 | 厂商 |
| 应用配置 | 用户 | 用户 | 共享，以租户配置为主 |
| 数据、身份、权限 | 用户 | 用户 | 用户 |
| 典型收益 | 灵活性最高 | 上线更快 | 使用门槛最低 |
| 典型代价 | 运维最重 | 平台约束更强 | 可定制性最弱 |
有两点特别值得注意：
- 无论选哪种模式，「数据、身份、权限」永远是你自己的责任。 云厂商不会替你管好谁能访问什么数据——很多云上安全事故，根源都是用户侧的权限配置失误，而不是云平台本身被攻破。
- 责任边界同时也是能力边界。 你放弃了对操作系统的控制，也就同时放弃了在系统层做深度定制的能力。选型时要问的不是「哪种模式更先进」，而是「我需要控制到哪一层」。
三、它们从哪来：从分时计算到 NIST 标准定义
这三种模式并不是突然出现的，它们的思想可以追溯到半个多世纪前：
- 1960 年代 — 分时计算（Time-sharing）：多个用户共享一台昂贵的大型机，「共享算力」的理念由此发端。
- 1990 年代 — ASP（Application Service Provider）：软件开始「在线租用」，可视为 SaaS 的前身，但受限于当时的网络与架构，多数 ASP 并未成功。
- 1999 年 — Salesforce 上线云端 CRM：喊出「No Software」的口号，把企业软件做成按订阅付费的在线服务，SaaS 商业模式就此出圈。
- 2006 年 — AWS 推出 S3 与 EC2：存储和计算第一次变成「按用量付费的公共资源」，这是 IaaS 的决定性引爆点。
- 2007 年 — Heroku 成立：
git push即部署的极致体验，定义了「开发者体验优先」的托管应用平台，带起 PaaS 的早期风潮。 - 2008 年 — Google App Engine 发布：把「大规模自动伸缩」的托管平台做成大厂样板，是经典「纯 PaaS」的代表。
- 2010 年 — Microsoft Azure 商用：云平台进入大型企业的主流采购清单。
- 2011 年 — NIST 发布 SP 800-145：IaaS、PaaS、SaaS 从行业惯用语升格为标准定义。
- 2020 年代 — 容器、Serverless、AI 平台化：PaaS 与 SaaS 的边界持续演进，「XaaS」家族不断扩张。
如果只问「谁最能代表各模式的风潮引领者」，一个相对稳妥的判断是：SaaS 看 Salesforce，IaaS 看 AWS，PaaS 看 Heroku 与 Google App Engine——前者定义了开发者文化与部署体验，后者树立了大厂托管平台的能力范式。
四、2026 年的主流代表产品
先说明市场口径：IaaS 的市场格局最清晰，PaaS 最分散，SaaS 最细分。 以下信息优先依据官方资料与公开可访问的研究机构数据（Synergy Research、Gartner、Forrester、IDC 等），时间截至 2026 年 7 月。
IaaS：超大云厂商的主场
| 产品 | 功能定位 | 典型客户 | 优点 | 局限 |
|---|---|---|---|---|
| AWS EC2 | 通用云主机/算力底座，覆盖 Web、数据库、HPC、AI | 互联网公司、ISV、大型企业 | 规格最全、生态最深、全球成熟度高 | 成本治理与架构复杂度高 |
| Azure Virtual Machines | 面向企业的 VM 与混合云基础设施 | 微软技术栈企业、政企 | 与 Windows/AD/SQL/混合云整合强 | 产品线复杂，跨服务配套较重 |
| Google Compute Engine | 高性能 VM、自定义机型、数据/AI 友好 | 数据密集型、AI 团队 | 网络与数据平台强，适合云原生/AI | 企业软件生态广度弱于前两者 |
| 阿里云 ECS | 国内/亚太常见云主机底座 | 中国企业、本地合规、出海团队 | 本土生态与中国场景适配强 | 全球生态与海外通用性弱于前三 |
据 Synergy Research Group 的数据，2026 年第一季度全球公有云基础设施市场中，AWS 份额约 28%，Microsoft Azure 约 21%，Google Cloud 约 14%，三家稳居第一梯队。
PaaS：从「纯托管平台」到「云原生应用平台」
| 产品 | 功能定位 | 典型客户 | 优点 | 局限 |
|---|---|---|---|---|
| Azure App Service | 托管 Web 应用与 API 平台 | 中大型企业、.NET 团队 | 部署快、托管度高、Azure 集成强 | 灵活性不如自建 IaaS/K8s |
| Google App Engine | 经典「纯 PaaS」，自动伸缩托管应用 | 追求快上线的小团队 | 运维负担低、自动扩缩容成熟 | 平台约束较强，存在一定锁定 |
| Red Hat OpenShift | 企业级混合云应用平台/Kubernetes PaaS | 大型企业、强治理场景 | 混合云一致性好、企业治理能力强 | 学习曲线和总体成本较高 |
| Heroku | 开发者体验优先的应用托管平台 | 初创团队、原型/中小应用 | 上手极快、部署体验优秀 | 灵活性和企业长期路线较弱 |
PaaS 这一层的形态变化最大：微软在 2025 年 Gartner 云原生应用平台魔力象限中位居领导者；OpenShift 是 2025 年 Gartner 容器管理象限的领导者之一。而作为历史先锋的 Heroku，据公开报道已于 2026 年进入 sustaining engineering（维持性工程）阶段——这也印证了 PaaS 的重心正从「托管应用平台」转向「云原生应用平台、容器平台与函数/无服务器平台」。
SaaS：深入几乎所有通用软件领域
| 产品 | 功能定位 | 典型客户 | 优点 | 局限 |
|---|---|---|---|---|
| Salesforce CRM | CRM/销售/服务/营销一体化 | 中大型企业、销售与客服组织 | 业务能力广、生态强、可扩展性高 | 成本高，实施复杂度不低 |
| Microsoft 365 | 办公协作套件（邮件、文档、会议、存储） | 各类组织，尤其微软栈企业 | Office/Teams/安全与管理整合强 | 生态绑定较深 |
| Google Workspace | 浏览器原生办公协作 | 中小企业、教育、互联网团队 | 协作顺滑、管理简单、AI 已内置 | 复杂表格/本地 Office 兼容略弱 |
几个市场地位的参考点：IDC 认定 Salesforce 连续 13 年位居全球 CRM 市场第一；Microsoft 2025 财年商业席位继续增长，消费者订阅达 8900 万；Google 官方称 Workspace 已覆盖超 30 亿用户、付费客户超 1100 万。
如果关注中国本土协同 SaaS，飞书也是高关注度的代表：官方提供基础版、商业版、企业版，典型卖点是一体化协同与 AI 工作平台。不过它更适合与 Microsoft 365、Google Workspace 放在「协同办公 SaaS」维度对照，而不是与 CRM 类 SaaS 直接对比。
五、怎么选：一套简单的决策思路
选型可以从「需求的本质」出发，三个问题依次问下来：
第一问：我需要的是不是「现成的业务软件」？ 邮箱、文档协作、CRM、HR、客服、财务……如果答案是肯定的，优先看 SaaS。经验法则是：凡是不构成你公司核心差异化竞争力的软件能力，都应该先考虑「买」而不是「建」。
第二问：我要自己开发应用，但不想管运维吗？ 如果你要快速开发并上线 Web/API 应用，团队不大、不想自己维护操作系统、运行时、补丁和扩缩容，优先看 PaaS。它用平台约束和一定的供应商锁定，换来更快的交付速度。对于大型企业、多云与强治理环境，OpenShift 一类「云原生应用平台」往往比传统纯 PaaS 更合适。
第三问：我是否需要对底层的完全控制？ 搬迁传统系统上云、自定义网络/安全/中间件、GPU/裸金属/非标架构——这些场景优先看 IaaS。它自由度最高，但也最要求你具备运维、成本治理和架构能力。
而多数企业的实际落地方式是组合拳：
- 协同办公、CRM 等通用能力 → SaaS
- 面向客户的新应用 → PaaS
- 遗留系统与特殊算力 → IaaS
这也是今天企业云架构最常见的形态。
六、快速对照表与总结
| 模式 | 一句话定义 | 最像什么 | 适合谁 | 典型场景 |
|---|---|---|---|---|
| IaaS | 租基础设施 | 租机房/云主机 | 有平台与运维能力的团队 | 迁移旧系统、复杂架构、GPU/HPC |
| PaaS | 租开发运行平台 | 租「带厨具的厨房」 | 想快交付、少运维的研发团队 | Web/API、内部系统、云原生应用 |
| SaaS | 租现成软件 | 开箱即用的在线服务 | 业务部门与通用软件采购 | 邮箱、文档、CRM、客服、HR |
最后浓缩成四点：
- 三种模式的本质差别是管理边界：从 IaaS 到 SaaS，你的控制力递减，运维负担也递减。
- 数据、身份、权限永远是你自己的责任，无论选哪种模式。
- 历史坐标：SaaS 看 Salesforce（1999），IaaS 看 AWS（2006），PaaS 看 Heroku（2007）与 Google App Engine（2008）。
- 选型不是三选一，而是按「是否核心竞争力、是否需要底层控制」把三者组合起来用。
参考资料
- NIST,《The NIST Definition of Cloud Computing》(SP 800-145)
- Microsoft Azure,《What are IaaS, PaaS, and SaaS?》及共享责任模型文档
- AWS,《Our Origins》《Amazon EC2》《Shared Responsibility Model》
- Salesforce 官方公司历史，及 IDC 全球 CRM 市场排名
- Google App Engine 官方发布信息与产品文档
- Synergy Research Group 2026Q1 云基础设施市场数据
- Red Hat OpenShift 官方资料与 Gartner/Forrester 公开摘要
- Microsoft 2025 Annual Report、Google Workspace 官方定价与新闻稿