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

[[139769]]

從物理服務器向“云環(huán)境”轉移的過程不僅僅是一項技術任務，同時也意味著我們的思維方式需要作出針對性的轉變?？傮w而言，在物理環(huán)境下我們需要關注的只是每一臺獨立主機; 它們各自擁有自己的靜態(tài)IP，我們能夠對其分別加以監(jiān)控。而一旦其中一臺發(fā)生故障，我們必須盡最大可能讓其快速恢復運轉。大家可以以為只要將基礎設施轉移到AWS環(huán)境之下，就能直接享受到“云”技術帶來的種種收益了。遺憾的是，事情可沒那么簡單(相信我，我親身嘗試過了)。在AWS環(huán)境之下，我們必須轉變思維，而且這方面的任務往往不像技術難題那么容易被察覺。因此，受到了SehropeSarkuni最近一篇帖子的啟發(fā)，我將自己幾年來積累得出的AWS 使用心得匯總于此，而且說實話、我真希望自己當初剛剛接觸AWS時能有人告訴我這些寶貴經(jīng)驗。這些心得總結自我在AWS之上部署個人及工作應用程序時的親身感受，其中一部分屬于需要高度關注的“疑難雜癥”(我自己就是直接受害者)，而另一部分則是我聽其他朋友說起過、并隨后親自確認有效的解決方案。不過總體而言，為了積累這些經(jīng)驗，我確實付出了相當慘痛的代價：)

應用程序開發(fā)

千萬不要把應用程序狀態(tài)保存在自己的服務器上。

之所以這么說，是因為一旦我們的服務器發(fā)生故障，那么應用程序狀態(tài)很可能也隨之徹底消失。有鑒于此，會話應當被存儲在一套數(shù)據(jù)庫(或者其它某些集中式存儲體系、memcached或者redis當中)而非本地文件系統(tǒng)內。日志信息應當通過系統(tǒng)日志(或者其它類似方案)進行處理，并被發(fā)送至遠程位置加以保存。上傳內容應當直接指向S3(舉例來說，不要將其存儲在本地文件系統(tǒng)內，并通過其它流程隨后遷移到S3)。再有，任何已經(jīng)處理過或者需要長期運行的任務都應該通過異步隊列(SQS非常適合處理此類任務)來實現(xiàn)。

編輯點評:對于S3上傳內容而言，HN用戶Krallin指出，我們可以徹底避免其與自有服務器的接觸，并利用預簽名URL保證用戶的上傳數(shù)據(jù)被直接發(fā)送至S3當中。

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

日志記錄通常包含有時間戳以及pid等信息。大家也可能希望將實例id、服務區(qū)域、可用區(qū)以及環(huán)境(例如分步環(huán)境或者生產環(huán)境等)添加進來，而這些都能在日后的調試工作中作為參考。大家可以從instance metadata service當中獲取到這些信息。我所采用的方法是將這些信息作為引導腳本的組成部分，并將其以文件形式存儲在文件系統(tǒng)當中(例如/env/az或者 /env/region等)。這樣一來，我就用不著持續(xù)查詢元數(shù)據(jù)服務來獲取這些信息了。大家應當確保這些信息能夠在實例重新啟動時得到正確更新，畢竟我們都不希望在保存AMI時發(fā)現(xiàn)其中的數(shù)據(jù)還跟上次完全一樣，這肯定屬于非正常狀況。

如果我們需要與AWS進行交互，請在當前語言中使用對應SDK。

千萬不要試圖自己動手。我當初就犯過這個錯誤，因為我認為自己只是單純需要向S3上傳內容，但隨著后續(xù)服務的持續(xù)增加、我發(fā)現(xiàn)自己的決定簡直愚蠢至極。AWS SDK的編寫質量很高，能夠自動處理驗證、處理重試邏輯，而且由Amazon官方負責維護與迭代。此外，如果大家使用EC2 IAM角色(大家絕對應該這么做，這一點我們后面會進一步提到)，那么該SDK將幫助我們自動獲取到正確的證書。

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

大家應當采用管理員工具、系統(tǒng)日志查看器或者其它方案，從而幫助自己在無需在運行中實例內使用SSH的方式查看當前實時日志信息。如果大家擁有集中式日志記錄系統(tǒng)(我強烈建議大家使用此類系統(tǒng))，那么當然希望能在不使用SSH的情況下完成日志內容查看任務。很明顯，將SSH引入正處于運行狀態(tài)的應用程序實例會引發(fā)諸多弊端。

