關注公衆号：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載)
網站：www.iloveaws.cn
【 Domain 1的組織複雜性設計（Design for Organizational Complexity）】——企業的多賬戶政策
Hello大家好歡迎回來，我們今天将讨論企業的多賬戶政策内容，是SAP-C01 2019新版考試藍圖中【 Domain 1的組織複雜性設計（Design for Organizational Complexity）】的第一篇内容。
如需檢視【SAP-C01 2019 新版考試藍圖】的内容請點選這裡。
AWS解決方案架構師認證 Professional / AWS Certified Solutions Architect–Professional —2019系列的課程的最終目的是幫助大家順利通過新版考試。随着後續系列課程的持續深入，我們的目标是将所有SAP-C01新版考試涉及到的内容、考點逐漸推出系列課程，幫助大家備考。此系列課程也同樣适用于想了解和學習AWS的同學，請大家多多支援。
企業的多賬戶政策
我之前就職的企業，有十幾個AWS賬戶，為了管好這麼多的賬戶，需要提前做好賬戶的規劃和管理的政策。作為一個解決方案架構師來說，了解多AWS賬戶所帶來的管理挑戰，以及掌握一些多賬戶管理的方法和政策是非常重要的。讓我們進一步了解這部分内容：
企業采用多AWS賬戶政策通常都會是一個非常棒的選擇，因為它提供了最大數量的資源和足夠程度的安全隔離。目前很多企業實際隻是使用一個區域層面隔離的解決方案，僅用一個AWS賬戶，如他們可能會在東京區域部署開發環境，然後在首爾區域部署生産環境，通過将企業不同的環境部署在不同的AWS區域中實作資源隔離，很多情況下這種隔離的程度是不夠的，也不是我們推薦的最佳實踐，因為如果建立了IAM使用者及相應政策配置設定給了開發人員，而這個政策又沒有進行合理安全配置，開發人員是可以通路首爾區域生産環境的，如發生誤操作等情況有可能會影響生成環境的業務穩定性。
是以，在類似這種場景下，企業配置并擁有多個AWS賬戶是最佳實踐，為開發人員單獨建立一個AWS賬戶，并為生産環境也單獨建立一個AWS賬戶部署資源，這樣可以避免開發賬戶意外通路生産環境資源進而導緻影響業務的穩定性，除非我們給其開對應的權限政策。
企業使用多AWS賬戶時，常見的賬戶體系結構：
1、身份賬戶體系結構（Identity Account Architecture）
2、日志賬戶體系結構 (Logging Account Architecture)
3、釋出賬戶體系結構 (Publishing Account Structure)
4、賬單結構 (Billing Structure)
下面的内容我們将對這4種常見的賬戶體系結構進行讨論：
1、身份賬戶體系結構（Identity Account Architecture）
假設您的企業是多AWS賬戶環境，當使用者有變動時您肯定不希望在每個AWS賬戶下都要管理使用者變動。比如您企業有5個AWS賬戶，分别部署了不同的業務環境，來了一個新員工，他在這些不同業務環境中有不同的工作職責，這樣需要在這5個AWS賬戶分别給新員工建立使用者，配置設定權限，這樣的分散管理的方式過不了多久管理任務就會變的越來越糟糕。
推薦的作法是，在單一的中心區域對所有使用者進行集中管理，以取代在每個AWS賬戶單獨管理使用者的方式，并允許他們通路多個AWS賬戶下的不同的AWS資源。這種在單一的中心區域對所有使用者進行管理可以通過跨賬戶IAM角色和身份聯合（Federation）來達成。關于這些具體的内容我們會在後面接下來的系列課程中讨論，現在我們隻要了解概念即可。
2、日志賬戶體系結構（Logging Account Architecture）
多賬戶環境通常将所有賬戶的所需日志都存儲在一個中心區域，在這個中心區域集中對日志進行定期監控和分析，如有三個AWS賬戶，ACCOUNT A 和 ACCOUNT B，以及 ACCOUNT C。我們在ACCOUNT C中配置一個S3存儲桶負責集中存儲ACCOUNT A和B的相關日志，将A和B賬戶的CloudTrail、vpc flow日志、config log日志等配置成發送到ACCOUNT C中心賬戶的S3存儲桶中集中存儲，這個架構就是日志集中存儲賬戶體系結構。
您可以定期集中分析ACCOUNT C的S3存儲桶日志，也可以使用splunk等工具從S3存儲桶中擷取日志，進行安全、審計、監控、排錯等其他的需求分析，通過單一的節點實作所有管理的AWS賬戶的日志存儲、分析、監控需求。
3、釋出賬戶體系結構 (Publishing Account Structure)
我們可能會遇到這種場景，企業使用多個AWS賬戶，且有多個開發團隊使用這些賬戶進行開發工作，他們需要啟動EC2執行個體，有的開發團隊啟動的是Centos AMI，有的開發團隊啟動了Amazon linux AMI，還有開發團隊啟動了Ubuntu AMI，這樣會導緻開發環境不統一，也談不上标準化，且在後續開發的過程中，因為環境的複雜性可能會造成環境調試或者安全相關問題。
那麼要如何解決這個問題呢？通常情況下的作法是企業的安全團隊負責提供golden image(黃金鏡像)，如果有多個AWS賬戶，需要確定開發人員隻能啟動安全團隊準許的，提供的經過安全加強的鏡像啟動執行個體,這樣，在啟動執行個體時就實作了AMI标準化管理。
這也就是釋出賬戶體系結構，這種架構對于希望集中管理整個企業預先準許的AMI及AWS Cloudformation模闆的客戶而言可能是非常有幫助的。我們看下這個圖，圖中的EC2 AMI，我們假設這個AMI是由企業安全團隊建立。這個AMI可以分享給所有其他AWS賬戶，并且您可以建立IAM政策，使得開發人員在啟動EC2執行個體時隻能使用此AMI。您可以使用AWS的Service Catalog服務來實作，這是釋出賬戶體系結構。
4、賬單結構(Billing Structure)
當企業是多AWS賬戶環境時，您可以使用AWS Organizations的整合賬戶功能，建立組織的主賬戶并整合和支付所有成員AWS子賬戶，使得您可以在一個主賬戶上追蹤整個企業的AWS子賬戶的賬單，并可為多個AWS子賬戶在主賬戶上進行統一支付。
在整合賬戶後最大的好處就是使得企業的AWS賬單易于追蹤， 在主賬戶上可以非常清晰的檢視所有子賬戶的AWS賬單，當然也享有合并所有賬戶使用量優惠等等，在這裡就不在過多擴充了，我們将在後續系列的教程中深入讨論。
我們今天的課程介紹了當企業中設定多個AWS賬戶後，可能需要面對的一些挑戰，以及一些常見的多賬戶體系結構。在本篇教程中我們在一個較高的層面概述了這些挑戰以及我們如何設計多AWS賬戶的架構，我們會在後續的教程中深入詳細讨論這部門内容。
我們今天将讨論企業的多賬戶政策内容，是SAP-C01 2019新版考試藍圖中【 Domain 1的組織複雜性設計（Design for Organizational Complexity）】的第一篇内容，01-企業的多賬戶政策（Multi-Account Strategy for Enterprises）。
希望此系列教程能為您通過 AWS解決方案架構師認證 Professional 認證考試帶來幫助，如您有任何疑問，請聯系我們：
關注公衆号：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載)
網站：www.iloveaws.cn