在今天的文章中，我整理出了大量當初曾經錯過、而至今仍將我追悔莫及的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，而且完全找不到引發這一問題的理由。