AWS Certificate Manager v2.0 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Certificate Manager（ACM） は、SSL/TLS 証明書の発行・管理・自動更新を無料で提供するマネージドサービス であり、CloudFront・ALB・API Gateway などの AWS サービスに証明書を簡単に統合できます。HTTPS化の複雑性を排除し、業界標準の自動更新により期限切れリスクをゼロにします。本ドキュメントは、ACM の仕組み・検証方法・ユースケース・セキュリティ最適化・2026年の最新動向を体系的に解説する完全ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています：

初心者向け： ACM とは何か、なぜ必要かを学びたい方
開発者向け： Public/Private 証明書の実装、検証方法、自動更新の仕組み
インフラ・SRE 向け： CloudFront 証明書、マルチリージョン対応、Private CA 連携
セキュリティ担当者向け： 証明書ポリシー、監査、コンプライアンス要件への対応
意思決定者向け： Let’s Encrypt・DigiCert・Cloudflare SSL との比較・投資判断

2026 年の ACM エコシステム

Post-Quantum Cryptography（PQC）対応準備： 量子耐性署名アルゴリズム（ML-DSA）サポート
ACM Private CA 統合深化： Private Issuer による自動更新証明書の発行
Multi-Region Certificate 強化： クロスリージョン証明書複製の簡素化
External Key Store（XKS）統合： CloudHSM・オンプレミス HSM との連携
AI 駆動監視： 証明書使用状況の異常検知、有効期限予測

概要
ACM が解決する課題
主な特徴
アーキテクチャ
証明書の種類
Public vs Private 証明書
検証方法（DNS / Email）
Auto Renewal（自動更新）
コアコンポーネント
主要ユースケース
設定・操作の具体例（CLI / IaC）
統合サービス一覧
ワイルドカード・マルチドメイン SAN
Wildcard Certificate 運用
ACM Private CA との連携
CloudFront 専有制限
証明書チェーン・エクスポート
セキュリティ・監査
トラブルシューティング
類似サービス比較
ベストプラクティス
2025-2026 最新動向
学習リソース
実装例・チェックリスト
まとめ

概要

初心者向けメモ： ACM は「HTTPS 証明書を無料で自動管理するサービス」です。従来、Let’s Encrypt や商用 CA（DigiCert等）から証明書を取得すると、90日ごとに手動更新 が必要で、期限切れによるサービス停止のリスクがありました。ACM は CloudFront / ALB / API Gateway と統合され、自動更新・無料・管理不要 を実現します。

AWS Certificate Manager は以下を提供する統合証明書管理プラットフォームです：

機能	説明
Public SSL/TLS 証明書	ブラウザが自動信頼する無料公開証明書
Private CA 発行証明書	企業内・マイクロサービス向けプライベート証明書
証明書インポート	外部 CA 発行の証明書を ACM で管理
自動更新（DNS）	Route 53 CNAME で自動検証・自動更新
Multi-Domain（SAN）	複数ドメイン・ワイルドカード対応
CloudFront 統合	グローバル CDN での SSL/TLS オフロード

ACM が解決する課題

1. 証明書期限切れによるサービス停止リスク

課題：Let’s Encrypt（90日更新）や商用証明書（1年更新）は手動管理が必要で、更新漏れでサービス停止

ACM の解決：

自動更新により期限切れゼロを保証
CloudWatch アラート + 更新失敗時の通知
60日前から自動更新試行

2. 証明書購入・更新のコスト・手続き

課題：年間数千〜数万円の商用証明書コスト、ドメイン検証・更新申請の手間

ACM の解決：

公開証明書は完全無料
ワイルドカード・マルチドメイン SAN も無料
検証 CNAME の自動提示で数分で発行

3. 複数リージョン・複数リソースの証明書管理

課題：ALB が複数リージョンにある場合、各リージョンで証明書を購入・管理する必要がある

ACM の解決：

各リージョンで無料で証明書をリクエスト
Private CA 使用時は Multi-Region Issuer で統一管理

4. CloudFront + オンプレ SSL の複雑性

課題：CloudFront + オンプレミス HTTPS 統合時に複数の証明書管理が必要

ACM の解決：

CloudFront 用証明書（us-east-1）+ オンプレ用インポート証明書で統一管理

主な特徴

graph TD
    ACM["AWS Certificate Manager"]
    
    ACM -->|Public| PubCert["パブリック証明書<br/>DV検証<br/>無料"]
    ACM -->|Private| PrivCert["プライベート証明書<br/>Private CA<br/>有料"]
    ACM -->|Import| ImpCert["外部CA証明書<br/>Let's Encrypt等<br/>無料"]
    
    PubCert -->|DNS検証| Route53["Route 53 CNAME<br/>自動更新"]
    PubCert -->|Email検証| Email["ドメイン管理者メール<br/>手動承認"]
    
    PrivCert -->|Root CA| RootCA["Root CA<br/>企業内PKI"]
    PrivCert -->|Subordinate| SubCA["Subordinate CA<br/>ECS/EKS向け"]
    
    Route53 -->|CloudFront| CFront["CloudFront<br/>グローバルCDN"]
    Route53 -->|ALB| ALB["ALB/NLB<br/>ロードバランサー"]
    Route53 -->|API GW| APIGW["API Gateway<br/>REST/HTTP"]

1. 自動更新による期限切れ排除

DNS 検証使用時、Route 53 CNAME レコードが残っていれば自動更新
更新失敗は CloudWatch アラート + SNS 通知
手動操作不要で、5 年間ノーメンテナンス

2. 完全無料（パブリック証明書）

AWS マネージドサービスで利用する限り完全無料
ワイルドカード（*.example.com）も無料
Multi-Domain SAN（複数ドメイン）も無料

3. 複数ドメイン・ワイルドカード対応

