昨天提到，面對一個 AWS 需求時，我不會急著選服務，不過，實際開始整理需求後，還會遇到另一個問題：客戶提出的每句話，看起來都很重要，到底該先看哪一個？

假設客戶告訴我：「希望系統高可用、資料放在新加坡、三週內完成上線，而且最好不要管理太多伺服器。」如果直接從這句話開始找服務，很快就會列出一長串選項，卻不一定知道該用什麼標準刪除。

這時候，我會先把收到的資訊分成三類：需求、限制與偏好。

需求是系統真正要達成的結果：例如「高可用」背後可能代表單一 EC2 故障時要自動恢復，也可能要求整個 Availability Zone 發生問題時，服務仍不能中斷，與其只留下「高可用」三個字，我會繼續確認可接受的中斷時間、資料最多能遺失多少，以及哪些功能一定要持續運作，當需求能進一步轉成 RTO、RPO、流量或回應時間，後面的服務比較才有依據。

限制則是方案不能跨過的界線：資料必須留在新加坡、只能透過私有網路存取、三週內必須上線，或每月預算不能超過多少，都可能直接排除部分選項，即使某個方案在技術上很好，只要無法滿足這些條件，就不會是這次適合的答案。

剩下的是偏好，例如希望盡量使用受管服務、團隊比較熟悉 EC2，或未來想導入 Kubernetes，偏好通常還有討論空間，但也不是永遠排在最後，假如團隊完全沒有 Kubernetes 維運經驗，專案卻只剩三週就要上線，那麼「團隊熟悉度」就可能從偏好變成實際限制。

這也是為什麼我不太喜歡只用關鍵字選服務，聽到全球使用者就直接想到 CloudFront，聽到容器就選 EKS，或看到跨區備援就決定使用 Aurora Global Database，都可能跳過真正需要解決的問題，同樣的服務放進不同團隊、時程和預算裡，結果可能完全不同。

把需求、限制與偏好分開後，我才會開始比較服務，並可以參考 AWS Well-Architected Framework 的六大支柱重新檢查方案，我不會把它當成每一項都要拿滿分的評分表，而是用來提醒自己：這次的選擇是否只解決了效能，卻增加了維運負擔；是否提高了可用性，卻讓成本超出預期；又或者為了降低成本，接受了哪些風險。

最後，我希望每個選型都能用一句話說明：

在哪些限制下，我選擇了什麼方案，因為它最符合哪項需求，同時接受了什麼代價。

架構選型不一定只有一個正確答案，但至少要說得清楚當時為什麼這樣選，未來當流量、預算或團隊能力改變時，才知道哪些決定需要重新檢查。

下一篇會從 AWS 多帳號架構開始，看看當公司、系統與環境逐漸增加時，為什麼不一定適合把所有資源都放在同一個 AWS 帳號。