AWS 新方案:免費的 CDN+WAF 超量不收費,還送 5GB 的 S3 儲存額度?
有時候我們以為把程式運作架構規劃得很輕巧,沒有 over design,也沒有為了技術而技術。
結果來幾次雲端服務大當機,就讓整串服務像骨牌一樣倒下來,連 OpenAI, Canva, Spotify 那種有完整工程團隊的大公司,也會因為雲端基礎設施故障而受影響使用者。
上游雲端供應商的一個小小功能故障,到了基層開發者佈署的末端服務,實際上連通知、排程、人機驗證、錯誤記錄這些寫在報價單上也不會有人看的項目,都有機會在關鍵時刻卡死整個功能。
2025 年有幾次雲端服務大當機,紀錄一下感想,還有順便看一下最近出的 AWS CloudFront 免費新方案,葫蘆裡在賣什麼藥。
躲過今年的 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 要錢,用 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
關於 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當來源、調整快取政策等一堆功能,在新的這個免費版都被鎖起來了。

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

想自由設定 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 的官方價格介紹頁面,也都更換得差不多了,但變成一些比較深層的介紹文件連結失效…
我沒用 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 都掛了」。
最後能走到哪一步,多半不是技術問題,而是每個組織對「壞掉時願意承受多少」的誠實判斷。