証明書タイプ	対応	例
Single Domain	✅	`example.com` のみ
Wildcard	✅	`*.example.com`（全サブドメイン対応）
Multi-Domain SAN	✅	`example.com`, `api.example.com`, `cdn.example.com` 同時保護
Multi-Wildcard	✅	`.example.com`, `.api.example.com`

4. CloudFront グローバル配信

CloudFront の証明書は必ず us-east-1で発行する必要があり、ACM がこの要件を担保

5. ACM Private CA 統合

Private CA と統合して、社内サービス・IoT デバイス・マイクロサービス用の信頼されたプライベート証明書を発行

アーキテクチャ

高可用性・リージョン分散

(1) リージョンA（ap-northeast-1）
    ├─ ACM 証明書（ALB 用）
    ├─ ALB → ECS サービス → RDS
    └─ 証明書は自動更新（Route 53 CNAME）

(2) リージョンB（us-west-2）
    ├─ ACM 証明書（ALB 用）
    ├─ ALB → ECS サービス → RDS
    └─ 証明書は自動更新（Route 53 CNAME）

(3) グローバル（CloudFront）
    ├─ ACM 証明書（us-east-1 発行）
    ├─ CloudFront 配信 → オリジンは複数リージョン ALB
    └─ 証明書は自動更新（Route 53 CNAME）

検証フロー（DNS 方式）

ステップ 1: ACM でドメイン検証をリクエスト
  → 検証用 CNAME レコードを生成（例: _abc123.example.com CNAME _xyz789.acm-validations.aws）

ステップ 2: Route 53 に CNAME を追加
  → ACM コンソール内で "Create record in Route 53" をワンクリック

ステップ 3: ACM が Route 53 を照会して CNAME を確認
  → 数分で検証完了（通常 <10 分）

ステップ 4: 証明書発行 → [CloudFront / ALB / API Gateway] に自動適用

ステップ 5: 有効期限 60 日前から自動更新試行
  → CNAME が残っていれば自動更新成功
  → 手動操作不要

Email 検証フロー（代替方法）

ステップ 1: ACM でドメイン検証をリクエスト

ステップ 2: ドメイン所有者のメールアドレスに確認メール送信
  例: admin@example.com, hostmaster@example.com など

ステップ 3: メール内のリンクをクリックして検証承認

ステップ 4: 証明書発行 → リソースに手動適用

ステップ 5: 有効期限 60 日前にメール通知
  → 手動で再承認が必要（手動更新必須）

証明書の種類

Public Certificate（パブリック証明書）

概要: AWS 発行の公開信頼証明書

特性:
  - ブラウザ・OS が自動信頼
  - Domain Validation（DV）のみ実施（Organization Validation なし）
  - 無料

使用例:
  - CloudFront のオリジン SSL
  - ALB / API Gateway の HTTPS
  - Elastic Beanstalk・AppSync

有効期限: 13 ヶ月（2023 年時点の CA/Browser Forum 決定）

自動更新: DNS 検証 + Route 53 CNAME で自動

Private Certificate（プライベート証明書）

概要: AWS Private CA から発行される企業内証明書

特性:
  - 内部ドメイン（*.internal など）対応
  - ACM が Private CA を発行者として機能
  - 有料（CA 月額 $400 + 証明書発行料 $0.75）

使用例:
  - マイクロサービス間 mTLS
  - ECS/EKS サービス間通信
  - IoT デバイス認証
  - コード署名

有効期限: 設定可能（デフォルト 1 年）

自動更新: ACM + Private CA で自動更新可能

Imported Certificate（インポート証明書）

概要: 外部 CA（Let's Encrypt・DigiCert など）から取得した証明書を ACM で管理

特性:
  - 既存証明書の統一管理
  - ACM では自動更新できず（ACM 管理外で更新して再インポート）
  - 無料

使用例:
  - Let's Encrypt 証明書をインポートして ALB で使用
  - 商用 CA 証明書の管理
  - 既存インフラの証明書を ACM に統合

有効期限: インポート時の有効期限に依存

自動更新: 不可（手動で更新・再インポート必須）

Public vs Private 証明書

観点	Public 証明書	Private 証明書
信頼元	ブラウザ・OS が自動信頼	CA 証明書をクライアントにインストール必須
ドメイン要件	パブリック FQDN が必須（example.com 等）	内部ドメイン可（*.internal.corp など）
DV 検証	DNS / Email 検証	Private CA が発行、検証不要
コスト	無料	CA 月額 $400 + 証明書発行 $0.75
使用場所	CloudFront・ALB・API Gateway 等	マイクロサービス・IoT・内部サービス
有効期限	13 ヶ月	カスタマイズ可能
自動更新	✅ DNS 検証で自動	✅ Private CA で自動

検証方法（DNS / Email）

DNS 検証（推奨）

# ステップ 1: ACM でドメイン検証をリクエスト
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names www.example.com api.example.com \
  --validation-method DNS \
  --region ap-northeast-1

# 出力例:
# CertificateArn: arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123-def456

# ステップ 2: 検証用 CNAME を取得
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123-def456 \
  --region ap-northeast-1

# 出力：
# DomainValidationOptions:
#   - DomainName: example.com
#     ValidationDomain: example.com
#     ResourceRecord:
#       Name: _abc123.example.com
#       Type: CNAME
#       Value: _xyz789.acm-validations.aws

# ステップ 3: Route 53 に CNAME を自動作成（ワンクリック）
# ACM コンソール → "Validation" → "Create record in Route 53"

# または AWS CLI で手動作成：
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "_abc123.example.com",
          "Type": "CNAME",
          "TTL": 300,
          "ResourceRecords": [
            {"Value": "_xyz789.acm-validations.aws"}
          ]
        }
      }
    ]
  }'

# ステップ 4: 検証状態を確認
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123-def456 \
  --region ap-northeast-1 \
  --query 'Certificate.DomainValidationOptions[*].[DomainName,ValidationStatus]'

# 出力例:
# [[example.com, SUCCESS], [www.example.com, SUCCESS], [api.example.com, SUCCESS]]

