使用AWS CodeBuild为Spring Boot应用注入环境变量的方案咨询

方案1：将完整YAML文件加密存储至AWS Secrets Manager（最推荐，适配现有配置逻辑） #

• 提前将各环境对应的完整application-{profile}.yml文件加密上传到Secrets Manager，可按环境设置独立的密钥ID，例如/appname/{env}/spring-config-yaml
• 为CodeBuild执行角色配置Secrets Manager对应密钥的读取权限，避免越权访问
• 在buildspec.yml的pre_build阶段添加拉取配置的命令，直接生成到项目资源目录：
  aws secretsmanager get-secret-value --secret-id /appname/prod/spring-config-yaml --query SecretString --output text > src/main/resources/application-prod.yml
• 关闭CodeBuild构建日志的明文输出功能，避免敏感内容意外打印
• 优势：完全复用现有YAML配置逻辑，70+变量无需逐个处理，配置文件全程加密存储、仅在构建阶段临时生成，不会泄露到Git或构建产物之外，操作成本极低

方案2：通过Elastic Beanstalk批量导入环境变量 #

• 把YAML配置中的变量批量转换为Elastic Beanstalk支持的键值对格式，支持通过控制台一次性批量上传JSON格式的环境变量配置，无需逐个输入
• Elastic Beanstalk的环境变量默认加密存储，应用启动时会自动注入到运行环境，Spring Boot可直接读取，无需在构建阶段处理配置
• 优势：配置和构建流程解耦，后续修改配置无需重新触发构建，直接在Beanstalk控制台更新即可生效

方案3：批量同步配置到AWS Systems Manager Parameter Store #

• 将所有配置项按环境路径批量导入Parameter Store，例如统一放在/appname/{env}/config/路径下
• 可选两种使用方式：要么在构建阶段批量拉取该路径下的所有参数自动生成YAML文件，要么给Spring Boot添加AWS参数存储依赖，应用启动时直接从Parameter Store拉取配置
• 优势：支持细粒度的配置权限控制，适合配置项频繁单独变更的场景

选型建议 #

• 优先选择方案1，完全适配你现有多profile YAML的配置逻辑，70+变量不需要做任何拆分转换，工作量最小，安全合规性也满足要求
• 如果有配置热更新、不需要重新构建就能生效的需求，可选择方案2或3
• 不推荐在buildspec中逐个定义变量，70+变量的维护成本极高，后续增改变量都需要修改buildspec，易出现配置遗漏或错误

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