AWS雲使用100條寶貴經驗分享

在今天的文章中，我整理出了大量當初曾經錯過、而至今仍將我追悔莫及的Amazon Web Services（簡稱AWS）使用心得。在幾年來的實踐當中，我經過在AWS之上新手構建及部署各種應用程序而積累到了這些經驗。雖然內容有些雜亂，但相信仍然能給各位帶來一點啓示。

從物理服務器向「雲環境」轉移的過程不只僅是一項技術任務，同時也意味着咱們的思惟方式須要做出針對性的轉變。整體而言，在物理環境下咱們須要關注的只是每一臺獨立主機; 它們各自擁有本身的靜態IP，咱們可以對其分別加以監控。而一旦其中一臺發生故障，咱們必須盡最大可能讓其快速恢復運轉。你們能夠覺得只要將基礎設施轉移到AWS環境之下，就能直接享受到「雲」技術帶來的種種收益了。遺憾的是，事情可沒那麼簡單（相信我，我親身嘗試過了）。在AWS環境之下，咱們必須轉變思惟，並且這方面的任務每每不像技術難題那麼容易被察覺。所以，受到了SehropeSarkuni最近一篇帖子的啓發，我將本身幾年來積累得出的AWS使用心得彙總於此，並且說實話、我真但願本身當初剛剛接觸AWS時能有人告訴我這些寶貴經驗。這些心得總結自我在AWS之上部署我的及工做應用程序時的親身感覺，其中一部分屬於須要高度關注的「疑難雜症」（我本身就是直接受害者），而另外一部分則是我聽其餘朋友提及過、並隨後親自確認有效的解決方案。不過整體而言，爲了積累這些經驗，我確實付出了至關慘痛的代價：）

應用程序開發

千萬不要把應用程序狀態保存在本身的服務器上。

之因此這麼說，是由於一旦咱們的服務器發生故障，那麼應用程序狀態極可能也隨之完全消失。有鑑於此，會話應當被存儲在一套數據庫（或者其它某些集中式存儲體系、memcached或者redis當中）而非本地文件系統內。日誌信息應當經過系統日誌（或者其它相似方案）進行處理，並被髮送至遠程位置加以保存。上傳內容應當直接指向S3（舉例來講，不要將其存儲在本地文件系統內，並經過其它流程隨後遷移到S3）。再有，任何已經處理過或者須要長期運行的任務都應該經過異步隊列（SQS很是適合處理此類任務）來實現。

編輯點評:對於S3上傳內容而言，HN用戶Krallin指出，咱們能夠完全避免其與自有服務器的接觸，並利用預簽名URL保證用戶的上傳數據被直接發送至S3當中。

將額外信息保存在日誌當中。

日誌記錄一般包含有時間戳以及pid等信息。你們也可能但願將實例id、服務區域、可用區以及環境（例如分步環境或者生產環境等）添加進來，而這些都能在往後的調試工做中做爲參考。你們能夠從instance metadata service當中獲取到這些信息。我所採用的方法是將這些信息做爲引導腳本的組成部分，並將其以文件形式存儲在文件系統當中（例如/env/az或者/env/region等）。這樣一來，我就用不着持續查詢元數據服務來獲取這些信息了。你們應當確保這些信息可以在實例從新啓動時獲得正確更新，畢竟咱們都不但願在保存AMI時發現其中的數據還跟上次徹底同樣，這確定屬於非正常情況。

若是咱們須要與AWS進行交互，請在當前語言中使用對應SDK。

千萬不要試圖本身動手。我當初就犯過這個錯誤，由於我認爲本身只是單純須要向S3上傳內容，但隨着後續服務的持續增長、我發現本身的決定簡直愚蠢至極。AWS SDK的編寫質量很高，可以自動處理驗證、處理重試邏輯，並且由Amazon官方負責維護與迭代。此外，若是你們使用EC2 IAM角色（你們絕對應該這麼作，這一點咱們後面會進一步提到），那麼該SDK將幫助咱們自動獲取到正確的證書。

