這30天的Lab皆在AWS區域「us-east-1」

注意：如果要選用其他的區域，會有機會因為區域問題，導致部分服務尚未啟用！

一、前言

在雲端網站部署過程中，域名與憑證是基礎但又繁瑣的環節，若透過手動申請與驗證，常會遇到 DNS 記錄配置錯誤、憑證過期忘記更新等問題。
尤其是明年開始，網頁憑證的最長效期將會從原本的398天率續縮短，可參考文章末的連結[1]。

利用 Route 53 搭配 ACM（AWS Certificate Manager），即可自動化驗證與續期，避免人為疏失。
而且在AWS上的服務，通常都可以直接一鍵配置DNS，故如果將域名託管在AWS上，可以在部署上省掉DNS配置上的流程。

(1) 痛點：傳統憑證需要手動申請、下載、安裝，更新時還得重複流程，容易出錯。
(2) 必要性：利用 ACM 與 Route 53，自動完成憑證申請與 DNS 驗證，節省人力並提高可靠性。
(3) 在整體 Serverless 架構中的定位：這是日後所有前端與 API Gateway、CloudFront 使用 HTTPS 的基礎，屬於「安全與可用性」的起點。

最佳實務（Best Practices）：
(1) 建立ACM憑證時建議同時加入根網域（example.com）與萬用子網域（*.example.com），避免日後需要額外申請。
(2) 務必選擇 DNS validation，不要用 Email validation，這樣 ACM 才能自動續期。
(3) 將 ACM 憑證建立在 us-east-1（N. Virginia），因為 CloudFront 只接受該區的憑證。

二、需要使用到的服務

• Route 53：管理自有網域，並自動建立 ACM 驗證所需的 DNS CNAME 記錄。
• ACM（AWS Certificate Manager）：申請並管理公有 SSL/TLS 憑證，自動完成續期。
• IAM（可選）：建立最小權限策略，限制使用者只能操作 ACM/Route 53。

三、架構/概念圖

四、技術重點

此架構說明只要網域託管在 Route 53，ACM 申請憑證即可自動完成驗證並持續有效。

ACM 可以使用的主要 AWS 服務：

ACM 憑證無法匯出，因為它們是設計來與 AWS 服務無縫整合的。以下是 ACM 最常見的應用服務：

1. CloudFront (CDN)
   • 用途： 這是 ACM 最常見的搭配服務。您需要一個 ACM 憑證來為您的 CloudFront 分發啟用 HTTPS，這樣您的網站或應用程式才能安全地透過 CloudFront 加速。
2. ELB (Elastic Load Balancing)
   • 用途： ELB 扮演著將流量分發到多個後端伺服器的角色。為了確保客戶端到 ELB 之間的通訊安全，您可以在 ELB 的監聽器（listener）上綁定 ACM 憑證。
3. API Gateway
   • 用途： 當您想為您的 API 建立自訂網域（例如 api.yourdomain.com）並啟用 HTTPS 時，您可以在 API Gateway 的設定中，直接使用 ACM 憑證。
4. Elastic Beanstalk
   • 用途： 如果您使用 Elastic Beanstalk 來部署應用程式，您可以將 ACM 憑證直接整合到您的環境中，以啟用 HTTPS。
5. AWS App Runner
   • 用途： 對於 AWS 的容器服務 App Runner，ACM 憑證可以自動整合，為您的應用程式提供安全的 HTTPS 端點。
6. AWS Global Accelerator
   • 用途： 這個服務旨在優化全球網路流量。您可以在 Global Accelerator 上使用 ACM 憑證，以確保從客戶到您的服務端點之間的連線安全。

五、Lab流程

1️⃣ 前置作業

• 準備好在 Route 53 註冊或移轉進來的網域（例如：example.com）。
  💡首先，你要有一個自己的網域，這邊以「Gandi」為例。
  

• 確保擁有 ACM 與 Route 53 的管理權限。

2️⃣ 主要配置

1. 託管Route 53

1. 進入「Route 53」服務頁面。。
   

2. 創建新的託管區域。
   

3. 輸入域名，並選擇託管公有網域。
   

4. 複製NS紀錄值。
   

5. 在自己的DNS內，修改DNS伺服器位址。
   

6. 之後就可以開始使用Route 53做DNS管理了。
   

2. 創建ACM憑證

1. 點選「Certificate Manager」服務頁面。
   

2. 點選「請求」，申請一張新的SSL。
   

3. 請求一張新的憑證。
   

4. 輸入自己的網域，建議購買「*.」開頭的網域SSL（Wildcard SSL），因為這樣可以適用於不同前綴（子網域）。
   
   

5. 添加CNAME紀錄，用以驗證網域網域所有權。（這邊可以點選按鈕，自動將紀錄值加入Route 53中）
   

6. 驗證完成畫面。（通常需要等待1~5分鐘，等待SSL憑證下發）
   

3️⃣ 測試驗證

• 確認憑證狀態為 Issued。
  
• 若驗證失敗，檢查 Route 53 的 DNS 記錄是否正確建立。

六、結語

本篇 Lab 展示如何透過 Route 53 + ACM 自動化管理憑證與網域驗證，解決傳統憑證管理的痛點。完成後，我們能確保整個 Serverless 架構在後續的 CloudFront、API Gateway 等服務中，均能安全使用 HTTPS，且完全免去人工更新憑證的風險，提升了安全性與維運便利性。

【補充】
如果網域沒有託管在Route 53上，可以自行添加CNAME紀錄值。(但是這不能自動續約)

-------------- 參考資料 --------------

[1]iThome - SSL/TLS憑證最長效期2029年將縮減成47天：
https://www.ithome.com.tw/news/168409