AWS Certificate Manager (ACM)

解決する課題

• TLS/SSL 証明書を外部 CA から購入・更新する手間とコストをなくしたい
• 証明書の有効期限切れによるサービス停止を避けたい
• 秘密鍵をサーバーに置かず安全に管理したい
• 複数のロードバランサーや CDN に証明書を一元的に配布したい

ACM は、HTTPS 通信に必要な証明書のライフサイクル（発行・保管・更新・配布）をマネージドに引き受け、HTTPS 終端を行う AWS サービスへ紐付けるだけで使える状態にします。

主要概念と用語

• パブリック証明書: ACM の Amazon Trust Services を CA として発行する公的に信頼される証明書。インターネット向けサイトに使い、発行は無料
• プライベート証明書: AWS Private CA（旧 ACM Private CA）が発行する、組織内部向けの証明書。内部 API やマイクロサービス間通信などに使う
• ドメイン検証（DV）: 証明書を発行する前にドメインの所有・管理を確認する手続き。DNS 検証とメール検証の2方式がある
• DNS 検証: ACM が指定する CNAME レコードを DNS に登録して所有を証明する方式。一度設定すれば自動更新が無人で回るため推奨
• メール検証: ドメインの登録者・管理者メールアドレス宛の確認メールに応答する方式。手動操作が必要で更新時も対応が要る
• マネージド更新: ACM が有効期限前に証明書を自動で再発行・差し替えする仕組み
• ワイルドカード証明書: *.example.com のように同一ドメイン配下の複数サブドメインを1枚でカバーする証明書
• SAN（Subject Alternative Name）: 1枚の証明書に複数のドメイン名を含める拡張
• 証明書のインポート: 外部 CA で発行した証明書を ACM に取り込んで管理する機能。インポート証明書は自動更新の対象外

仕様・制限・クォータ

• 発行・利用は無料: パブリック証明書の発行と、対応 AWS サービスへの利用に料金はかからない。プライベート CA は別途課金される
• リージョンスコープ: 証明書はリージョン単位の管理。複数リージョンの ELB に使うなら各リージョンで発行・管理する
• CloudFront はバージニア北部（us-east-1）固定: CloudFront に紐付ける証明書は us-east-1 で発行・インポートする必要がある
• 秘密鍵はエクスポート不可: ACM が発行したパブリック証明書の秘密鍵は取り出せず、対応サービスへの紐付けでのみ利用できる（後述のエクスポート可能なパブリック証明書を除く）
• 使えるサービスが限定: HTTPS 終端を ACM 連携でサポートするサービス（ELB、CloudFront、API Gateway など）に紐付けて使う。EC2 上の任意の Web サーバーに直接インストールする用途には向かない
• 検証されないと発行されない: DV が完了するまで証明書は Pending validation のまま発行されない
• 証明書数や検証待ち時間などには上限・所要時間があり、件数の上限はクォータ引き上げ申請で緩和できる場合がある

内部の仕組み

ACM の中核は「ドメイン検証」と「マネージド更新」です。発行時には、申請したドメインを本当に管理しているかを ACM が確認します。DNS 検証では、ACM が一意の CNAME レコード値を提示し、利用者がそれを対象ドメインの DNS に登録します。ACM はその CNAME を解決できることをもって所有を確認します。

更新時もこの仕組みが鍵になります。DNS 検証で発行した証明書は、検証用 CNAME が DNS に残っている限り、ACM が有効期限前に所有を再確認して自動で新しい証明書を再発行します。新しい証明書は同じ ARN のまま中身が差し替わるため、ELB や CloudFront 側の設定変更は不要です。

秘密鍵は ACM 内で生成・保管され、平文で外部に出ません。HTTPS 終端を行う対応サービス（ELB のノードや CloudFront のエッジ）に対してのみ、AWS 内部の仕組みで安全に配布されます。これにより、利用者はサーバーに秘密鍵ファイルを置く運用から解放されます。

設計パターン / ベストプラクティス

