摘要：# 当CC攻击撞上Serverless：按量付费是省钱还是烧钱？ 我得先坦白，我见过不少用Serverless架构的团队，平时聊起成本节省都眉飞色舞——毕竟不用就几乎不花钱嘛。但去年有个做电商的朋友半夜给我打电话，声音都变了：“兄弟，我们被CC了，账单正…

当CC攻击撞上Serverless：按量付费是省钱还是烧钱？

我得先坦白，我见过不少用Serverless架构的团队，平时聊起成本节省都眉飞色舞——毕竟不用就几乎不花钱嘛。但去年有个做电商的朋友半夜给我打电话，声音都变了：“兄弟，我们被CC了，账单正在疯涨，怎么办？”

那场景，我现在想起来都替他肉疼。

先别急着下结论，这事儿得拆开看

很多人一听到“CC攻击”和“按量付费”放在一起，第一反应就是“完了，要被刷破产了”。这种担心不是没道理，但说实话，有点太简单粗暴了。

CC攻击（Challenge Collapsar，挑战黑洞）说白了，就是攻击者用大量傀儡机，模拟正常用户不停地访问你的网站——特别是那些耗资源的动态页面。而Serverless的按量付费，就像你家的水表电表，用多少算多少。

那么问题来了：当攻击者疯狂“用水用电”时，这个“表”会不会转得飞起？

真实情况比你想的复杂

我拿我那个电商朋友的实际遭遇来说吧。他们的活动页面被盯上，攻击流量在高峰时段冲到了平时正常流量的50多倍。如果是传统服务器，这时候可能已经瘫了，但他们用的是某大厂的Serverless服务。

结果呢？页面居然没完全挂掉——因为Serverless能自动弹性扩容。但代价是：那个小时的费用，是平时一整天的12倍。

你看，这里就出现了两个关键点：

1. 业务没瘫，这算不幸中的万幸
2. 成本确实爆了，但没到“破产”那么夸张

那些厂商不会主动告诉你的细节

很多Serverless服务商在宣传时，会重点强调“自动弹性”、“高可用”，但关于CC攻击下的成本问题，往往说得比较含糊。我研究了几家主流厂商的计费细则，发现几个有意思的地方：

第一，计费粒度其实很细。 大部分是按100毫秒甚至更细的粒度计费。这意味着，如果你的函数能快速处理请求并返回，单次请求的成本其实很低。但CC攻击的“聪明”之处就在于，它会故意访问那些处理逻辑复杂、耗时长的接口——比如商品搜索、订单提交这些。

第二，不是所有流量都“平等”。 很多Serverless平台对API网关的请求和函数执行是分开计费的。攻击者如果只是疯狂ping你的API网关（而不触发函数），这部分成本可能没那么吓人。但专业的CC攻击，一定会想办法触发你的核心业务函数。

第三，冷启动是个双刃剑。 在流量激增时，Serverless需要启动新的函数实例（冷启动）。这个过程本身不收费，但启动后的实例只要活着就在计费。攻击者如果持续施压，你的函数实例数就会维持在高位——这才是成本大头。

所以，到底会不会增加成本？

答案是：会，但程度取决于你的防护配置和攻击模式。

我整理了几个典型场景，你可以对照看看：

场景A：裸奔的Serverless应用

• 攻击特征：持续、高并发、针对复杂接口
• 成本影响：灾难级。见过最夸张的案例，2小时攻击产生了平时一个月的费用
• 一句话点评：千万别这么干

场景B：有基础限流的Serverless

• 攻击特征：同上，但你给API网关配置了频率限制
• 成本影响：中等偏高。能挡掉一部分无效请求，但绕过限流的攻击流量还是会触发函数
• 一句话点评：比裸奔强，但还不够

场景C：配合WAF/高防的Serverless

• 攻击特征：攻击流量先经过清洗
• 成本影响：可控。大部分攻击流量在到达你的函数前就被过滤了
• 一句话点评：这才是正经做法

几个实用到有点“鸡贼”的省钱思路

聊完问题，得给点实在的建议。下面这些方法，有些是我自己试过的，有些是跟运维老哥们喝酒时套出来的：

1. 分层防御，把钱花在刀刃上 在Serverless前面，一定要加一层“缓冲”。可以是WAF（Web应用防火墙），也可以是带CC防护的高防IP。这笔钱不能省——它就像你家门口的保安，虽然也花钱，但总比让贼直接进屋搞破坏强。

2. 设置“熔断”机制 很多Serverless框架支持设置并发上限或费用预算。比如，当函数并发数超过正常值的3倍时，自动触发告警甚至降级。虽然可能影响部分正常用户，但总比账单失控强。

3. 优化函数逻辑，让攻击者“不划算” 这是最容易被忽略的一点。仔细检查你的函数：

• 有没有不必要的数据库查询？
• 能不能加缓存？
• 响应能不能更精简？

举个例子，有个内容站把文章详情页的数据库查询从3次优化到1次，单次函数执行时间从200ms降到了80ms。平时省不了几个钱，但被CC时——攻击者用同样的流量，你的成本直接减半以上。

4. 用好免费额度 主流云厂商的Serverless服务都有免费额度。把核心业务和非核心业务拆到不同账户或不同函数，确保核心业务尽量在免费额度内。听起来有点麻烦，但关键时刻能救命。

一个残酷的真相

最后说句大实话：没有任何架构能完全免疫CC攻击的成本影响。传统服务器被打瘫了要修，要加班，要损失业务；Serverless被打要付钱。本质上，你是在选择承担哪种风险。

但Serverless有个独特优势：它的成本是线性的、可预测的。你至少能看到每一分钱花在哪了，而不是像传统架构那样，面对一堆瘫掉的服务器和无法量化的业务损失干瞪眼。

所以，回到最初的问题

面对CC攻击，Serverless的按量付费会不会增加成本？

会，但它给了你更精细的控制权和更明确的账单。 关键不在于用不用Serverless，而在于你有没有认真对待防护这件事。

我那个电商朋友后来怎么样了？他们加装了WAF，优化了函数，设置了费用告警。上个月又遇到一次小规模CC攻击，账单比正常高了30%，但业务完全没受影响。用他的话说：“现在至少能睡个安稳觉了。”

说到底，网络安全这事儿，从来就没有一劳永逸的方案。Serverless不是银弹，按量付费也不是洪水猛兽。真正重要的是，你得知道自己面对的是什么，然后——做好该做的准备。

毕竟，在互联网上做生意，哪有不遇到点风浪的。