DNS 検証の利点：

自動更新対応（CNAME が残っていれば自動）
メール受信不要
Route 53 との統合で管理の手間が最小

Email 検証（代替）

# ステップ 1: Email 検証でリクエスト
aws acm request-certificate \
  --domain-name example.com \
  --validation-method EMAIL \
  --region ap-northeast-1

# ステップ 2: ドメイン所有者のメールアドレスに検証メール送信
# 送信先: admin@example.com, hostmaster@example.com, postmaster@example.com など

# ステップ 3: メール内のリンクをクリックして検証

# ステップ 4: 有効期限 60 日前に手動更新通知メール
# 手動で再度メール確認が必要

Email 検証の注意：

手動更新が必須（DNS 検証に劣る）
「admin@」「hostmaster@」「postmaster@」等の標準メールが必須
Route 53 以外のレジストラ使用時のみ推奨

Auto Renewal（自動更新）

DNS 検証時の自動更新フロー

有効期限 60 日前
  ↓
ACM が自動更新を試行
  ↓
Route 53 で CNAME を確認
  ↓
CNAME がある → 検証成功 → 新証明書発行 → 自動適用
CNAME がない → 検証失敗 → CloudWatch アラート + SNS 通知

自動更新の前提条件

条件1: DNS 検証を使用
  - Email 検証の場合は手動更新必須

条件2: Route 53 CNAME が残っている
  - CNAME を削除すると自動更新が停止

条件3: リソースが ACM と同じリージョン
  - CloudFront は us-east-1 必須
  - ALB は各リージョン

条件4: ACM が証明書を発行（インポート証明書は自動更新不可）

CloudWatch で自動更新を監視

# 自動更新失敗時のアラーム設定
aws cloudwatch put-metric-alarm \
  --alarm-name ACM-Certificate-Renewal-Failed \
  --alarm-description "Alert when ACM certificate renewal fails" \
  --metric-name CertificateExpiration \
  --namespace AWS/CertificateManager \
  --statistic Minimum \
  --period 86400 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123-def456

# SNS 通知設定
aws sns create-topic --name acm-renewal-alerts
aws cloudwatch put-metric-alarm \
  --alarm-name ACM-Certificate-Renewal-Failed \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:acm-renewal-alerts

コアコンポーネント

1. Certificate Request（証明書リクエスト）

# 単一ドメイン
aws acm request-certificate \
  --domain-name example.com \
  --validation-method DNS \
  --region ap-northeast-1

# ワイルドカード + マルチドメイン SAN
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names \
    www.example.com \
    api.example.com \
    "*.sub.example.com" \
  --validation-method DNS \
  --region ap-northeast-1

# Tags 付き
aws acm request-certificate \
  --domain-name example.com \
  --validation-method DNS \
  --tags Key=Environment,Value=Production Key=Team,Value=Platform \
  --region ap-northeast-1

2. Domain Validation（ドメイン検証）

検証方法別のフロー

方法	実装	所要時間
DNS CNAME	Route 53 に CNAME 追加	数分〜10分
Email	メール確認リンククリック	数分（手動）
Wildcard	ベースドメイン検証で全サブドメイン対応	数分〜10分

3. Certificate Metadata（メタデータ）

# 証明書情報を取得
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123-def456 \
  --region ap-northeast-1 \
  --query 'Certificate.[
    DomainName,
    SubjectAlternativeNames,
    Status,
    Type,
    CreatedAt,
    NotAfter,
    DomainValidationOptions[*].[DomainName,ValidationStatus]
  ]'

4. Certificate Association（リソースへの適用）

# ALB リスナーに適用
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:...:listener/app/... \
  --default-actions Type=forward,TargetGroupArn=... \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:...:certificate/...

# CloudFront ディストリビューションに適用
aws cloudfront update-distribution \
  --id E1234ABCD \
  --distribution-config '{...ViewerCertificate": {
    "ACMCertificateArn": "arn:aws:acm:us-east-1:...",
    "SSLSupportMethod": "sni-only"
  }...}'

主要ユースケース

1. Web サイトの HTTPS 化（ALB + ACM）

# シナリオ: example.com を ALB で HTTPS 公開

# ステップ 1: ACM で証明書をリクエスト
CERT_ARN=$(aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names www.example.com \
  --validation-method DNS \
  --region ap-northeast-1 \
  --query 'CertificateArn' \
  --output text)

# ステップ 2: Route 53 CNAME を自動作成（ワンクリック）
# → ACM コンソール → "Validation" → "Create record in Route 53"

# ステップ 3: 検証待機
sleep 60

# ステップ 4: ALB リスナー 443 に証明書を適用
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:...:loadbalancer/app/my-alb/... \
  --protocol HTTPS \
  --port 443 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:... \
  --certificates CertificateArn=$CERT_ARN

# ステップ 5: HTTP → HTTPS リダイレクト
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:...:listener/app/.../80 \
  --default-actions Type=redirect,RedirectConfig="{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}"

2. CloudFront CDN の SSL/TLS オフロード

# シナリオ: cdn.example.com を CloudFront で全世界配信

# ステップ 1: us-east-1 で証明書をリクエスト（CloudFront は us-east-1 必須）
CERT_ARN=$(aws acm request-certificate \
  --domain-name cdn.example.com \
  --subject-alternative-names "*.cdn.example.com" \
  --validation-method DNS \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text)

# ステップ 2: Route 53 に CNAME を自動作成

