标签：AMI Account 策略 账户 AWS ACCOUNT 企业 体系结构

@企业的多账户策略

企业的多账户策略

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。