利用工具查看應用程序日誌。

你們應當採用管理員工具、系統日誌查看器或者其它方案，從而幫助本身在無需在運行中實例內使用SSH的方式查看當前實時日誌信息。若是你們擁有集中式日誌記錄系統（我強烈建議你們使用此類系統），那麼固然但願能在不使用SSH的狀況下完成日誌內容查看任務。很明顯，將SSH引入正處於運行狀態的應用程序實例會引起諸多弊端。

運營心得

若是將SSH引入本身的服務器，那麼自動化機制恐怕將沒法生效。

在所有服務器上禁用SSH訪問。

這聽起來確實有點瘋狂，我知道，但在你們的安全組當中、請務必確保端口22不向任何人開放。若是各位想從今天的文章中得到什麼啓示，那請千萬牢記如下一點：若是將SSH引入本身的服務器，那麼自動化機制恐怕將沒法生效。從防火牆級別（而非服務器自己）禁用SSH有助於整套框架實現思惟轉變，由於這樣一來咱們就能瞭解到哪些區域須要進行自動化改造，同時你們也能更輕鬆地恢復訪問來解決當前面臨的問題。在乎識到不再必將SSH引入實例以後，你們確定會像我同樣感到渾身輕鬆。沒錯，這是我在實踐中瞭解到的最驚世駭俗、但也卻具實用性的心得。

編輯點評:不少人對這項心得表現出了高度關注（HackerNews網站上還出現了很多值得一讀的評論意見），所以咱們要在這裏多說幾句。我我的也會經過禁用入站SSH來矇騙自動化機制（哦，我只是SSH一下來修復某個問題，立刻就撤）。固然，若是我須要在某個實例中進行主動調試，那麼我仍然能夠在安全組中將其從新啓用，由於有時候咱們確實沒有其它辦法來調試特定問題。另外，具體狀況還取決於咱們實際使用的應用程序類型：若是你們應用程序的正常運行要求各位能力經過SSH將信息傳遞至服務器，那麼將其禁用確定不是什麼好主意。這種阻斷進站SSH的辦法確實適合我，也迫使我對本身的自動化機制加以精心打理，不過必須認可、這種方式並不適合每一位用戶。

服務器只是暫時性手段，不必太過關注。咱們要關注的僅僅是服務自己。

若是某臺服務器出現了故障，你們徹底不必對其太過關注。這是我在利用AWS來替代物理服務器以後，親身得到的最直接的便利成效。通常來說，若是一臺物理服務器沒法正常工做，技術人員總會暫時陷入恐慌。但在AWS當中，你們就徹底沒必要擔憂了，由於自動伸縮機制會很快幫咱們創建起新的實例。Netflix公司在此基礎之上還跨出了更具前瞻意義的步伐，他們組建了Simian Army團隊，並嘗試Chaos Monkey等極爲激進的測試項目——它會隨機關閉生產環境下的某些實例（他們還利用Chaos Gorilla項目隨機關閉可用區。我甚至獲得消息，說是Chaos Kong項目會直接關閉基礎設施大區……）。總而言之，我想表達的意思是：服務器總會發生故障，但這不應影響到咱們的應用程序。

不要爲服務器提供靜態/彈性IP。

對於一款典型的Web應用程序，你們應當將一切部署在負載均衡機制之下，並在不一樣可用區之間對資源使用狀況加以平衡。雖然我也遇到過一些須要使用彈性IP機制的狀況，但爲了儘量提升自動伸縮效果，你們仍是應該利用負載均衡機制取代在每一個實例中使用獨有IP的做法。

將自動化普及到各個角落。

