AWS CloudFront 出了免費版，超量不收費，還送 5GB 的 S3 儲存額度?

有時候我們以為自己把運作架構規劃得很輕巧，沒有 over design，也沒有為了技術而技術。

結果來幾次雲端服務大當機，就讓整串服務像骨牌一樣倒下來，連 OpenAI, Canva, Spotify 那種有完整工程團隊的大公司，也會因為雲端基礎設施故障而受影響使用者。

上游雲端供應商的一個小小功能故障，到了基層開發者佈署的末端服務，實際上連通知、排程、人機驗證這些寫在報價單上也不會有人看的項目，都能在關鍵時刻卡死整個功能。

2025 年有幾次雲端服務大當機，分享一下心得，還有 AWS 的 CloudFront 免費新方案的葫蘆在賣什麼藥。

躲過今年的 GCP 跟 AWS 大當機

GCP在2025年6月12號大當機，差不多是台灣時間6/13半夜一點多，晚上睡前看到 GCP Status Page 的服務中斷清單越拉越長，一堆世界知名的網站跟線上服務都出現故障，Cloudflare 的部分服務也跟著受影響。

這個部落格主程式是放在 GCP 的 us-west1 區域，當下都還能正常瀏覽，彷彿什麼事都沒發生。
我有兩個選擇，一個是趕快切換到備援方案，然後在社群網站上大吹特吹，然後社群貼文底下留言開放拍馬屁。不然 GCP 系統很快就修好了，讓我像個傻瓜一樣白忙一場。
但我選擇直接洗洗睡了。

後來看官方的事故報告，慶幸那時候什麼都沒動，因為故障的是整個雲端系統授權與配額查詢的部分，萬一把服務重啟，或是想要啟動其他區域的服務，應該都會操作失敗。

接著AWS在2025年10月19號大當機，又一堆世界知名的網站跟線上服務都出現故障，當天晚上我接著奏樂接著舞，秘訣就是沒有什麼東西放在那個區域，剛好逃過一劫。

Cloudflare 也大當機

結果隔一個月後，2025年11月18號換成 Cloudflare 也大當機，一些工程師群組起初還謠傳 Cloudflare 被攻擊到掛了，結果等到官方報告出來，只是一些程式小錯誤。

Cloudflare Global Network experiencing issues

這次沒有人是局外人，連我自己也受影響了。

• 有個網站要移機，白天先把東西複製在新環境，翻 GA 報表看哪時候人比較少，翻農民曆，等晚上比較沒人的時候偷改 DNS 切過去，結果台灣時間晚上剛好碰到 Cloudflare 當機，變更 DNS 的網頁介面打不開。
• 部分監測/發通知/跑排程的工具在 Cloudflare Workers 上面跑，也出現不穩定的情況，程式流程中間有用到那些服務的，也就無法正常運作。
• 人機驗證 Turnstile 掛掉，不管是進站前用 Managed Challenge (例如ChatGPT也有用)，還是送出資料前掛一個 verify you are human 的檢查，都有發生異常，讓使用者卡住。
• 少數線上系統有把 CDN proxied 打開，例如用 Cloudflare 的 WAF 功能做基本防禦，像是阻擋 AI 爬蟲偷幹資料、國外 IP 禁止使用線上系統、幫 API 程式做 rate limiting，或是有些網站要申請 SSL 憑證非常麻煩，就直接用 Cloudflare 的 CDN SSL，在本次事件也通通成為受災戶。
• 有些供應商背後也是使用 Cloudflare，例如把程式碼丟上去就不用管的 PaaS，背後支撐運作的不是佛心，而是把成本外部化，在 Cloudflare 當機期間也是十分不穩定。

當然每一個東西都可以有備案，只是增加更多成本和代價...

AWS CloudFront 免費版可以代替 Cloudflare 的 CDN 服務嗎?

如果想幫 Cloudflare 找其他備案，剛好 AWS 亞馬遜雲端也在這幾天發表了 CloudFront 免費版，剛好可以順便介紹一下。(段落沒有任何聯盟行銷分潤連結，請安心觀看)

大當機的 Cloudflare 是 WAF 送 CDN，還有一堆服務有免費額度，亞馬遜雲端上的一堆服務都要錢，VM 的 IPv4 要錢，用 API 撈帳單金額也要錢，還有一堆流量傳入傳出費用、依請求數計費、服務開著的基本費用，就已經讓許多人無法接受，還能怎麼打?

