AWS服務陷阱 沒有一勞永逸

一個常見的誤解是AWS服務滿足了所有的IT需求，Bhargava說：“你搞錯了，AWS提供的是擁有巨大價值和良好設計的基礎設施即服務（IaaS）解決方案，但我覺得仍有大批人相信AWS負責諸如安全、補丁、用戶管理等事務。”大部分情況下并非如此，“如果企業(yè)認為AWS需要負責上述事情而實際上AWS又沒有做，他們就將處于嚴重風險之中。”

從更加寬泛的角度來看待AWS服務陷阱，Orchestratus的CEO，Shlomo Swidler分享了他所認為的四大陷阱，分別是：

無法隔離生產(chǎn)環(huán)境與開發(fā)測試環(huán)境。在開發(fā)測試環(huán)境下發(fā)生的錯誤不應影響上線的服務，但是在統(tǒng)一的集成賬戶管理下，這種分隔很難實現(xiàn)。Swidler表示：“你還要嚴格控制生產(chǎn)環(huán)境配置，因為生產(chǎn)環(huán)境中包含機密信息，如支付網(wǎng)關電子憑證以及密碼等。”簡言之，使用獨立的AWS賬戶來管理生產(chǎn)環(huán)境和開發(fā)測試環(huán)境是一個好辦法。

失去賬單追蹤能力。Swidler解釋說，由于對大量的AWS資源使用是建立在一個用戶賬戶中，審計和追蹤AWS服務使用情況將變得日益困難。在此情況下，Swidler推薦使用AWS的合并賬單（Consolidated Billing）功能，該功能允許用戶將多個獨立賬戶歸集到一個主賬戶下來管理，展示統(tǒng)一的使用信息并可統(tǒng)一支付。他還推薦在每個賬戶上設置消費警報，以此通知用戶達到預設的消費級別的時刻。

跟上需求的變化。Swidler表示：“啟動AWS內(nèi)的資源并長期使用是容易的，但是你會忽略云服務的一大特色：適應變化需求的靈活性。”他推薦通過定期檢查自身需求（至少每季度一次）來解決此問題，他補充道，一旦AWS降低了價格或者增加了新服務，你會發(fā)現(xiàn)通過及時變更資源配置能夠更加有效地滿足需求。

依靠傳統(tǒng)數(shù)據(jù)中心管理工具來管理AWS資源。“數(shù)據(jù)中心管理工具在管理相對靜態(tài)的服務器資源上是非常優(yōu)秀的，但云服務模型允許用戶動態(tài)添加和刪除后臺的服務器資源，這種使用模式使得面向數(shù)據(jù)中心管理的工具無法良好地應對，”Swidler說。相反，AWS的客戶應該使用“諸如Chef、Puppet、RunDeck等設計處理動態(tài)模型的現(xiàn)代化管理工具” .