5

我正在考虑使用 AppConfig，但我很难理解在测试和暂存部署位于不同帐户中的情况下如何使用配置。

在这两个帐户中拥有两个完全不同的 AppConfig 设置似乎适得其反，因为这会使配置升级到不同的部署变得困难。

我也可以设置一个 AppConfig，然后从我的应用程序中调用它，但这需要跨账户访问，使用我假设的不同角色，因为无法使用 ARN 或基于资源的策略访问 AppConfig。

那么如何跨多个帐户访问 AppConfig？

4

2 回答 2

0

堆栈集

某些服务确实通过控制台提供本机多帐户支持。但如果失败，您可以随时使用StackSets. 如果你能设法将你的模板打包AppConfig成一个CloudFormation模板，你可以将一组堆栈Organizational Unit部署到一个OU.

根据您的要求，这可能适合也可能不适合您的用例。这样做的典型用例是在这些账户中强制执行合规性和统一性，即 VPC 设置是一致的、启用了日志记录等。不一定要将应用程序部署到不同的账户中，并不是说这不是一个好主意，这取决于。

CI/CD - 首选 (IMO)

我相信大多数人所做的是在 AWS 中拥有一个 CI/CD 帐户，或者在 AWS 之外拥有一个单独的 CI/CD 工具，这将有一个管道（Code Pipline在 AWS 中），其中每个帐户都将作为一个单独的阶段。在您的管道中，如果需要，您将拥有每个账户的环境变量，并对您手动执行 ATM 的 AWS 进行 CLI/API 调用。IMO 这将是大多数时候最可维护的方法，原因如下：

  • 很容易在环境中产生差异，（CloudFormationIMO 中的条件很难维护
  • 如果您的堆栈组中的一个堆栈存在问题，则不是这样的问题，因为您可能有一个堆栈影响其他堆栈。
  • CloudFormation通常，您拥有比仅StackSets使用CloudFormation.

服务目录

另一种选择是使用 AWS Service Catalog，自动更新预置产品，这里有一个示例。但这同样适用于组织中的独立 IT 团队使用公司可用的 IT 产品的一个稍微不同的用例。

于 2021-10-06T23:47:52.553 回答
-1

App Config 应该是特定于环境的，而云形成可能是解决部署复杂性的解决方案之一。

于 2021-10-04T17:03:05.257 回答