#p#

運營心得

如果將SSH引入自己的服務器，那么自動化機制恐怕將無法生效。

在全部服務器上禁用SSH訪問。

這聽起來確實有點瘋狂，我知道，但在大家的安全組當中、請務必確保端口22不向任何人開放。如果各位想從今天的文章中獲得什么啟示，那請千萬牢記以下一點：如果將SSH引入自己的服務器，那么自動化機制恐怕將無法生效。從防火墻級別(而非服務器本身)禁用SSH有助于整套框架實現(xiàn)思維轉變，因為這樣一來我們就能了解到哪些區(qū)域需要進行自動化改造，同時大家也能更輕松地恢復訪問來解決當前面臨的問題。在意識到再也不必將SSH引入實例之后，大家肯定會像我一樣感到渾身輕松。沒錯，這是我在實踐中了解到的最驚世駭俗、但也卻具實用性的心得。

編輯點評:很多人對這項心得表現(xiàn)出了高度關注(HackerNews網(wǎng)站上還出現(xiàn)了不少值得一讀的評論意見)，因此我們要在這里多說幾句。我個人也會通過禁用入站SSH來蒙騙自動化機制(哦，我只是SSH一下來修復某個問題，馬上就撤)。當然，如果我需要在某個實例中進行主動調試，那么我仍然可以在安全組中將其重新啟用，因為有時候我們確實沒有其它辦法來調試特定問題。另外，具體情況還取決于我們實際使用的應用程序類型：如果大家應用程序的正常運行要求各位能力通過SSH將信息傳遞至服務器，那么將其禁用肯定不是什么好主意。這種阻斷進站SSH的辦法確實適合我，也迫使我對自己的自動化機制加以精心打理，不過必須承認、這種方式并不適合每一位用戶。

服務器只是暫時性手段，沒必要太過關注。我們要關注的僅僅是服務本身。

如果某臺服務器出現(xiàn)了故障，大家完全沒必要對其太過關注。這是我在利用AWS來替代物理服務器之后，親身獲得的最直接的便利成效。一般來講，如果一臺物理服務器無法正常工作，技術人員總會暫時陷入恐慌。但在AWS當中，大家就完全不必擔心了，因為自動伸縮機制會很快幫我們建立起新的實例。 Netflix公司在此基礎之上還跨出了更具前瞻意義的步伐，他們組建了Simian Army團隊，并嘗試Chaos Monkey等極為激進的測試項目——它會隨機關閉生產環(huán)境下的某些實例(他們還利用Chaos Gorilla項目隨機關閉可用區(qū)。我甚至得到消息，說是Chaos Kong項目會直接關閉基礎設施大區(qū)……)?？偠灾蚁氡磉_的意思是：服務器總會發(fā)生故障，但這不該影響到我們的應用程序。

不要為服務器提供靜態(tài)/彈性IP。

對于一款典型的Web應用程序，大家應當將一切部署在負載均衡機制之下，并在不同可用區(qū)之間對資源使用情況加以平衡。雖然我也遇到過一些需要使用彈性IP機制的情況，但為了盡可能提高自動伸縮效果，大家還是應該利用負載均衡機制取代在每個實例中使用獨有IP的作法。

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

不只是AWS，自動化機制應該作為整體運營工作中的通用性指導方針，其中包括恢復、部署以及故障轉移等等。軟件包與操作系統(tǒng)更新都應該由自動化方案所管理，具體可表現(xiàn)為bash腳本或者Chef/Puppet等。我們不該把主要精力放在這些瑣碎的雜事上。正如前文中所提到，大家還需要確保禁用SSH 訪問，從而快速了解到自己的執(zhí)行流程中還有哪些方面沒有實現(xiàn)自動化改造。請記住前面提到的重要原則：如果將SSH引入自己的服務器，那么自動化機制恐怕將無法生效。

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

通常情況下，我們會為服務設置一個“運營賬戶”，而整個運營團隊都將共享登錄密碼。但在AWS當中，大家當然不希望遵循同樣的處理方式。每位員工都要擁有一個IAM賬戶，其中提供與其需求相符的操作權限(也就是最低權限)。IAM用戶已經(jīng)可以控制基礎設施中的一切。截至本文撰寫時，IAM用戶惟一無法訪問的就是計費頁面中的部分內容。