新的固定月費套餐

AWS 在此時先放下可怕的跳表計費，新推出了一個固定費率套餐，有四種：免費版（每月 0 美元）、專業版（每月 15 美元）、商務版（每月 200 美元）和高級版（每月 1000 美元），套餐裡面包含一些 AWS 的服務:

• CloudFront CDN
• AWS WAF and DDoS protection
• Bot management and analytics
• Amazon Route 53 DNS
• Amazon CloudWatch Logs ingestion
• Serverless edge compute(不要太興奮，只是 CloudFront Functions 而已)
• Monthly Amazon S3 storage credits

關於 CloudFront，我本來就有在用他的 CDN，還可以透過 ACM 發免費 SSL 憑證，這服務本來就有每個月的免費用量額度(即使不是AWS第一年的免費帳戶)，本來用超過就會開始跳表計費。新方案號稱用超過不會多收錢(monthly price with no overage charges)，聽起來很吸引人。

AWS 的一些服務預設都有 Layer3&4 的 DDoS 攻擊防護，但如果碰到 Layer7 的 DDoS 攻擊，可以直接到 CloudFront 裡面把 AWS WAF and DDoS 防護的開關打開，這玩意基本上依用量計費，下個月帳單會有美金幾位數? 只有上帝才知道了。現在變成號稱用超過不會多收錢，聽起來很吸引人。

免費版 = 功能閹割版

結果上去一看...原來又是商業手法，免費版的功能有被閹割過。
以下放截圖比對一下本來的跳表計費版本跟新出的免費方案:

這個是以前的 pay-as-you-go 版的 WAF 設定:

這是新出的免費閹割版的 WAF 設定，雖然少了費用說明和是否開啟的開關，但可以發現有些開關是不能點的:

免費版的一些 WAF 功能是直接鎖住不給用的，要升級。
Layer 7 DDoS 要 Business 方案才能啟用(每月 200 美元)
SQL 防護要 Pro 版才能啟用(一年大概快6000台幣)

選VPC當來源、調整快取政策等一堆功能，在新的這個免費版都被鎖起來了。

放錯圖了...下面這張才對

想自由設定 Policy? 請先升到每個月 200 美金的 Business 方案。

過濾規則只能選擇用 IP 或國家，其他的都要升級上去才能選。

想要擋 AI 爬蟲之類的，也是要先升到每個月 200 美金的 Business 方案。

往好的說，這以前是打開就要收費的，現在讓人可以免費體驗一些功能。也可以敘述成大企業資本家刀法精準、吃人血饅頭，讓網站營運成本逐年墊高，不同敘述方式就會吸引不同的客群。

AWS 官方說不用擔心額度用完會被收費，只會降速(You may experience reduced performance if you exceed your allowance)，至於免費方案的1百萬次請求數和100GB資料傳輸額度用完後，會降成怎樣，我還沒去特別測試，也許跟 Cloudflare 免費版的路由繞去國外一樣慢吧? 留給有興趣的人去玩玩。

本來用 AWS CloudFront 舊方案的，也可以直接「降級」成新的免費方案(如下圖)，不用擔心重新建立設定的那些破事兒。

還發現每個 AWS 帳號能開的免費方案有限，我開了3個後，額度就用完囉，付費升級才有更多額度。

包含 5GB 的 S3 免費儲存額度

更有趣的是這個方案包含 5GB 的 S3 折抵額(any S3 Standard storage costs in your AWS account)，一樣是隨著免費、專業版、商務版和高級版，等級越高送越多，送的是標準儲存級別的，不是冷儲存級別的。

對雲端不熟的人看起來可能覺得好爽。但我是不敢用。雲端老韭菜們知道這些物件儲存服務的玩法，把資料放進去的各種方式會產生費用，各種讀取資料/把資料拿出來/傳到別處也會產生費用，等帳單出來就走著瞧。

官方比較表、公告與文件更新

不用擔心什麼有些人不知道有免費版，每個月還傻傻繳錢，基本上只要從 AWS web console 進到 CloudFront 管理介面，就會跳出一塊公告介紹這個 flat-rate pricing plans 了。

其他新套餐各層級方案的功能限額與差別，可以參考 AWS 官方的詳細比較表: CloudFront flat-rate pricing plans，從表中發現免費方案和 Pro 的方案沒有任何 SLA 保證，所以哪天又碰到什麼大當機事故，也別想得到什麼賠償額度。

