2026 年，你可能不需要 AWS

你的團隊選擇 AWS 的理由是什麼？

如果答案是大公司都用、老闆說要用、前一份工作也是這樣用，這篇文章可以當作參考。

AWS 的隱藏代價

AWS 的表面成本是帳單上的數字。真正的代價藏在別的地方。

一個 3-5 人的團隊，光是把基礎設施跑起來就需要設定：

• VPC：網路隔離，設定 subnet、CIDR
• ALB：Load Balancer，處理流量分配跟健康檢查
• ECS Cluster + Service + Task Definition：容器的核心設定
• ECR：Container Registry，而且通常你需要 dev / staging / production 各一個
• IAM Role：權限管理，Task Execution Role、Task Role、Service-Linked Role
• EIP：固定 IP（如果你需要的話）
• NAT Gateway：讓 private subnet 的容器能存取外部網路
• Route 53：DNS 管理
• Cloudfront：如果想要接 CDN，或是避免 ALB 暴露在外網就需要另外設定

這還只是基礎設施。你還沒開始寫任何一行應用程式的 code。

IAM Policy 寫錯一個 Action，container 就是拉不到 ECR 的 image，錯誤訊息只會跟你說 CannotPullContainerError，不會告訴你是權限問題。

NAT Gateway 忘記設定，container 起來了但打不到任何外部 API，你可能 debug 半天才發現是網路不通。

在有規模的公司，這些流程通常已經標準化，照著做就好。

前公司是採用 Private Cloud，一鍵建立 K8S 的集群。就算是 VPS，也已經內建了常見腳本設定，監控、OS 參數、Logging、跳板機都是在建立 Instance 之後直接設定好。

剛起步的公司不太可能有這樣的規模，這些工作不會產生任何產品價值，卻會吃掉至少一個工程師的產能。

在ECS 部署策略那篇文章裡，我算過一個 5 人團隊因為複雜的部署流程，每年的隱藏成本大約在 200-250 萬台幣。

先看固定費用：

• NAT Gateway 不管有沒有流量，每月至少 $32 USD。
• ALB 的基本費用 $16 USD
• 2 vCPU / 4GB 的 Fargate task，光是運算費用每月就要 $70-80 USD

這些加起來，什麼都還沒跑就已經超過 $120 USD/月。

AWS 的 egress（資料傳出）是按量計費的，東京區域每 GB 收 $0.114 USD。以一個有接 CDN 的一般 web service 來估算，月活躍用戶 40-50 萬大約會產生 1 TB 的 egress，對應的流量費約 $117 USD/月。

如果沒有接 CDN，1.5-2 萬 MAU 就能達到同樣的流量，再加上 NAT Gateway 的 data processing 費（$0.045/GB），1 TB 又多了 $46 USD。

這些流量費不會出現在你一開始的成本估算裡，因為產品剛上線時流量很低。但隨著用戶成長，帳單會悄悄膨脹，固定費用加上流量費，每月輕鬆突破 $300 USD。

現在有更簡單的選擇

過去選 AWS 是因為沒什麼替代方案。現在不一樣了。

平台	適合場景
Railway / Render / Zeabur	全端應用、API 服務
Cloudflare Workers	V8 引擎架構，冷啟動時間近乎零，只依賴 CPU 運算時間計費
Vercel	想要 Edge Function，服務用 Next.js 撰寫
Supabase	想要開箱即用的 Database 以及驗證、CRUD API
PlanetScale	資料庫開發與部署平台，把 schema 變更納入 Git-like workflow

Vercel 值得多聊幾句。Next.js 近年帶來的複雜度不低，React Server Components 需要開發者意識到瀏覽器端與伺服器端的差異，ISR/CSR/SSR 各有取捨。

但 Vercel 與 Next.js 的整合相當好（這本來就是他們的商業策略），Next.js 專案一鍵 push 就上版。

我自己喜歡的幾個服務：

• Railway：他的 UI 跟部署體驗非常好，有 CLI 可以使用，原生就有支援多環境的功能
• Supabase：有內建 auth 功能，可以跟 SDK 連結，幾乎不需要另外自己實作；還有 CRUD API 可以使用跟可以在網頁裡編輯 Table 的編輯器

我很期待 Zeabur，自己的個人專案也都是用 Zeabur 來部署。目前我不推薦的原因有幾個：

