企業的多賬戶策略（Multi-Account Strategy for Enterprises）

關注公衆號：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