小编BuZ*_*uZz的帖子

几年前，我的公司（一家没有客户或外部接口的内向机构）已将所有运营从本地数据中心转移到 AWS，主要转移到少数几个大型 AWS 账户（网络、管理、计费、沙箱、开发、测试，产品）。开发人员在这个初始设置中很难进行创新，因为 IAM 策略和服务白名单由于这些帐户的共享性质而必须非常严格。

所以，我们现在正在忙的最新事情是引入更多帐户，例如每个产品或开发团队的三个开发/测试/生产帐户。一些关键帐户围绕这些产品帐户创建防护栏（提供网络 VPC、安全扫描、日志/报告等...）。每个开发团队的独立帐户三元组意味着他们所做的事情的飞溅半径将更容易通过帐户间防火墙、安全组等来控制......开发人员获得他们的帐户后，他们还将获得一个管理员帐户，以便更自由地探索，如果他们做了一些可疑的事情（例如，一台机器将所有端口开放到 0.0.0.0/0），我们会立即让 Turbot.com 攻击流氓资源/帐户。

看起来很容易，但出于某种原因，我不会在这里提到的我们的第 3 方帐户/计费提供商一直面临着为我们提供新帐户的挑战（我们在启动新项目时谈论的是数十个帐户三元组/内部应用程序）。

我对以下几点感到困惑：

• 为什么我们的内部云团队不直接从 AWS 购买账户？
• 他们没有迅速提供新帐户可能是什么问题？
• 该服务产品有什么复杂之处？
• 它们是如何设计的？
• 他们如何为我们的根凭证提供安全性、IAM 和关怀？我知道我们被限制使用他们为自己保留的某些名称创建角色和策略
• 以他们的方式自动化 3rd 方 AWS 账户配置需要什么？我知道他们有点拥有我们的每个帐户，并且帐单会汇总到他们拥有很大控制权的特定帐户中。

我试图了解他们所做工作的复杂性以及是否有替代路线。作为一名开发人员，我已经在内部等待我的帐户数周了，我正在寻找答案。在我看来，这就像过去随意决定的繁文缛节。