谷歌云解风控 Google Cloud Armor vs AWS WAF/Shield：DDoS 防护与 Web 安全对比
如果你是在 AWS 和 Google Cloud 之间选择 DDoS 防护，真正需要先判断的不是“哪个产品名更强”，而是：现有业务跑在哪个平台、流量是否经过对应的 CDN 或负载均衡、账号能否正常完成企业认证，以及攻击流量上来后是否承受得起额外账单。
先给决策结论：已经使用 CloudFront、ALB 或 API Gateway 的业务，通常优先采用 AWS WAF，并根据风险决定是否增加 Shield Advanced；已经部署在 Google Cloud 外部 HTTP(S) 负载均衡、Cloud CDN 或相关前端上的业务，Cloud Armor 接入更直接。新账号不要通过购买“已实名账号”来绕过审核，这类账号后续被重新验证、冻结或追回的概率，往往高于注册阶段节省的时间。
一、Cloud Armor 与 AWS WAF/Shield，实际不是同一层面的比较
| 决策维度 | Google Cloud | AWS |
|---|---|---|
| Web 攻击防护 | Cloud Armor 负责 Web ACL、规则匹配、预配置规则及部分应用层攻击控制。 | AWS WAF 负责 Web ACL、托管规则、Bot Control、速率限制等。 |
| 基础 DDoS 防护 | 需要结合 Cloud Armor 版本及接入的 Google 前端资源确认覆盖范围。 | Shield Standard 自动覆盖部分 AWS 资源，通常不单独收取产品费用。 |
| 增强型 DDoS 服务 | Cloud Armor Enterprise 等版本通常涉及订阅、受保护资源和额外服务项。 | Shield Advanced 通常是较高的月度订阅成本，并提供更强的响应和支持能力。 |
| 接入前提 | 流量必须经过支持 Cloud Armor 的外部负载均衡或相关 Google 前端。 | WAF 必须挂载到 CloudFront、ALB、API Gateway 等支持的资源。 |
最容易出现的误判是把“Cloud Armor”直接等同于“AWS WAF+Shield Advanced”。AWS 将 Web 层防护和 DDoS 服务拆成两个产品，而 Google Cloud 的产品组合方式不同。对普通网站来说，AWS WAF 加 Shield Standard 与 Cloud Armor 基础版本才更接近；对金融、交易、游戏等高价值业务，才需要进一步比较 Shield Advanced 与 Cloud Armor Enterprise 的响应机制、合同条款和费用。
二、账号不要买成品，正确开通流程是什么
搜索“购买 AWS 账号”“购买 Google Cloud 已实名账号”的用户，通常是遇到了银行卡验证、企业资料审核或所在地区支付限制。成品账号短期可能能登录，但存在几个实际问题：
- 恢复邮箱、绑定手机和付款资料不在你手里，卖家可以重新找回账号。
- 账号主体、付款人、登录地点和实际业务地区不一致，后续容易触发重新审核。
- 历史欠费、优惠滥用、关联账号违规记录会一并继承。
- 发生冻结时，平台通常只与原注册主体核验，购买者很难证明所有权。
如果通过服务商协助开通，建议采用“客户主体新开账号”的方式，而不是接收旧账号：
- 使用企业域名邮箱注册，避免临时邮箱和多人共用邮箱。
- 由企业法定主体提供注册名称、地址、税务信息和授权人资料。
- 绑定企业名下银行卡，账单地址尽量与付款资料一致。
- 客户自行保管 AWS Root 或 Google Cloud 超级管理员恢复方式。
- 开通后立即设置 MFA、IAM 角色、账单管理员和告警联系人。
- 先部署测试资源，再逐步开通 WAF、日志、CDN 和大流量服务。
AWS 账号一般通过邮箱、手机号、付款卡和身份验证完成开通；Google Cloud 则涉及 Google Payments Profile、Cloud Billing Account、项目和组织资源。国际站并不代表免实名认证，也不代表任何国家发行的虚拟卡都可以通过审核。
三、企业实名认证，平台真正核对哪些资料
| 资料类别 | 准备要求 | 常见问题 |
|---|---|---|
| 企业主体 | 公司注册证书、统一社会信用代码或当地企业注册号。 | 英文名称、注册地址与付款资料不一致。 |
| 联系人 | 法定代表人、授权联系人、企业电话和可验证邮箱。 | 只提交个人邮箱，无法说明与公司的关系。 |
| 支付证明 | 企业银行卡、账单地址，必要时提供扣款记录或卡片持有人证明。 | 使用他人信用卡、预付卡或频繁更换付款卡。 |
| 经营信息 | 企业官网、业务说明、产品页面、预计流量和使用区域。 | 新账号刚开通就申请高额配额或产生异常大流量。 |
资料不需要一开始堆得越多越好，关键是名称、地址、付款人和业务描述保持一致。若平台要求补充材料，应通过控制台工单或官方验证邮件提交，不要把身份证、银行卡完整信息发送给不明代理。
四、充值、续费和支付方式：AWS 与 Google Cloud 有明显差异
谷歌云解风控 这两家云服务通常不是传统意义上的“购买防护套餐后充值使用”。WAF 多数按资源、规则和请求量计费，账单会随着业务流量变化。
| 项目 | AWS | Google Cloud |
|---|---|---|
| 常规付款 | 信用卡、借记卡；符合条件的企业可申请月结或合同账期。 | 信用卡、借记卡；部分地区和企业可申请发票或银行付款。 |
| 充值模式 | 按月出账并自动扣款为主，不是普遍性的预充值模式。 | 以 Billing Account 自动扣费、账期或企业合同为主，具体取决于付款资料地区。 |
| 优惠额度 | Credits 可抵扣部分服务，但通常有产品、时间和账号限制。 | 新客户试用额度或企业 credits 也有使用范围和有效期。 |
| 第三方代充 | 账号控制权、付款记录和发票归属需要重点核实。 | 若账号实际属于代理商 Billing Account，项目所有权和停服风险要写入合同。 |
企业支付建议优先使用公司卡，并提前确认发卡国家、账单地址、税务主体和注册地区。个人卡并非一定不能使用，但当企业名称、卡片持有人和账号资料差异较大时，后续补审概率会明显增加。预算告警只能提醒费用，不能自动保证服务停止；正式业务还应配置请求量、日志保留和 CDN 缓存策略，避免攻击流量造成账单失控。
五、成本怎么估，不能只看 WAF 产品价格
AWS WAF 的常见计费维度包括 Web ACL、规则数量和请求量，托管规则组、Bot Control、日志及关联的 CloudFront、ALB、数据传输费用另计。按常见公开计费档位做一个示例：1 个 Web ACL、10 条规则、每月 1 亿次请求，基础 WAF 可能接近“ACL 费用 + 规则费用 + 请求费用”的组合，粗略可达到几十美元级别；如果增加托管规则、机器人检测和日志，账单会继续上升。Shield Standard 通常没有单独产品费用，但不代表攻击期间所有网络及请求费用都自动免除。
Cloud Armor 则需要根据版本查看政策、规则、请求量、受保护资源及 Enterprise 订阅项目。建议用下面的方式估算，而不是直接拿 AWS 的每百万请求价格套用：
Cloud Armor 月成本 = 政策费用 + 规则费用 + 请求费用 + Enterprise 或受保护资源费用 + 负载均衡/CDN/日志费用
有三个场景需要特别注意：
- 20M 至 100M 次正常请求/月：先使用基础 WAF 版本，重点控制托管规则和日志量。若业务已经在某一云平台，迁移云平台的网络和运维成本通常高于 WAF 差价。
- 1B 次以上请求或经常被攻击：不能只比较 WAF 请求单价，应把 CDN 缓存命中率、源站带宽、攻击期间的请求计费、应急响应和服务支持一起计算。
- 高价值业务：Shield Advanced 或 Cloud Armor Enterprise 的主要价值在额外响应、监控和合同支持，适合按年度损失风险评估，不适合仅按“每月防护费”判断。
如果攻击流量可以直接打到源站 IP，WAF 费用再低也无法解决根本问题。必须让源站只接受 CloudFront、负载均衡或 Google 前端的回源流量，并配合安全组、防火墙和源站 IP 隐藏。
六、地区、账号和部署限制会影响最终选择
- AWS WAF 绑定 CloudFront 时属于全球范围管理，相关 Web ACL 通常在 us-east-1 控制；绑定 ALB、API Gateway 等区域资源时，WAF 必须和资源位于对应区域。
- Google Cloud Armor 通常依赖支持的外部负载均衡和前端架构，不能脱离接入资源单独保护任意公网服务器。
- 谷歌云解风控 付款国家会影响可用货币、税务发票、银行转账和企业账期；同一个产品在不同地区的税费和支付审核并不完全相同。
- 新账号可能存在服务配额、API 开通、付款验证和异常流量限制。申请高配额时要说明业务类型、预计并发、上线时间和流量来源。
- 两家平台都不建议在公网进行未经授权的压力测试或 DDoS 模拟。测试应使用受控流量，并提前查看服务条款和提交工单。
七、最常见的失败原因与处理方式
1. 注册成功，但付款验证失败
通常与卡片不支持线上预授权、账单地址不一致、3-D Secure 验证失败或短时间多次尝试有关。处理时先停止重复提交，确认银行是否拦截小额预授权，再使用企业卡和一致的账单地址重新提交。
2. 账号开通后几小时被限制
常见触发因素包括购买账号、多个账号共用付款卡、注册地与登录地变化过大、代理 IP 频繁切换，以及刚开通就大量创建资源。应准备企业注册资料、付款凭证、官网和业务说明，通过官方支持渠道申诉，不要继续注册更多账号。
3. WAF 开启后正常用户大量报错
电商搜索、登录、JSON 请求和文件上传最容易被托管规则误拦。上线前先使用 Count 或 Preview 模式观察至少数天，分析采样请求，再针对登录接口、支付回调、健康检查设置例外。不要直接关闭整组规则，应缩小例外路径和参数范围。
4. 误以为 Shield 可以替代 WAF
Shield 主要解决 DDoS 层面的防护和响应，不能替代针对 SQL 注入、跨站脚本、异常请求参数和机器人行为的 WAF 规则。AWS 网站通常仍需要 WAF；Cloud Armor 的具体能力则要按版本和接入资源确认。
八、根据业务场景做决定
| 业务情况 | 更实际的做法 |
|---|---|
| 已有 CloudFront + ALB | 先上 AWS WAF，Shield Standard 作为基础防护；只有在攻击损失较高、需要响应支持或费用保护时评估 Shield Advanced。 |
| 已有 Google Cloud 外部负载均衡 | 优先接入 Cloud Armor，先用基础版本观察规则命中和请求成本，再决定是否升级 Enterprise。 |
| 刚开始建站，尚未确定云平台 | 先比较 CDN、负载均衡、数据库、出口流量和企业支付条件，不要只比较 WAF 单项价格。 |
| 多云部署 | 每个云平台的公网入口分别配置本地 WAF，统一日志和告警；不要只在其中一朵云配置防护后再转发全部流量。 |
FAQ
Google Cloud Armor 是否比 AWS WAF/Shield 便宜？
没有固定答案。低流量时，规则和请求量影响较小，已有云平台的接入成本更重要；高流量或攻击场景下，托管规则、日志、源站带宽和增强型 DDoS 服务会改变结果。
可以用代理商账号再开 Cloud Armor 或 WAF 吗？
可以采用企业合同或合作伙伴计费，但必须确认项目、账号、恢复邮箱、管理员权限和账单归属。不要接受只有代理商掌握 Root 或超级管理员权限的账号。
充值后能否防止账号欠费停服？
不能仅靠充值承诺判断。应在官方控制台确认余额、credits、付款方式和账单状态，并设置多名账单联系人。第三方口头承诺的“永久余额”不等于平台认可的可用额度。
实际决策顺序建议：先确定业务入口和源站架构，再用企业主体自行开通账号，完成付款验证后做小流量规则测试，最后根据正常流量、攻击风险和支持要求评估增强型 DDoS 服务。这样比先购买一个来历不明的成品账号，再处理冻结、归属和账单问题更可控。