一、成本意识觉醒：为什么无服务器不等于免费？理解按需付费的底层逻辑

1.1 那个让我惊醒的账单

我记得刚接触无服务器架构那会儿，心里想的是：「太好了，终于不用管服务器了！」

结果呢？第一个月账单下来，我差点从椅子上跳起来。不是几块钱，是几千美金。

为什么会这样？说白了，我把「无服务器」和「免费」划等号了。这是个天大的误会。

无服务器（Serverless）不是没有服务器，而是你不用管服务器。服务器还在跑，只是换成了云厂商在管。你想想看，云厂商又不是做慈善的，他们帮你管服务器，肯定得收费。

1.2 按需付费的底层逻辑

无服务器的计费模型，核心就四个字：按需付费。

但「按需」到底按的是什么？我拆开来讲：

• 计算时间：你的函数跑了多久，就付多少钱。精确到毫秒。
• 调用次数：每触发一次，计一次费。百万次调用和十次调用，价格天差地别。
• 资源分配：你给函数分配了多少内存、多少CPU，直接决定单价。
• 数据传输：进出的流量，尤其是出站流量，往往是隐藏的大头。

我在项目中遇到过一位客户，他把一个定时任务写成了无服务器函数，每5秒跑一次。一个月下来，调用次数超过50万次。账单出来的时候，他问我：「不是说无服务器很便宜吗？」

我问他：「你算过每5秒跑一次，一个月要跑多少次吗？」

他沉默了。

1.3 免费额度：甜蜜的陷阱

各大云厂商都提供免费额度。AWS Lambda 每月有100万次免费调用，400万GB-秒的计算时间。听起来很多，对吧？

但你要注意：

• 免费额度是按账户算的，不是按函数算的。你开10个函数，共享这100万次。
• 免费额度有时效，通常是12个月。过期后，一切按标准价收费。
• 免费额度不覆盖所有服务。API Gateway、DynamoDB、S3 的流量费，都不在免费额度里。

1.4 隐藏成本：那些你容易忽略的收费项

无服务器的成本，远不止函数本身。我列几个常见的「隐形杀手」：

成本项	说明	典型场景
API Gateway 费用	每次请求都要经过网关，按请求数和数据传输量计费	REST API、WebSocket
数据库读写费用	DynamoDB 按读写容量单位计费，冷热数据差异巨大	频繁查询、大表扫描
日志存储费用	CloudWatch Logs 按存储量和写入量收费	高并发函数、调试日志
VPC 网络费用	函数在 VPC 内运行，会产生 NAT 网关费用	访问 RDS、ElastiCache
冷启动惩罚	虽然不是直接收费，但冷启动会延长执行时间，间接增加成本	低频调用、定时任务

你想想看，一个简单的 CRUD API，背后可能涉及 API Gateway + Lambda + DynamoDB + CloudWatch。每个环节都在计费，加在一起就不是小数目了。

1.5 成本意识：从设计阶段就要考虑

我个人的习惯是，在画架构图的时候，就把成本估算表画在旁边。这不是多此一举，而是让你从一开始就清楚：

• 这个功能值不值得用无服务器？
• 有没有更便宜的替代方案？
• 流量高峰时，成本会涨到什么程度？

1.6 无服务器到底省不省钱？

这个问题没有标准答案。我见过用无服务器省了80%成本的案例，也见过比传统服务器贵3倍的案例。

关键看场景：

• 适合无服务器的场景：低频、突发、短任务。比如图片处理、消息推送、定时任务。
• 不适合无服务器的场景：高并发、长连接、持续运行。比如实时流处理、WebSocket 长连接、后台批处理。

我记得有一次，一个客户想把一个24小时不间断的数据处理任务迁移到 Lambda。我算了一笔账：

• 传统方案：一台 EC2 t3.medium，每月约30美金。
• 无服务器方案：Lambda 持续运行24小时，每月约200美金。

结果很明显。我直接建议他别用无服务器，老老实实用 EC2。

嗯，这里要注意：无服务器不是银弹。它适合特定场景，不是所有场景。

1.7 总结：成本意识是第一课

说了这么多，其实就想表达一个意思：

无服务器不等于免费，按需付费也不等于便宜。

你只有理解了底层计费逻辑，才能在设计阶段做出正确的决策。否则，等到账单出来再后悔，那就晚了。

下一章，我会讲具体的成本估算方法，教你如何在上线前就算清楚每一分钱。到时候，我会拿一个真实的项目案例来拆解。

先记住今天这句话：成本意识，从理解账单开始。