其他分享
首页 > 其他分享> > 企业的多账户策略

企业的多账户策略

作者:互联网

@企业的多账户策略

企业的多账户策略

常⻅的账户体系结构:
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