AWS 大當機事件的真正問題

前兩天 AWS 大當機，網路上哀嚎遍野，Canva、Airtable、Perplexity 都掛掉，有朋友跑來問我，你們家（91APP）還好嗎？

「還好耶。」「為什麼！」

身為 AWS 台灣的重度客戶，我們為什麼沒事呢？

其實就是一點實力，加上了一點運氣。（煙）

關鍵是「AWS 沒有真的掛掉」，至少 EC2、S3、Lambda 等所有的主幹服務，都活得好好的。

其實掛掉的是一個小東西叫做 DNS 解析，結果，竟然影響了 AWS 各服務找不到 IAM，無法拿到憑證，AWS 服務彼此之間就無法溝通，才造成連鎖骨牌效應，讓各家 based 在 AWS 上的應用服務倒站。

91APP 的核心主流程，也就是購物結帳流程，都跑在 EC2 上，完全沒有受到影響。因為 AWS 就...沒有掛掉，主服務全數都運作正常。

那為什麼很多服務平台，像是 Canva，都掛掉了？

真正的問題

簡單說，AWS 的各個服務之間要溝通，像是 EC2 跟 S3、Lambda 跟 DynamaDB 跟 S3、EventBridge 跟 Lambda 等等，都需要透過 IAM 來問授權。

所以 IAM 掛掉，EC2 就連不上 S3、Lambda 就 call 不到 DynamoDB，災情就來了，沒有 IAM，服務之間彼此不認識，服務也就沒辦法透過 STS 取得有效憑證，沒有憑證，彼此就不能連線，應用服務就無法正常運作，整個應用服務層當然就掛掉了。

但精確的說，也不用戶每使用一次用應用服務（像 Canva），底層的 AWS 的服務彼此都要去問一次 IAM，只有在起新 instance（新機器），也就是「冷啟動」的時候才需要。

也就是說，如果 instance 還在（沒有被回收），STS 憑證就都還在，AWS 服務彼此可以溝通，像 EC2 call 的到 S3，那一切就都運作正常（像 91APP 我們家的狀況）。

所以，那啟動新機器，或者說冷啟動，會這麼頻繁到影響整個服務嗎？

還真的會，尢其是 Serverless 的架構。

像是著名的 Serverless 三件套：Lambda、S3、DynamoDB，在高流量的網站平台下，幾乎無時不刻都有新的 instance 在冷啟動。

因為事實是，Serverless 不是真的沒有 Server，只是由 AWS 「更有效率」的管理 Server 資源，所以 AWS 為了節省資源，在 Container 的架構下，AWS 就會依據(他的)需要，來回收 (你的) Container ，依應用程式事件觸發時，AWS 再重新給資源，也就是冷啟動。

冷啟動就需要去問 IAM，然後像這次找不到 IAM，然後應用層就崩潰了。

Canva 大量用了 Serverless 的架構，然後更慘的是，依據 Canva 的設計，幾乎 S3 每上傳一次檔案的時候，譬如說...上傳圖檔的時候，就會觸發一次 Event Notification，然後冷啟動 Lambda。

上傳圖檔！這是什麼意思？意思就是像 Canva，作為一個知名設計軟體，全世界的用戶一定同時都在大量操作上傳圖片吧，然後你可以想像底層 AWS 就不停瘋狂冷啟動 instance，然後 instance 瘋狂去問 IAM，但 IAM 他...不見了，自然就...應聲倒地了。

單點問題

這麼說起來，IAM 是很關鍵的服務節點，難道 AWS 都沒有做任何對應準備嗎？

其實也不是沒有，嚴格地來說，IAM 是全球都有部署邊緣節點的，就是要防止他掛掉。而且憑證的請求頻率，說實在更高的需求是 STS。

拆開來說，AWS 服務彼此溝通要的憑證，是 STS 在管理，常態性憑證過期（像是每小時），都先去 STS 重新更新憑證就好了。

也就是說 IAM 是不發憑證的，IAM 只管理權限與角色的 Policy，發憑證是 STS 的事。所以 IAM 才可以做到極速回應，因為他只回應 Policy。

所以為了保護 STS，AWS 的 STS 是區域性分散的。也就是美西的 STS 掛掉，東京的 STS 是不被影響的，所以針對頻繁的憑證更新需求，我們自己都可以設計異地備援。