不僅是AWS，自動化機制應該做爲總體運營工做中的通用性指導方針，其中包括恢復、部署以及故障轉移等等。軟件包與操做系統更新都應該由自動化方案所管理，具體可表現爲bash腳本或者Chef/Puppet等。咱們不應把主要精力放在這些瑣碎的瑣事上。正如前文中所提到，你們還須要確保禁用SSH訪問，從而快速瞭解到本身的執行流程中還有哪些方面沒有實現自動化改造。請記住前面提到的重要原則：若是將SSH引入本身的服務器，那麼自動化機制恐怕將沒法生效。

每位員工都要擁有一個IAM帳戶。永遠不要登陸主帳戶。

一般狀況下，咱們會爲服務設置一個「運營帳戶」，而整個運營團隊都將共享登陸密碼。但在AWS當中，你們固然不但願遵循一樣的處理方式。每位員工都要擁有一個IAM帳戶，其中提供與其需求相符的操做權限（也就是最低權限）。IAM用戶已經能夠控制基礎設施中的一切。截至本文撰寫時，IAM用戶唯一沒法訪問的就是計費頁面中的部份內容。

若是你們但願進一步保護本身的帳戶，請確保爲每位員工啓用多因素驗證機制（你們可使用谷歌Authenticator）。我據說有些用戶會將MFA令牌交付給兩名員工，並將密碼內容交付給另外兩名員工，這樣主帳戶在執行任意操做時、都至少須要兩名員工的贊成。對我來講這種做法有點小題大作，但也許您所在的企業確實須要如此高強度的控制機制。

我最後一次從CloudWatch收到操做警告大約是在一年以前……

將警告信息轉化爲通知內容。

若是你們已經將一切步驟正確部署到位，那麼運行狀態檢查機制應該會自動清除故障實例並生成新的實例。在收到CloudWatch警告信息時，咱們通常不須要採起任何行動，由於全部應對措施都能以自動化方式實現。若是你們獲得警告稱相關問題須要手動干預，那麼請作好過後檢查、看看能不能找到一種能夠在將來經過自動化方式將其解決的途徑。我最後一次從CloudWatch收到操做警告大約是在一年以前，並且對於任何一位運營人員來講、可以再也不被警告消息打擾了清夢都應該算是天大的好消息。

計費機制

創建起細化計費警告機制。

你們應當始終設定至少一套計費警告機制，但其內容卻能夠很是簡單——例如只在咱們超出了當月資源用量限額時發出提醒。若是你們但願早點掌握計費指數的動向，則須要一套更爲完備的細化方案。我解決這個問題的辦法是以星期爲單位設定預期使用量。如此一來，假如第一週的警告額度爲1000美圓，那麼第二週應該爲2000美圓，第三週爲3000美圓，依此類推。若是第二週的警告在當月的14號或者15號以前就被觸發，那麼我就能推定確定發生了什麼異常情況。若是想更進一步地實現細化控制，你們能夠爲每項服務設置獨立的警告方案，這樣就能快速瞭解究竟是哪項服務把咱們的資源預算早早耗盡了。若是你們每月都在固定使用某幾項服務，並且其中一些很是穩定、另外一些則起伏較大，那麼這種方法可以收到良好的成效。在此類狀況下，咱們不妨爲穩定服務設置每週獨立警告，同時爲起伏較大的服務設置週期更長的總體警告。固然，若是各項服務的資源使用量都很穩定，那麼上述方法就有點過度謹慎了，畢竟只要看一眼CloudWatch、你們就能立刻了解究竟是哪項服務出了問題。

安全性保障

使用EC2角色，不要爲任何應用程序提供IAM帳戶。

若是你們在應用程序當中內置有AWS證書，那麼確定屬於「處理失當」的情況了。前面之因此強調在開發語言中使用AWS SDK，最重要的理由之一就是咱們可以輕鬆藉此使用EC2 IAM角色。角色的設計思路在於，容許你們爲特定角色指定其所必需的恰當權限，然後將該角色分配至對應EC2實例當中。而不管咱們什麼時候將AWS SDK應用至實例當中，都沒必要再指定任何驗證憑證。相反，該SDK將回收咱們在設置當中爲該角色指定權限所使用的任何臨時性證書。整個流程都會以透明化方式處理，很是安全並且極具實用性。

