Marico's space
最近折腾AWS成本优化，踩了几个坑，这篇把问题说清楚。
AWS（亚马逊云服务）为开发团队提供了极大的灵活性。几分钟就能启动基础设施，应用自动扩缩容，存储海量数据集，跑多地域工作负载，还不用自建机房。听起来挺美的。
但问题来了——这种灵活性是有代价的，AWS账单的增长速度往往超出预期。
一个小型开发环境可能悄悄变成昂贵的生产平台。闲置资源不断累积。EC2实例配得太大，7x24小时跑着，应用却几乎用不上那些算力。数据传输出钱、存储出钱、数据库出钱、日志出钱、备份出钱……这些叠加起来，分分钟给你一个惊喜。
好消息是：降低AWS成本不等于让应用变慢或不可靠。事实上，合理的成本优化反而能提升性能，因为它会倒逼你改善架构、智能扩缩容、清理基础设施、提高资源利用率。
目标不是单纯少花钱。
目标是在保持应用所需性能、可用性、安全性和可靠性的前提下，让每一分钱都产生更多业务价值。
下面展开说说怎么做。
动手改基础设施之前，先把钱的流向理清楚。很多团队上来就删资源、缩实例，根本不分析实际消耗情况。结果呢，性能问题冒出来了，最大的浪费源头却没解决。
先把AWS支出按账户、服务、环境、应用、团队、工作负载拆开来看。AWS的成本管理能力、账单报表、标签策略、仪表盘都能帮你建立这种可见性。重点关注哪些服务或环境的支出异常增长，然后深挖原因。
接下来，建立有意义的成本分摊标签：Environment（环境）、Application（应用）、Team（团队）、Owner（负责人）、CostCenter（成本中心）。标签打好了，就很容易搞清楚哪些工作负载在烧钱、谁该负责。
最关键的一点：别只看每月账单。要看每次请求的成本、每笔交易的成本、每个客户的成本、每个工作负载的成本、每个环境的成本。这些指标能真正反映你的架构是不是在变高效。
EC2（弹性计算云）是最容易发现节省空间的地方。但解决方案不是简单地把大实例换成小的。
正确做法是：分析每个工作负载实际消耗了多少CPU、内存、网络带宽和存储性能。应用在大实例上CPU利用率只有10%，可能有优化空间；但内存密集型应用可能反而需要更大的内存容量，即便CPU看起来不高。
用历史利用率数据，别只看一个时间点。服务器可能在正常工作时段看起来利用率不高，但在晚些时候流量会飙高。所以要评估峰值时段、周末、部署期间、季节性活动的利用率。
搞清楚工作负载特征后，选择匹配它需求的实例族。通用型、计算优化型、内存优化型、突发性能型各有各的用武之地。正确的实例不一定是最便宜的，而是能以最低可持续成本提供所需性能的。
对于流量波动的工作负载，24x7跑在最大容量上根本不划算。
自动扩缩容（Auto Scaling）让基础设施能伸能缩：需求上来就扩容，需求下去就缩容。这样高峰期能保持应用性能，低谷期不用为空闲容量付费。
但光开启自动扩缩容不等于省钱。配置糟糕的扩缩策略会导致不必要的扩容、缩容过慢、或者容量持续波动。
用有意义的指标来驱动扩缩决策。CPU利用率对某些工作负载有效，但请求数、队列深度、响应延迟、自定义应用指标可能提供更好的信号。
比如，API平台可能按每个目标的请求数扩缩，而不是只看CPU。后台处理系统可能按队列中等待的消息数来决定扩缩。这样基础设施响应的是实际工作负载压力，而不是笼统的基础设施指标。
AWS提供了几种采购方式，选对了能显著影响你的长期基础设施账单。
对于可预测的工作负载，储蓄计划（Savings Plans）或预留实例（Reserved Instances）相比持续按需运行标准费率能省下可观的钱。但这些选项需要承诺，所以在做长期承诺之前，团队应该先分析工作负载的稳定性。
对于能容忍中断的工作负载，竞价实例（Spot Instances）是另一个强大的成本优化策略。它们特别适合容错工作负载，比如批处理、CI/CD（持续集成/持续部署）worker、分布式数据处理、测试环境、以及某些Kubernetes（容器编排平台）工作负载。
不过，竞价实例需要架构层面的准备。应用应该能容忍中断并优雅恢复。如果你的应用处理不了突然的实例终止，纯粹为了省钱强行上竞价实例，只会带来运维问题。
所以，让采购模式匹配工作负载行为，别盲目选最便宜的定价选项。
存储刚建一个bucket（存储桶）或卷的时候看起来挺便宜。但时间一长，未使用的快照、旧对象、备份、日志、遗忘的卷会悄悄变成大开销。
首先识别那些不再产生业务价值的存储。旧EBS卷、 detached卷、过时快照、废弃AMI（亚马逊机器镜像）、不必要的备份都值得定期审查。
对于S3（简单存储服务），生命周期策略能自动把老数据迁到更合适的存储层。频繁访问的数据可以留在标准存储层，而更老或很少访问的数据可以转到低价层级。
重要的一点是：别把每个字节的数据都一视同仁。
昨天的数据库备份和五年没被访问过的归档不需要同样的存储策略。通过让存储成本匹配访问模式，可以在不影响关键数据可用性的前提下减少支出。
数据库基础设施往往是云环境中成本最高的部分之一。但数据库成本优化需要特别小心，因为激进的改动会直接影响应用性能。
首先搞清楚数据库实际受什么约束：CPU、内存、存储吞吐量、IOPS（每秒输入输出操作数）、连接数还是查询性能。缩减数据库实例可能降了账单，但同时造出了更慢的查询和更高的应用延迟。
正确做法是深挖低效查询、缺失索引、过多连接、超配的存储分配、不必要的副本。数据库优化有时候比单纯选个更小的数据库实例能省更多。
还要考虑工作负载模式。开发和测试数据库可能不需要持续运行。给非生产数据库排个 schedule（调度），在空闲时段停掉，能省下一大笔不必要的支出。
同时，生产数据库应该优先保障可用性和性能需求。成本优化绝不应该演变成追求最小配置的竞赛。
降低AWS支出最简单的方法之一，就是删掉没人用的基础设施。
云环境天然会积累废弃资源。工程师创建临时EC2实例、测试负载均衡器、开发数据库、未使用的弹性IP、遗忘的EBS卷、旧快照、临时环境。到最后，没人记得是谁创建的、为什么还在。
建立自动化的闲置资源发现流程。比如识别持续低利用率的EC2实例、attached的EBS卷、未使用的负载均衡器、旧快照、最近无活动的非生产资源。
但不要毫无保护就自动删除。有些看似闲置的资源可能支撑着灾难恢复、合规、测试或未来部署。
正确做法是引入所有权模型。每个资源都应该有负责人、环境、应用和用途。如果一个资源没有负责人，应该触发调查，而不是让它变成永久基础设施。
AWS数据传输成本连有经验的团队都可能中招。
应用经常在可用区之间、地域之间、服务之间、外部网络之间搬数据。微服务架构会让这个情况特别有趣——几十个服务可能持续互相通信。
举个例子，如果架构反复跨可用区传输大量数据，应用可能产生可观的网络费用。跨区域复制和频繁数据移动同样会增加开支。
解决方案不一定是非得消灭分布式架构。而是要理解数据在哪跑、为什么跑。
用架构图和流量分析识别不必要的传输。考虑数据局部性、缓存、服务放置位置、压缩、批处理，以及AWS网络服务的合理使用。
性能和成本往往能一起改善——减少不必要的网络跳数意味着更低的延迟，同时账单也更漂亮。
缓存能同时提升性能和成本效率。
当应用反复执行同一个昂贵的数据库查询或获取同一个对象时，每次都执行就是在浪费计算资源、数据库容量和网络资源。
缓存让频繁访问的数据更靠近应用或用户。根据架构，团队可以使用CloudFront（内容分发网络）、ElastiCache（托管Redis/Memcached）、应用层缓存或数据库缓存策略。
举个例子，一个不常变化的产品目录不需要每次用户请求都查主数据库。设计良好的缓存层可以快速响应重复请求，同时降低数据库负载。
但缓存引入了复杂度：过期、失效、一致性、内存使用。所以要缓存正确的数据，并为TTL（生存时间）和失效机制建立清晰的策略。
目标不是缓存一切。而是在缓存真正能改善工作负载的地方，防止重复劳动。
生产基础设施通常需要持续可用。开发基础设施往往不需要。
但很多组织让开发、测试、预发、沙盒资源7x24小时跑着，即便非工作时间根本没人用。
这是个容易的优化机会。
给非生产EC2实例、数据库和其他符合条件的资源创建 schedule（调度），在空闲时段自动停止。比如只在工作时间使用的开发环境，没必要通宵周末也跑着。
自动化让这在大规模下变得可行。与其让工程师每天手动停止资源，不如实现自动处理这些流程的策略。
同时，要给真正需要持续环境的团队提供例外机制。目标是自动化可预测的行为，同时不给开发者添堵、不破坏重要的工作流程。
Serverless（无服务器）架构可以降低基础设施管理开销，对某些工作负载也可能提升成本效率。
Lambda这样的服务让组织按执行付费，而不是持续维护专用服务器。这特别适合事件驱动应用、定时任务、轻量级API、文件处理、自动化和异步工作流。
但serverless不等于自动更便宜。
设计糟糕的serverless架构可能产生意想不到的调用、执行、存储或数据传输成本。长时间运行的工作负载可能更适合容器或传统计算。
所以要根据工作负载特征评估serverless。如果应用持续运行、利用率可预测，专用或容器化计算可能提供更好的性价比。如果应用间歇性运行，serverless会特别有吸引力。
架构应该跟随工作负载行为走，而不是被营销术语牵着鼻子。
对于跑Amazon EKS或其他容器平台的组织，Kubernetes可能引入另一层云成本复杂性。
过度配置的worker节点是常见的浪费源头。如果Kubernetes请求和限制远远高于实际应用需求，集群可能需要超出必要的节点数。
从分析CPU和内存请求、实际利用率、Pod密度、节点利用率、工作负载扩缩行为开始。然后基于观察到的使用情况和适当的安全边际调整资源请求。
集群自动扩缩也能帮助让节点容量匹配工作负载需求。同时，工作负载自动扩缩可以根据实际应用压力调整Pod数量。
但优化必须考虑可用性。把节点跑在极高利用率上可能降低调度灵活性，加剧工作负载峰值的影响。
健康的Kubernetes成本策略要在节点利用率、Pod密度、扩缩速度、可用性和性能之间找平衡，而不是优化某个单一指标。
可观测性是必需的，但无限制的日志会变得很贵。
应用往往生成海量日志、指标、链路追踪和事件。团队可能永久保留每条日志，因为看起来存储便宜，相比日志的运维价值不算什么。
但日积月累，那堆数据就贵了。
根据实际运维需求建立保留策略。生产安全日志可能需要更长的保留期，而开发环境的详细调试日志可能只需要短期保留。
还要减少不必要的日志量。如果应用反复写入重复信息上百万次，改善日志策略可以降低存储和摄入成本，同时让重要事件更容易找到。
目标不应该是"收集一切，永远保留"。
而是要围绕信号质量、保留需求、事件响应需求和合规义务构建可观测性策略。
当团队在基础设施进入生产环境之前就处理成本优化，事情会简单很多。
Terraform这样的IaC（基础设施即代码）工具让团队能标准化资源配置、在部署前审查基础设施变更。这创造了在代码审查阶段捕获昂贵配置决策的机会。
比如，一个Terraform pull request可以触发自动化检查，查找 oversized实例、缺失标签、过多存储、公共资源，或违反组织策略的非生产基础设施。
类似地，CI/CD pipeline（持续集成/持续部署流水线）可以在部署前验证基础设施变更是否符合成本策略。
这让成本管理从每月财务 exercise（练习）变成持续的工程实践。
不用等基础设施部署了好几周才发现大账单，团队可以在风险配置到达AWS之前就识别出来。
团队收到早期预警时，成本优化会效果好很多。
为AWS账户、环境、应用或团队设置预算。当支出超过预期阈值或使用量异常变化时建立告警。
但不要只依赖绝对金额限制。小型创业公司和大型企业的支出水平自然差异巨大。
要追踪趋势和异常。数据库支出突然涨40%可能值得调查，即便组织整体还在月度预算范围内。
成本告警应该触发问题：
这些问题把账单数据变成可执行的工程信息。
AWS成本优化不应该只属于财务或云基础设施团队。
开发者影响数据库查询、API流量、日志、缓存、存储、架构和资源利用率。DevOps团队影响基础设施配置、扩缩、自动化和部署实践。产品团队影响流量模式和功能需求。
所以成本意识应该成为共同的工程责任。
创建简单的成本仪表盘，让负责工作负载的团队能看到。架构评审和事后复盘中适当地讨论成本。
最重要的是，别把成本优化变成追责 exercise（练习）。
别问"谁造成了这个账单"，要问"系统里什么变了，我们怎么能让它更高效"。
这种心态鼓励工程师改善架构，而不是隐藏成本。
当团队只衡量支出时，成本优化会变得危险。
想象一个工程团队把AWS支出砍了30%，但API延迟增加了200%。基础设施账单好看了，但应用对用户来说变差了很多。
所以要把成本指标和性能、可靠性指标配对看。
有用的衡量指标包括：
这些指标提供上下文。
如果成本下降而性能保持稳定或改善，优化可能在创造真正的效率。如果成本下降而可靠性恶化，架构需要再审视。
一个常见错误是一次性优化所有东西。大规模基础设施变更可能引入意外故障，让很难判断是哪个变更导致的问题。
正确做法是渐进优化。先从明显的浪费开始，衡量结果，然后再处理更复杂的变更。
另一个错误是只关注基础设施价格。有时候最贵的资源不是服务器本身，而是跑在上面低效的工作负载。
低效的数据库查询、过多的网络流量、不必要的API调用、糟糕的缓存、冗长的日志可能造成大得多的下游成本。
最后，别追求最低可能的AWS账单。目标应该是高效的基础设施，而不是人为地便宜。
健康的生产系统需要适当的冗余、监控、备份、安全控制和安全容量。单纯为了省钱砍掉这些保护可能在后面造成更大的成本。
别把优化当成一次性清理项目，而是创建可重复的路线图。
从可见性开始。按支出识别最大的AWS服务和 workload（工作负载）。然后把机会分类：闲置资源、right-sizing、存储优化、调度、定价承诺、架构改进、应用效率。
接下来根据潜在节省和运维风险排优先级。
比如，删除废弃资源通常比重新设计生产数据库架构风险低。给未使用的开发环境排调度可能比重构多区域应用简单。
用三个值追踪每个优化：
Before → Change → After
比如：
$10,000/月 → right-size计算 + 调度 → $7,500/月
这让优化可衡量，帮助团队理解哪些工程改进真正创造了财务价值。
AWS成本优化绝不应该演变成追求最小基础设施配置的竞赛。
真正的目标是创建一个云环境：每个资源都有用途，每个工作负载都获得适当容量，基础设施自动适应需求。
这意味着要综合多种做法：right-size计算、使用智能自动扩缩、优化存储、控制数据传输、改善缓存、调度非生产环境、选择合适的采购模式、优化Kubernetes、管理可观测性成本、以及把成本控制嵌入IaC（基础设施即代码）。
最重要的是，把性能和可靠性保持在对话中。
优化良好的AWS环境不应该感觉是老环境的廉价版。它应该感觉更智能。
它在客户需要时扩容，需求消失时缩容，自动消除浪费，提供业务所需的性能。
这才是云成本优化的真正含义。
能省的地方省，该投的地方投，其余的自动化。