我正在考虑使用 AppConfig，但我很难理解在测试和暂存部署位于不同帐户的情况下如何使用配置。
在这两个帐户中使用两个完全不同的 AppConfig 设置似乎适得其反，因为这会使配置升级到不同的部署变得困难。
我也可以设置一个 AppConfig，然后从我的应用程序中调用它，但这需要跨账户访问，使用我假设的不同角色，因为无法使用 ARN 或基于资源的策略访问 AppConfig。
那么如何跨多个帐户访问 AppConfig？
【问题讨论】：
https://aws.amazon.com/about-aws/whats-new/2019/11/simplify-application-configuration-with-aws-appconfig/
标签： amazon-web-services aws-lambda aws-app-config
某些服务确实通过控制台提供原生多帐户支持。但如果失败，您可以随时使用StackSets。如果您可以设法将您的AppConfig 很好地打包到CloudFormation 模板中，您可以将一组堆栈部署到Organizational Unit，它将部署到该OU 中的所有帐户。
根据您的要求，这可能适合也可能不适合您的用例。典型的用例是在这些账户中强制执行合规性和统一性，即 VPC 设置是一致的、启用了日志记录等。不一定要将应用程序部署到不同的账户中，并不是说这不是一个好主意，这取决于。
我相信大多数人所做的是在 AWS 中拥有一个 CI/CD 帐户，或者在 AWS 之外拥有一个单独的 CI/CD 工具，其中将有一个管道（AWS 中的Code Pipline），其中每个都有帐户作为一个单独的阶段。在您的管道中，如果需要，您将拥有每个账户的环境变量，并对您手动执行 ATM 的 AWS 进行 CLI/API 调用。 IMO 这将是大多数时候最可维护的方法，原因如下：
CloudFormation 中的条件很难维护 IMOCloudFormation 和 StackSets 相比，您通常拥有更多的粒度和控制力，尽管在技术上您可以使用 CloudFormation 完成所有操作。另一种选择是使用 AWS Service Catalog，自动更新预置产品，here 有一个示例。但这又是针对组织中的独立 IT 团队使用公司可用的 IT 产品的一个稍微不同的用例。
【讨论】：
App Config 应该是特定于环境的，并且云形成可能是解决部署复杂性的解决方案之一。
【讨论】：