AWS 新方案:免費的 CDN+WAF 超量不收費，還送 5GB 的 S3 儲存額度?
各大國際公有雲端服務在 2025 年發生幾次大當機，紀錄一下感想，還有順便看一下最近出的 AWS CloudFront 免費新方案，葫蘆裡在賣什麼藥。
有時候我們以為把程式運作架構規劃得很輕巧，沒有 over design，也沒有為了技術而技術。
結果來幾次雲端服務大當機，就讓整串服務像骨牌一樣倒下來，連 OpenAI, Canva, Spotify 那種有完整工程團隊的大公司，也會因為雲端基礎設施故障而受影響使用者。
上游雲端供應商的一個小小功能故障，到了基層開發者佈署的末端服務，實際上連寫在報價單上也不會有人看的項目，通知、排程、人機驗證、錯誤記錄之類的，都有機會在關鍵時刻卡死整個功能。
躲過今年的 GCP 跟 AWS 大當機
差不多是台灣時間6月13號半夜一點多開始，睡前看到 GCP Status Page 的服務中斷清單越拉越長，一堆世界知名的網站跟線上服務都出現故障，Cloudflare 的部分服務也跟著受影響。
Multiple GCP products are experiencing Service issues.
這個部落格主程式是放在 GCP 的 us-west1 區域，當下都還能正常瀏覽，彷彿什麼事都沒發生。
我有兩個選擇，一個是趕快切換到備援方案，然後在社群網站上大吹特吹，社群貼文底下留言開放拍馬屁。不然 GCP 系統很快就修好了，讓我像個傻瓜一樣白忙一場。
但我選擇直接洗洗睡了。
後來看官方的事故報告，慶幸那時候什麼都沒動，因為故障的是整個雲端系統授權與配額查詢的部分，萬一把服務重啟，或是想要啟動其他區域的服務，應該都會操作失敗。
接著AWS在2025年10月19號大當機，又一堆世界知名的網站跟線上服務都出現故障，當天晚上我接著奏樂接著舞，秘訣就是沒有什麼東西放在那個區域，剛好逃過一劫。
Cloudflare 也大當機
結果隔一個月後，2025年11月18號換成 Cloudflare 也大當機，一些工程師群組起初還謠傳 Cloudflare 被攻擊到掛了，結果等到官方報告出來，只是一些程式小錯誤。
Cloudflare Global Network experiencing issues
這次沒有人是局外人，連我自己也受影響了。
- DNS 管理功能故障
有個網站要移機，白天先把東西複製在新環境，翻 GA 報表看哪時候人比較少，翻農民曆，等晚上比較沒人的時候偷改 DNS 切過去，結果台灣時間晚上剛好碰到 Cloudflare 當機，變更 DNS 的網頁介面打不開。 - Serverless 服務運作不穩定
部分監測/發通知/跑排程的工具跑在 Cloudflare Workers 上面，也出現不穩定的情況，程式流程中間有用到那些服務的，也就無法正常運作。 - 人機驗證 Turnstile 掛掉
不管是進站前用 Managed Challenge (例如ChatGPT也有用)，還是送出資料前掛一個 verify you are human 的檢查，都有發生異常，讓使用者卡住。 - WAF 故障讓網站無法正常運作
少數線上系統有把 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 要錢，固定一組 IPv4 又要再收錢，用 API 撈帳單金額也要錢，還有一堆流量傳入傳出費用、依請求數計費、服務開著的基本費用，林林總總算下來就一堆人付不起，還能怎麼打?
新的固定月費套餐
AWS 在此時先放下可怕的跳表計費，新推出了一個固定費率套餐，有四種：免費版、專業版（每月 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
關於 AWS CloudFront，我本來就有在用，以這個部落格為例:
- 讓 CloudFront 的 CDN 層擋在前面，讓後面的伺服器不用直接面對昂貴的對外流量費。
- 透過 AWS Certificate Manager (ACM) 拿免費 SSL 憑證，系統自動續約+自動安裝。我可以不用自己管理SSL自動排程續簽、檢查SSL是否到期或異常等一堆的程式。
- 在 CloudFront function 裡面做一些邊緣運算，把有特定特徵的請求直接過濾掉。
AWS CloudFront 本來就有每個月的免費用量額度(即使不是AWS第一年的免費帳戶)，以前是用超過免費額度就會開始跳表計費。新方案號稱用超過不會多收錢(monthly price with no overage charges)，聽起來很吸引人。
AWS 的一些服務預設都有 Layer3&4 的 DDoS 攻擊防護，但如果碰到 Layer7 的 DDoS 攻擊，可以直接到 CloudFront 裡面把 AWS WAF and DDoS 防護的開關打開。不像隔壁 GCP 還要先啟用負載平衡服務，然後把那堆什麼 Armor 綁在負載平衡服務上，一下多出兩個服務的費用。
AWS CloudFront 這玩意基本上依用量計費，下個月帳單會有美金幾位數? 只有上帝才知道了。新方案變成號稱用超過不會多收錢，聽起來很吸引人。
免費版 = 功能閹割版
結果上去一看...原來又是商業手法，免費版的功能有被閹割過。
以下放截圖比對一下本來的跳表計費版本跟新出的免費方案:
這個是以前的 pay-as-you-go 版的 WAF 設定:
這是新出的免費閹割版的 WAF 設定，雖然少了費用說明和是否開啟的開關，但可以發現有些開關是不能點的:
免費版的一些 WAF 功能是直接鎖住不給用的，要升級。
Layer 7 DDoS 要 Business 方案才能啟用(每月 200 美元)
SQL 防護要 Pro 版才能啟用(一年大概快6000台幣)
選VPC當來源、調整快取政策等一堆功能，在新的這個免費版都被鎖起來了。
放錯圖了...下面這張才對
![](/wp-content/uploads/2025/11/cloudfront-free-plan-cache-rule.webp")
想自由設定 Policy? 請先升到每個月 200 美金的 Business 方案。
過濾規則只能選擇用 IP 或國家，其他的都要升級上去才能選。
想要擋 AI 爬蟲之類的，也是要先升到每個月 200 美金的 Business 方案。
往好的說，這以前是打開就要收費的，現在讓人可以免費體驗一些功能，讓一些聽到雲端就望而卻步的人進來使用。
也可以說成這些大企業的刀法精準、資本家吃人血饅頭，讓網站營運成本逐年墊高，不同敘述方式就會吸引不同的客群。
AWS 官方說不用擔心額度用完會被收費，只會降速(You may experience reduced performance if you exceed your allowance)，至於免費方案的1百萬次請求數和100GB資料傳輸額度用完後，會降成怎樣，我還沒去特別測試，也許跟 Cloudflare 免費版的路由繞去國外一樣慢吧? 留給有興趣的人去玩玩。
本來用 AWS CloudFront 舊方案的，也可以直接「降級」成新的免費方案(如下圖)，不用擔心重新建立設定的那些破事兒。
如果不喜歡免費方案，可以在同樣的地方選擇 Cancel Plan，回到原本的 Pay-as-you-go 方案；或是選擇 Change Plan，選擇其他付費方案。
還發現每個 AWS 帳號能開的免費方案有限，我開了3個後，額度就用完囉，付費升級才有更多額度。
雖然一個AWS帳號預設只能開3個免費方案，但我想可能還會有一些三流業者搞離譜操作，直接宣稱自家網站方案包含 WAF，把其他公司的免費產品借花獻佛拿來賣。這種閹割版的免費套餐，跟別家的商業級 WAF 防護還是沒得比，一旦流量或防護需求上來，該付錢的還是要付。
包含 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 的官方價格介紹頁面，也都更換得差不多了，但變成一些比較深層的介紹文件連結失效…
新年第一天就踩坑，換方案後啟動陷阱卡
2026 年第一個工作天就在查 AWS 花費，為何這個月第 1 天晚上就收到 exceeded alert threshold 通知?
仔細一查發現......轉換方案時，忘了關閉原本在方案中免費+預設開啟的功能，它在轉換方案後默默變成了正常收費項目。前因後果大概是這樣:
1.用新方案開了幾個測試的 Cloudfront distributions，新方案的 WAF 沒有開關，預設就是打開的...(這點很重要，後面要考)
2.因為每個 AWS 帳戶能開的這方案數量有限，12月的時候把一些測試的 Cloudfront distributions 改成 pay-as-you-go 的方案，flat-rate 扣打給別的網站系統用。
失誤的地方:
1.改方案之後，沒檢查那個 WAF 有沒有關好(建立預設是啟用的)
2.換方案的當月不會計費，所以沒發現
3.換方案後的下個月，才會開始用正常方案計費，所以 WAF 相關的那些 WebACL rule 的費用，就讓我收到通知了。😂
想要試用新服務，結果又被免費方案卡住
Microsoft Clarity 在 2026 年初推出一個 AI Bot Activity，可以從報表輕鬆看到有哪些 AI 大廠來爬網頁。
報表上的資料不是憑空生出來的，首波公測直接跟幾間 CDN 大廠合作，需要網站管理員在 CDN 上面做一些設定，先把資料送到 Microsoft Clarity 哪邊去，才有報表可以看。
剛好 AWS Cloudfront 是其中一家。反觀 Cloudfront 還要 Enterprise 方案才能用，免費仔沒得用。(因為把資料發到 Microsoft Clarity 會用到 Logpush，那個是 Cloudfront Enterprise 才有的功能)
但設定時尷尬的事又來了，那個 Logging 的功能在 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 的網頁介面當機，剛好要移機改 DNS 就沒辦法操作。但如果用 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 切換時，也有可能讓訪客短暫看到瀏覽器顯示連線錯誤或安全警告畫面，這些都是實務上一定會遇到的現象，並不是多準備一套備援，就能永遠順利無痛切換，王子公主過著幸福快樂的日子。
AWS 的新方案剛好也有代管 DNS 的免費額度
開頭介紹的 AWS 新方案，剛好也包含一些 Route 53 的用量，免費方案包含一百萬次 DNS 查詢次數，適合一些沒什麼人來看的小網站。Name Server 本來用 Cloudflare 的，可以從 DNS Analytics 檢查用量，評估會不會超過 Route 53 的免費額度。
Route 53 的託管區域跟 GCP 的 Cloud DNS 一樣也是要錢的，要記得去綁定方案才享有免費優惠額度，要把 Route 53 的託管區域綁定到 AWS CloudFront 的方案中(如下圖)，但用到一些 Route 53 的進階功能，還是要額外付費。
目前手上暫時還沒有適合的域名能整個擺到 AWS Route 53，而且它功能太強大了，拿來代管 DNS 真是格局小了。
Serverless 和 verdor-lock 的備援問題
有些系統功能(例如有人登入時發 slack 通知/監測網站某些指標/定時排程執行網站某些程式/類似MQ機制...等等)，我才不要在每個網站的裡面各寫一遍幾乎重複的程式碼，而是設計成跨應用的輕量微服務組件，部署在 Cloudflare Workers 上。
不是不爆，只是時機未到，在 Cloudflare 大當機當天，發現物件儲存服務 R2 沒掛，本部落格的圖片都放在上面，透過 API 都能正常讀取檔案。但其他跑在 Workers 的程式就沒這麼幸運了。
| 好處 | 壞處 | 理想解法 |
|---|---|---|
| 用 Cloudflare 大全套集中管理，大多數情況的確省下相當多重複開發與管理的功夫 | 在大當機事件中也成為新的單點風險。當 Workers 環境不穩定，程式無法正常運作時，整條流程都會跟著失效，各網站共同依賴的遠端服務呼叫，全部都可能中斷。 | 準備備援的備援的備援的備援 |
| 在 Cloudflare Workers 上輕鬆管理的服務，toml 加幾行東西，wrangler 下幾行指令就能做很多事 | 各家雲端服務或 PaaS 對於這種 Serverless 的程式語言支援程度、功能支援程度、cold start 等細節都不盡相同，難以輕鬆遷移到別家雲端上。 | 少碰這種被雲端廠商綁死的技術 |
| 使用 Workers 的環境變數(Secrets)功能，將程式碼和金鑰隔開。 | 在跨平台遷移時會變成額外的障礙。設定後無法再次檢視，難以直接導出既有設定，也無法快速比對差異，整個備援和部署流程變得更複雜。 | 使用第三方金鑰管理服務，然後再準備備援的第三方金鑰服務的備援的備援的備援 |
| 輕鬆加入幾行程式就能將 Cloudflare WorkerS 跟 KV、D1、R2 等服務輕鬆整合 | 當 Workers 掛掉時，即使 KV、D1、R2 的資料都好好的，也跟著無法使用 | 另做一套程式直接存取 KV、D1、R2，避免大門卡住整棟房子就進不去出不來的情況 |
| 輕鬆加入幾行程式就能將 Cloudflare WorkerS 跟 KV、D1、R2 等服務輕鬆整合 | 可能碰到只有 Workers 自己活著，其他 KV、D1、R2 都掛掉 | 尋找其他備援，並把 Workers 內的程式都做一層抽象介面，方便把 KV、D1、R2 替換成其他服務 |
還是那句話，光是「備而不用」就會增加成本，當然大部分問題都用錢可以解決，問題是沒人要出錢。
結語
文章裡很多觀點本質上都是「我自己的網站或服務掛了，我知道怎麼補、知道痛點在哪，但沒錢沒時間就不要想這麼多了」。
如果換一個視角，像是公司經營點餐系統、企業資料管理系統等各種 SaaS 服務產品線，上游的雲端大廠掛掉，下游需要面對 SLA、客訴與法務風險，那就會變成另一種問題。
如果再換到外包的角色，客戶一看到「提高數位韌性的代價」可能就會瞬間變成「唉算了，應該不會那麼衰吧」「反正 ChatGPT 都掛了」。
最後能走到哪一步，多半不是技術問題，而是每個組織對「壞掉時願意承受多少」的誠實判斷。