CloudFront 踩雷與反思

前情提要

我想 ClouFront 這個服務對開發過一段時間的 web 工程師或相關領域的 pm 等等應該都了解是什麼， 就不多說了。這次案發狀況主要是團隊在做直播時，發生大量的錯誤快取導致直播 segment 順序錯誤，播放器無法識別 playlist，直接 crash。還好不是什麼大流量的內容，不然會被電。

原因

因為團隊很早期就已經大量使用 CloudFront，因此 cache behavior 設定都停留在早期階段，至今都沒有 migrate 成新版本的 cache behavior。然而 AWS 也毫不客氣，直接就是把你的設定改名為 legacy setting，沒有一點要指引我們更新的意思。

然而這邊隱藏的意思其實跟以前已經不一樣了。以前可以選擇要 forward 的 query string。現在這邊只有說 cache key，容易讓人誤會。查了一下文件，發現還真的讓人誤會。

這邊意思是，只要我有 cache key，QueryString 這個 field 就會變成 true，然後就會強制 forward 全部的 query string，跟原本的理解完全不一樣啊！

雖然文件以及功能上都明確說明 deprecated, legacy，但介面真的還是蠻讓人誤會的。

改善

只能乖乖的使用 policies ！分為三種，相信應該很多人都有在使用了。我們團隊是只有最新的服務使用而已，90% 的主服務基本還是使用 legacy setting。

• Origin Request Policy: 這就是原本 allow list 的概念，他可以控制哪些 header, query string, cookie 要送到 origin。如果沒有寫，就會被濾除，對於這次事件，非常有效，因為前端會有固定的追蹤 query 帶到每個直播連結。因此針對特定 origin 不能快取的，就要用這個 policy 好好的定義，有寫的才會 forward 到 origin，沒寫的，即使前端 request 帶上去，也是忽略
• Cache Policy: 這就是跟 legacy setting 一樣意思，有定義出來的，會當作 cache key，沒有寫，就會忽略。跟 Origin Request Policy 分開就可以個別控制，有時候我想要 forward query string 到 origin，但是我並不想要當作 cache policy，這時候就非常實用了。
• Response Header Policy: 這個主要會用在 CORS 上，其實大部分 CORS 會加在 origin server，應該是針對某些無法客製化的服務加的，例如 MediaPackage, MediaTailor。此外還可以加上 server-timing 去檢查快取的 performance。

反思

這次案件我重新審視了團隊的 CloudFront 使用情況，除了剛剛提到，大比例的服務都是使用 legacy setting ，很擔心未來一個 deprecate，會需要花蠻多時間 migrate，這是第一個我認為需要慢慢調整的。

然後有不少服務都設成 TTL = 0，純粹是利用 CloudFront 的 cache behavior 來做 path 分流。好用是好用，不過是需要給點 donate 的。以廣告相關服務，我用 aws calculator 粗算，每個月可以省下約 800 USD，說多是也不多，但是如果全部服務統整，一個月我相信可以省下一大筆錢，以一年來看，應該蠻可觀的。畢竟都沒有使用到 cache，可能可以想想改成用 proxy 服務會不會比較好。

AWS 很雷

每個帳號，policy 上限是 20 個..，並且沒有 quota increate 選項。目前看起來是 hard limit。針對每個服務都客製化的 cache policy 來說，蠻有可能達到上限的。例如我們的服務，假如 legacy setting 全部轉移到 policy，我覺得 cache key 的分類就可能超過 20 種了…希望未來能開放調整這個上限。