規格文件太長看不完，那可以先看漏掉很多細節的公告就好:Introducing flat-rate pricing plans with no overages。

然後本來 AWS 官網的 CloudFront 的官方價格介紹頁面，也都更換得差不多了，但變成一些比較深層的介紹文件連結失效…

我沒用 Cloudflare，但上游供應商在用

不要以為遠在天邊的美國廠商大當機，跟台灣沒什麼關係，在現代網路架構上已經是全球一命了，一些台灣本地的線上服務廠商也發生故障，例如:

• 因為 Zeabur 自己的後端 API 服務也是用 CloudFlare CDN 做防護和加速，以及連帶 Zeabur 使用的幾個上游服務供應商（例如 Email 服務）也收受到 CloudFlare 的影響。
• Internal server error Error code 500:由於我們系統有使用Cloudflare 故造成 meepShop 網站前台也顯示異常。
• 在此事件中，lihi 大眾網域轉址跟 lihi 後台都有受到波及；自訂網域轉址則完全不受影響，除非您的自訂網域 DNS 使用 Cloudflare。
• Cloudflare，於今晚 19:58 起，發生大規模當機事件， Portaly 同步也受到影響。

我有些小網站跑在國外的 PaaS 服務上，結果 Cloudflare 故障的時候也跟著時好時壞的，仔細一看發現人家一開始就大大的寫著 Cloudflare，但我只關心人家的價目表，從來沒去關心背後的供應商。

小網站跑在平台上，只要在本機寫好網頁程式，git push 之後就自動佈署在雲端上，而不用煩惱伺服器的許多維護管理問題，還有一些免費額度能用。
但風險除了平台可能隨時終止免費額度，像本次供應鏈中故障導致網站打不開，還有前幾段所述，可能難以快速搬家的問題，搬到其他地方可能面臨天價帳單，還有各家的服務功能差異。

與其說是撿到寶了? 還不如說是這種服務要是太常用，就有可能腳麻走不動了。

有些人以為只要自己不用某某東西，別人家出事也不甘我的事?
但實際情況是線上服務的上游跟上上游跟上上上游，往往層層都壓在同幾套基礎設施上。

平常大家都運作得很好，你完全感受不到這條依賴鏈的存在；直到某一天全部一起失靈，你才會發現自己並不是在用「一個服務」，而是一整個你從未檢視過的供應網。

很多人看到這種連鎖式故障，第一反應往往是：「哇，所以他們背後用的服務比較爛？」
不是，這跟好不好、貴不貴、SLA 多漂亮完全沒關係。
當全球型基礎設施出現系統性問題，所有建築在上面的一層層服務都會一起被捲進去，大家都只是不同環節層級的受害者而已。把責任怪在誰頭上，只是把問題看得太淺。

接著也有人會想：「那我是不是該去問我的廠商，他們背後到底用了哪些供應商？」
現實是，對方才不會把完整供應鏈一五一十攤出來。不要問，很可怕。
如果想要透明的供應鏈，通通換成在台股名單或美股名單上的廠商，也行，那價格可能也會很可怕。

人機驗證掛了，使用者就進不來：隱形的流量阻斷點

去年的文章 Google reCAPTCHA 暴改收費政策，每月百萬次免費變成 1 萬次免費將 Cloudflare Turnstile 列為備選之一，結果今年就碰到它出問題。

在 Cloudflare 大當機的時候，不只是送出資料前掛一個 verify you are human 小方塊的人機驗證 Turnstile 掛掉，進站前用 Managed Challenge (例如ChatGPT、普發現金的政府網站都有用)也有發生異常，別說網頁表單送不出去，還有可能讓使用者根本進不了網站。

一些新聞中放的圖片，看起來是 pic.see 縮網址服務掛掉，但是現在去沒找到公告，算了。

這種情況下，要把人機驗證關掉，讓使用者不用驗證直接送資料，讓有心人士也順便摸進來? 還是要暫停禁止使用? 這次的事件只是提醒大家：就算是安全性邊界上的小元件，一旦強烈綁定單一供應商，也足以讓整個系統停擺。若架構本身沒有留退路，當機時的決策就只剩「冒風險」或「不能用」兩種選項。

他X的，是不是又在講一些大道理? 希望這次事件有沒有讓一些人體會到，當某些 KOL 在網路上喊著「用 XX 好貴，換成 YYY 好便宜」時，是不是只看到表面?