# ステップ 3: CloudFront ディストリビューションを作成（ACM 証明書指定）
aws cloudfront create-distribution \
  --distribution-config '{
    "CallerReference": "my-cdn-'$(date +%s)'",
    "DefaultCacheBehavior": {
      "TargetOriginId": "myOriginId",
      "ViewerProtocolPolicy": "redirect-to-https",
      "ForwardedValues": {"QueryString": false},
      "TrustedSigners": {"Enabled": false, "Quantity": 0}
    },
    "Origins": {
      "Quantity": 1,
      "Items": [
        {
          "Id": "myOriginId",
          "DomainName": "api.example.com",
          "CustomOriginConfig": {
            "HTTPPort": 80,
            "HTTPSPort": 443,
            "OriginProtocolPolicy": "https-only"
          }
        }
      ]
    },
    "ViewerCertificate": {
      "ACMCertificateArn": "'$CERT_ARN'",
      "SSLSupportMethod": "sni-only",
      "MinimumProtocolVersion": "TLSv1.2_2021"
    },
    "Enabled": true
  }'

3. API Gateway の API エンドポイント保護

# シナリオ: api.example.com/v1 を API Gateway で HTTPS 保護

# ステップ 1: ACM で証明書をリクエスト
CERT_ARN=$(aws acm request-certificate \
  --domain-name api.example.com \
  --validation-method DNS \
  --region ap-northeast-1 \
  --query 'CertificateArn' \
  --output text)

# ステップ 2: 検証待機

# ステップ 3: Custom Domain Name を作成
aws apigateway create-domain-name \
  --domain-name api.example.com \
  --certificate-arn $CERT_ARN \
  --regional-certificate-arn $CERT_ARN \
  --region ap-northeast-1

# ステップ 4: Route 53 にエイリアスレコードを追加
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z2FDTNDATAQYW2",
            "DNSName": "d123456.cloudfront.net",
            "EvaluateTargetHealth": false
          }
        }
      }
    ]
  }'

4. IoT デバイスの mTLS 通信（Private CA）

# シナリオ: AWS IoT Core で IoT デバイスに証明書を配布

# ステップ 1: ACM Private CA を作成
CA_ARN=$(aws acm-pca create-certificate-authority \
  --certificate-authority-configuration \
    KeyAlgorithm=RSA_2048,\
    SigningAlgorithm=SHA256WITHRSA,\
    Subject='{
      "C": "JP",
      "ST": "Tokyo",
      "L": "Tokyo",
      "O": "MyCompany",
      "OU": "IoT",
      "CN": "IoT Root CA"
    }' \
  --certificate-authority-type ROOT \
  --region ap-northeast-1 \
  --query 'CertificateAuthorityArn' \
  --output text)

# ステップ 2: Root CA 証明書をリクエスト
aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn $CA_ARN

# ステップ 3: Root CA 証明書に署名
# (省略: 実際には AWS API で署名)

# ステップ 4: IoT デバイス向け証明書をリクエスト
aws acm-pca issue-certificate \
  --certificate-authority-arn $CA_ARN \
  --csr file://device-csr.pem \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/BluetoothPeripheralDeviceCertificate/V1

# ステップ 5: デバイスに証明書をインストール

5. マイクロサービス間 mTLS（ECS/EKS）

# シナリオ: ECS サービス A ↔ サービス B で mTLS 通信

# ステップ 1: ACM Private CA を作成（上記参照）

# ステップ 2: サービス A の証明書を発行
aws acm-pca issue-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/... \
  --csr file://service-a-csr.pem \
  --signing-algorithm SHA256WITHRSA

# ステップ 3: サービス B の証明書を発行
aws acm-pca issue-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/... \
  --csr file://service-b-csr.pem \
  --signing-algorithm SHA256WITHRSA

# ステップ 4: ECS タスク定義で TLS 通信を設定
# (サービス A の TLS リスナー：服用証明書 + CA 証明書)
# (サービス B のクライアント：CA 証明書でサーバー検証)

# ステップ 5: App Mesh / Envoy で mTLS をトランスペアレントに管理

設定・操作の具体例（CLI / IaC）

AWS CLI 例

# 例1: ワイルドカード + SAN 証明書をリクエスト
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names \
    "*.example.com" \
    "api.example.com" \
    "www.example.com" \
  --validation-method DNS \
  --tags \
    Key=Environment,Value=Production \
    Key=Team,Value=Backend \
  --region ap-northeast-1

# 例2: 証明書一覧を表示（フィルタ）
aws acm list-certificates \
  --region ap-northeast-1 \
  --filters Name=STATUS,Values=ISSUED

# 例3: 証明書を削除（60日以内の検証済み証明書）
aws acm delete-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/abc123 \
  --region ap-northeast-1

# 例4: 証明書を追加検証（複数ドメイン）
aws acm request-certificate \
  --domain-name new-domain.com \
  --validation-method DNS \
  --region ap-northeast-1

CloudFormation（IaC）

# テンプレート例: ACM 証明書 + ALB
AWSTemplateFormatVersion: '2010-09-09'
Description: 'ACM Certificate with ALB'

Parameters:
  DomainName:
    Type: String
    Default: example.com
    Description: Domain name for the certificate

  VpcId:
    Type: AWS::EC2::VPC::Id
    Description: VPC ID for ALB

  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>
    Description: Subnet IDs for ALB