將權限分配至組，而非用戶。

管理用戶每每是件使人頭痛的事情，特別是在使用Active Directory或者其它一些已經與IAM相整合的外部驗證機制時，並且這類做法的實際效果也不夠理想（固然也有效果不錯的狀況）。不過我發現更輕鬆的辦法，即只將權限分配至組而非個別用戶，這將大大下降權限的管理難度。很明顯，相較於面向每位獨立用戶來查看爲其分配的權限，以組爲單位進行權限交付可以幫助咱們更好地把握系統總體概況。

設置自動化安全審計機制。

在平常工做中，很重要的一點是追蹤基礎設施內安全設置的各項變動。實現這一目標的辦法之一在於首先創建起一套安全審計角色（即JSON模板）。這一角色會對帳戶以內與安全相關的各種設置進行只讀訪問。在此以後，你們就能夠利用這一相似於Python腳本的方案達到目標了，它將可以對帳戶中的全部條目進行審查並生成一整套與配置相關的規範比對結果。咱們能夠設置一個cronjob來運行該腳本，並將輸出結果與上一次的結果相比較。其中的差別之處就表明着咱們安全配置方案當中所出現的變化。這種方式很是實用，並且可以經過電子郵件將變動信息通知給你們。

使用CloudTrail來記錄審計日誌。

CloudTrail經過經過API或者S3存儲桶內的Web控制檯記錄全部執行過的操做活動。利用版本控制機制設置存儲桶能夠確保任何人都沒法修改這些日誌內容，而咱們本身則能夠隨後對帳戶內的所有變動進行完全審計。咱們固然不但願遇到須要審計日誌內容的情況，但正所謂有備無患，準備好這麼一套方案仍是頗有必要的。

S3

在存儲桶內的SSL名稱中使用「-」而非「.」。

若是你們但願在SSL之上使用本身的存儲桶，那麼使用「.」做爲名稱的組成部分將致使證書不匹配錯誤。一旦存儲桶建立完成，咱們將沒法再對其名稱進行更改，因此你們只能將一切複製到新的存儲桶當中。

我發現文件系統就像大型政府部門同樣「可靠」。

 

避免載入文件系統（例如FUSE）。

我發如今被用於關鍵性應用程序時，這些文件系統就像大型政府部門那樣「可靠」。總之，使用SDK做爲替代方案更加明智。

咱們用不着在S3以前使用CloudFront（但這樣確實可以起到助益）。

編輯評論:根據Hacker News網站用戶的最佳反饋內容，咱們對這條心得做出了部分修改。

若是你們對於可擴展能力比較看重，那麼最好是將用戶直接引導至S3 URL而非使用CloudFront。S3可以實現任意水平的容量擴展（雖然一部分用戶報告稱其沒法實現實時規模擴展），所以這也是充分發揮這一優點的最佳思路。除此以外，更新內容在S3中的起效速度也夠快，雖然咱們仍然須要在使用CDN查看變動時等等TTL的響應（不過我相信你們如今已經可以在CloudFront中得到0延遲TTL，因此這一點也許存在爭議）。

若是你們須要良好的速度表現，或者須要處理對傳輸帶寬要求極高的數據（例如超過10TB），那麼你們可能更但願使用像CloudFront這樣的CDN方案與S3相配合。CloudFront可以極大提高全球各地用戶的訪問速度，由於它會將相關內容複製到各邊緣位置。根據實際用例的不一樣，你們能夠經過較低數量的請求實現高傳輸帶寬（10TB以上），並藉此下降使用成本——這是由於相較於S3傳輸帶寬，當傳輸總量高於10TB時CloudFront的傳輸成本每GB比其低0.010美圓。不過CloudFront的單次請求成本較直接訪問S3中的文件卻要略高一點。根據具體使用模式，傳輸帶寬的成本節約額度也許會超過單一請求所帶來的額外成本。由於在直接訪問S3存儲內容時，咱們只需以較低頻度從S3獲取數據（遠較正常使用狀況更低），因此成本也就更加低廉。AWS官方提供的CloudFront說明文檔解釋瞭如何將其與S3配合使用，感興趣的朋友能夠點擊此處查看細節信息。

