Amazon EC2 彈性雲端計算

EC2 是 AWS 的地基，也是最容易被買錯的產品。絕大多數「雲伺服器怎麼選」的問題，最後都落在兩個決定上：選哪個實例系列、選哪種計費方式。這兩件事定錯，後面最佳化都只是補救——實例買大了是長期浪費，計費方式買錯了同樣燒錢。 我們每天都在幫客戶開 AWS 賬號和代付，見過最常見的失誤是：拿一臺 m5.large 跑本該用 Graviton 的負載，或者在穩定生產環境裡一直用按需付費。下面按實際採購決策的順序講清楚。

規格與計費

第一步：按工作負載選系列，而不是按價格

AWS 的實例系列不是「貴一點的好一點」，而是橫向分工。先判斷你的負載屬於哪一類： - Web 與業務系統 → M 系列。CPU 與記憶體均衡，大多數業務都不需要專門最佳化。 - 編譯、轉碼、批次處理 → C 系列。持續吃滿 CPU，M 系列在同樣的錢下跑得更慢。 - 資料庫、Redis、記憶體快取 → R 系列。記憶體/核心比更高，資料庫頁快取命中更多。 - GPU 訓練與推論 → G / P 系列，訓練看顯示記憶體容量，推論看單價與並發。 選錯方向的代價是長期且持續的：用 M 系列跑編譯任務，等於按通用價買專用效能；用 C 系列跑資料庫，等於為用不到的 CPU 核心付錢。

如果你的服務能跑 ARM：Graviton 值得先試

第二步：區域比實例選型更影響體驗

這是最容易被低估、卻最該優先決定的一件事。延遲由使用者到你所選區域的實體距離與網路路徑決定，換實例型解決不了。 對亞太使用者：香港（ap-east-1）到大陸/臺灣/香港通常在 15–30ms 區間；東京（ap-northeast-1）與新加坡（ap-southeast-1）大致在 45–95ms，具體隨電信商與時段波動。 動手前自己測一遍：開一臺最小配置實例，從你真實使用者所在的網路連續 ping 24 小時，重點看晚高峰。測試成本幾塊錢，選錯區域的代價是長期且持續的。

第三步：計費方式決定長期成本

實務建議：開發階段用隨需，正式環境穩定後轉節省計畫或預留實例。 大多數團隊能把雲端成本壓下來 30%–50%，靠的不是換更便宜的機器，而是不再為閒置時間付全價。 如果你的實例規格會變（比如從 M 升到 R），選節省計畫而不是預留實例——RI 綁死規格，規格一變它就失去意義；SP 按用量計費，跟著負載走。 如果你有 GPU 訓練這類「用完就停」的任務，Spot 配自動 checkpoint 是價效比最高的組合，競價價格通常只有隨需的一到兩成。

怎麼開通：走合作夥伴的完整流程

1. 說明需求：區域、實例系列、預計用量、是否需要固定公網 IP。
2. 確認報價：折扣幅度、計費方式、後續升配是否額外收費，都會寫進訂單確認單。
3. 開通帳號：我們協助完成 AWS 帳號開通與支付驗證，你不需要繫結本人信用卡，也不需要提交個人證件材料。
4. 付款結算：按約定幣種結算；帳單一併核對後交付。
5. 環境交付：帳號開通後你在 AWS 官方控制檯自助下單，實例環境由我們協助初始化。

四個常見坑

• 長期跑隨需付費：穩定負載用了半年才想起來轉節省計畫，白白多付半年。
• 跨區流量費：應用與資料庫放在不同區域，流量費可能超過機器本身的錢。
• EBS 卷與快照忘刪：刪實例不會刪卷，快照持續按 GB 計費，是帳單裡最常見的意外項。
• T 系列 CPU 積分耗盡：超出基準效能後按超額計費，長時間跑滿 CPU 的負載並不便宜。