Resources:
  # ACM 証明書
  Certificate:
    Type: AWS::CertificateManager::Certificate
    Properties:
      DomainName: !Ref DomainName
      SubjectAlternativeNames:
        - !Sub 'www.${DomainName}'
        - !Sub 'api.${DomainName}'
      ValidationMethod: DNS
      DomainValidationOptions:
        - DomainName: !Ref DomainName
          ValidationDomain: !Ref DomainName
      Tags:
        - Key: Name
          Value: !Sub '${DomainName}-cert'
        - Key: Environment
          Value: Production

  # ALB（セキュリティグループ）
  ALBSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: ALB Security Group
      VpcId: !Ref VpcId
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0

  # ALB
  LoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: my-alb
      Subnets: !Ref SubnetIds
      SecurityGroups:
        - !Ref ALBSecurityGroup
      Scheme: internet-facing
      Tags:
        - Key: Name
          Value: my-alb

  # ターゲットグループ
  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: my-targets
      Port: 80
      Protocol: HTTP
      VpcId: !Ref VpcId
      HealthCheckEnabled: true
      HealthCheckPath: /
      HealthCheckProtocol: HTTP
      HealthCheckIntervalSeconds: 30
      HealthCheckTimeoutSeconds: 5
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 3

  # HTTPS リスナー（ACM 証明書を使用）
  HTTPSListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !GetAtt LoadBalancer.LoadBalancerArn
      Port: 443
      Protocol: HTTPS
      Certificates:
        - CertificateArn: !Ref Certificate
      DefaultActions:
        - Type: forward
          TargetGroupArn: !GetAtt TargetGroup.TargetGroupArn
      SslPolicy: ELBSecurityPolicy-TLS-1-2-2017-01

  # HTTP リスナー（443 にリダイレクト）
  HTTPListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !GetAtt LoadBalancer.LoadBalancerArn
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: redirect
          RedirectConfig:
            Protocol: HTTPS
            Port: '443'
            StatusCode: HTTP_301

Outputs:
  CertificateArn:
    Description: ACM Certificate ARN
    Value: !Ref Certificate
    Export:
      Name: !Sub '${AWS::StackName}-CertArn'

  LoadBalancerDNS:
    Description: ALB DNS Name
    Value: !GetAtt LoadBalancer.DNSName
    Export:
      Name: !Sub '${AWS::StackName}-ALB-DNS'

Terraform（IaC）

# provider
provider "aws" {
  region = "ap-northeast-1"
}

# ACM Certificate
resource "aws_acm_certificate" "main" {
  domain_name       = "example.com"
  validation_method = "DNS"

  subject_alternative_names = [
    "www.example.com",
    "api.example.com"
  ]

  lifecycle {
    create_before_destroy = true
  }

  tags = {
    Environment = "Production"
    Team        = "Platform"
  }
}

# Route 53 DNS 検証レコード
resource "aws_route53_record" "dns_validation" {
  for_each = {
    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = data.aws_route53_zone.main.zone_id
}

# DNS 検証完了待機
resource "aws_acm_certificate_validation" "main" {
  certificate_arn           = aws_acm_certificate.main.arn
  timeouts {
    create = "5m"
  }
  depends_on = [aws_route53_record.dns_validation]
}

# ALB
resource "aws_lb" "main" {
  name               = "my-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.subnet_ids

  tags = {
    Name = "my-alb"
  }
}

# ターゲットグループ
resource "aws_lb_target_group" "main" {
  name        = "my-targets"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = var.vpc_id
  target_type = "instance"

  health_check {
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

# HTTPS リスナー
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS-1-2-2017-01"
  certificate_arn   = aws_acm_certificate_validation.main.certificate_arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }
}

# HTTP リスナー（HTTPS リダイレクト）
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type = "redirect"

    redirect {
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }
}

