上周有位朋友拿着一张某云平台的月度账单来找我，指着其中一行问：“我这台机器平时几乎没人访问，怎么突然冒出个‘公网出流量’收了几百块？”我让他把账单明细截全，屏幕上依次出现“弹性公网IP”“按流量计费”“快照存储容量”“对象存储请求次数”“负载均衡实例规格”，他盯着看了半天说了句实话：在他的认知里，这些统统属于“我买的那台云服务器”。这一幕几乎是每个刚开始接触云计算的人都会经历的困惑。云计算领域的专业术语从来不是为了把简单的事说复杂，它背后对应的是清晰的责任边界、成本归属和故障范围——不懂这些词，你就不知道自己到底买了什么、该为哪一部分付钱、出问题时该找谁。
这份术语梳理就是写给那些“文档能看懂每个字，连起来却不知道在说什么”的人。刚入行的运维、准备上云的后端开发、需要评估预算的技术负责人，甚至是需要和供应商对话的采购，都能从里面找到能直接拿去用的解释。我会按照资源、流量、存储网络、可用性、计费、云原生与安全这几个真实工作中高频出现的场景来归类，每个词都尽量说清楚它解决什么问题、和相邻概念差在哪里、实际使用中容易在哪栽跟头。术语这个东西，光背定义没用，得知道它在什么语境下被人提起。
1. 一张账单暴露的术语断层
1.1 术语混乱的根源：同一件事在不同层被反复命名
云计算的术语体系之所以让人头晕，很大程度是因为它同时承载了三套语言的翻译工作：底层是硬件与操作系统的语言（CPU、内存、磁盘、网卡），中间是平台抽象出来的能力语言（实例、镜像、安全组、对象），上层是商业计费的语言（规格族、包周期、流量包、预留）。这三套语言经常指向同一件东西，比如“一块 100G 的云盘”，在资源视角叫块存储，在计费视角叫云盘容量，在运维视角叫数据盘，在备份视角叫快照源。你要是把它们当成四个不同的事物去学，记忆负担立刻翻倍。
我的处理办法是先把所有术语往四个抽屉里塞：资源层（我到底租到了什么实体或虚拟实体）、能力层（平台替我做了什么，比如负载均衡、自动伸缩、托管数据库）、运营层（怎么观测、怎么容灾、怎么发布）、商业层（怎么计费、怎么承诺、怎么赔付）。同一个词如果跨抽屉出现，说明它是个跨界概念，需要单独记，比如“弹性”既是能力也是卖点，“SLA”既是运营指标也是合同条款。
这个分法不唯一，但它有个好处：当你在一份陌生的架构文档里看到十几个不认识的词时，能快速判断出“这是资源选型问题”还是“这是计费口径问题”，从而知道该去查哪一类资料，而不是漫无目的地搜。我见过不少人把“存储类型”和“计费模式”混在一起讨论，结果方案会上吵了半小时，其实两边说的根本不是同一层的东西。
提示：遇到不认识的术语，先问一句“它描述的是资源、能力、运维还是钱”，八成能立刻定位。
1.2 四个抽屉的划分与自查清单
资源层的典型词包括：实例、规格族、vCPU、内存、GPU、裸金属、虚拟机、容器、镜像、快照、云盘、本地盘。能力层包括：负载均衡、自动伸缩、对象存储、托管数据库、消息队列、函数计算、CDN。运营层包括：可用区、地域、监控指标、日志、告警、灰度发布、容灾、备份、RTO、RPO。商业层包括：按量付费、包年包月、预留、竞价实例、出网流量、请求次数、SLA、赔付。
刚上手时可以做一张自己的对照表，左边写你听到的原词，右边写“它属于哪个抽屉”“它解决什么问题”“它和哪个词最容易混”。我自己的表里有一行记了三年：“会话保持——四层/七层负载均衡都支持，但实现方式不同，排查粘性失效时先看这个”。这种一句话笔记，比任何官方文档都管用，因为它来自你自己踩过的坑。
后面几节我会按这个思路往下拆，重点放在“多个词放在一起才看得懂”的地方，因为单独的术语解释到处都有，真正难的是分辨它们之间的边界。
2. 资源层：从一台机器拆到一个函数
2.1 IaaS、PaaS、SaaS 的责任分界线
这三个缩写几乎出现在所有云计算的入门材料里，但很多人只记住了“基础设施即服务、平台即服务、软件即服务”这串翻译，并没抓住真正有用的信息：责任边界在哪里。用一句话概括，IaaS 是你租了机房和机器，操作系统以上全归你管；PaaS 是你只交出代码和数据，运行时、中间件、扩缩容归平台管；SaaS 是你连代码都不用管，只负责使用和配置账号。
这条边界为什么重要？因为它直接决定了故障时谁背锅、安全漏洞谁修、版本升级谁做。举个具体例子：你买了一台 IaaS 云服务器，操作系统内核爆出高危漏洞，补丁得你自己打；你用了托管数据库（典型 PaaS 能力），数据库小版本升级通常由平台在维护窗口完成，但你得关注它什么时候重启、会不会影响业务连接。很多人把托管服务当成“买了就不用管”，结果在维护窗口被强制重启打了个措手不及。
还有一个常见误解是把“托管”等同于“免运维”。托管只是把一部分运维动作转移给平台，你的表结构设计、索引优化、慢查询治理、连接池配置，一样都跑不掉。我在评审里见过最典型的翻车是：业务方以为用了托管缓存服务就不会有性能问题，结果把所有热点 key 集中在一个分片上，平台再稳也救不了。
2.2 虚拟机、容器、裸金属、Serverless 的取舍逻辑
这四个词经常被并列讨论，但它们解决的是不同维度的问题。虚拟机提供的是完整的操作系统隔离，隔离性强、兼容性好、启动在分钟级；容器共享宿主机内核，启动在秒级、密度高，但隔离强度弱于虚拟机；裸金属给你的是不带虚拟化层的物理机，适合对性能抖动敏感、需要特定硬件特性或强合规隔离的场景；Serverless（函数计算这类形态）把“实例”这个概念都藏起来了，你只提交代码，平台按请求调度，冷启动是它的固有代价。
选型时真正该问的不是“哪个更先进”，而是三个问题：启动速度要求多少、隔离要求多严、负载是否持续。负载持续且稳定的服务，用虚拟机或裸金属的单位成本往往更优；有明显波峰波谷、且能接受冷启动的异步任务，函数计算很省心；需要快速弹性又要保持语言运行时自由的，容器是折中点。我曾经把一个日均请求量不大的定时任务放在常驻虚拟机上跑，一年下来机器空转的时间超过九成，换成按请求计费的模式后成本直接降了一个量级。
这里还要提一个词：超分。它指的是平台把物理 CPU 或内存按一定比例超额分配给多个虚拟机。超分比例高，单机成本低，但邻居吵闹（noisy neighbor）的风险上升。共享型规格和独享型规格的差价，本质上就是你在为“确定性”付钱。对延迟敏感的服务，别只看价格选共享型，我见过因为 CPU 争抢导致接口 P99 从 80ms 抖到 400ms 的情况，排查了两天才定位到是宿主争用。
2.3 镜像、快照、模板：三个“复制”动作的区别
这三个词经常被混用，但用途完全不同。镜像（Image）是一个可启动的系统模板，包含操作系统、预装软件和配置，用来批量创建实例；快照（Snapshot）是某个时间点磁盘数据的副本，用来做数据回滚和备份，本身不能直接启动；模板（Template）更多是编排层的概念，把实例规格、网络、安全组、启动脚本打包成一套可重复部署的定义。
实操中最容易出问题的是快照。很多人以为做了快照就等于做了备份，其实要看快照的存储位置和一致性。如果快照和应用写入没有配合（比如数据库还在跑着就打了快照），恢复出来的数据可能处于不一致状态，需要额外的日志回放才能用。对数据库这类有状态服务，更稳的做法是应用层逻辑备份加物理快照双保险，并且定期做恢复演练——没演练过的备份，只能叫“可能存在的备份”。
镜像这边的心得是：把“基础镜像”和“业务镜像”分层维护。基础镜像只放操作系统加固、监控代理、日志采集这些通用件，业务镜像在其上叠加。这样基础层出安全补丁时，只需重建基础镜像并批量滚动更新，不用逐个业务去改 Dockerfile 或启动脚本。我们早期把所有东西塞在一个镜像里，后来一次系统级漏洞修复，二十多个镜像全部要重做，那滋味不太好受。
3. 弹性与流量：云的核心卖点到底怎么落地
3.1 伸缩组、最小最大实例数、冷却时间
“弹性伸缩”这个词听起来很美好，但真正配置过的人都知道，它的难点不在“能扩”，而在“什么时候扩、扩多少、扩完多久再动手”。伸缩组（Scaling Group）是一组同质实例的集合，你在上面配置最小实例数、最大实例数和期望实例数，再挂伸缩规则。最小实例数决定了保底容量，最大实例数决定了成本上限——这两个数字其实是成本与可用性之间的两个旋钮。
冷却时间（Cooldown）是最容易被忽略的参数。它指的是上一次伸缩动作完成后，系统在多长时间内不再触发新的伸缩。设得太短，指标一抖动就反复扩缩，实例刚起来就被杀掉，白白浪费启动时间；设得太长，流量来了却扩不动。经验做法是把冷却时间设成“实例启动时间 + 应用预热时间”的量级，比如实例 90 秒启动、应用加载缓存 60 秒，冷却时间给到 180 到 300 秒比较稳妥。
还有一个概念叫预热（Warm-up）。有些负载均衡支持配置预热时间，新加入的后端在预热期内只接收小比例流量，避免冷实例被瞬间打满。这个机制对 Java 这类启动后需要 JIT 预热的应用尤其重要。我吃过一次亏：扩容策略配得很激进，一次流量峰值扩了二十台，结果新实例全部处于冷状态，响应时间反而比扩容前更差，用户侧感受到的就是一次明显的抖动。
3.2 四层与七层负载均衡的分工
负载均衡这个词本身不难，难的是分清四层和七层。四层工作在传输层，看的是 IP 和端口，转发效率高、协议无关，但看不懂 HTTP 内容；七层工作在应用层，能解析 URL、Header、Cookie，因此可以做基于路径的路由、基于 Header 的灰度、证书卸载。选择依据很直接：需要按 HTTP 内容做转发规则的，用七层；纯 TCP/UDP 服务或者追求极致转发性能的，用四层。
调度算法也值得说两句。轮询适合后端性能一致的场景；加权轮询用于后端配置不同的情况；最小连接数在长连接场景下更均衡；一致性哈希用于需要把同一类请求固定到同一后端的场景，比如缓存代理。会话保持（Session Affinity）是另一个高频词，它让同一客户端的请求落到同一后端，配置简单但会带来负载不均，一旦某台后端故障，粘在它上面的会话就会受影响，所以更推荐把会话状态外置到共享存储。
健康检查是负载均衡里最不能省的一环。它分 TCP 探测和 HTTP 探测，前者只看端口通不通，后者能校验业务是否真的可用。检查间隔、超时时间、不健康阈值、健康阈值这四个参数要成套看：间隔太短会给后端带来额外压力，阈值太低容易误摘，太高则故障摘除慢。我一般会把不健康阈值设为 2 到 3 次，健康阈值设为 3 到 5 次，宁可摘得慢一点，也别让一台刚恢复的实例立刻被流量打垮。
3.3 QPS、并发连接数、P99：三个被混着用的指标
QPS 是每秒查询数，衡量吞吐；并发连接数是同一时刻保持的连接数量，衡量占用；P99 是把响应时间排序后第 99 百分位的值，衡量尾部体验。这三个指标经常被混为一谈，导致容量评估失真。一个接口 QPS 只有 50，但每个请求耗时 2 秒，那并发就是 100 左右；如果连接池只配了 20，请求会在排队上耗掉大量时间，表现出来就是 P99 飙升而 CPU 很闲。
限流、熔断、降级是配套的三个动作。限流是主动拒绝超出配额的部分，常见算法有令牌桶和漏桶，前者允许一定突发，后者输出更平滑；熔断是在依赖方错误率超过阈值时快速失败，避免线程被拖死；降级是在资源不足时牺牲非核心功能，保住主链路。这三件事最好在架构设计阶段就规划好降级预案，而不是等故障发生时临时拍脑袋。我的习惯是给每个对外接口标注“可降级/不可降级”，并在压测时专门演练一次降级开关的切换。
| 指标 | 含义 | 常见误用 |
|---|---|---|
| QPS | 每秒请求数 | 用它估算并发，忽略响应时间 |
| 并发连接数 | 同时保持的连接数量 | 只看连接数不看连接池上限 |
| P99 响应时间 | 尾部延迟 | 只看平均值，掩盖长尾 |
| 错误率 | 失败请求占比 | 不区分业务错误与系统错误 |
4. 存储与网络：最容易张冠李戴的一组
4.1 块存储、文件存储、对象存储的选择依据
这三种存储的区别，用一句话记住：块存储像一块可以插到机器上的硬盘，文件存储像一个可以被多台机器同时挂载的共享目录，对象存储像一个通过 HTTP 接口存取文件的超大网盘。块存储的性能最好、延迟最低，但通常只能挂载到一台实例上（部分平台支持多挂但需要集群文件系统配合）；文件存储支持多机共享，适合需要共享读写目录的场景；对象存储容量几乎无上限、按量计费、通过 API 访问，适合图片、视频、备份、日志归档这类非结构化数据。
选错类型的代价不小。我见过把用户上传的图片存进块存储的案例，随着数据量增长，云盘不断扩容，成本居高不下，而且备份和迁移都非常笨重；换成对象存储后，同样的数据量成本降了大半，还顺带获得了生命周期管理和跨区域复制能力。反过来，也有把数据库文件放在对象存储上的尝试，结果 IO 延迟完全不可接受——对象存储不是为随机小 IO 设计的。
对象存储里还有几个必知的词：桶（Bucket）是命名空间，键（Key）是对象路径，最终一致性曾经是个坑但现在多数实现已提供强一致读，存储类别决定单价和取回成本，预签名 URL 用来在不开通公开读的情况下临时授权访问。跨域访问、防盗链、版本控制这些配置项，做 Web 业务时几乎都会碰到。
4.2 生命周期、冷热分层与取回成本
对象存储的计费不是单一的“每 GB 多少钱”，它由存储费、请求费、取回费、流量费几部分构成。热数据单价高但取回免费，冷数据和归档单价低但取回要收费，而且可能有最短存储期限——存进去三天就删，照样按一个月计费。这就是“生命周期规则”存在的意义：你可以配置“创建 30 天后转低频、90 天后转归档、365 天后删除”，让数据自动沉降到便宜的层级。
这里有个特别容易忽略的成本陷阱：归档类存储的取回通常不是即时的，有的需要几分钟到几小时，而且取回请求本身按量收费。如果业务对读取延迟有要求，把还在被频繁访问的数据误配成归档层，用户体验和账单会同时出问题。我的做法是先用访问日志统计出数据的真实访问分布，再定分层阈值，而不是拍脑袋设个 30 天。
快照的存储费也是同理。快照是按增量存储的，但长期保留大量历史快照，累积起来的容量和费用并不低。设置快照保留策略（比如保留最近 7 天每日、最近 4 周每周）比无限期保留要理性得多。
4.3 VPC、子网、安全组、NAT：网络术语的最小闭环
VPC（虚拟私有云）是你专属的隔离网络空间，可以自定义网段；子网是 VPC 内的网段切分，通常按可用区划分；路由表决定流量往哪走；安全组是作用于实例的虚拟防火墙，默认有状态——出去的连接回包自动放行；网络 ACL 作用于子网，通常无状态，需要分别配置入和出。这四个词构成了云上网络的最小闭环，绝大多数“连不通”的问题都能在这四层里定位。
排查思路我一般按这个顺序走：先看安全组规则是否放通了目标端口和来源网段，再看子网路由表是否有到目标的路由，然后确认实例是否绑定了公网 IP 或位于有 NAT 网关的子网，最后看应用本身是否监听在 0.0.0.0 而不是 127.0.0.1。这个顺序能覆盖八成以上的故障，而且每一步都能用最简单的连通性测试验证，不用一上来就抓包。
| 术语 | 作用范围 | 是否有状态 | 典型用途 |
|---|---|---|---|
| 安全组 | 实例 | 有状态 | 控制进出实例的流量 |
| 网络 ACL | 子网 | 无状态 | 子网级粗粒度管控 |
| 路由表 | 子网 | 不适用 | 决定流量下一跳 |
| NAT 网关 | VPC | 有状态 | 私网实例主动访问公网 |
带宽相关的词也要分清：固定带宽是按峰值上限包月计费，适合流量平稳的业务；按使用流量计费是用了多少算多少，适合波动大或流量很小的业务；共享带宽包把多个公网 IP 的带宽合并计费，能削峰填谷。最容易产生意外账单的是出网流量——同地域内网互通通常免费，跨地域和出公网才收费，很多人在压测时忘了这一点，一晚上跑掉不少预算。
5. 可用性：几个 9 到底意味着什么
5.1 地域、可用区与故障域
地域（Region）是物理位置相对独立的数据中心集群，可用区（AZ）是同一地域内电力与网络相对独立的机房。跨可用区部署的意义在于：单个机房级别的故障不会导致整体不可用，同时同地域内跨可用区访问的延迟通常在毫秒级，比跨地域低一个数量级。跨地域部署解决的是更大范围的灾难，但代价是延迟增加和数据同步复杂度上升。
故障域是更抽象的概念，指“一个故障可能同时影响的范围”。同一个机架、同一台物理机、同一个交换机，都可以是一个故障域。做高可用设计时，核心是让副本分散在不同的故障域里。我见过把主备数据库放在同一可用区的架构，看起来做了主备，实际上机房一断两个一起没，这种“假高可用”在评审里应该被直接指出来。
5.2 RTO 与 RPO：容灾方案的两个硬指标
RTO（恢复时间目标）回答的是“故障发生后多久能恢复服务”，RPO（恢复点目标）回答的是“最多能容忍丢失多长时间的数据”。这两个数字决定了容灾方案的档次和成本。RTO 要求分钟级，就得做热备或双活；允许小时级，冷备加自动化恢复脚本就够。RPO 要求接近零，就得做同步复制或持续日志传输；允许几分钟，异步复制即可。
很多团队在写方案时把 RTO、RPO 写成“越快越好、越少越好”，这等于没写。正确的做法是先跟业务方对齐可接受的损失，再倒推技术方案和预算。一个内部管理系统要求 RPO 为零、RTO 五分钟，为此付出的成本可能远超它本身的价值。反过来，交易类系统如果 RPO 写成几小时，那基本是不可接受的。
可用性的“几个 9”也值得换算成具体时长，不然数字没有体感。
| 可用性 | 全年允许不可用时长 | 大致感受 |
|---|---|---|
| 99% | 约 87.6 小时 | 每季度停一天多 |
| 99.9% | 约 8.76 小时 | 每月不到一小时 |
| 99.95% | 约 4.38 小时 | 每季度半小时级 |
| 99.99% | 约 52.6 分钟 | 全年总计不到一小时 |
| 99.999% | 约 5.26 分钟 | 需要多活架构支撑 |
要特别注意，云平台承诺的 SLA 通常是针对“单个实例或单个服务”的可用性，不是你的整体业务可用性。你的业务由十几个组件串联，每个组件 99.9%，串联起来的理论可用性会明显低于 99.9%。这就是为什么架构上要尽量减少串行依赖、要给关键路径做冗余。
5.3 灰度、蓝绿与回滚
灰度发布（也叫金丝雀发布）是把新版本先放给一小部分流量，观察指标正常后再逐步放量；蓝绿部署是同时维护两套环境，切换流量入口完成发布，回滚就是把入口切回去；滚动发布是分批替换实例，过程中新旧版本共存。这三个词经常被混着说，但关键差别在于“回滚速度和资源占用”：蓝绿切换最快但资源翻倍，灰度最省资源但需要流量控制能力，滚动是折中。
真正决定发布质量的不是选了哪种方式，而是有没有配套的可观测性和回滚预案。发布前要明确看哪些指标判断成功——错误率、P99、关键业务转化率，而不是只看机器 CPU。发布中要保证新旧版本的数据兼容，尤其是数据库 schema 变更，必须先做向前兼容的加字段，再上车代码，最后清理旧字段，分三次发布完成。一次性改表结构再发版，是回滚事故的高发区。
6. 计费术语：报价单上最容易看错的部分
6.1 按量、包年包月、预留与竞价
按量付费是按实际使用时长计费，灵活但单价最高；包年包月是预付费，单价低但灵活性差；预留（或称节省计划）是一种承诺消费换折扣的模式，通常承诺一年或三年的用量，折扣力度介于按量和包月之间；竞价实例利用平台的闲置容量，价格大幅低于按量，但可能被随时回收，只适合可中断的任务，比如批处理、渲染、离线计算。
选择逻辑可以简化为一条线：负载是否 7×24 稳定运行。稳定的核心服务，包月或预留更划算；有明显波峰波谷的，波峰用按量、波谷用包月；可以中断的任务，优先竞价。这里的关键是别把竞价实例用在有状态服务上，一旦被回收，处理不当会丢数据。用竞价实例的任务必须做到“随时可被杀、进度可续跑”。
还有一个词叫“节省计划”，它不绑定具体实例规格，只承诺每小时消费金额，抵扣范围更广，适合规格经常调整的团队。相比绑定具体实例的预留，它的灵活性更高，折扣略低一点，属于典型的“用一点折扣换自由度”。
6.2 出网流量、请求次数与 IOPS 的计费陷阱
云计算账单里最容易失控的三项：出网流量、请求次数、存储 IOPS。出网流量指数据从云上流到公网产生的费用，入方向通常免费；请求次数主要针对对象存储、API 网关、函数计算这类按调用计费的服务，单次极便宜但量大起来很可观；IOPS 则出现在高性能云盘上，超过基础性能的部分要额外付费。
拿对象存储举例，如果业务把大量小文件直接暴露给公网访问，每一次 GET 都是一次请求计费，再加上出网流量，成本可能远超存储本身。合理的做法是前面挂 CDN 做缓存，把回源次数压下来；小文件做合并或打包；对冷数据设置生命周期规则自动沉降。
还有一个常被忽略的点是闲置资源。未挂载的云盘、未绑定的公网 IP、长期没人用的负载均衡实例、忘记删除的旧快照，都在持续计费。我建议每月做一次资源盘点，把“创建时间超过 90 天且监控无流量”的资源列出来复核，这一招往往能省下不少预算。
| 计费模式 | 适合场景 | 主要风险 |
|---|---|---|
| 按量付费 | 流量波动大、短期项目 | 单价高，忘记释放会持续扣费 |
| 包年包月 | 7×24 稳定负载 | 规格选大后难降配 |
| 预留/节省计划 | 长期稳定且有成本优化诉求 | 承诺期内用量不足则浪费 |
| 竞价实例 | 可中断的批处理任务 | 被回收导致任务中断 |
7. 云原生与安全：评审现场出现频率最高的一批词
7.1 微服务、容器编排、服务网格与 Serverless
微服务是一种架构风格，把单体拆成按业务边界划分的独立服务，每个服务独立部署、独立扩展。它带来的收益是解耦和独立迭代，代价是分布式复杂性——服务发现、配置管理、链路追踪、分布式事务，一个都躲不掉。很多团队拆完微服务才发现，运维复杂度上升带来的成本，超过了独立部署带来的收益，所以拆分前要先想清楚边界，别为了拆而拆。
容器编排（典型代表是 Kubernetes）解决的是“一堆容器怎么调度、怎么自愈、怎么滚动更新、怎么服务发现”。它的核心概念包括 Pod（最小调度单元）、Deployment（无状态工作负载）、Service（稳定访问入口）、ConfigMap 与 Secret（配置与密钥）、Namespace（逻辑隔离）。学这些词的关键是理解它们各自解决什么问题，而不是背 API 对象字段。
服务网格是在服务之间加一层轻量代理，把流量治理（重试、超时、熔断、灰度、mTLS 加密）从业务代码里剥离出来。它的价值在服务数量多、语言栈杂的场景下最明显，代价是额外的延迟和运维复杂度。服务规模不大的时候引入，很可能得不偿失。
Serverless 前面提过，这里补充两个配套词：冷启动和并发度。冷启动是函数实例首次创建时的初始化耗时，可以通过预留实例或减小包体积来缓解；并发度决定同一时刻能处理多少请求，超出部分要么排队要么被拒绝，配置时要结合下游数据库的连接数上限一起考虑，别让函数把数据库连接打满。
7.2 身份、密钥、WAF 与审计
身份与访问管理（IAM）是云上安全的基石，核心概念有账号、用户、角色、策略、临时凭证。实操中最容易犯的错是给应用直接分配长期密钥，正确做法是给实例绑定角色，让应用通过实例元数据获取临时凭证，到期自动轮换。长期密钥一旦泄露，攻击者可以长期使用；临时凭证的有效期通常以小时计，风险窗口小得多。
密钥管理服务（KMS）负责密钥的生成、存储、轮换和使用审计。数据库加密、对象存储加密、磁盘加密背后通常都依赖它。要分清“静态加密”和“传输加密”：前者保护落盘数据，后者保护链路数据，两者都要有，不能互相替代。
WAF（Web 应用防火墙）主要防 SQL 注入、XSS、恶意爬虫这类应用层攻击；DDoS 防护针对的是流量型攻击，靠清洗中心把异常流量拦在外面。这两个词经常被一起提，但防护层次完全不同。配置 WAF 时要注意规则上线初期用观察模式跑一段时间，直接拦截容易误伤正常业务。
审计日志记录的是“谁在什么时间对什么资源做了什么操作”，出安全事件时这是唯一的追溯依据。建议把关键操作（删除、权限变更、网络策略调整）单独配置告警，而不是等月底才去翻日志。
7.3 建立自己的术语表：一个可持续的方法
术语这东西，看一遍记不住，用一次就忘不掉。我自己的做法是维护一份纯文本的术语表，每条只写三行：一句话定义、一个我踩过的坑、一个相邻概念的区分。比如“安全组：实例级有状态防火墙；坑是改完规则没生效，后来发现是入方向没放通；和网络 ACL 的区别是后者作用于子网且无状态”。这份表积累到几十条之后，看新文档的速度会明显变快。
第二个方法是“反向解释”。每次遇到一个新词，试着用一句不含该词的话把它解释给一个没接触过云计算的人听。解释不通，说明你只是记住了字面，没抓住语义。我经常在通勤路上做这个练习，比刷文档效率高。
第三个方法是按场景串词，而不是按字母排序背。比如把“一次请求从用户到数据库”的完整路径画出来，沿途标上 CDN、负载均衡、网关、服务、缓存、数据库、对象存储，每个节点再展开对应的术语。这样记下来的词是有位置的，用的时候能顺着路径找回来。
最后提醒一句：不同云平台对同一能力经常用不同名字，比如负载均衡有的叫 SLB、有的叫 ELB，对象存储的层级命名也各不相同。看到一个陌生缩写，先别急着记，去查它对应的能力类别，把它归到自己抽屉里的对应位置，比死记缩写有用得多。术语是工具，不是考点，能用来做判断的才值得留在脑子里。