在密鑰開頭使用隨機字符串。

這初看起來彷佛有點難以理解，不過S3所採起的一大實現細節在於，Amazon會利用對象密鑰來檢測某個文件到底保存在S3中的哪一個物理位置。所以若是多個文件使用一樣的前綴，那麼它們最終極可能會被保存在同一塊磁盤當中。經過設置隨機性密鑰前綴，咱們可以更好地確保本身的對象文件被分散在各個位置，從而進一步提高安全性。

EC2/VPC

別忘了使用標籤！

幾乎每項服務都提供標籤功能，別忘了善加利用！它們很是適用於進行內容歸類，從而大大簡化後續出現的搜索與分組工做。你們也能夠利用這些標籤在本身的實例中觸發特定行爲，例如env-debug標籤能夠確保應用程序在部署以後進入調試模式。

我遇到過這類問題，感受很很差，你們千萬不要重蹈覆轍！

在非自動伸縮實例中使用停止保護。之後你會感激個人建議的，絕對。

若是你們擁有某些不具有自動伸縮機制的一次性實例，則應當儘量同時使用停止保護，從而避免某些人無心中將這些實例給刪除掉。我就遇到過這類問題，感受很很差，你們千萬不要重蹈覆轍！

使用VPC。

當初我剛剛開始接觸AWS時，VPC要麼還不存在、要麼就是被我給忽視了。雖然剛開始上手感受很糟糕，但一旦熟悉了它的特性並可以順暢使用，它絕對能帶來使人喜出望外的便捷效果。它可以在EC2之上提供各種附加功能，事實證實設置VPC花掉的時間徹底物有所值——甚至物超所值。首先，你們能夠利用ACL從網絡層面上控制流量，此外咱們還能夠修改實例大小及安全組等等，同時無需停止當前實例。你們可以指定出口防火牆規則（在正常狀況下，咱們沒法控制來自EC2的離站流量）。不過最大的助益在於，它能爲咱們的實例提供獨立的私有子網，這就完全將其餘人排除在外，從而構成了額外的保護層。不要像我當初那樣傻等着了，馬上使用VPC並讓一切變得更加輕鬆。

若是你們對於VPC抱有興趣，我強烈建議各位觀看《百萬數據包的一日之期》這段資料。

利用保留實例功能來節約大量成本。

保留實例的本質就是將一部分資金節約下來，從而使其保持較低的資源耗費速率。事實證實，保留實例相較於按需實例可以幫助咱們省下大量經費。所以，若是你們意識到只須要繼續保持某個實例運行一到三年，那麼保留實例功能將是各位的最佳選擇。保留實例屬於AWS當中的一類純邏輯概念，你們用不着將某個實例指定爲需保留對象。咱們要作的就是設定好保留實例的類型與大小，接下來任何符合這一標準的實例都將處於低速運轉加低成本支出的運行模式之下。

鎖定安全組。

若是有可能，千萬不要使用0.0.0.0/0，確保使用特定規則來限制用戶對實例的訪問。舉例來講，若是你們的實例處於ELB以後，各位應該將安全組設定爲只容許接受來自ELB的流量，而非來自0.0.0.0/0的流量。你們能夠經過將「amazon-elb/amazon-elb-sg」寫入CIDR的方式實現這一目標（它會自動幫你們完成其他的工做）。若是你們須要爲一部分來自其它實例的訪問請求向特定端口放行，也不要使用它們的對應IP，而最好利用其安全組標識符來替代（只須要輸入‘sg-’，其它的部分將自動完成）。

不要保留無關的彈性IP。

咱們所建立的任意彈性IP都會成爲計費項目，不管其與實例是否相關，所以請確保在使用事後將其及時清理掉。