# セキュリティグループ
resource "aws_security_group" "alb" {
  name = "alb-sg"
  vpc_id = var.vpc_id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Route 53 ゾーン（外部で管理）
data "aws_route53_zone" "main" {
  name = "example.com"
}

# アウトプット
output "certificate_arn" {
  value = aws_acm_certificate_validation.main.certificate_arn
}

output "alb_dns_name" {
  value = aws_lb.main.dns_name
}

統合サービス一覧

ACM 証明書が直接適用できる AWS サービス：

サービス	説明	検証方法
CloudFront	グローバル CDN	DNS / Email（us-east-1 発行必須）
Application Load Balancer（ALB）	層 7 ロードバランサー	DNS / Email
Network Load Balancer（NLB）	層 4 ロードバランサー	DNS / Email
API Gateway	REST / HTTP API	DNS / Email
Elastic Beanstalk	PaaS 環境	DNS / Email
AppSync	GraphQL API	DNS / Email
CloudSearch	マネージド検索サービス	DNS / Email
AWS Service Catalog	ポートフォリオ管理	DNS / Email
IoT Core	IoT プラットフォーム（mTLS）	Private CA
App Mesh	マイクロサービスメッシュ	Private CA
ECS / EKS	コンテナオーケストレーション（cert-manager）	Private CA / 外部

注： EC2 上の Nginx・Apache・カスタムアプリは ACM 証明書を直接使用できません。EC2 は ALB 経由で HTTPS 終了することを推奨します。

ワイルドカード・マルチドメイン SAN

ワイルドカード証明書の仕組み

証明書: *.example.com

保護対象:
  ✅ www.example.com
  ✅ api.example.com
  ✅ cdn.example.com
  ✅ foo.bar.example.com（深さ制限なし）

非保護:
  ❌ example.com（ベースドメイン）→ ワイルドカード + SAN で対応
  ❌ api.sub.example.com（異なるドメイン）

複数ワイルドカード + SAN の例

# 実装例: 複数サブドメインツリーを保護
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names \
    "www.example.com" \
    "*.example.com" \
    "*.api.example.com" \
    "*.cdn.example.com" \
  --validation-method DNS \
  --region ap-northeast-1

# 保護される:
#   example.com
#   www.example.com
#   *.example.com → api.example.com, cdn.example.com 等
#   *.api.example.com → rest.api.example.com, graphql.api.example.com 等
#   *.cdn.example.com → images.cdn.example.com, static.cdn.example.com 等

Wildcard Certificate 運用

ワイルドカード証明書のコスト効率

シナリオ: example.com 配下に 100 個のサブドメイン

パターン A: 個別証明書
  購入数: 100 個
  年間コスト: 数十万円
  管理負荷: 膨大

パターン B: ワイルドカード証明書（ACM）
  購入数: 1 個（*.example.com）
  年間コスト: 0 円（無料）
  管理負荷: ゼロ（自動更新）

→ ワイルドカード証明書が圧倒的に有利

ワイルドカード証明書のセキュリティ注意点

利点:
  - コスト削減
  - 管理の簡潔性
  - スケーラビリティ

懸念事項:
  - 秘密鍵が漏洩すると全サブドメインが危険
    → 解決: キーローテーション・ACM Private CA で段階的更新

  - DNS 漏洩時にサブドメイン乗っ取りリスク
    → 解決: DNS CNAME で ACM が自動更新。DNS レコードは CloudFront 等で保護

推奨策:
  ✅ ワイルドカード証明書 + DNS 検証（Route 53）
  ✅ CloudWatch で証明書有効期限を監視
  ✅ CloudTrail で証明書関連操作をログ

ACM Private CA との連携

Private CA で発行した証明書を ACM で管理

# ステップ 1: ACM Private CA で Root CA を作成（別ガイド参照）
# ステップ 2: Private CA で証明書を発行
# ステップ 3: ACM が Private CA 発行証明書を自動管理

# 利点:
#   - Private CA 発行証明書も ACM で一元管理
#   - CloudFront / ALB / API Gateway で使用可能
#   - 自動更新対応

# 例: ACM で Private Issuer をリクエスト
aws acm request-certificate \
  --domain-name internal.corp \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/... \
  --region ap-northeast-1

CloudFront 専有制限

us-east-1 依存の理由

CloudFront は AWS のグローバルサービス（すべてのリージョンで同一）
  ↓
証明書も「グローバル」として機能する必要がある
  ↓
ACM 証明書は リージョン資源（ap-northeast-1, us-west-2 等で独立）
  ↓
CloudFront の証明書リージョンは「us-east-1」に統一
  ↓
CloudFront 用 ACM 証明書は必ず us-east-1 で発行・管理

複数リージョン ALB の場合

ALB は リージョン資源
  ↓
各リージョンで独立した ACM 証明書が必要

例:
  ap-northeast-1 ALB → ap-northeast-1 証明書
  us-west-2 ALB → us-west-2 証明書
  eu-west-1 ALB → eu-west-1 証明書

ただし同じドメイン名の場合:
  → 各証明書で同じドメイン検証
  → Route 53 CNAME は共有可能（同じレコード）

証明書チェーン・エクスポート

ACM からの証明書エクスポート

# Private CA 発行証明書のエクスポート（EC2 等で利用）
aws acm export-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:...:certificate/... \
  --passphrase $(echo -n "MySecurePassphrase" | base64) \
  --region ap-northeast-1 \
  --output json > certificate.json

# エクスポート内容:
# {
#   "CertificatePem": "-----BEGIN CERTIFICATE-----\n...",
#   "CertificateChainPem": "-----BEGIN CERTIFICATE-----\n...",
#   "PrivateKeyPem": "-----BEGIN RSA PRIVATE KEY-----\n..."
# }

# ファイルに保存
jq -r '.CertificatePem' certificate.json > cert.pem
jq -r '.CertificateChainPem' certificate.json > chain.pem
jq -r '.PrivateKeyPem' certificate.json > private-key.pem

注意： Public Certificate はエクスポート不可（秘密鍵は AWS が保管）

セキュリティ・監査

CloudTrail で ACM 操作を監査

# ACM 関連の CloudTrail イベント
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=example.com \
  --region ap-northeast-1

# 出力: 証明書リクエスト・検証・削除等の操作ログ

CloudWatch でアラーム設定

# 証明書有効期限アラーム
aws cloudwatch put-metric-alarm \
  --alarm-name ACM-Certificate-Expiration-Alert \
  --alarm-description "Alert if certificate expires within 30 days" \
  --metric-name DaysToExpiry \
  --namespace AWS/ACM \
  --statistic Minimum \
  --period 86400 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:ap-northeast-1:...:certificate/...

IAM ポリシーで ACM アクセス制御

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequestCertificateOnly",
      "Effect": "Allow",
      "Action": [
        "acm:RequestCertificate",
        "acm:DescribeCertificate",
        "acm:ListCertificates"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyDeleteCertificate",
      "Effect": "Deny",
      "Action": "acm:DeleteCertificate",
      "Resource": "*"
    }
  ]
}

トラブルシューティング

問題	原因	解決策
Validation failed（検証失敗）	CNAME がドメインに追加されていない	Route 53 に CNAME を追加（1クリック自動作成）
Certificate not appearing（証明書が表示されない）	リージョン指定が異なる	CloudFront は us-east-1、他は各リージョン確認
Auto renewal failed（自動更新失敗）	CNAME レコードが削除された	Route 53 で CNAME を再作成
Permission denied（権限エラー）	IAM ポリシーが不足	acm:RequestCertificate・acm:DescribeCertificate を許可
Domain validation email not received	メール検証で送信先メールが受信できない	admin@・hostmaster@ 等の標準メールを確認

類似サービス比較

観点	ACM	Let’s Encrypt	DigiCert	Cloudflare SSL	GCP Certificate Manager
コスト	無料	無料	$100-$500/年	無料/有料	無料（GCP リソース向け）
自動更新	✅ DNS/Email	✅ API	❌ 手動	✅	✅
有効期限	13ヶ月	90日	1-3年	可変	13ヶ月
AWS 統合	✅ ネイティブ	⚠️ インポート	⚠️ インポート	⚠️ インポート	❌
CloudFront	✅	⚠️	⚠️	⚠️	❌
セキュリティ	FIPS対応	標準	高度	標準	標準
Private CA	✅	❌	⚠️	❌	⚠️

ベストプラクティス

✅ 推奨事項

1. DNS 検証（Route 53）を使用
   理由: 自動更新対応・Email 検証より安全

2. Route 53 CNAME を削除しない
   理由: 削除すると自動更新が停止

3. CloudFront 用は必ず us-east-1
   理由: CloudFront はグローバルで us-east-1 のみ対応

4. ワイルドカード証明書を活用
   理由: コスト削減・管理の簡潔化

5. CloudWatch でアラーム設定
   理由: 期限切れを早期発見

