【要約】外部DNS（Route 53以外）でACM公開証明書を自動更新する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
AWSでWebサービスを構築する運用担当者が、DNS管理をRoute 53以外で行っている場合に直面する課題について記述する。Route 53を使用していない環境では、ACMの自動連携機能が制限されるため、以下の問題が発生する。
- ・ACMの「Route 53でレコードを作成」ボタンが利用できない。
- ・検証用CNAMEレコードを手動で外部DNSに登録する必要がある。
- ・設定ミスやレコードの誤削除により、証明書の自動更新が停止するリスクがある。
- ・CloudFrontとALBでリージョンが異なる場合、証明書管理が複雑化する。
// Approach
外部DNS環境下でACM証明書の自動更新を実現するため、以下の手順で検証プロセスを構築する。ACMが提示する検証用値を外部DNSに正しく配置し、リソースへ紐付けることが核心である。
1.ACMでパブリック証明書をリクエストし、検証方法として「DNS検証」を選択する。
2.ACMから提示される検証用CNAME名と値を、外部DNSプロバイダの管理画面に手動で登録する。
3.発行された証明書を、CloudFront（us-east-1）やALB（各リージョン）にアタッチする。
4.「証明書のアタッチ」と「CNAMEレコードの維持」の2条件を継続的に満たす運用を行う。
// Result
本手法を適用することで、既存のDNS運用を変えずに証明書のライフサイクル管理を自動化できる。具体的には以下の成果が得られる。
- ・一度CNAMEを登録すれば、有効期限が来るたびにAWSが自動で再検証・更新を行う。
- ・CloudFront用とALB用でリージョンが異なる場合でも、同一ドメインならCNAMEは共通のため、登録作業は1件で済む。
- ・証明書のARNが更新後も変わらないため、CloudFrontやALB側の設定変更が不要となる。
Senior Engineer Insight
> 既存のDNS運用を維持しつつ、証明書管理のみをAWSに集約できる点は極めて合理的だ。ただし、CNAMEレコードの管理が自動更新の生命線となる。DNS整理や移行時に誤って削除すると、証明書失効という致命的な障害を招く。また、ACMEプロトコル経由の証明書はマネージド更新の対象外である点など、仕様の細部への理解も不可欠だ。運用設計においては、DNSレコードの変更管理プロセスにACMの検証レコードを含めるべきである。