ELB

在負載均衡器上停止SSL。

你們須要將本身的SSL證書信息添加到ELB當中，但在服務器上停止SSL可以消除由此帶來的常規資源消耗，從而提升運行速度。除此以外，若是你們須要上傳本身的SSL證書，則能夠經由HTTPS流量實現、而負載均衡器會爲咱們的請求添加額外的標頭（例如x-forwarded-for等），這有助於咱們瞭解最終用戶到底是何許人也。相比之下，若是咱們經由TCP流量實現，那麼這些標頭將不會被添加進來、相關信息天然也就無從獲取。

若是打算執行高強度流量，請對ELB進行預熱。

對於ELB來講，容量擴展是須要一段時間週期才能完成的。若是你們意識到本身將會迎來流量峯值（例如銷售門票或者召開大型活動等），則須要提早對ELB進行預熱。咱們能夠主動增長流量規模，這樣ELB就會提早進行容量添加，從而避免實際流量來臨時發生卡頓。不過AWS建議你們最好是與服務人員取得聯繫，而非自行對負載均衡器進行預熱。或者，你們也能夠在EC2實例當中安裝本身熟悉的負載均衡軟件並加以使用（例如HAProxy等）。

ElastiCache

使用配置端點而非獨立節點端點。

一般狀況下，你們須要讓應用程序識別出各可用Memcached節點的存在。但若是你們但願以動態方式實現容量擴展，那麼這種做法可能會帶來新的問題，由於咱們將須要採起多種方式才能保證應用程序識別到容量的變化。比較簡便的解決方案在於使用配置端點，這意味着使用Memcached庫的AWS版原本對新節點自動發現機制加以抽象並剝離。AWS使用指南中提供了更多與緩存節點自動發現議題相關的解答，感興趣的朋友能夠點擊此處查看細節信息。

RDS

爲故障轉移設置事件訂閱機制。

若是你們正在使用多可用區方案，那麼這多是一種被各位所忽略、但在相關需求出現時卻又悔之晚矣的重要解決方案。

CloudWatch

使用CLI工具。

要利用Web控制檯建立警報機制，咱們可能須要面臨大量繁的工做，特別是在設置衆多內容相似的警報信息時，由於咱們沒法直接「克隆」現有警報並僅對其中一小部分做出修改。在這種狀況下，利用CLI工具實現腳本化效果可以幫助各位節約大量寶貴時間。

使用免費監測指標。

CloudWatch監控工具以避免費方式提供各種監測指標（包括傳輸帶寬、CPU使用率等等），並且用戶可以獲取到最多兩週的歷史數據。有鑑於此，咱們根本用不着花錢購置本身的工具來實現系統監控。但若是你們須要超過兩週的歷史數據記錄，那沒辦法，只能使用第三方或者自行開發的監控方案了。

使用自定義監測指標。

若是你們但願監控免費指標以外的其它項目，則能夠將本身的定製指標信息發送至CloudWatch，並使用相關警報與圖形功能。這不只能夠用於追蹤諸如磁盤空間使用量等情況，同時也能夠根據實際需求自行設定應用程序監測方向。感興趣的朋友能夠點擊此處查看AWS提供的發佈自定義監測指標頁面。

使用詳細監測機制。

這項服務每個月每實例的使用成本約爲3.5美圓，但其提供的豐富額外信息絕對可以值回票價。1分鐘的細化監測甚至好過5分鐘的粗放查看。你們能夠藉此瞭解到某次時長5分鐘的崩潰究竟是因何而起，同時以很是明確的方式將其以1分鐘圖表的方式顯示出來。也許這項功能並不適用於每閏用戶，但就我我的而言、它確保幫我弄清了很多本來神祕的疑難雜症。

自動伸縮

利用INSUFFICIENT_DATA以及ALARM進行規模縮減。