6. CloudTrail で監査ログを取得
   理由: コンプライアンス・セキュリティ

7. IAM ポリシーで削除を制限
   理由: 誤削除防止

❌ アンチパターン

1. CloudFront 用を us-east-1 以外で発行
   → CloudFront に適用できない

2. Email 検証で手動更新を放置
   → 期限切れリスク

3. Route 53 CNAME を定期削除
   → 自動更新が停止

4. インポート証明書を更新しない
   → 期限切れでサービス停止

5. 一つの証明書秘密鍵を複数リージョンで共有
   → セキュリティリスク

6. Private CA コストを無視
   → 不要な高額費用

2025-2026 最新動向

1. Post-Quantum Cryptography（PQC）対応準備

AWS は 2025-2026 年に量子耐性暗号への対応を準備中

現在: RSA-2048、ECDSA（P-256/P-384）
将来: ML-DSA（Module-Lattice-Based Digital Signature Algorithm）

影響:
  - ACM で PQC アルゴリズム指定可能に
  - Private CA での ML-DSA 証明書発行対応
  - CloudFront・ALB での PQC 証明書対応

準備:
  ✅ AWS ブログで進捗情報確認
  ✅ Private CA で ML-DSA 試験段階

2. External Key Store（XKS）統合深化

Private CA が External Key Store（XKS）で CloudHSM・オンプレ HSM と連携

メリット:
  - キーを AWS が管理しない（顧客完全制御）
  - FIPS 140-3 Level 3 認証
  - 高度なコンプライアンス要件対応

動向:
  - XKS サポート リージョン拡大
  - CloudHSM 統合強化
  - オンプレミス HSM（Thales・Entrust）連携

3. AI 駆動監視・最適化

AWS は AI で証明書管理を自動化

機能：
  - 証明書使用状況の異常検知
  - 有効期限予測・更新スケジュール提案
  - セキュリティ推奨事項（ワイルドカード活用・更新方法最適化）

実装時期: 2025 年後半から段階的

4. Multi-Region Certificate 簡素化

複数リージョン ALB 環境での証明書複製を簡素化
現在: 各リージョンで個別リクエスト（DNS 検証も各リージョン）
将来: ワンクリックで複数リージョンに複製
実装状況: 試験段階

学習リソース

公式ドキュメント・ガイド

ブログ・チュートリアル

OSS・ベンダーリソース

Let’s Encrypt 公式 - 無料 CA（ACM の代替）
Smallstep CA - Private CA オープンソース
HashiCorp Vault PKI - Enterprise PKI
cert-manager（Kubernetes） - EKS での自動証明書管理

実装例・チェックリスト

チェックリスト

## ACM 導入前チェックリスト

### 要件確認
- [ ] 公開ドメイン名がある（Route 53 または他レジストラ）
- [ ] HTTPS 対応リソースが明確（CloudFront / ALB / API Gateway）
- [ ] 証明書有効期限管理の要件を確認
- [ ] Private CA（社内PKI）が必要か判断

### 設計
- [ ] 証明書発行リージョンを決定（CloudFront は us-east-1）
- [ ] 検証方法を決定（DNS 推奨）
- [ ] ワイルドカード・SAN 要件を確認
- [ ] アーキテクチャ図を作成

### 実装
- [ ] IAM ポリシー設定（acm:RequestCertificate 等）
- [ ] Route 53 ゾーンを確認
- [ ] ACM で証明書をリクエスト
- [ ] DNS CNAME を自動作成（Route 53）
- [ ] 検証完了を確認（ISSUED ステータス）
- [ ] リソース（ALB / CloudFront）に適用

### 運用
- [ ] CloudWatch アラーム設定（有効期限）
- [ ] CloudTrail で操作ログ確認
- [ ] 定期的に証明書ステータス確認
- [ ] 自動更新が正常に動作か監視

### セキュリティ
- [ ] IAM ポリシーで削除操作を制限
- [ ] CloudTrail ログを保護（S3 MFA Delete）
- [ ] 秘密鍵は AWS 管理（エクスポート不可）
- [ ] 定期的なアクセス権限レビュー

実装サンプル（全統合例）

#!/bin/bash
set -e

# 設定
DOMAIN="example.com"
SUBDOMAIN="api"
AWS_REGION="ap-northeast-1"
HOSTED_ZONE_ID="Z1234567890ABC"
VPC_ID="vpc-12345678"
SUBNET_IDS="subnet-12345678 subnet-87654321"

echo "=== ACM + ALB の完全統合デプロイ ==="

# ステップ 1: ACM で証明書をリクエスト
echo "Step 1: Requesting ACM Certificate..."
CERT_ARN=$(aws acm request-certificate \
  --domain-name "${DOMAIN}" \
  --subject-alternative-names "www.${DOMAIN}" "${SUBDOMAIN}.${DOMAIN}" \
  --validation-method DNS \
  --tags Key=Environment,Value=Production Key=ManagedBy,Value=Terraform \
  --region "${AWS_REGION}" \
  --query 'CertificateArn' \
  --output text)

echo "Certificate ARN: ${CERT_ARN}"

# ステップ 2: 検証待機（60秒）
echo "Step 2: Waiting for certificate validation..."
sleep 60

# ステップ 3: Route 53 に CNAME を自動作成（実際には ACM コンソールで実施）
echo "Step 3: Creating Route 53 DNS records..."
# (スクリプト省略：実際には aws route53 change-resource-record-sets を実行)

# ステップ 4: ALB セキュリティグループ作成
echo "Step 4: Creating ALB Security Group..."
SG_ID=$(aws ec2 create-security-group \
  --group-name alb-sg \
  --description "ALB Security Group" \
  --vpc-id "${VPC_ID}" \
  --query 'GroupId' \
  --output text)

aws ec2 authorize-security-group-ingress \
  --group-id "${SG_ID}" \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id "${SG_ID}" \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# ステップ 5: ALB 作成
