一個 95% 的門檻先被寫進了文件：Lightsail 流量監控手冊，是一頁照做的介面

V2EX 的分享創造版近日出現一篇長文，作者 aitobox 自述使用 AWS Lightsail 時遇到一個缺口：每臺 VPS 的流量是疊加計算的，但 AWS 沒有提供「流量快用完就自動停機」的功能，網路上找得到的腳本多半只監控單臺機器，於是自己動手寫了一套方案，並由 AI 邊操作邊記錄、最後整理成文，作者人工覆核過一遍。

這類技術文件通常只有工程意義，值得從設計角度看，是因為它其實是一頁被排好的介面：讀者在什麼順序下做什麼動作、在哪裡停下來複製一串 ARN、在哪裡被提醒別選錯，全都有安排。

文件的骨架：從信箱開始，以百分比收尾

手冊的結構值得看。第一步不是寫程式，而是到 SNS 建一個名為 lightsailmonitor 的主題、綁上電子郵件訂閱。也就是說，整套方案的第一個使用者接觸點，是作者自己信箱裡那封 AWS Notifications 的確認信。告警通道先於邏輯存在，這個順序本身就是一種設計判斷：先確保出事時有人會收到通知，再談怎麼偵測出事。

第二步才建立 Lambda 函數，同樣命名為 lightsailmonitor。文件在這裡插入一段多數教學會省略的細節：預設 3 秒的超時不夠用。因為腳本要併發掃描全球 15 個 Lightsail 區域，實測耗時約 5 到 9 秒，作者明確要求讀者把超時改成 30 秒、記憶體設 256 或 512 MB。把「實測秒數」寫進文件，等於把看不見的執行時間變成讀者可以核對的數字，這是技術文件裡少見的誠實。

真正的主角是一條計費規則

這套方案的核心不在程式，在於它對齊了 AWS 的計費邏輯。作者強調三件事：同區域所有 VPS 的流量配額與實際用量（入站加出站）自動累加；當月新建的實例，首月配額按剩餘天數比例折算；以及當某區域總用量超過總配額的 95% 時，自動關停該區所有實例，並透過 SNS 寄出彙總告警郵件。

這裡的設計難度其實是「翻譯」。雲端計費規則本身是一套文件，使用者讀完未必知道它對應到什麼行為；這套腳本把「區域流量池共享」「首月按天折算」這些計費條款，翻譯成兩個可執行的動作：算進去、超過就停。95% 這個門檻留在配額之內，留了 5% 的緩衝，避開計量延遲造成的誤差。防的則是同一件事：帳單出現無預期的巨額費用。

與網路上既有的單機監控腳本相比，這份方案的差別在於計算單位從「一臺 VPS」換成「一個區域」。單機腳本只需要讀一個數字；區域池要先聚合同區所有實例的配額與用量，再判斷總量。這也是它必須併發掃描 15 個區域、必須調整 Lambda 超時的原因。

自助文件的生產方式，也是設計

作者自述這份文件是「邊操作邊用 AI 記錄，最後 AI 整理完成」，自己再覆核一遍。這個生產流程值得留意：AI 負責把操作過程整理成連續的步驟敘事，人負責確認無誤。文件裡那些容易被省略的提醒，例如「不要複製後面帶冒號和隨機字串的訂閱 ARN」，正是這種流程的產物，它記錄的是實際操作中會踩到的坑，憑空寫不出來。

與 AWS 官方文件相比，這份手冊的優勢在於它有立場。官方文件描述每個服務能做什麼；這份手冊只有一個目標，就是別讓帳單爆掉，所有步驟都為此服務。讀者不需要理解整個 AWS，只需要照順序做完。這種單一目的的文件，本質上是把一團分散的服務（Lambda、SNS、EventBridge、IAM）重新排成一條有先後的路徑。

成本這一段也講得具體：作者指出 Lambda 在一定額度內免費，這個小腳本的消耗完全落在免費額度內。對個人使用者來說，這句話比任何架構圖都有說服力，因為一套用來省錢的工具若自己產生費用，邏輯就站不住。

這種由個人需求出發、把官方服務的縫隙補起來的工具，性質上接近我們先前觀察過的 LiveSub 直播字幕工具的介面取捨：官方沒提供的功能，由使用者自己拆成可操作的步驟。差別在於 LiveSub 裝在本地，這套方案則完全寄住在 AWS 自己的免費額度裡，用平臺的資源監管平臺的帳單。

一頁好的手冊，是把不確定性排掉

這份文件最有價值的地方，不是腳本本身，而是它把整個流程中每個可能出錯的節點都提前標了出來：超時要改、ARN 別抄錯、權限要走最小原則、訂閱要回信箱確認。一份部署手冊讀起來順，靠的從來都是這些被排好的檢查點，而不是文筆。AWS 沒做的自動停機，作者用一頁任何人都能照做的文件補上了；而在雲端服務越來越複雜的現在，這種把計費規則翻譯成防護動作的自助文件，本身就是一種值得被認真對待的設計工作。