如果大家希望進一步保護自己的賬戶，請確保為每位員工啟用多因素驗證機制(大家可以使用谷歌Authenticator)。我聽說有些用戶會將MFA令牌交付給兩名員工，并將密碼內容交付給另外兩名員工，這樣主賬戶在執(zhí)行任意操作時、都至少需要兩名員工的同意。對我來說這種作法有點小題大做，但也許您所在的企業(yè)確實需要如此高強度的控制機制。

我最后一次從CloudWatch收到操作警告大約是在一年之前……

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

如果大家已經(jīng)將一切步驟正確部署到位，那么運行狀態(tài)檢查機制應該會自動清除故障實例并生成新的實例。在收到CloudWatch警告信息時，我們一般不需要采取任何行動，因為所有應對措施都能以自動化方式實現(xiàn)。如果大家得到警告稱相關問題需要手動干預，那么請做好事后檢查、看看能不能找到一種可以在未來通過自動化方式將其解決的途徑。我最后一次從CloudWatch收到操作警告大約是在一年之前，而且對于任何一位運營人員來說、能夠不再被警告消息打擾了清夢都應該算是天大的好消息。

計費機制

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

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

#p#

安全性保障

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

如果大家在應用程序當中內置有AWS證書，那么肯定屬于“處理失當”的狀況了。前面之所以強調在開發(fā)語言中使用AWS SDK，最重要的理由之一就是我們能夠輕松借此使用EC2 IAM角色。角色的設計思路在于，允許大家為特定角色指定其所必需的恰當權限，而后將該角色分配至對應EC2實例當中。而無論我們何時將AWS SDK應用至實例當中，都不必再指定任何驗證憑證。相反，該SDK將回收我們在設置當中為該角色指定權限所使用的任何臨時性證書。整個流程都會以透明化方式處理，非常安全而且極具實用性。

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

管理用戶往往是件令人頭痛的事情，特別是在使用Active Directory或者其它一些已經(jīng)與IAM相整合的外部驗證機制時，而且這類作法的實際效果也不夠理想(當然也有效果不錯的情況)。不過我發(fā)現(xiàn)更輕松的辦法，即只將權限分配至組而非個別用戶，這將大大降低權限的管理難度。很明顯，相較于面向每位獨立用戶來查看為其分配的權限，以組為單位進行權限交付能夠幫助我們更好地把握系統(tǒng)整體概況。

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

在日常工作中，很重要的一點是追蹤基礎設施內安全設置的各項變更。實現(xiàn)這一目標的辦法之一在于首先建立起一套安全審計角色(即JSON模板)。這一角色會對賬戶之內與安全相關的各類設置進行只讀訪問。在此之后，大家就可以利用這一類似于Python腳本的方案達到目標了，它將能夠對賬戶中的所有條目進行審查并生成一整套與配置相關的規(guī)范比對結果。我們可以設置一個cronjob來運行該腳本，并將輸出結果與上一次的結果相比較。其中的差異之處就代表著我們安全配置方案當中所出現(xiàn)的變化。這種方式非常實用，而且能夠通過電子郵件將變更信息通知給大家。

使用CloudTrail來記錄審計日志。

CloudTrail通過通過API或者S3存儲桶內的Web控制臺記錄所有執(zhí)行過的操作活動。利用版本控制機制設置存儲桶可以確保任何人都無法修改這些日志內容，而我們自己則可以隨后對賬戶內的全部變更進行徹底審計。我們當然不希望遇到需要審計日志內容的狀況，但正所謂有備無患，準備好這么一套方案還是很有必要的。

S3

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

如果大家希望在SSL之上使用自己的存儲桶，那么使用“.”作為名稱的組成部分將導致證書不匹配錯誤。一旦存儲桶創(chuàng)建完成，我們將無法再對其名稱進行更改，所以大家只能將一切復制到新的存儲桶當中。

我發(fā)現(xiàn)文件系統(tǒng)就像大型政府部門一樣“可靠”。

避免載入文件系統(tǒng)(例如FUSE)。

我發(fā)現(xiàn)在被用于關鍵性應用程序時，這些文件系統(tǒng)就像大型政府部門那樣“可靠”?？傊?，使用SDK作為替代方案更加明智。

我們用不著在S3之前使用CloudFront(但這樣確實能夠起到助益)。

編輯評論:根據(jù)Hacker News網(wǎng)站用戶的最佳反饋內容，我們對這條心得作出了部分修改。

