在設計 SaaS（軟體即服務）系統時，開發者經常面臨一個核心抉擇：是要將所有客戶放在同一個大帳號裡（Shared Account），還是為每個客戶開一個獨立帳號（One-Account-per-Tenant）。前者管理簡單，但後者在安全性與成本計算上具有絕對優勢。工業穿戴設備廠商 ProGlove 的案例，向我們展示了後者在極端規模化（達到一百萬個 Lambda 函數）時的實作路徑與踩過的坑。
多租戶隔離策略與權衡
ProGlove 選擇了極其嚴格的隔離模式，即每個客戶擁有獨立的 AWS 帳號。這種做法的主要目的在於建立強大的安全邊界，確保客戶 A 的資料絕對不會意外流向客戶 B。此外，獨立帳號意味著每個客戶擁有獨立的 Service Quotas（服務配額），避免單一客戶的流量暴增導致所有客戶同時崩潰（所謂的吵鬧鄰居問題），且能精確地將雲端帳單分攤到每個客戶頭上。
然而，這種設計在客戶數超過 50 個時就開始產生運維摩擦。想像一下，如果你有 1000 個帳號，要更新一個小功能，你不可能手動登入 1000 次。這就是為什麼自動化基礎設施變得至關重要。
解決規模化部署的瓶頸
為了管理數千個帳號，ProGlove 結合了 AWS Organizations（用於管理多帳號層級）、Step Functions（用於協調部署流程）以及 CloudFormation StackSets。
這裡需要特別提到 CloudFormation StackSets，它是 AWS 提供的一種工具，允許開發者將同一套基礎設施模板一次性部署到多個 AWS 帳號或多個區域中。透過這套自動化管線，ProGlove 能從單一入口點更新所有帳號中的微服務。在 AWS 工程團隊的協助下，他們提升了 StackSet 的吞吐量，最終成功在數千個帳號中維護超過一百萬個 Lambda 函數。
避免自我觸發的 DDoS 攻擊
在規模化過程中，ProGlove 遇到了一個經典的工程陷阱：同步排程。
初期他們使用類似 Cron 的固定時間觸發器。當數千個帳號在同一秒鐘（例如每小時整點）同時觸發 Lambda 函數時，會對區域資源造成瞬間巨大的壓力，這在實務上就像是對自己的系統發起了一場 DDoS 攻擊。
為了修正這個問題，他們引入了 Jitter（抖動）概念。Jitter 是指在原本的觸發時間上加上一個隨機的偏移量，讓執行時間分散在一個時間窗格內。同時，他們將架構轉向事件驅動（Event-driven），利用 EventBridge 處理業務事件，從而平滑化區域負載，而不需要依賴昂貴的 Reserved Concurrency（預留並發量）或 Provisioned Capacity（預置容量）。
控制可觀測性的成本陷阱
當 Lambda 函數數量達到百萬級別時，日誌（Logs）與指標（Metrics）產生的費用會變得極其驚人。如果每個函數都詳細記錄所有資訊，雲端帳單可能會被監控成本給吞噬。
ProGlove 採取了精簡策略：他們將高優先級的錯誤集中到一個中央死信隊列（Dead-letter Queue, DLQ），並刪除不必要的 SQS 隊列。透過這種方式，他們成功將每個帳號在閒置狀態下的月支出降低到 1 美元以下，實現了真正的 Scale-to-Zero（縮減至零）成本管理。
實務總結與啟發
ProGlove 的經驗給予我們三個重要的工程建議：
第一，如果對安全性與成本追蹤有極高要求，可以考慮強隔離的帳號模型，但必須在早期就將基礎設施即代碼（IaC）徹底自動化。
第二，在分佈式系統中，絕對要避免所有節點在同一時間執行相同任務，務必引入隨機抖動（Jitter）來分散壓力。
第三，可觀測性成本（Observability Spend）必須被視為一個一等公民的限制條件。在設計日誌與監控方案時，要考慮數量級擴展後的費用，而非僅考慮單一環境的運行。
來源：infoq.com (AWS Details How One Customer Scaled to One Million Lambda Functions)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。