便宜、免費、快速部署都很好，背後的供應商依賴、技術鎖定、特殊功能綁定、轉移成本、異常狀態時的處理空間，才是每個線上服務要面對的現實。

DNS 到 SSL 的多層備援考量

當晚的情況 Cloudflare 的網頁介面當機，但如果用 Cloudflare 的 Update DNS Record API 還是能正常執行某些操作，可以透過 API 把 proxied 設定關掉。

如果我也把串 API 編輯 DNS 的功能先做好放在冰箱備用，實際上真的要用的時候，還是有可能 API 早就改版了根本不能用，多一套程式就多一套成本。未來還是有機會碰到 Cloudflare 更多服務一起連環故障的時候。前面那段所費的功夫又成為空談。

DNS 紀錄可以改用 GCP 的 Cloud DNS，但光是「備而不用」就會增加成本。只要有記錄放在上面就要收費(Managed-zone 的月費)，然後真的切過去用，又要依查詢次數收費(Query-per-million 的費用)，當然 Google 雲端也是會故障的。

然後本來線上服務設定在 Cloudflare 的 WAF 規則、CDN SSL，武功全廢，都要重新設定。如果 SSL 憑證裝的還是那種充滿儀式感，跟憑證商花錢申請的，找客服重簽一張也需要時間。

線上服務的 SSL 切換時，也有可能讓訪客短暫看到瀏覽器顯示連線錯誤或安全警告畫面，這些都是實務上一定會遇到的現象，並不是多準備一套備援，就能永遠順利無痛切換，王子公主過著幸福快樂的日子。

Serverless 和 verdor-lock 的備援問題

跨應用的輕量微服務組件(例如有人登入時發 slack 通知/監測網站某些指標/定時排程執行網站某些程式/類似MQ機制...等等)，有一些是抽出來部署在 Cloudflare Workers 上，而不是在每個網站的程式碼裡面各寫一遍。

這樣集中管理，大多數情況的確省下相當多重複開發與管理的功夫，但在大當機事件中也成為新的單點風險。當 Workers 環境不穩定，程式無法正常運作時，整條流程都會跟著失效，各網站共同依賴的遠端服務呼叫，全部都可能中斷。

各家雲端服務或 PaaS 對於這種 Serverless 的程式語言支援程度、功能支援程度、cold start 等細節都不盡相同。本來在 Cloudflare Workers 上輕鬆管理的服務，toml 加幾行東西，wrangler 下幾行指令就能做到的事，換到別家不一定能直接跑。

這些服務還高度依賴 Workers 的環境變數(Secrets)，而 Cloudflare 的環境變數在設定後無法再次檢視，雖然安全，但在跨平台遷移時會變成額外的障礙：你既無法直接導出既有設定，也無法快速比對差異，整個備援部署流程因而變得更複雜。

在 Cloudflare 大當機當天，發現物件儲存服務 R2 沒掛，本部落格的圖片都放在上面，透過 API 都能正常讀取檔案。但要是透過 Cloudflare Workers 讀取檔案，就會因為 Workers 當機而失效。萬一程式中還用到一堆 Cloudflare KV、D1 等服務，這些服務在 Workers 當機時，都會跟著無法使用。

為了怕 Workers 掛掉而導致後面服務無法存取，可能要另做一套程式直接存取 KV、D1、R2。為了怕只有 Workers 自己活著，其他都掛掉，還要把 Workers 內的程式都做一層抽象介面，方便把 KV、D1、R2 替換成其他服務。

還是那句話，光是「備而不用」就會增加成本，當然大部分問題都用錢可以解決，問題是沒人要出錢。

結語

文章裡很多觀點本質上都是「我自己的網站或服務掛了，我知道怎麼補、知道痛點在哪，但沒錢就不要想這麼多了」。

如果換一個視角，像是公司經營點餐系統、企業資料管理系統等各種 SaaS 服務產品線，上游的雲端大廠掛掉，下游需要面對 SLA、客訴與法務風險，那就會變成另一種問題。

如果再換到外包的角色，客戶一看到「提高數位韌性的代價」可能就會瞬間變成「唉算了，應該不會那麼衰吧」「反正 ChatGPT 都掛了」。

最後能走到哪一步，多半不是技術問題，而是每個組織對「壞掉時願意承受多少」的誠實判斷。