但 IAM 不一樣，IAM 是全球性的，也就是不管你在哪一區，美西、東京、新加坡，在 AWS 的世界裡，大家都去問 https:// iam .amazonaws .com 這個網址，當然背後，就設計成全球化的邊緣節點的部署，來穩住 IAM 這個服務。

結果，IAM 沒有掛掉，掛掉的是 DNS 解析，也就是 DNS 解析錯誤，再怎麼全球化邊緣節點也沒有用，大家找不到 IAM 門牌，找不到 https:// iam .amazonaws .com，就找不到 IAM，而不是真的 IAM 掛掉，IAM 明明活得好好的，

但結果一樣，就...全盤崩潰了，說實在的，跟掛掉是一樣的。

也沒料到是這麼鳥的問題，這個意外的單點問題，我想 AWS 接下來應該要好好解決的....對吧？

設計思維

所以，我們（91APP）為什麼沒事呢？

其實有一個原因是，我們的核心主流程，也就是客戶最關心的購物結帳流程，我們沒有用 Serverless 架構，而還是用「傳統的」 EC2 來處理。

也就是說，現代化最潮的架構設計 Serverless 架構，我們並沒有套用在核心主流程上。因為，在 Enterprise 等級的服務裡，關鍵的核心主流程的架構選擇，我們關心的是「穩」，而不是「潮」。

老服務自然穩，像 EC2 這個 AWS 出來就有的服務，經過多少大風大浪，雖然比較古板，但就是該踩得坑都踩過了，自然表現就很穩。

新服務很潮、效能可能真的更好、也的確更好維運，但「年輕人畢竟就是年輕人」，踩過的坑比較少，自然遇到災難性問題的機會就比較大。

所以我們都不用 Serverless 嗎？用啊，當然用，但用在新應用，那些非核心主流程的部分。

所以這次我們一點影響都沒有？有啊，怎麼沒有，像是我們 Marketing Cloud 裡面要做會員分群溝通設計就掛了，也就是有 30 分鐘不能...設計新的會員活動。但...真的還好吧。（行銷人員說可以下班了？反正... Canva 掛了）

但核心主流程，也就是消費者照樣逛網站，照樣結帳，對客戶來說，該收的錢繼續收，完全沒有影響。

對關鍵的核心流程來說，穩定比新潮還重要。

91APP 的準備

而且，我們買了很多 RI。

也就是雖然用 EC2，在流量波動大的時候，也是常常會有 instance 冷啟動的問題，AWS 還是會回收以及重給 instance 資源。

因為投資了 RI ，我們就大規模保留核心服務的 instance 長期運行，不讓 AWS 頻繁回收。而那些動態調整的 EC2 instance 就...「在事件發生的時候，趕快手動保留他，不讓他下線」（暫停 Auto scaling）。因為不讓 AWS 回收，就不會再遇到冷啟動問題，就不用再去問 IAM，我們就可以控有足夠的運算支援撐過這次事件。

「在事件發生的時候，趕快手動保留他，不讓他下線」這件事是大量事前的準備才做到的。

第一個問題就是：為什麼你們還登的進去 AWS 後台？

因為第一時間，IAM 找不到，自然 AWS 後台就完全進不去，進不去後台，工程師什麼都沒辦法做啊？

那我們為什麼進的去？因為...我們一直沒有登出。所以 Session 還在，可以操作後台，畢竟 AWS 所有主幹服務本來就沒有真的掛掉。

而背後功勞，都是歸因於我們的「即時監控機制」跟「人工排班機制」。

即時監控，意思就是第一時間我們就收到 AWS 的 IAM 異常了。（跳出 Slack）

人工排班，就是立刻有人看到警示，而且也代表，任何時刻都一定有人是登入在 AWS 的後台的，所以一定有一台電腦是登入 AWS 後台的狀態， Session 還在，就可以趕快去操作，保留 instance。

還有，這些動作能快速反應，也是因為我們每一年的「災害還原」演練都是玩真的，也就是我們自己演習，像是假設「東京出現哥吉拉」的狀況，哥吉拉毀滅的東京機房，我們演練在 10 分鐘以內，在新加坡起完所有站台，之類的演練。

演練玩真的，同仁遇到緊急狀況，就可以異常冷靜跟快速反應，正常發揮，來度過危機。

這就是最前面說的，屬於我們的實力跟運氣。