如何在不失去理智的情况下构建安全可靠的 AWS 云架构

介绍

如果您尝试过在 AWS 中从头开始设计云架构，您可能已经知道：这是一个既自由又混乱的过程。有一千种方法可以构建某样东西，也有同样多的方法可以把它搞砸。

简单浏览一下 AWS 文档，你可能会想："酷，我们只需遵守一流的实践即可"。但是，在真实的国际环境中，一流的实践往往无法与真实的商业企业需求、价格范围限制或人为错误第一时间取得联系。这就是为什么在早期与perfsys这样的专业人士合作，可以避免日后在保护漏洞和扩展问题上打擦边球。

我们的目标不仅仅是获得能运行的东西。而是要建立一个系统，当流量激增或某个区域闪退时，它不会倒下，也不会向互联网敞开大门。

让我们从显而易见的问题开始：AWS 是一头猛兽

你几乎可以用 AWS 构建任何东西。从两个人的初创公司到庞大的企业平台，构建模块一应俱全：EC2、Lambda、RDS、S3、IAM、VPC，不胜枚举。问题是什么？选项越多，就越容易造成混乱。

这并不是说 AWS 设计得不好。只是你必须正确地设计它。否则，就会出现一些团队所说的 "云意大利面条"：相互依赖的服务、硬编码的机密、无标记、无日志记录，而且完全不知道什么花费了多少钱。

可靠性和安全性不是 "可有可无 "的东西

将安全性和可靠性视为未来问题是很有诱惑力的。"我们会在上线后确保安全"。"下个冲刺阶段我们将增加监控功能"。但是，试问任何一个处理过数据泄露或多小时故障的人--跳过这些步骤就是你最终通宵达旦的原因。

可靠性的真正含义

这不是幻灯片上的正常运行时间保证。而是针对故障的工程设计。服务瘫痪。磁盘故障。应用程序接口超时。重要的是，当出现故障时，你的系统能否继续运行。

您的系统在可用区之间有冗余吗？您的系统能否承受数据库节点故障而不丢失数据或出错？您是否因为 "最容易部署 "而在单一区域运行关键工作负载？这些问题将工作系统与弹性系统区分开来。

安全性呢？不仅仅是 IAM

是的，身份和访问管理（IAM）是第一道墙。但安全问题远不止于此。可公开访问的 S3 存储桶。过度授权的角色。硬编码到 Lambda 函数中的秘密。为了节省成本而关闭日志记录。所有这些都是定时炸弹。

使用aws 完善架构框架有助于在这些问题爆发前将其识别出来。它将架构分解为五个关键领域--安全性、可靠性、卓越运营、性能效率和成本优化--并迫使团队诚实地评估每一个领域。这不是灵丹妙药，但它能促使你提出棘手的问题。

真正重要的组成部分

好了，让我们进入正题。以下是在 AWS 上构建安全、可靠的架构时最重要的事项，以及团队最常出错的地方。

正确使用 IAM 角色（是的，真的）

IAM 角色非常强大。有时太强大了。因为某些东西无法正常工作，所以很容易就使用 "管理员访问权限"，并承诺稍后修复......但却永远无法修复。

你需要尽早锁定它。最小特权原则不仅是最佳实践，也是唯一合理的操作方法。这意味着

• 每个服务的角色范围

• 避免权限中的通配符

• 短期凭证

• 人类用户的强制 MFA

听起来很麻烦？确实很麻烦。但向你的老板解释为什么有人从配置错误的 Lambda 中窃取客户数据也很麻烦。

认真分离网络

这是另一个捷径适得其反的地方。你不需要超级复杂的网络设置，但一些基本的设置会有很大帮助：

• 公共子网只用于必须面对互联网的服务（如 ALB）

• 专用子网用于其他一切

• 用于受控出站访问的 NAT 网关

• 用于 AWS 服务流量的 VPC 端点，不接触公共互联网

将所有东西都放在同一个子网中的扁平 VPC 可能会让人感觉很简单。直到有什么东西坏了，把所有东西都带走。

日志和监控：你无法修复你看不到的问题

这一点甚至都不用再争论了。日志记录并非可有可无。如果你没有捕获 CloudTrail、CloudWatch 指标和 VPC 流量日志，那你就等于盲目飞行。

但问题是，仅仅记录日志是不够的。你需要真正查看日志。为重要内容创建警报。过滤噪音。确保日志在不同账户和地区集中管理。零散的可见性就是不可见性。

加密一切（无一例外）

对静态数据使用 KMS。对传输中的数据使用 TLS。轮流使用密钥。监控访问。现在偷懒，以后就会付出高昂代价。

不要忘记 RDS 加密、EBS 卷设置和 API 网关 TLS 强制执行等事项。这些小细节都会造成损失。

基础架构即代码

还在通过点击 AWS 控制台进行部署？这对开发来说没问题，但对产品来说就危险了。

使用 Terraform、CloudFormation 或 CDK。不管你的团队喜欢什么，只需选择一种并坚持使用。对模板进行版本控制。使用 CI/CD 进行部署。自动回滚。手动部署容易出错。

另外：标记一切。没有标签的资源就像没有标签的电缆，没有人知道它们的用途，每个人都不敢碰它们。

不沉没地扩展

让我们把话说清楚：AWS喜欢你超额配置。你得到了 "性能"，他们得到了你的钱。要想高效扩展，就必须了解自己的模式，并为之做好规划。

使用自动扩展组、点实例（小心）和缓存层。但更重要的是：在负载情况下进行测试。你最不希望看到的情况是，在启动两天后，发现自己的 RDS 实例在实际流量下融化了。

此外，合理预留容量。这样既能省钱，又能防止意外的配置失败。

灾难恢复计划不是可有可无的

如果一个区域宕机了怎么办？主数据库损坏了怎么办？如果答案是 "呃......我们会有麻烦"，那么是时候重新制定灾难恢复策略了。

这并不意味着在另一个区域建立一个完全相同的基础架构副本。而是要了解情况：

• 要恢复的内容

• 需要多长时间

• 会丢失哪些数据（如果有的话）

• 故障转移期间谁负责什么

是的，您应该测试您的恢复计划。否则，它只是虚构的。

应避免的常见反模式

让我们快速讨论一些经常出现的禁忌：

• 使用 AWS 组织。分离 prod、dev、staging 等。

• 不动默认 VPC 和安全组：锁定它们。

• 过度依赖 "用于测试的 "t2.micro 实例--它们最终会进入 prod。

• 未对 CloudWatch 成本进行预算：是的，日志记录需要花钱。不记录日志的成本更高。

• 提供 "只需快速修复 "的访问权限：而不是修复你的流程。

最后的话？保持灵活，保持理智

云架构并不是要找到完美的设置。而是要构建一个灵活、健壮、可理解的架构，而不仅仅是编写架构的人。

你永远不会真正 "完成"--这没关系。重要的是用心。尽早提出棘手的问题。经常审核。在重要的地方实现自动化。知道何时需要求助。

老实说，AWS 功能强大，但也很容易迷失方向。与经验丰富的云架构工程师合作，可以让 "大部分情况下都能正常工作 "和 "我们晚上睡得很香 "截然不同。

这值得我们为之努力。