echo "Step 5: Creating Application Load Balancer..."
ALB_ARN=$(aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets ${SUBNET_IDS} \
  --security-groups "${SG_ID}" \
  --scheme internet-facing \
  --type application \
  --query 'LoadBalancers[0].LoadBalancerArn' \
  --output text)

# ステップ 6: ターゲットグループ作成
echo "Step 6: Creating Target Group..."
TG_ARN=$(aws elbv2 create-target-group \
  --name my-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id "${VPC_ID}" \
  --health-check-enabled \
  --health-check-path / \
  --health-check-protocol HTTP \
  --health-check-interval-seconds 30 \
  --health-check-timeout-seconds 5 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

# ステップ 7: HTTPS リスナー作成
echo "Step 7: Creating HTTPS Listener..."
aws elbv2 create-listener \
  --load-balancer-arn "${ALB_ARN}" \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn="${CERT_ARN}" \
  --default-actions Type=forward,TargetGroupArn="${TG_ARN}" \
  --ssl-policy ELBSecurityPolicy-TLS-1-2-2017-01

# ステップ 8: HTTP → HTTPS リダイレクト
echo "Step 8: Creating HTTP Listener with HTTPS Redirect..."
aws elbv2 create-listener \
  --load-balancer-arn "${ALB_ARN}" \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=redirect,RedirectConfig="{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}"

# ステップ 9: CloudWatch アラーム設定
echo "Step 9: Setting up CloudWatch Alarms..."
aws cloudwatch put-metric-alarm \
  --alarm-name ACM-Cert-Expiration-Alert \
  --alarm-description "Alert when ACM certificate expires within 30 days" \
  --metric-name CertificateExpiration \
  --namespace AWS/ACM \
  --statistic Minimum \
  --period 86400 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=CertificateArn,Value="${CERT_ARN}"

echo ""
echo "=== Deployment Complete ==="
echo "ALB ARN: ${ALB_ARN}"
echo "Target Group ARN: ${TG_ARN}"
echo "Certificate ARN: ${CERT_ARN}"

まとめ

AWS Certificate Manager（v2.0） は、以下を実現する統合HTTPS管理プラットフォームです：

自動更新による運用ノーメンテナンス - DNS 検証 + Route 53 で期限切れゼロ
完全無料（パブリック証明書）- ワイルドカード・SAN も無料
AWS サービス統合 - CloudFront・ALB・API Gateway にシームレス適用
Private CA との統合 - 社内 PKI・マイクロサービス mTLS に対応
セキュリティと監査 - CloudTrail・CloudWatch で完全可視化

導入フロー

① ドメイン取得（Route 53）
  ↓
② ACM で証明書をリクエスト（DNS 検証）
  ↓
③ Route 53 に CNAME を追加（自動）
  ↓
④ 検証完了（数分）
  ↓
⑤ ALB / CloudFront に適用
  ↓
⑥ 自動更新で以降メンテナンス不要

2026 年の進化

Post-Quantum Cryptography（PQC）対応
AI 駆動監視・最適化
Multi-Region 簡素化
External Key Store（XKS）拡大

最終更新：2026-04-27 バージョン：v2.0

目次

AWS Certificate Manager v2.0 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の ACM エコシステム

目次

概要

ACM が解決する課題

1. 証明書期限切れによるサービス停止リスク

2. 証明書購入・更新のコスト・手続き

3. 複数リージョン・複数リソースの証明書管理

4. CloudFront + オンプレ SSL の複雑性

主な特徴

1. 自動更新による期限切れ排除

2. 完全無料（パブリック証明書）

3. 複数ドメイン・ワイルドカード対応

4. CloudFront グローバル配信

5. ACM Private CA 統合

アーキテクチャ

高可用性・リージョン分散

検証フロー（DNS 方式）

Email 検証フロー（代替方法）

証明書の種類

Public Certificate（パブリック証明書）

Private Certificate（プライベート証明書）

Imported Certificate（インポート証明書）

Public vs Private 証明書

検証方法（DNS / Email）

DNS 検証（推奨）

Email 検証（代替）

Auto Renewal（自動更新）

DNS 検証時の自動更新フロー

自動更新の前提条件

CloudWatch で自動更新を監視

コアコンポーネント

1. Certificate Request（証明書リクエスト）

2. Domain Validation（ドメイン検証）

3. Certificate Metadata（メタデータ）

4. Certificate Association（リソースへの適用）

主要ユースケース

1. Web サイトの HTTPS 化（ALB + ACM）

2. CloudFront CDN の SSL/TLS オフロード

3. API Gateway の API エンドポイント保護

4. IoT デバイスの mTLS 通信（Private CA）

5. マイクロサービス間 mTLS（ECS/EKS）

設定・操作の具体例（CLI / IaC）

AWS CLI 例

CloudFormation（IaC）

Terraform（IaC）

統合サービス一覧

ワイルドカード・マルチドメイン SAN

ワイルドカード証明書の仕組み

複数ワイルドカード + SAN の例

Wildcard Certificate 運用

ワイルドカード証明書のコスト効率

ワイルドカード証明書のセキュリティ注意点

ACM Private CA との連携

Private CA で発行した証明書を ACM で管理

CloudFront 専有制限

us-east-1 依存の理由

複数リージョン ALB の場合

証明書チェーン・エクスポート

ACM からの証明書エクスポート

セキュリティ・監査

CloudTrail で ACM 操作を監査

CloudWatch でアラーム設定

IAM ポリシーで ACM アクセス制御

トラブルシューティング

類似サービス比較

ベストプラクティス

✅ 推奨事項

❌ アンチパターン

2025-2026 最新動向

1. Post-Quantum Cryptography（PQC）対応準備

2. External Key Store（XKS）統合深化

3. AI 駆動監視・最適化

4. Multi-Region Certificate 簡素化

学習リソース

公式ドキュメント・ガイド

ブログ・チュートリアル