是的，進入第 30 天了(含淚)。
沒有任何存檔的情況下，每天都拋下女兒&老婆跟時鐘賽跑，努力在 00:00 前送出文章，然後人腦斷電昏睡。
這感覺很微妙，經驗也很特別，應該很難忘記。

寫些關於 CloudFront 的雜想

用了多年 CloudFront，有些想法想跟還沒接觸過的人分享。

使用 CloudFront 可以帶來什麼好處

我認為使用 CloudFront 時，有一些好處，其中包含:

• 節省費用，CloudFront 的 DataTransfer Out，如果量夠大，是可以議價的。

2023年的現在，這個夠大約是每個月 10TB的量級。

• 隱藏了你實際的 Server 所在，多一層提高了調度的彈性。
• 除了調度外，也增加了程式運算的彈性(Lambda@Edge, CloudFront Fucntions)
• 極高的吞吐能力，只要請求到的內容是已經緩存在 CloudFront且可用的，就可以大幅下降對 Origin 的需求，而 CloudFront 的容量也相當的高(至少至少有 150Gbps & 250,000 rps，這對目前地端 Server 來說，是很難達成的量)。而在 Cache Behavior 設定正確的情況下，Origin 需要承擔的擴展(垂直/水平)需求也不會隨著請求數量直線上升。
• 比起許多分散式 Origin 的日誌，CloudFront 內建集中了日誌的產出，且可以方便的透過不同方式分析。(還包含許多能幫上忙的 CW metrics + Console Report)

即便規模如 AWS CloudFront，也有相對較無力的部分

紅樓夢裡的王熙鳳說過「大有大的難處」，即便這麼多人用的服務，也有他相對不是那麼能處理的部分。

• 比方說，提供服務給中國客戶使用。
  中國大陸是一個微妙的環境，有獨立的一套 CloudFront 環境。所以你在 AWS 設置的 CloudFront 很可能無法讓來自大陸的 User 使用(比方遇到 DNS 污染、偉大的長城/防火牆)，這是一種你努力很久也可能克服不了的經驗(CloudFront 也是，不然不需要獨立提供一套)。
• 如果你也在中國大陸申請了 CloudFront 服務，也有些功能跟一般 CloudFront 不太一樣，比方說沒法提供 Lambda@edge。

技能的成長

說回到對個人的影響，如果你是負責 CloudFront 的使用、設定、甚至問題排查的人，那麼我要恭喜你。

• CloudFront 位於 Client & 你的 HTTP Server 之間，居中的位置讓你在排查問題時可能需要從頭到尾都去瞭解服務。
  這邊我要引用一位大神曾經分享過的話，大意如下:

服務發生問題後，透過問題獲得最多成長的，是去認真調查問題後寫報告的人。

比方說，為了排查是否是 CloudFront 產生的問題，你得先瞭解相關的架構為何，比方說架構可能是:
APP --> CloudFront --> ALB --> EC2 --> MySQL
為了查問題，你可能會需要做這些事:

• 錯誤發生的地方在哪一段，
• 確認進出某一段時，請求/回應的內容是否有被改變 & 被如何改變。
• 各節點/區段需要的資訊是什麼
• 甚至，將調查範圍擴大，前後不同請求之間的順序是否合理，以及是否有影響?

在這些過程中，你會一次一次對於使用環境中的細節項目進一步瞭解，K 文件、看資料、甚至 tracing 相關程式碼，進一步瞭解一些以往以為理所當然的東西，接著在不知不覺中進步。

期許

下方圖片來自我很喜歡的「影視颶風」的 slogan - 「無限進步」

期許後續仍會有可以跟您分享/討論的資訊，我們一起無限進步。

後記:
9月份帳單來了， 19塊美刀，嗚嗚嗚。文章寫完先來砍資源。

Greetings from Amazon Web Services,

This e-mail confirms that your latest billing statement, for the account ending in ****7885, is available on the AWS web site. Your account will be charged the following:

Total: $19.08