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

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

應(yīng)用程序開發(fā)

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

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

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

將額外信息保存在日志當(dāng)中。

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

如果我們需要與AWS進(jìn)行交互，請在當(dāng)前語言中使用對應(yīng)SDK。

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

利用工具查看應(yīng)用程序日志。

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

運營心得

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

在全部服務(wù)器上禁用SSH訪問。

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

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

服務(wù)器只是暫時性手段，沒必要太過關(guān)注。我們要關(guān)注的僅僅是服務(wù)本身。

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

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

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

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

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

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

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

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

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

將警告信息轉(zhuǎn)化為通知內(nèi)容。

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

計費機制

建立起細(xì)化計費警告機制。

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

安全性保障

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

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

將權(quán)限分配至組，而非用戶。

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

設(shè)置自動化安全審計機制。

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

使用CloudTrail來記錄審計日志。

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

S3

在存儲桶內(nèi)的SSL名稱中使用“-”而非“.”。

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

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

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

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

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

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

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

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

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

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

EC2/VPC

別忘了使用標(biāo)簽!

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

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

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

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

使用VPC。

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

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

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

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

鎖定安全組。

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

不要保留無關(guān)的彈性IP。

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

ELB

在負(fù)載均衡器上中止SSL。

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

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

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

ElastiCache

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

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

RDS

為故障轉(zhuǎn)移設(shè)置事件訂閱機制。

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

CloudWatch

使用CLI工具。

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

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

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

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

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

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

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

自動伸縮

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

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

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

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

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

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

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

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

IAM

使用IAM角色。

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

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

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

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

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

Route53

使用ALIAS(即別名)記錄。

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

彈性MapReduce

在S3中為Hive結(jié)果指定一個目錄。

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