亞馬遜雲國際 AWS CloudFront SSL/TLS 證書無法綁定？ACM 證書 Region (us-east-1) 陷阱
先講結論：CloudFront 綁定 SSL/TLS 證書，ACM 必須在 us-east-1
很多人第一次替 CloudFront 綁定自訂網域時，會把憑證明明已經申請好了，卻怎麼都選不到。最常見的原因不是證書失效，也不是 CloudFront 壞掉，而是 ACM 證書放錯 Region。只要你是要給 CloudFront 用的 Viewer Certificate，ACM 幾乎就必須建立在 us-east-1，也就是美國北維吉尼亞區域。
這個限制很容易讓人誤判。因為平常我們習慣把資源放在離系統最近的區域，例如台灣、日本、新加坡，覺得延遲較低、管理也直覺。可是 CloudFront 是全球性服務，它的邊緣節點分布在世界各地，證書綁定卻不是跟著內容伺服器所在區域走，而是跟著 CloudFront 支援的控制面規則走。你如果把 ACM 證書申請在 ap-northeast-1、ap-southeast-1 或任何其他區域，CloudFront 就看不到它。
為什麼會出現這個陷阱
要理解這個限制，先不要把 CloudFront 當成一般區域型服務。像 EC2、ALB、RDS 這類服務，資源通常跟區域綁定得很明確，你在哪個 Region 建立，就在哪個 Region 管理。但 CloudFront 是全球分發網路，使用者連到的是離他最近的邊緣節點，後端控制邏輯卻有一部分集中在特定區域管理。也因為這樣，AWS 對 CloudFront 的自訂憑證支援，採用了固定的 ACM 區域規則。
白話一點說，就是 CloudFront 不在乎你的網站主機在哪個區域，卻很在乎你拿來做 TLS 終結的憑證是不是來自 us-east-1。這和人們對雲端的直覺很不一樣，所以才會屢屢踩雷。尤其團隊中如果有人習慣在建立資源時只看預設 Region，另一個人又在別的區域補申請證書，就很容易出現「證書狀態明明是 Issued，為什麼 CloudFront 還是不能選」這種情況。
最常見的症狀
- 亞馬遜雲國際 在 CloudFront 分配設定裡，找不到剛剛申請好的 ACM 證書。
- 介面顯示證書清單是空的，或只出現舊憑證。
- 部署時跳出憑證區域錯誤，提示必須在 us-east-1。
- Terraform 或 CLI 建立失敗，回傳 InvalidViewerCertificate 類型的錯誤。
- 證書狀態雖然已發行，但綁定後 CloudFront 仍無法生效。
如果你遇到上述任一種情況，先不要急著重建 CloudFront，也不要急著懷疑 DNS。先檢查 ACM 的 Region，通常就能省下大量時間。
先做三個基本檢查
處理這類問題時，最有效的方法不是憑感覺猜，而是按順序確認。第一步先看證書在哪個區域；第二步看憑證內容有沒有完整覆蓋網域；第三步看證書是否真的已經完成發行。
第一個檢查：Region 是否正確
進入 ACM 後，先確認右上角的區域是不是 us-east-1。很多人以為自己在 Console 裡已經切到正確帳號，其實 Region 仍然停留在其他地方。只要區域不對，即使證書完全正常，CloudFront 也不會列出來。
如果你是用 IAM 權限分工，也要注意有些人雖然能申請證書，卻沒有切換到 us-east-1 的習慣。最後看到的就是一張已簽發但無法使用的證書，結果問題被誤以為是權限不足。其實權限和 Region 是兩件事，不要混為一談。
第二個檢查：網域名稱是否完整
CloudFront 綁定證書時，看的不是你有沒有一張有效的 SSL，而是這張 SSL 能不能覆蓋你要對外公開的網域。例如你要用 www.example.com，證書裡就必須包含這個名稱；如果你同時要支援 example.com 和 www.example.com，最好把兩者都列進 SAN，或者使用適當的萬用字元證書。
這一點也很常被忽略。有人以為只要申請了 example.com，www.example.com 自然會一起包含，其實不一定。CloudFront 對名稱比對很嚴格，綁定不成功時，問題未必在 Region，也可能是名稱不匹配。
第三個檢查：證書是否已完成驗證與發行
如果你是用 DNS 驗證，確認 CNAME 紀錄是否已正確加入託管區域。若憑證還停在 Pending validation，CloudFront 當然無法使用。很多人只看 ACM 頁面上有一張新證書，就以為可以直接綁定，其實真正可用的前提是狀態必須是 Issued。
另外，若你匯入的是外部簽發的憑證，還要確認私鑰、憑證本體與中繼鏈是否完整。少了其中任一項，都可能導致 CloudFront 無法接受。
正確做法：在 us-east-1 重新建立或匯入證書
當你確認問題是 Region 不對，最直接的處理方式就是在 us-east-1 重新申請一張新的 ACM 證書。雖然很多人第一時間會想把舊證書搬過去，但 ACM 的區域屬性不是單純複製就能解決的。對 CloudFront 來說，最穩妥的方法就是直接在正確區域完成申請、驗證與發行。
實務上，流程通常是這樣：先切到 us-east-1，建立公有證書，填入要使用的主網域與所有別名，例如 example.com、www.example.com、static.example.com。接著選擇 DNS 驗證，將 AWS 提供的驗證紀錄加入對應的 DNS 代管區。等待驗證通過後，證書狀態變成 Issued，再回到 CloudFront 分配設定中選擇這張證書。
如果你有現成的外部商用證書，也可以匯入到 us-east-1。記住，匯入不是到哪個區域都一樣，CloudFront 依舊只認這個區域中的版本。換句話說，不管你證書來源是 ACM 還是外部 CA，只要要給 CloudFront 用，最後都得落在 us-east-1。
如果你使用 Route 53，會快很多
DNS 驗證最省事的情況，就是你的網域交給 Route 53 管理。因為建立驗證紀錄時，幾乎可以直接照著 ACM 的提示操作，不用手動翻查第三方 DNS 供應商的介面。只要 CNAME 放對，通常幾分鐘到數十分鐘就會完成驗證。
亞馬遜雲國際 如果網域不是在 Route 53，也不是不能做，只是要更小心。你必須確認驗證紀錄的名稱和值完全正確，包含多餘空白、錯誤拼字、舊紀錄殘留等問題。很多卡住的案例，其實只是 DNS 紀錄建立錯了一個字元。
CloudFront 綁證書時，還有幾個容易一起出錯的地方
亞馬遜雲國際 Region 雖然是最大魔王，但不是唯一問題。很多時候你修正了 us-east-1，卻還是綁不上去，原因常常落在其他設定上。以下幾個坑很值得一起檢查。
別名網域沒有加到 CloudFront
如果你想用自訂網域存取 CloudFront，除了證書要涵蓋該網域之外，CloudFront Distribution 本身也必須設定 Alternate domain name，也就是 CNAME。證書與分配設定必須兩邊對得上，少一邊都不行。
有些人只做了 DNS 指向，沒有把網域填進 CloudFront，結果瀏覽器看到的就是預設的 CloudFront 網址，或者直接回報名稱不匹配。這時候看起來像證書問題，其實是分配設定還沒完整。
證書類型與演算法不相容
ACM 支援的公開證書通常沒問題，但如果是手動匯入，還是要留意演算法與長度。CloudFront 對支援的密鑰與簽章演算法有一定限制，像過舊的設定就可能不被接受。實務上，選擇主流的 RSA 2048 或合適的 ECDSA 設定，通常最穩。
此外，中繼憑證鏈如果缺失，瀏覽器可能會對連線產生警告。雖然 CloudFront 有時候仍能部署，但使用者端會出現信任問題。這種情況不能只看有沒有綁上去，還要實際從外部檢查完整 TLS 鏈路。
憑證更新後，沒有等部署傳播完成
CloudFront 是全球分散式系統，設定變更需要時間傳播。你剛把證書換好，未必代表每個節點立刻同步完成。若你在調整過程中反覆切換證書、刪除再新增，很容易把問題弄得更複雜。比較好的做法是一次確認正確，再耐心等待分發完成。
用 Terraform 或自動化工具時更要小心
如果你是用 Terraform、CloudFormation 或 CI/CD 流程管理基礎設施，這個 Region 陷阱會更常見。原因很簡單：程式化部署通常會把 provider 的預設區域寫死，如果你沒有特別拆出一個 us-east-1 的 ACM provider，最後建立出來的證書就會落在錯誤區域。
很多團隊一開始都以為只要把 CloudFront 與 ACM 都交給同一套自動化流程就能順利完成，實際上卻常常卡在 provider 設定。做法上，應該把 CloudFront 需要的 ACM 資源獨立出來，明確指定 us-east-1。這樣不論是第一次部署，還是後續更新憑證，都能維持一致性。
另一個常見問題是憑證發行時間。如果 pipeline 在 ACM 還沒完成 DNS 驗證時就直接去綁 CloudFront，失敗是必然的。自動化流程要考慮到驗證等待時間，否則你會得到一個看似成功建立、實際無法使用的分配。
如果已經卡住，照這個順序排查
遇到 CloudFront 不能綁證書時，最有效率的排查順序通常是先粗後細。不要一開始就改 DNS、改分配、改私鑰，先把最關鍵的條件一個一個排除。
- 先確認 ACM 是否在 us-east-1。
- 亞馬遜雲國際 再確認證書狀態是否為 Issued。
- 接著檢查證書是否包含要使用的網域名稱。
- 再確認 CloudFront Distribution 是否已加入對應的 Alternate domain name。
- 最後才檢查 DNS 指向與傳播是否完成。
這個順序很重要，因為如果 Region 錯了，後面的檢查幾乎都只是浪費時間。先修正最根本的條件，才有意義繼續往下查。
一個容易被忽略的觀念：CloudFront 不是網站主機，是入口
很多人把 CloudFront 當成只是 CDN，或是把它想成另一台前端伺服器，所以會自然認為證書應該跟網站主機放在同一區域。其實這個想法不太對。CloudFront 更像是整個網站的全球入口，它負責把使用者連線在邊緣先終結，再把請求送往來源站點。也因為它站在入口位置，所以 TLS 憑證的管理方式和後端主機不一樣。
一旦理解這件事，us-east-1 的限制就不再神祕。它不是任意設計的障礙，而是 CloudFront 架構與 ACM 整合方式的一部分。你不必喜歡這個規則，但你必須尊重它。只要把握住這個原則，之後在建立多網域分發、更新憑證、整合自動化流程時，都會順很多。
結語：先記住這一句，就能少踩很多坑
如果你今天只想記一件事，那就是：CloudFront 要綁 ACM 證書，請先到 us-east-1 檢查。這不是小細節，而是成敗關鍵。許多看似複雜的憑證問題，最後都只是區域選錯。把 Region 放對，再去看網域、驗證、鏈路與分配設定，排查效率會高很多。
下次你再遇到 CloudFront 無法選取證書、綁定失敗、或部署後仍顯示錯誤憑證時，別急著推翻整個架構。先看 ACM 是否真的在 us-east-1。這一步做對了，通常就已經解掉一半以上的問題。
