用计算找出账单上的第一名
目标
传输费用之所以可怕，不在于金额，而在于看不出它来自哪里。本实验无需云账号：把架构的流量路径展开成一张表，再亲手做出读取这张表的计算器和激增检测器。
单价表（本实验的假设）
| 路径 | 单价 |
|---|---|
| 互联网入站 | 每 GB $0 |
| 互联网出站 | 每 GB $0.09 |
| 同一 AZ 内 | 每 GB $0 |
| 跨 AZ | 两侧各收 $0.01，实际为每 GB $0.02 |
| 跨区域 | 每 GB $0.02 |
| NAT 网关 | 按处理量每 GB $0.045，常驻费用每小时 $0.045（每月 730 小时） |
| CDN 出站 | 每 GB $0.06 |
费率因云厂商和区域而异。这里要掌握的不是具体数值，而是估算数量级的方法。
流量路径（每月传输量）
| 路径 | 类型 | 每月传输量 |
|---|---|---|
| 互联网到 Web 层 | ingress |
3,000 GB |
| Web 层到互联网 | egress |
26,000 GB |
| 应用（AZ-a）与 DB（AZ-b） | cross-az |
8,000 GB |
| 应用到对象存储（经由 NAT） | nat |
5,000 GB |
| 日志到其他区域的采集器 | cross-region |
1,200 GB |
| Web 与缓存（同一 AZ） | same-az |
20,000 GB |
出站流量 26,000 GB 中，18,000 GB 是平均 20KB 的 API 响应，其余 8,000 GB 是已经压缩过的图片和视频。
要创建的内容
| 文件 | 内容 |
|---|---|
/root/transfer/paths.csv |
各路径的传输量与费用 |
/root/transfer/02-top3.md |
费用最高的前三项与合计 |
/root/transfer/bill.py |
读取该表的计算器 |
/root/transfer/04-gzip.md |
压缩带来的节省金额 |
/root/transfer/05-cdn.md |
CDN 对比与盈亏平衡命中率 |
/root/transfer/daily.csv · spike.py |
传输量激增检测 |
/root/transfer/07-notes.md |
总结 |
参考
第 3 步的计算器和第 6 步的检测器，评分器会用它藏起来的表来测试。 即使换了表也要算对，才能用在设计评审会上。
把路径做成表
将说明中列出的六条路径写入 /root/transfer/paths.csv，共四列：경로,종류,월GB,월요금（韩文，意为“路径,类型,月 GB,月费用”）。免费路径的费用也要写成 0。
“类型”列 종류（韩文，意为“类型”）共有 ingress、egress、same-az、cross-az、cross-region、nat 六种，各占一行。
费用直接用单价表中的值相乘即可。跨 AZ 的费用会同时计在流出方和流入方两侧，实际为每 GB $0.02——只算一半是最常见的错误。
不要把免费路径从表中删掉。看不出哪里免费，下一步就无法决定把什么搬到哪里。
按费用从大到小排序
把费用最高的三项写入 /root/transfer/02-top3.md，并在每项后各补一行，说明改变什么可以降低它。最后一行写出再加上 NAT 常驻费用（730 小时 × $0.045）后的月度合计。
排序可以直接从第 1 步的表中得出。留意这三项的数量级相差多少。
降低费用的方法在前面的阅读里都讲过：改变路径、改变布局、缩小体积，三者之一。
NAT 除了处理量费用之外，还有只要开着就会计的按小时费用。即使流量减少，这部分也不会消失。
换了表也能算对的计算器
创建 /root/transfer/bill.py。用 python3 /root/transfer/bill.py <경로CSV>（占位符为路径 CSV 文件）调用时，逐行输出费用，并在最后一行输出 합계,<숫자>（韩文，意为“合计,<数字>”）。常驻费用与传输量无关，不计入。
单价作为常量放在脚本里。直接照抄说明中的单价表。
由“类型”列 종류（韩文，意为“类型”）决定单价，再乘以 월GB（韩文，意为“月 GB”），就是这一行的费用。即使有第四列也要忽略——计算器必须重新计算才有意义。
评分器也会用藏起来的表来运行。即使换了表也要算对，才能用在设计评审会上。
把压缩的价值写成金额
出站 26,000 GB 中有 18,000 GB 是 API 响应，平均 20KB。若用 gzip 压缩到平均 5KB，传输量和节省金额分别是多少？以及哪些内容不应压缩？把答案写入 /root/transfer/04-gzip.md。
20KB 变成 5KB，传输量就变成四分之一。18,000 GB 会变成多少，减少了多少？
用减少的 GB 数乘以出站单价 $0.09，就是每月节省的金额。
其余 8,000 GB 是已经压缩过的图片和视频，即使用 gzip 也不会变小，只会消耗 CPU。另外，流式响应不要压缩——数据块会积压在缓冲区里，使流式传输失去意义。
求出 CDN 开始变便宜的临界点
把 8,000 GB 的图片和视频放到 CDN 后面。把命中率为 90% 时的月费用和节省金额，以及命中率至少达到多少 CDN 才更便宜，写入 /root/transfer/05-cdn.md。
现在这 8,000 GB 直接从源站流出。命中率为 90% 时，源站只流出 10%，而 CDN 会把 8,000 GB 全部发送给用户。
源站出站单价为 $0.09，CDN 出站单价为 $0.06。两项金额相加，就是部署 CDN 之后的费用。
盈亏平衡点的求法是：把命中率设为 h，解方程 8000 × (1 - h) × 0.09 + 8000 × 0.06 = 720。答案用百分数表示。
比账单更早发现的机制
创建 /root/transfer/spike.py。读取 날짜,GB（韩文，意为“日期,GB”）格式的表，逐行输出传输量达到前 7 天中位数 3 倍以上的日期；只要有一天满足就以退出码 1 结束，没有则以 0 结束。前面不足 7 天的日期要跳过。测试用的样本自己写入 /root/transfer/daily.csv。
费用告警通常来得太晚。收到“已超过月预算一半”的告警时，往往已经花掉了好几天的量。
把传输量本身作为指标，在达到平时的若干倍时告警，要快得多。使用中位数，是因为平均值会被激增当天的数据自己拉高。
statistics.median 就足够了。如果阈值定得太低，告警每天都会响，而每天都响的告警没有人会看——评分器也会检查这一点。
总结三件事
在 /root/transfer/07-notes.md 中至少写三行：哪个方向会产生费用、为什么改成多 AZ 之后费用会上升、不用费用而用什么来管理。
正文中必须包含 이그레스（韩文，意为“出站流量”）、AZ 和 전송량（韩文，意为“传输量”）。