AWS Auto Scaling組是一個優秀的功能，該自動化系統負責管理服務器宕機并為用戶自動擴展服務。一個Auto Scaling組連接到彈性負載均衡，則會讓確保應用總是啟動并處于運行中這件事變得容易。

管理員可以指定一個亞馬遜Web服務(AWS)Auto Scaling組使用彈性負載均衡(ELB)健康檢查，這將確保該服務在服務器上是運行的–而不只是服務器本身是運行的。這可以快速和自動更換任何行為不正常的服務器，殺掉那些壞的服務器并用好的干凈的服務器取代它們。

使用ELB健康檢查，而不僅僅是彈性計算云(EC2)健康檢查是很重要的。我碰到過這樣的問題，服務器仍在運行，但服務器上的服務已經死掉并且無法重新啟動。該ELB會從服務器斷開，因為它已不再服務請求，但AWS Auto Scaling組并沒有替換它，因為服務器仍在運行。最終，所有服務器都有了同樣的問題，該服務停止工作。然后，我收到了一個來自Pingdom的警告，通知我說Web服務不工作。AWS Auto Scaling組一直認為所有的服務器都正常，沒有檢測出實際的Web服務已經死亡并且無法重啟。

最好對每一個生產服務使用Scaling組，即使他們并不需要真正的自動擴展。我的大部分AWS Auto Scaling組只是簡單的描述為，“保持X數量的服務器一直運行。”這意味著，如果出現一個問題然后其中一臺服務器宕掉，該服務器會被殺掉并自動替換。這并不意味著我需要根據負載自動增加服務器的數量。但那使得自動化一些簡單的DevOps任務如重新啟動一臺服務器變得更容易。

什么地方出錯了?

關于AWS EC2定價的一個需要小小討論的事實是，用戶按照每臺服務器運行任意部分小時來支付費用。這意味著，如果一個用戶啟動服務器，然后在五分鐘內殺死它，他仍然要為這完整的一小時買單。這似乎是可接受的，但是如果一個用戶殺掉一個服務器然后使用完全相同類型和位置的一個新的服務器來替換它，這個舉動會讓費用翻倍。

起初，我啟動了一個服務器，被收取一臺服務器的費用，五分鐘后殺掉該服務器，然后換成另一臺。但我被收取了2倍服務器運行的費用，直到第一臺服務器被啟動(圖1)之后達到一小時。當你將那種計費模式和AWS Auto Scaling組不斷殺死和重新啟動服務器的錯誤結合起來，成本就會不斷上漲。

　　Auto Scaling在五分鐘后殺死一個實例并啟動另一個。

在我的這個案例中，Auto Scaling組的配置有一個問題，一個服務器連續被殺死并在有問題的同一區域內被重新啟動。這意味著，每五分鐘，一個新的服務器啟動，舊的被取代，從而產生每小時12個實例小時的費用 - 即便在任何時間永遠都只有一個實例在運行。并且該實例甚至都沒有正常工作。

我一開始沒有注意到，直到收到之后的帳單列表，因為這個原因出現了一筆額外的1200美金的支出。這時，我聯系了AWS的支持人員。當我發現這個問題的時候我非常沮喪，但亞馬遜修復了它并給了我由于壞掉的Auto Scaling組導致的額外的信用度。 AWS還針對該問題進行了檢測，并給了我Auto Scaling組失控的2個月的信用度。

現在回想起來，我本應該設置Auto Scaling組的通知，我本應該驗證Auto Scaling的行為不可能每15分鐘超過一次。有了這些改變，最多只可能出現四倍的正常收費。這仍然是糟糕的，但卻沒有12倍那么糟糕。我本應該驗證所有地區的服務器都正常啟動了。

如何防止Auto Scaling故障

首先，訂閱Auto Scaling組通知 - 即使它只是使用一個電子郵件地址，因為使用尋呼可能有點極端。管理員還應該小心該組突然“暴走”。如果確實發生了一些什么狀況并且AWS Auto Scaling組不停的啟動和替代服務器，管理員則可以禁用一個可用區域或阻止該組執行任何操作。把“冷靜”時間增加到15分鐘也許是個不錯的主意，以防止類似的錯誤發生到完全失控。

最后，確保ELB在服務器啟動之后給予了足夠寬裕的時間來決定是否最終會正常啟動。如果該服務通常需要5分鐘才能啟動成功，那么給它15分鐘。如果開發人員檢查到他至少有2臺服務器跑在ELB后面，在新的服務器正在啟動時，運行的服務器必須能夠處理負載。

提供額外的能力總是一個不錯的主意，因為用戶可能需要在修復問題的時候停掉一些服務器。請記住，AWS Elastic Beanstalk內部使用的是Auto Scaling組，因此也可以訂閱對他們的通知，如果他們被設置好的話。