• 產品方向：從開發早期以貼錢、免費的方式吸引開發者；到後來轉變為給 Vibe Coder 的部署服務；到現在變成了 AI DevOps，新創為了探索市場需要不斷轉變產品方向，對公司來說是不穩定的因素
• 近期出錯率：我遇過幾次 Zeabur 當機的情形

目前 Zeabur 已經不再採用共享 Cluster 的方式，而是你要先購買主機，Zeabur 提供了統一的介面給你使用幫你管機器。會持續關注 Zeabur 的開發狀況。

另外一個我一直很想用用看的是 PlanetScale，這是由 GitHub 前 VPoE Sam Lambert 帶領的公司，這幾個功能是我很想使用的：

• Database branching：資料庫層級的分支。先在隔離環境改 schema、測試，再決定是否合併，這在不同功能開發時，如果有大幅更動 schema 時非常好用
• Deploy requests：schema 變更不是直接打到 production，而是先發 deploy request，檢查 diff、審核，再做部署，簡化以前要給 DBA 審查的流程
• 開發者體驗：不只有提供 DB Instance 而已，連開發工具都幫你準備好了

AWS 不再是唯一的選項，只是用久了容易忘記還有別的路。

什麼時候 AWS 仍然合理

以下情境選擇 AWS 是合理的：

• 合規要求：金融、醫療、政府標案，需要特定的認證（HIPAA、ISO 27001）和資料落地要求。AWS 在這方面的文件和支援最完整
• 流量規模夠大：月活躍用戶破百萬、需要精細的流量控制和成本優化。這個規模下，AWS 的 Reserved Instance 和 Savings Plan 能省下可觀的費用，也有足夠的談判籌碼跟代理商拿折扣
• 團隊有專職的基礎設施工程師：有人全職負責 Terraform、監控、安全性，AWS 的彈性才能發揮
• 深度使用 AWS 專屬服務：SageMaker、Kinesis、DynamoDB 等沒有直接替代品的服務，且這些服務是你產品的核心

如果以上條件一個都不符合，AWS 就是 overkill。

之後再遷移的成本

常見的反駁是：「那先用簡單平台，之後流量大了再搬到 AWS。遷移成本很高吧？」

遷移確實有成本，但需要拆開來看：

• 應用層：如果你的服務是容器化的（Docker），搬到哪裡都一樣。CI/CD pipeline 要重寫，但這是一次性的工作
• 資料庫：這是遷移中比較痛的部分。如果規模已經大到必須考量搬遷資料庫，通常搬遷本身也不是問題了（已經有資源、預算處理）
• 網路架構：從簡單平台搬到 AWS，VPC 和 ALB 要從頭設定。這確實要花時間，但也是一次性的

多數新創公司的瓶頸不是基礎設施撐不住，是產品還沒找到 product-market fit。在這個階段，花兩個月搞 AWS 基礎設施而一行產品 code 都沒寫，才是真正昂貴的選擇。

基礎設施的選擇是商業決策

選擇基礎設施本質上是一項投資。投資就要問回報：這筆錢和人力投下去，能為公司帶來什麼？答案取決於公司現在在哪個階段、未來要往哪裡去。

• 產品早期：目標是尋找 Product Market Fit，這個階段最貴的資源是時間。每多花一週在基礎設施上，就是少一週驗證產品假設。選一個能讓你明天就上線的平台，把所有精力放在產品本身
• 產品成長期：用戶快速增加：系統開始承受壓力，擴展性變成真正的問題。這時候才值得評估 AWS 這類平台，因為你有了具體的需求（流量成長曲線、效能瓶頸）
• 準備被收購或 IPO：基礎設施的選擇會直接影響公司的財務指標。毛利率、稅前淨利這些數字，背後都跟基礎設施的成本結構有關

每個階段對基礎設施的需求不同，對應的投資規模和回報也不同。在產品還沒站穩的時候就押重注在 AWS 上，就像還沒確定要開什麼餐廳就先花三個月裝潢一樣。

技術領導者容易掉入的陷阱是：用技術語言去爭取基礎設施的預算。但對經營層來說，他們在意的是這筆投資能帶來多少 ROI、能省下多少營運成本、能讓產品多快推向市場。學會用商業語言溝通，經營層才會認真看待現代化的提案。

基礎設施的選擇應該跟著公司的階段和戰略一起演進。先把產品做出來，驗證完再說。不需要在第一天就為十年後的流量做準備。