如果大家對于可擴展能力比較看重，那么最好是將用戶直接引導至S3 URL而非使用CloudFront。S3能夠實現(xiàn)任意水平的容量擴展(雖然一部分用戶報告稱其無法實現(xiàn)實時規(guī)模擴展)，因此這也是充分發(fā)揮這一優(yōu)勢的最佳思路。除此之外，更新內容在S3中的起效速度也夠快，雖然我們仍然需要在使用CDN查看變更時等等TTL的響應(不過我相信大家現(xiàn)在已經(jīng)能夠在 CloudFront中獲得0延遲TTL，所以這一點也許存在爭議)。

如果大家需要良好的速度表現(xiàn)，或者需要處理對傳輸帶寬要求極高的數(shù)據(jù)(例如超過10TB)，那么大家可能更希望使用像CloudFront這樣的CDN方案與S3相配合。CloudFront能夠極大提升全球各地用戶的訪問速度，因為它會將相關內容復制到各邊緣位置。根據(jù)實際用例的不同，大家可以通過較低數(shù)量的請求實現(xiàn)高傳輸帶寬(10TB以上)，并借此降低使用成本——這是因為相較于S3傳輸帶寬，當傳輸總量高于10TB時CloudFront的傳輸成本每GB比其低0.010美元。不過CloudFront的單次請求成本較直接訪問S3中的文件卻要略高一點。根據(jù)具體使用模式，傳輸帶寬的成本節(jié)約額度也許會超過單一請求所帶來的額外成本。因為在直接訪問S3存儲內容時，我們只需以較低頻度從S3獲取數(shù)據(jù)(遠較正常使用情況更低)，所以成本也就更加低廉。AWS官方提供的CloudFront說明文檔解釋了如何將其與S3配合使用，感興趣的朋友可以點擊此處查看細節(jié)信息。

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

這初看起來似乎有點難以理解，不過S3所采取的一大實現(xiàn)細節(jié)在于，Amazon會利用對象密鑰來檢測某個文件到底保存在S3中的哪個物理位置。因此如果多個文件使用同樣的前綴，那么它們最終很可能會被保存在同一塊磁盤當中。通過設置隨機性密鑰前綴，我們能夠更好地確保自己的對象文件被分散在各個位置，從而進一步提升安全性。

#p#

EC2/VPC

別忘了使用標簽!

幾乎每項服務都提供標簽功能，別忘了善加利用!它們非常適用于進行內容歸類，從而大大簡化后續(xù)出現(xiàn)的搜索與分組工作。大家也可以利用這些標簽在自己的實例中觸發(fā)特定行為，例如env-debug標簽可以確保應用程序在部署之后進入調試模式。

我遇到過這類問題，感覺很不好，大家千萬不要重蹈覆轍!

在非自動伸縮實例中使用中止保護。以后你會感激我的建議的，絕對。

如果大家擁有某些不具備自動伸縮機制的一次性實例，則應當盡可能同時使用中止保護，從而避免某些人無意中將這些實例給刪除掉。我就遇到過這類問題，感覺很不好，大家千萬不要重蹈覆轍。

使用VPC。

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

如果大家對于VPC抱有興趣，我強烈建議各位觀看《百萬數(shù)據(jù)包的一日之期》這段資料。

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

保留實例的本質就是將一部分資金節(jié)約下來，從而使其保持較低的資源耗費速率。事實證明，保留實例相較于按需實例能夠幫助我們省下大量經(jīng)費。因此，如果大家意識到只需要繼續(xù)保持某個實例運行一到三年，那么保留實例功能將是各位的最佳選擇。保留實例屬于AWS當中的一類純邏輯概念，大家用不著將某個實例指定為需保留對象。我們要做的就是設定好保留實例的類型與大小，接下來任何符合這一標準的實例都將處于低速運轉加低成本支出的運行模式之下。

鎖定安全組。

如果有可能，千萬不要使用0.0.0.0/0，確保使用特定規(guī)則來限制用戶對實例的訪問。舉例來說，如果大家的實例處于ELB之后，各位應該將安全組設定為只允許接受來自ELB的流量，而非來自0.0.0.0/0的流量。大家可以通過將“amazon-elb/amazon-elb-sg”寫入 CIDR的方式實現(xiàn)這一目標(它會自動幫大家完成其余的工作)。如果大家需要為一部分來自其它實例的訪問請求向特定端口放行，也不要使用它們的對應IP，而最好利用其安全組標識符來替代(只需要輸入‘sg-’，其它的部分將自動完成)。

