@企业的多账户策略

企业的多账户策略

常⻅的账户体系结构：
1、身份账户体系结构（Identity Account Architecture）
2、⽇志账户体系结构 (Logging Account Architecture)
3、发布账户体系结构 (Publishing Account Structure)
4、账单结构 (Billing Structure)

⾝份账户体系结构（Identity Account Architecture）

假设您的企业是多AWS账户环境，当⽤户有变动时您肯定不希望在每个AWS账户下都要管理⽤户变动。⽐如您企业有5个AWS账户，分别部署了不同的业务环境，来了⼀个新员⼯，他在这些不同业务环境中有不同的⼯作职责，这样需要在这5个AWS账户分别给新员⼯建⽴⽤户，分配权限，这样的分散管理的⽅式过不了多久管理任务就会变的越来越糟糕。

推荐的作法是，在单⼀的中⼼区域对所有⽤户进⾏集中管理，以取代在每个AWS账户单独管理⽤户的⽅式，并允许他们访问多个AWS账户下的不同的AWS资源。这种在单⼀的中⼼区域对所有⽤户进⾏管理可以通过跨账户IAM⻆⾊和身份联合（Federation）来达成。

⽇志账户体系结构（Logging Account Architecture）

多账户环境通常将所有账户的所需⽇志都存储在⼀个中⼼区域，在这个中⼼区域集中对⽇志进⾏定期监控和分析，如有三个AWS账户，ACCOUNT A 和 ACCOUNT B，以及 ACCOUNTC。我们在ACCOUNT C中配置⼀个S3存储桶负责集中存储ACCOUNT A和B的相关⽇志，将A和B账户的CloudTrail、vpc flow⽇志、config log⽇志等配置成发送到ACCOUNT C中⼼账户的S3存储桶中集中存储，这个架构就是⽇志集中存储账户体系结构。

发布账户体系结构 (Publishing Account Structure)

我们可能会遇到这种场景，企业使⽤多个AWS账户，且有多个开发团队使⽤这些账户进⾏开发⼯作，他们需要启动EC2实例，有的开发团队启动的是Centos AMI，有的开发团队启动了Amazon linux AMI，还有开发团队启动了Ubuntu AMI，这样会导致开发环境不统⼀，也谈不上标准化，且在后续开发的过程中，因为环境的复杂性可能会造成环境调试或者安全相关问题。

那么要如何解决这个问题呢？通常情况下的作法是企业的安全团队负责提供golden image(⻩⾦镜像)，如果有多个AWS账户，需要确保开发⼈员只能启动安全团队批准的，提供的经过安全加固的镜像启动实例,这样，在启动实例时就实现了AMI标准化管理。

这也就是发布账户体系结构，这种架构对于希望集中管理整个企业预先批准的AMI及AWSCloudformation模板的客户⽽⾔可能是⾮常有帮助的。我们看下这个图，图中的EC2 AMI，我们假设这个AMI是由企业安全团队创建。这个AMI可以分享给所有其他AWS账户，并且您可以创建IAM策略，使得开发⼈员在启动EC2实例时只能使⽤此AMI。您可以使⽤AWS的ServiceCatalog服务来实现，这是发布账户体系结构

账单结构 (Billing Structure)

当企业是多AWS账户环境时，您可以使⽤AWS Organizations的整合账户功能，建⽴组织的主账户并整合和⽀付所有成员AWS⼦账户，使得您可以在⼀个主账户上追踪整个企业的AWS⼦账户的账单，并可为多个AWS⼦账户在主账户上进⾏统⼀⽀付。

在整合账户后最⼤的好处就是使得企业的AWS账单易于追踪， 在主账户上可以⾮常清晰的查看所有⼦账户的AWS账单，当然也享有合并所有账户使⽤量优惠等等。

标签：AMI,Account,策略,账户,AWS,ACCOUNT,企业,体系结构
来源： https://blog.csdn.net/weixin_48135995/article/details/115248434