跳转到主要内容

AWS 生产环境架构设计:从 Landing Zone 到高可用服务

博主
2 分钟
236 字
--

随着企业上云的深入,仅仅在 AWS 上“开几台 EC2”已经远远不能满足安全、合规和可扩展性的需求。一个健壮的生产环境架构需要从地基(Foundation)开始规划。本文将分享我在构建企业级 AWS 环境时的核心设计思路和最佳实践。

1. 多账号策略与 Landing Zone

永远不要在单个 AWS 账号中运行所有环境(Dev/Test/Prod)。多账号架构是隔离风险、简化计费和权限管理的最佳实践。

1.1 组织结构 (AWS Organizations)

建议采用如下 OU(Organizational Unit)结构:

  • Root
    • Security OU: 存放安全相关账号(Log Archive, Security Audit)。
    • Infrastructure OU: 存放共享服务(Shared Services, Networking)。
    • Workloads OU:
      • Prod: 生产环境账号。
      • Non-Prod: 开发与测试账号。
    • Sandbox OU: 开发者个人沙盒,限制消费额度。

1.2 身份管理 (IAM Identity Center)

放弃使用长期的 IAM User (Access Key/Secret Key)。启用 IAM Identity Center (原 AWS SSO),与企业 IDP(如 Azure AD, Okta, Google Workspace)集成。

  • 原则:用户登录 SSO 门户,获取短期凭证访问对应账号。
  • 权限:使用 Permission Sets 定义角色(如 ViewOnly, PowerUser, NetworkAdmin),遵循最小权限原则(Least Privilege)。

2. 网络架构规划 (VPC Design)

网络是云上架构的血管。一个糟糕的 VPC 设计会导致后期扩展极为痛苦。

2.1 CIDR 规划

  • 避免使用 192.168.0.0/16(容易与家庭网络冲突)或默认的 172.31.0.0/16
  • 建议使用 10.x.0.0/16 段,并为不同环境预留足够的 IP 空间。
  • 子网划分
    • Public Subnet: 仅放置 NAT Gateway, ALB, Bastion Host。
    • Private App Subnet: 放置应用服务器(EC2, EKS Nodes, Lambda)。
    • Private Data Subnet: 放置数据库(RDS, ElastiCache),严禁互联网直接访问。

2.2 流量控制

  • Transit Gateway (TGW): 用于连接多个 VPC 和本地数据中心(VPN/Direct Connect),替代复杂的 VPC Peering 网状拓扑。
  • VPC Endpoints: 访问 S3, DynamoDB 等 AWS 服务时,走内网链路,避免流量绕行公网(NAT Gateway),既安全又省钱。

3. 计算与高可用架构

3.1 弹性与自愈

生产环境必须具备 AZ(Availability Zone)级高可用。

  • Auto Scaling Group (ASG): 即使是单体应用,也应放入 ASG(Min=1, Max=1),利用其健康检查自动重启故障实例。
  • Multi-AZ: 数据库(RDS Multi-AZ)、缓存(ElastiCache Multi-AZ)必须开启多可用区部署。即使单 AZ 故障,也能在分钟级自动切换。

3.2 存储选择

  • EBS: 系统盘和高性能 I/O 数据。注意 GP3 比 GP2 性价比更高。
  • EFS: 需要多个实例共享文件系统时使用(如 CMS 的上传目录)。
  • S3: 静态资源、备份数据、日志。配置 Lifecycle Rules 自动将冷数据转存至 Glacier,大幅降低成本。

4. 安全与合规

安全是 AWS 架构的“第零号任务”。

  • 加密:开启 EBS 默认加密,S3 Bucket 默认加密,RDS 存储加密。
  • Security Groups: 仅开放必要的端口。例如,数据库 SG 仅允许应用层 SG 的 ID 访问,而不是 IP 段。
  • CloudTrail: 开启所有区域的审计日志,并投递到 Security 账号的 S3 Bucket,配置 Object Lock 防止篡改。
  • GuardDuty: 启用智能威胁检测,识别恶意 IP 扫描和异常行为。

5. 基础设施即代码 (IaC)

最后,也是最重要的一点:拒绝手动控制台操作

所有基础设施变更必须通过代码(Terraform 或 CloudFormation)管理,并纳入版本控制。

  • 可追溯:谁在什么时候修改了什么配置。
  • 可复用:Prod 环境的架构可以直接由 Non-Prod 代码提升而来,保证环境一致性。
  • 灾难恢复:在极端情况下,可以快速在另一个 Region 重建整套环境。

结语

构建 AWS 生产环境不仅仅是技术的堆砌,更是管理理念的体现。通过 Landing Zone 建立规范,通过 IaC 保证执行,通过 Well-Architected 持续优化,才能打造出真正稳定、高效、安全的云上基石。

分享文章