不要保留無關的彈性IP。

我們所創(chuàng)建的任意彈性IP都會成為計費項目，無論其與實例是否相關，因此請確保在使用過后將其及時清理掉。

ELB

在負載均衡器上中止SSL。

大家需要將自己的SSL證書信息添加到ELB當中，但在服務器上中止SSL能夠消除由此帶來的常規(guī)資源消耗，從而提高運行速度。除此之外，如果大家需要上傳自己的SSL證書，則可以經(jīng)由HTTPS流量實現(xiàn)、而負載均衡器會為我們的請求添加額外的標頭(例如x-forwarded-for等)，這有助于我們了解最終用戶究竟是何許人也。相比之下，如果我們經(jīng)由TCP流量實現(xiàn)，那么這些標頭將不會被添加進來、相關信息自然也就無從獲取。

如果打算執(zhí)行高強度流量，請對ELB進行預熱。

對于ELB來說，容量擴展是需要一段時間周期才能完成的。如果大家意識到自己將會迎來流量峰值(例如銷售門票或者召開大型活動等)，則需要提前對 ELB進行預熱。我們可以主動增加流量規(guī)模，這樣ELB就會提前進行容量添加，從而避免實際流量來臨時發(fā)生卡頓。不過AWS建議大家最好是與服務人員取得聯(lián)系，而非自行對負載均衡器進行預熱。或者，大家也可以在EC2實例當中安裝自己熟悉的負載均衡軟件并加以使用(例如HAProxy等)。

ElastiCache

使用配置端點而非獨立節(jié)點端點。

通常情況下，大家需要讓應用程序識別出各可用Memcached節(jié)點的存在。但如果大家希望以動態(tài)方式實現(xiàn)容量擴展，那么這種作法可能會帶來新的問題，因為我們將需要采取多種方式才能保證應用程序識別到容量的變化。比較簡便的解決方案在于使用配置端點，這意味著使用Memcached庫的AWS版本來對新節(jié)點自動發(fā)現(xiàn)機制加以抽象并剝離。AWS使用指南中提供了更多與緩存節(jié)點自動發(fā)現(xiàn)議題相關的解答，感興趣的朋友可以點擊此處查看細節(jié)信息。

RDS

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

如果大家正在使用多可用區(qū)方案，那么這可能是一種被各位所忽略、但在相關需求出現(xiàn)時卻又悔之晚矣的重要解決方案。

CloudWatch

使用CLI工具。

要利用Web控制臺創(chuàng)建警報機制，我們可能需要面臨大量繁的工作，特別是在設置眾多內容類似的警報信息時，因為我們無法直接“克隆”現(xiàn)有警報并僅對其中一小部分作出修改。在這種情況下，利用CLI工具實現(xiàn)腳本化效果能夠幫助各位節(jié)約大量寶貴時間。

使用免費監(jiān)測指標。

CloudWatch監(jiān)控工具以免費方式提供各類監(jiān)測指標(包括傳輸帶寬、CPU使用率等等)，而且用戶能夠獲取到最多兩周的歷史數(shù)據(jù)。有鑒于此，我們根本用不著花錢購置自己的工具來實現(xiàn)系統(tǒng)監(jiān)控。但如果大家需要超過兩周的歷史數(shù)據(jù)記錄，那沒辦法，只能使用第三方或者自行開發(fā)的監(jiān)控方案了。

使用自定義監(jiān)測指標。

如果大家希望監(jiān)控免費指標之外的其它項目，則可以將自己的定制指標信息發(fā)送至CloudWatch，并使用相關警報與圖形功能。這不僅可以用于追蹤諸如磁盤空間使用量等狀況，同時也可以根據(jù)實際需求自行設定應用程序監(jiān)測方向。感興趣的朋友可以點擊此處查看AWS提供的發(fā)布自定義監(jiān)測指標頁面。

使用詳細監(jiān)測機制。

這項服務每月每實例的使用成本約為3.5美元，但其提供的豐富額外信息絕對能夠值回票價。1分鐘的細化監(jiān)測甚至好過5分鐘的粗放查看。大家可以借此了解到某次時長5分鐘的崩潰到底是因何而起，同時以非常明確的方式將其以1分鐘圖表的方式顯示出來。也許這項功能并不適用于每閏用戶，但就我個人而言、它確保幫我弄清了不少原本神秘的疑難雜癥。

