關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn
Hello大家好，歡迎回來，我們今天的課程要討論的內容是 AWS的集中式日誌存儲架構，包括集中式日誌存儲架構需要考慮的事項，以及使用了兩個AWS賬戶對架構的實現做了個快速的演示。
我們開始今天的內容。
集中式日誌存儲架構
當前，在絕大多數組織中，日誌的管理和分析都被列爲 是非常核心的任務。它使組織能夠更加了解業務運營情況、安全性、變更管理、各事件之間的關係等，可幫助持續對整個組織的架構運轉情況全面的掌控。
一般來說，當討論的是AWS時, 需要我們關注的日誌服務有 像AWS Cloudtrail ,VPC flow 日誌，AWS config日誌，可能還會有來自EC2的日誌等等，因此，將所有AWS賬戶的日誌轉發到一個作爲中央區域的賬戶的S3存儲桶，集中管理和存儲是非常有必要的。然後可以在這個中心區域分析整個組織的日誌，也可以使用splunk等工具從S3存儲桶中獲取日誌，進行安全、審計、監控、排錯等其他的需求分析，通過單一的節點實現所有管理的AWS賬戶的日誌存儲、分析、監控需求。
實現集中日誌架構注意事項
我們先看下在實現集中式日誌架構時，需要考慮的一些注意事項。
首先，儘早定義日誌所需保留時間等要求，以及日誌生命週期策略，這對於您的組織在遵循某種審計、合規政策時顯得更加的重要，對於不同的日誌類型對應不同的日誌保留要求是非常常見的。我們假設有一個日誌需要保留5年，就要確保如果您把日誌存儲到了一個集中的中央賬戶的S3存儲桶，你要確保日誌將在存儲桶中保留5年且不會被自動刪除。
同樣，生命週期策略也是同樣重要，尤其是出於成本因素考慮的時候。比如，當組織的某個應用程序產生了重要的日誌，並需要集中存儲時，數據達到了TB級別，我們可以先分析一下後續對於此日誌的需求，評估後續日誌的檢索次數和對於檢索時間的要求，根據這些需求您可能不需要一直將全部TB級別的日誌放在S3存儲桶，可以將大部分日誌轉移至glacier滿足您的需求併爲您節省很多的成本，這一點恰好就是生命週期策略起到重要作用的地方。
第二個 是生命週期策略要自動化執行，比如上面提到的程序日誌，將產生時間在1個月內的日誌保存在S3中，以便在程序出現問題或其他需要的時候快速，高頻進行檢索；當在S3保留時間超過1個月後，將所有舊的應用程序日誌自動轉移到glacier以節省大量的成本。這些應該是自動化執行不需要我們人工去幹預的。
第三點是我們的系統要能夠自動化安裝和配置日誌傳輸代理程序。假設你有ec2實例在autoscaling環境，在後半夜一個新的ec2啓動了，你需要確保這個新啓動的實例的應用程序日誌或者服務器日誌，也要傳輸到S3存儲桶中。要實現這個需求，就需要確保日誌傳輸代理程序自動安裝在了這個新啓動的實例上。取決於不同的環境案例，可以將其在UserData實現，或者也可以將它集成在AMI中。
這個很好理解吧？因爲如果您使用了autoscaling，非常可能發生的一個情況是一個EC2實例在後半夜因擴展規則自動啓動，然後在運行一段時間比如當cpu使用率降低後這個新啓動的實例又被終止了，如果您沒有自動安裝和配置日誌傳輸代理程序，那麼這個新啓動的實例上的日誌將會丟失。
最後一點是確保您實現的解決方案支持混合雲架構。當前出於安全考慮企業更願意將數據存放在本地私有云中，但是同時又希望可以獲得公有云的資源，在這種情況下，現在很多組織都在朝着混合雲架構方向發展，既擁有私有云，又同時使用多家公有云，如AWS ，阿里雲等，所以不管你採用的什麼解決方案，確認它支持混合雲架構。
這是集中日誌架構的一些注意事項。
AWS日誌相關服務
因爲我們的課程是AWS認證課程，所以我們需要了解如何使用AWS託管服務來構建集中式日誌解決方案。
AWS提供了很多服務幫您構建，如AWS ElasticSearch Service、AWS S3、AWS CloudWatch servcie 、Kinesis Firehose等等。
需要說明的一點是，在AWS中，在配置集中式日誌存儲方案時，以上提到的服務的配置方式都是不同的，比如配置CloudTrail服務構建集中式日誌解決方案的方式是和VPCflow配置的方式是不同的，需要注意。
集中式日誌存儲實現快速演示
接下來我們快速演示下集中式日誌存儲架構。
我們介紹下演示的架構，使用兩個AWS賬戶，在後面的演示中我們統一把把左邊的賬戶成爲中央賬戶或者ACCOUNT A，將右邊的賬戶成爲ACCOUNT B。我們將ACCOUNT B的config和CloudTrail日誌集中存儲至中央賬戶的S3對應的兩個存儲桶中。
當然，這個架構是隻是使用了2個賬戶的架構，您的組織中可能還存在着ACCOUNT C,D,E，分別可以配置這些賬戶將對應的日誌轉發至中央賬戶的S3存儲桶中集中存儲，實現集中式日誌存儲架構。
登陸ACCOUNT A ，查看日誌生成情況
我們現在登陸了中央賬戶ACCOUNT A，我們使用這個賬戶負責集中式日誌存儲。
打開S3控制檯，可以看到有兩個和本次演示相關的S3存儲桶，iloveawscn-central-config和ioveawscn-central-cloudtrail,負責存儲來自不同賬戶ACCOUNT B對應的aws config和cloudtrail日誌。
我們快速打開ioveawscn-central-cloudtrail存儲桶，可以看到來自另外一個AWS賬戶ACCOUNT B的CloudTrail日誌已經成功轉發過來了，在s3存儲桶中是按照賬戶id目錄進行存儲的，這個2732數字的文件夾就是ACCOUNT B的賬戶id。
登陸ACCOUNT B
我們切換到賬戶ACCOUNT B瀏覽器，進入支持-支持中心，我們看下ACCOUNT B賬戶id,和剛纔在中央賬戶中的cloudtrail存儲桶的文件夾的賬戶id是一樣的。也就是說目前中央賬戶的s3存儲桶中已經存儲了來自不同AWS賬戶的ACCOUNT B的cloudtrail日誌。
下面我們進入到ACCOUNT B的cloudtrail控制檯，進入跟蹤，我們看下我們已經創建好的配置。在存儲位置部分，可以看到我們已經完成 將中央賬戶的s3存儲桶ioveawscn-central-cloudtrail配置到了cloudtrail配置的存儲位置。
完成這一步後還無法成功轉發日誌到中央賬戶的S3，因爲S3要開放相應的策略允許它訪問。
登陸ACCOUNTA，查看存儲桶策略
我們切換到中央賬戶的這個S3存儲桶，我們提前配置好了存儲桶策略，策略的作用是允許account B的cloudtrail日誌轉發寫入這個存儲桶。這裏顯示了具體的存儲桶策略的內容，我們指定了 cloudtrail.amazonaws.com 這個aws service允許對這個存儲桶GetBucketAcl ，PutObject行爲，這個策略內容我之後會附到課程後面，大家直接複製修改後就可使用。
以上是cloudtail對應的配置演示。
我們前面演示了CloudTrail如何配置構建集中式日誌存儲，參照配置，可以將組織中所有賬戶的cloudtrail日誌轉發到中央賬戶的S3存儲桶中集中存儲。前面提到過不同的AWS服務（CloudTrail，VPCFlow）構建集中式日誌解決方案的配置方式各不相同。同樣cloudtrail和aws config的配置方式是不同的，我們下面將快速演示下aws config 日誌如何配置構建集中日誌存儲。
我們回到中央賬戶的s3控制檯，打開用於存儲config日誌的iloveawscn-central-config存儲桶，我們同樣可以看到來自於不同賬戶ACCOUNT B的aws config日誌已經成功寫入存儲桶中。
登陸ACCOUNT B
我們切換到ACCOUNT B打開aws config控制檯，進入設置，查看s3存儲桶配置部分，同樣，可以看到我們已經將中央賬戶的s3負責存儲config日誌的存儲桶名稱配置到了這裏。
爲了將ACCOUNT B的aws config日誌轉發到中央賬戶相應的存儲桶中，我們同樣要爲config日誌的存儲桶配置存儲桶策略，我們切換到中央賬戶的s3控制檯，打開存儲桶策略，我們看下我們已經配置策略的內容，基本上和前面cloudtral的策略差不多，Service這裏我們改成了config.amazonaws.com。
好的，以上就是我們今天的課程內容， 我們下節課將從頭開始配置本節課的快速演示內容，配置CloudTrail和aws Config日誌實現跨AWS賬戶日誌存儲。
希望此係列教程能爲您通過 AWS解決方案架構師認證 Professional 認證考試帶來幫助，如您有任何疑問
關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn
我們今天的課程就到這裏，感謝大家的觀看，我們下一課程再見。