• DNS 検証を標準にする: メール検証は更新のたびに手動対応が要るため、自動更新が回る DNS 検証を選ぶ
• HTTPS 終端は ELB / CloudFront に寄せる: ACM 証明書をこれらに紐付け、バックエンドの暗号化負荷と証明書管理から解放する
• CloudFront 用は us-east-1 で先に発行: グローバル配信を設計したら、証明書だけ別リージョン（us-east-1）で確保しておく
• ワイルドカード + SAN で枚数を減らす: サブドメインが多い構成は *.example.com とルートドメインを SAN にまとめて管理を簡素化する
• 内部通信は AWS Private CA: 社内 API やサービスメッシュなどパブリックに信頼させる必要がないものはプライベート証明書を使う
• 検証用 CNAME を消さない: 自動更新の前提条件なので、検証に使った DNS レコードを誤って削除しない

運用・監視

• 有効期限を監視する: ACM は証明書の有効期限が近づくと Amazon EventBridge にイベントを発行し、DaysToExpiry メトリクスを CloudWatch に出力する。これをアラーム化して期限切れを事前に検知する
• 更新失敗のアラート: 自動更新は検証用 CNAME の喪失やドメイン解決不能で失敗しうる。更新失敗イベントを通知に連携して早期に気づく
• インポート証明書は手動更新: 外部発行をインポートした証明書は自動更新されないため、期限管理を別途運用する
• 証明書の利用先を把握する: どの ELB / CloudFront / API Gateway に紐付いているかを定期的に棚卸しし、不要証明書を削除する

コスト

• パブリック証明書は無料: 発行と対応 AWS サービスでの利用に課金はない
• AWS Private CA は有料: CA インスタンスの月額と、発行した証明書ごとの料金がかかる。内部用途で多数発行するときはコスト試算が必要
• エクスポート可能なパブリック証明書は標準のマネージド利用と料金体系が異なるため、用途に応じて確認する
• 証明書そのものより、紐付ける ELB や CloudFront、データ転送の料金が全体コストの中心になることが多い

セキュリティ

• 秘密鍵を露出させない: 発行したパブリック証明書の秘密鍵は ACM 内に留まり、サーバーへ平文配置する運用を排除できる
• IAM で操作を制御: 証明書の発行・削除・利用の権限を IAM ポリシーで最小権限に絞る
• CloudTrail で監査: 発行・削除・更新などの API 操作は CloudTrail に記録されるため、誰がいつ何をしたかを追跡できる
• 暗号化通信の終端を統制: HTTPS 終端を ELB / CloudFront に集約することで、暗号スイートや TLS バージョンのポリシーを一元管理しやすくなる

Well-Architected の観点

• セキュリティ: 秘密鍵をサービス内に隔離し、IAM と CloudTrail で操作を統制することで、鍵の管理リスクと人的ミスを減らす。マネージド更新により期限切れによる予期せぬ HTTPS 停止を防ぎ、可用性面の信頼性にも寄与する
• 運用負荷の観点でも、証明書の調達・更新という反復作業を自動化し、運用上の手作業を削減する

試験で問われるポイント

関連サービス・比較

ACM はパブリック証明書を扱うサービスで、組織内部向けの認証局が必要な場合は AWS Private CA を組み合わせます。両者の違いを整理します。

ハンズオン / CLI例

# DNS 検証でパブリック証明書をリクエスト（東京リージョンの例）
# CloudFront 用なら --region us-east-1 を指定すること
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS \
  --region ap-northeast-1

# 発行された証明書の検証用 CNAME（DNS に登録する値）を確認
aws acm describe-certificate \
  --certificate-arn <証明書のARN> \
  --region ap-northeast-1 \
  --query "Certificate.DomainValidationOptions[].ResourceRecord"

# 上で得た CNAME を対象ドメインの DNS に登録すると、検証後に発行される
# （Route 53 ならコンソールから自動登録も可能）

# 発行済み・検証待ちの証明書を一覧表示
aws acm list-certificates --region ap-northeast-1