#p#

自動伸縮

利用INSUFFICIENT_DATA以及ALARM進行規(guī)?？s減。

對于規(guī)模縮減操作而言，大家需要確保能夠在不具備指標數(shù)據(jù)甚至觸發(fā)機制本身出現(xiàn)問題時仍能正常實現(xiàn)規(guī)模縮減。舉例來說，如果大家的某款應用程序平時始終處于低流量狀態(tài)，但突然迎來了流量峰值，大家肯定希望其能夠在峰值結束且流量中止后將規(guī)模恢復至原有水平。如果沒有流量作為參考，大家可以使用 INSUFFICIENT_DATA來替代ALARM作為低流量閾值情況下的規(guī)模縮減執(zhí)行手段。

使用ELB運行狀態(tài)檢查取代EC2運行狀態(tài)檢查。

在創(chuàng)建擴展組時系統(tǒng)會提供這樣一個配置選項，大家能夠指定是否使用標準的EC2檢查機制(當該實例接入網(wǎng)絡時)，或者使用自己的ELB運行狀態(tài)檢查機制。ELB運行狀態(tài)檢查機制能夠提供更出色的靈活性。如果大家的運行狀態(tài)檢查機制發(fā)生故障，那么該實例將被移出負載均衡池，在這種情況下大家當然希望能夠通過自動伸縮中止該實例并創(chuàng)建新的實例加以替代。如果大家沒有利用ELB檢查設置出擴展組，那么上述功能將無法實現(xiàn)。AWS在說明文檔當中就添加運行狀態(tài)檢查機制作出了詳盡說明，感興趣的朋友可以點擊此處進行查看。

只使用ELB預先配置的可用區(qū)。

如果大家將擴展組添加到多個可用區(qū)內，請確保自己的ELB配置能夠正確使用全部可用區(qū)，否則在容量發(fā)生向上擴展時，負載均衡器將無法正確識別出這些可用區(qū)。

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

如果大家在同一個自動伸縮組內選擇了多種用于觸發(fā)規(guī)模調整的CloudWatch警報機制，那么它們可能無法如各位的預期那樣正常起效。舉例來說，假設大家添加的觸發(fā)器會在CPU使用率過高或者入站網(wǎng)絡流量強度過大時進行向上擴展，并在情況相反時對規(guī)模進行縮減。但在使用過程中，我們往往會發(fā)現(xiàn) CPU使用率持續(xù)增加，但入站網(wǎng)絡流量卻保持不變。這時高CPU負載觸發(fā)器會進行容量擴展操作，但低入站流量警報卻會立即觸發(fā)規(guī)?？s減操作。根據(jù)各自執(zhí)行周期的不同，二者之間的作用很可能會被抵消，導致問題無法得到切實解決。因此，如果大家希望使用多種觸發(fā)器方案，請務必選擇多自動伸縮組的方式。

IAM

使用IAM角色。

不要面向應用程序創(chuàng)建用戶，而盡可能使用IAM角色。它們能夠簡化所有相關工作，并保證業(yè)務環(huán)境的安全水平。創(chuàng)建應用程序用戶只會帶來故障點(如果有人不小心刪除了API密鑰)，而且令管理工作更加難以完成。

用戶可以擁有多個API密鑰。

如果某些員工在同時處理多個項目，又或者大家希望能夠利用一次性密鑰對某些內容進行測試，那么這種方式將非常實用。我們完全不必擔心真正的密鑰被泄露出去。

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

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

Route53

使用ALIAS(即別名)記錄。

ALIAS記錄會將我們的記錄組直接鏈接到特定AWS資源處(即可以將某個域映射至某個S3存儲桶)，但其關鍵在于我們用不著為了ALIAS查找而支付費用。因此與CNAME這類付費機制不同，ALIAS記錄不會增加任何額外成本。另外，與CNAME不同，大家可以在自己的區(qū)索引當中使用ALIAS。感興趣的朋友可以點擊此處查看AWS官方提供的ALIAS資源記錄集創(chuàng)建說明頁面。

彈性MapReduce

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

如果大家打算利用Hive將結果輸出至S3，則必須在存儲桶內為其指定一個目錄——而非存儲桶根目錄。否則我們很可能遭遇NullPointerException，而且完全找不到引發(fā)這一問題的理由。