AWS 实战踩坑指南：避开那些昂贵且麻烦的「陷阱」
在 AWS 上快速搭建业务很容易,但要搭得稳、用得省、还没隐患,其实有不少「坑」需要提前填平。这篇文章汇总了我们在 EC2、RDS、CloudFront 等常用服务上踩过的坑和避坑方案。
1. EC2: 磨刀不误砍柴工,提前准备好「基础设施」
在控制台创建 EC2 实例时,最痛苦的莫过于到了最后一步才发现还没创建 Key Pair 或者 安全组 (Security Group)。这时候你不得不跳出当前页面去另外开一个窗口创建资源,然后再回来刷新。
避坑方案: 在正式启动「创建实例」流程前,务必确认当前 Region 下已经准备好了:
- 对应的 SSH Key Pair。
- 至少一个符合基础规则的安全组(例如放行 22 端口或业务端口)。
2. EC2: 别让「随机 IP」毁了你的业务稳定性
如果你把 EC2 部署在公有子网并勾选了「自动分配公网 IP」,看起来很方便,但隐藏着巨大的风险:当你停止 (Stop) 并重新启动 (Start) 实例时,AWS 会重新分配一个新的公网 IP。
这会导致:
- 已经配置好的 DNS 记录失效。
- 业务连接中断。
- 外部白名单配置失效。
避坑方案: 对于需要公网访问的长期业务,务必申请并关联 Elastic IP (EIP)。EIP 是静态的,除非你手动释放,否则它会一直与你的实例绑定,即便实例重启或更换。
3. 托管服务: KMS 密钥是跨账户迁移的「生死线」
RDS、ElastiCache、OpenSearch 等托管服务在创建时通常会询问是否加密。如果你选择使用「AWS 托管密钥 (AWS Managed Key)」,恭喜你,你可能在未来的跨账户迁移中遇到巨坑。
默认密钥的问题: AWS 默认的托管密钥不支持跨账户共享。这意味着如果你想把数据库快照共享到另一个账户进行恢复,你会发现因为无法解密而寸步难行。
避坑方案: 在创建这些托管服务之前,提前创建一个「客户托管密钥 (Customer Managed Key, CMK)」。使用 CMK 进行加密,未来如果涉及跨账户迁移,你只需要在 CMK 的 Policy 中添加目标账户的权限即可。
4. CloudFront: 拒绝「按需付费」带来的流量焦虑
CloudFront 默认是按使用量计费的。虽然这很灵活,但在面临恶意刷流量、DDoS 攻击或者突发大流量时,账单金额可能会让你瞬间破产。
避坑方案: 根据业务预估,考虑订阅固定流量包 (CloudFront Savings Bundles)。通过承诺每月最低消费,可以获得显著的价格折扣,并且在一定程度上让成本更加可预测。
5. S3: 安全与成本的双重护栏
S3 存储桶如果配置不当,不仅容易导致数据泄露,还容易成为「刷流量」的攻击目标。
避坑方案:
- 务必关闭公开访问 (Block Public Access): 除非是存放公共静态资源,否则绝不应允许匿名访问。
- 配合 CloudFront 使用: 不要让用户直接访问 S3 的 URL,通过 CloudFront 接入可以利用 AWS 全球边缘节点加速,并利用 Origin Access Control (OAC) 确保只有 CloudFront 能访问 S3。
- 引入 WAF: 在 CloudFront 前端挂载 WAF,配置防刷规则,过滤恶意请求,保护后端资源并控制成本。
本文将持续更新,记录我们在云端探索的更多实战经验。