基于AWS CDK构建非应用依赖型基础设施的最佳实践咨询

针对你提出的三个核心问题，结合一线实践给出具体方案，同时优化你现有的思路：

1. 代码仓库结构规划 #

你的aws_infra独立仓库思路完全正确，通用基础设施和业务应用代码解耦，避免业务迭代干扰 infra 维护。推荐按「功能栈+可复用构造+环境配置」的层级组织：

aws_infra/
├── bin/
│   └── aws-infra.ts       # CDK应用入口，负责实例化所有栈并绑定对应环境
├── lib/
│   ├── stacks/
│   │   ├── security-hub-stack.ts   # 对应Security Hub配置栈
│   │   ├── config-rules-stack.ts   # AWS Config规则栈
│   │   ├── cloudwatch-alarms-stack.ts  # 通用告警栈
│   │   └── cross-account-roles-stack.ts  # 跨账号访问角色栈（如有需要）
│   ├── constructs/
│   │   ├── base-alarm.ts       # 封装通用告警模板（比如阈值、通知主题）
│   │   └── config-rule-template.ts  # 通用Config规则构造
│   └── config/
│       └── env.ts              # 环境配置：存储各环境的账号ID、区域、参数
├── cdk.json
├── package.json
└── jest.config.js             # 可选：CDK单元测试配置

关键细节：

• 每个栈对应一类独立的通用服务，避免混合不同类型资源（比如不要把Security Hub和CloudWatch告警放一个栈），便于维护和隔离变更
• constructs层封装可复用逻辑，比如所有告警都需要绑定同一个SNS主题，就把这个逻辑抽成自定义构造，避免在每个栈里重复写
• 环境配置集中管理，在bin/aws-infra.ts里通过命令行参数或环境变量加载对应环境的配置，实例化带环境标识的栈（比如new SecurityHubStack(app, 'SecurityHubStack-Prod', { env: prodEnv })）

2. 避免误部署全部基础设施 #

除了指定单个栈部署的基础操作，还需要多层防护：

• 严格指定栈名部署：永远不用cdk deploy "*"或无参数部署，明确执行cdk deploy SecurityHubStack-Prod这类带环境标识的栈名命令
• 环境级栈隔离：在代码里判断当前环境，跳过非目标环境的栈实例化，比如测试环境不需要部署全部Config规则，可以在bin/aws-infra.ts里加条件判断
• 前置变更校验：部署前强制执行cdk diff $TARGET_STACK，查看变更内容，确认没有误修改再执行部署；CI/CD流程里必须加入这一步，禁止无diff确认的部署
• 权限最小化：给CDK部署角色设置权限边界，只允许操作对应栈的资源（比如部署Security Hub栈的角色只能修改Security Hub相关资源），就算误操作也不会影响其他栈
• 代码变更触发限制：在CI/CD里配置路径过滤，只有修改对应栈的代码（比如lib/stacks/security-hub-stack.ts）才触发该栈的部署流程，避免无关代码变更触发全栈部署

3. CI/CD集成方案 #

结合你的单栈部署思路，推荐以下落地流程：

分支与环境映射 #

• main分支 → 生产环境（Prod）
• staging分支 → 预发布环境
• dev分支 → 开发测试环境

核心CI/CD流程（以GitHub Actions为例） #

1. 代码检出与依赖安装：拉取代码后执行npm install或对应语言的依赖安装命令
2. 代码质量检查：运行lint、单元测试（比如npm test），不通过则终止流程
3. 变更预览：执行cdk diff $TARGET_STACK，将diff结果输出到日志，供人工审核（生产环境必须审核）
4. 部署触发：
   • 开发/预发布环境：自动执行cdk deploy $TARGET_STACK --require-approval never
   • 生产环境：需手动审批后，执行cdk deploy $TARGET_STACK（去掉--require-approval，保留CDK本身的变更确认）
5. 结果通知：部署成功/失败后通过Slack/邮件通知相关人员

关键配置 #

• 身份验证：用AWS OIDC角色代替长期密钥，在CI/CD工具里配置角色信任关系，避免密钥泄露
• 环境变量：在CI/CD里设置CDK_DEFAULT_ACCOUNT、CDK_DEFAULT_REGION等变量，或者从lib/config/env.ts加载配置
• 路径过滤：比如针对Security Hub栈，只在修改lib/stacks/security-hub-stack.ts或lib/constructs/base-alarm.ts时触发该栈的部署流程

你的现有思路优化点 #

• 给栈名加上环境后缀（比如SecurityHubStack-Prod），避免不同环境的栈名冲突
• 用CDK的Tags类给所有资源统一打环境标签（比如Environment: Prod），便于成本追踪和资源筛选
• 把通用配置（比如SNS告警主题ARN、Config规则阈值）放在环境配置文件里，不要硬编码在栈代码中

内容的提问来源于stack exchange，提问作者DimitriosK