對於規模縮減操做而言，你們須要確保可以在不具有指標數據甚至觸發機制自己出現問題時仍能正常實現規模縮減。舉例來講，若是你們的某款應用程序平時始終處於低流量狀態，但忽然迎來了流量峯值，你們確定但願其可以在峯值結束且流量停止後將規模恢復至原有水平。若是沒有流量做爲參考，你們可使用INSUFFICIENT_DATA來替代ALARM做爲低流量閾值狀況下的規模縮減執行手段。

使用ELB運行狀態檢查取代EC2運行狀態檢查。

在建立擴展組時系統會提供這樣一個配置選項，你們可以指定是否使用標準的EC2檢查機制（當該實例接入網絡時），或者使用本身的ELB運行狀態檢查機制。ELB運行狀態檢查機制可以提供更出色的靈活性。若是你們的運行狀態檢查機制發生故障，那麼該實例將被移出負載均衡池，在這種狀況下你們固然但願可以經過自動伸縮停止該實例並建立新的實例加以替代。若是你們沒有利用ELB檢查設置出擴展組，那麼上述功能將沒法實現。AWS在說明文檔當中就添加運行狀態檢查機制做出了詳盡說明，感興趣的朋友能夠點擊此處進行查看。

只使用ELB預先配置的可用區。

若是你們將擴展組添加到多個可用區內，請確保本身的ELB配置可以正確使用所有可用區，不然在容量發生向上擴展時，負載均衡器將沒法正確識別出這些可用區。

不要在同一個組內使用多個擴展觸發器。

若是你們在同一個自動伸縮組內選擇了多種用於觸發規模調整的CloudWatch警報機制，那麼它們可能沒法如各位的預期那樣正常起效。舉例來講，假設你們添加的觸發器會在CPU使用率太高或者入站網絡流量強度過大時進行向上擴展，並在狀況相反時對規模進行縮減。但在使用過程當中，咱們每每會發現CPU使用率持續增長，但入站網絡流量卻保持不變。這時高CPU負載觸發器會進行容量擴展操做，但低入站流量警報卻會當即觸發規模縮減操做。根據各自執行週期的不一樣，兩者之間的做用極可能會被抵消，致使問題沒法獲得切實解決。所以，若是你們但願使用多種觸發器方案，請務必選擇多自動伸縮組的方式。

IAM

使用IAM角色。

不要面向應用程序建立用戶，而儘量使用IAM角色。它們可以簡化全部相關工做，並保證業務環境的安全水平。建立應用程序用戶只會帶來故障點（若是有人不當心刪除了API密鑰），並且令管理工做更加難以完成。

用戶能夠擁有多個API密鑰。

若是某些員工在同時處理多個項目，又或者你們但願可以利用一次性密鑰對某些內容進行測試，那麼這種方式將很是實用。咱們徹底沒必要擔憂真正的密鑰被泄露出去。

IAM用戶可使用多因素身份驗證，請善加利用！

啓用多因素驗證機制可以爲咱們的IAM用戶提供額外的安全層。咱們的主帳戶確定應該引入這項機制，面只要有可能、普通IAM用戶亦應當享受到由此帶來的保障。

Route53

使用ALIAS（即別名）記錄。

ALIAS記錄會將咱們的記錄組直接連接到特定AWS資源處（便可以將某個域映射至某個S3存儲桶），但其關鍵在於咱們用不着爲了ALIAS查找而支付費用。所以與CNAME這類付費機制不一樣，ALIAS記錄不會增長任何額外成本。另外，與CNAME不一樣，你們能夠在本身的區索引當中使用ALIAS。感興趣的朋友能夠 點擊此處查看AWS官方提供的ALIAS資源記錄集建立說明頁面。

彈性MapReduce

在S3中爲Hive結果指定一個目錄。

若是你們打算利用Hive將結果輸出至S3，則必須在存儲桶內爲其指定一個目錄——而非存儲桶根目錄。不然咱們極可能遭遇NullPointerException，並且徹底找不到引起這一問題的理由。