AWS Certificate Manager（ACM）入門｜SSL証明書の取得から自動更新まで現場で使えるHTTPS化ガイド

「社内のWebサーバーをクラウドに移行したけれど、SSL証明書の管理が面倒で後回しにしている」「更新期限を忘れてサイトが表示されなくなったことがある」――オンプレ時代にこうした経験をした方は少なくないはずです。

オンプレミスでは、SSL証明書の取得・インストール・更新をすべて手作業で行う必要がありました。認証局（CA）への申請、CSRの生成、秘密鍵の管理、Apache/NginxへのPEM配置、そして1年や2年ごとの手動更新。サーバーが増えるほどこの作業は膨れ上がり、更新漏れが障害に直結する厄介な運用課題でした。

この記事では、AWS Certificate Manager（ACM）を使ったSSL/TLS証明書の取得・管理・自動更新について、オンプレ経験者にもわかりやすく解説します。ACMの仕組みから実際の設定手順、料金体系、現場で役立つ運用Tipsまでカバーしますので、クラウド移行後の証明書管理を効率化したい方はぜひ参考にしてください。

なぜクラウドでSSL証明書管理が変わるのか（オンプレとの違い）

オンプレミスでSSL証明書を管理する場合、大きく分けて以下の作業が必要でした。

・CSR（証明書署名要求）の生成: サーバー上でopensslコマンドを叩き、秘密鍵とCSRを作成する
・認証局への申請: CSRを認証局に送付し、ドメイン所有権の確認を経て証明書を受け取る
・Webサーバーへの配置: 証明書ファイルと秘密鍵をApacheやNginxの設定ファイルに記述する
・有効期限の管理と更新: 期限切れ前に同じ手順を繰り返す（1年～2年おき）

サーバーが数台であれば手作業でもなんとかなります。しかし、サーバーが10台、20台と増えてくると、どのサーバーにどの証明書が入っているか管理しきれなくなります。更新期限をExcelで管理し、それでも人的ミスで期限切れを起こす――そんな現場は珍しくありませんでした。

AWSのCertificate Manager（ACM）は、この証明書管理の手間をほぼゼロにするサービスです。

・CSR生成や秘密鍵の管理が不要: ACMが内部で鍵ペアを生成・保管する
・ドメイン検証がDNSレコードの追加だけで完了する: メール認証の手間がない
・証明書の自動更新: 期限切れの60日前からACMが自動で更新処理を行う
・ALBやCloudFrontとの統合: マネジメントコンソールでプルダウンから選ぶだけで紐付け完了

オンプレ時代の「証明書管理は誰がやるのか問題」が、ACMを使えばインフラ運用のタスクリストから消えます。

AWS Certificate Manager（ACM）の基本的な使い方

ACMでSSL証明書を取得し、ALB（Application Load Balancer）に適用するまでの基本手順を解説します。

1. ACMでパブリック証明書をリクエストする

AWSマネジメントコンソールにログインし、「Certificate Manager」を開きます。

リージョンの選択が重要です。ALBで使う場合はALBと同じリージョン、CloudFrontで使う場合は必ず「バージニア北部（us-east-1）」を選んでください。これはCloudFrontの仕様で、他のリージョンの証明書は紐付けできません。

「証明書をリクエスト」をクリックし、「パブリック証明書をリクエスト」を選択します。

ドメイン名の入力画面では、以下のように設定します。

・完全修飾ドメイン名: example.com（メインドメイン）
・追加の名前: *.example.com（ワイルドカード証明書にする場合）

ワイルドカード証明書を使えば、www.example.com、api.example.com、staging.example.comなど、サブドメインをすべて1枚の証明書でカバーできます。オンプレ時代にサブドメインごとに証明書を購入していた方には、これだけでもACMを使う大きなメリットです。

AWS CLIでリクエストする場合は以下のコマンドです。

# AWS CLI: パブリック証明書をリクエスト
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS \
  --region ap-northeast-1

2. DNS検証でドメイン所有権を証明する

検証方法は「DNS検証」と「Eメール検証」の2種類がありますが、DNS検証を強くおすすめします。

DNS検証では、ACMが指定するCNAMEレコードをドメインのDNSに追加するだけで完了します。Route 53を使っている場合は「Route 53でレコードを作成」ボタンを押すだけで自動的にCNAMEレコードが追加されます。

Route 53を使っていない場合でも、お使いのDNSサービスの管理画面でCNAMEレコードを手動で追加すれば大丈夫です。レコード名とレコード値はACMの画面に表示されますので、それをコピーして貼り付けます。

DNS検証を推奨する理由は以下の通りです。

・自動更新に必要: DNS検証で発行した証明書は、CNAMEレコードが残っている限り自動更新される
・Eメール検証の落とし穴: 更新のたびにメール承認が必要になり、人的ミスの温床になる
・一度設定すれば放置できる: CNAMEレコードを消さない限り、以後の運用作業はゼロ

CNAMEレコード追加後、通常は数分～30分ほどで検証が完了し、証明書のステータスが「発行済み」に変わります。

3. ALBやCloudFrontへ証明書を紐付ける

証明書が発行されたら、実際にHTTPS通信で使えるようにリソースへ紐付けます。

ALBに紐付ける場合:

EC2コンソールから対象のALBを選択し、「リスナー」タブを開きます。HTTPSリスナー（ポート443）を追加し、「デフォルトSSL証明書」の欄でACMから発行した証明書をプルダウンから選択します。

HTTP（ポート80）のリスナーは、HTTPSへのリダイレクトアクションを設定しておくと、HTTPでアクセスしてきたユーザーを自動的にHTTPSに転送できます。

# AWS CLI: ALBにHTTPSリスナーを追加
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-alb/xxxxxxxxxx \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxxxxxxxx

CloudFrontに紐付ける場合:

CloudFrontディストリビューションの設定画面で「カスタムSSL証明書」を選択し、ACMの証明書を指定します。繰り返しますが、CloudFront用の証明書は必ずus-east-1リージョンで発行しておく必要があります。

オンプレ時代は、ApacheならSSLCertificateFile、NginxならSSL_certificateディレクティブに証明書のパスを書いて、秘密鍵のパーミッションを600に設定して――という手順がありました。ACMではこうした作業が一切不要です。秘密鍵はAWS内部で厳重に管理され、外部に取り出すことはできない設計になっています。

料金の仕組み（ACMの無料範囲とコスト感覚）

ACMのパブリック証明書は無料です（2026年4月時点）。

これはオンプレ経験者にとって驚きかもしれません。従来、SSL証明書はドメイン認証（DV）タイプでも年間数千円～数万円、ワイルドカード証明書なら数万円～十数万円かかるものでした。

ACMの料金をまとめると以下の通りです。

注意すべきは、ACMの証明書そのものは無料でも、証明書を適用するリソース（ALB、CloudFrontなど）には別途利用料がかかるということです。ALBの固定料金は東京リージョン（ap-northeast-1）で月額約$16.20（2026年4月時点）ですので、HTTPS化のためだけにALBを追加する場合はその費用も見込んでおいてください。

プライベート証明書は社内のマイクロサービス間通信やVPN接続など、パブリックに公開しない環境で使います。月額$400のCA（認証局）維持費がかかるため、小規模環境には向きません。まずはパブリック証明書で十分です。

応用・実務Tips

複数ドメインを1枚の証明書でカバーする

ACMでは、1枚の証明書に対してSAN（Subject Alternative Name）として最大10個のドメインを追加できます。例えば、example.comとexample.jpとexample.co.jpを1枚の証明書にまとめることも可能です。

ただし、ワイルドカード（*.example.com）は1階層しかカバーしません。sub.api.example.comのような2階層以上のサブドメインには対応しないため、そのようなドメイン構成を使っている場合はSANに個別追加するか、別の証明書を発行してください。

証明書の自動更新を確実にする

ACMの自動更新が正しく動くために、以下の条件を満たしているか確認してください。

・DNS検証で発行していること: Eメール検証だと手動承認が必要になる
・CNAMEレコードが残っていること: DNSからレコードを消すと自動更新に失敗する
・証明書がAWSリソースに紐付いていること: どのリソースにも紐付いていない証明書は更新されない

自動更新の状況はACMのコンソールで確認できます。「更新ステータス」が「成功」になっていれば問題ありません。

# AWS CLI: 証明書の詳細を確認（更新ステータス含む）
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --query 'Certificate.{DomainName:DomainName,Status:Status,RenewalSummary:RenewalSummary}' \
  --output table

証明書の有効期限を監視する

ACMは自動更新してくれますが、「更新に失敗した場合に気づけるか」は別の問題です。Amazon CloudWatchやAWS Configを組み合わせて、証明書の有効期限が一定日数を切ったらアラートを飛ばす仕組みを作っておくと安心です。

AWS Configには「acm-certificate-expiration-check」というマネージドルールがあり、有効期限が指定日数以内の証明書を検出できます。Security Hubと連携すれば、期限切れリスクのある証明書をダッシュボードで一覧できます。

よくあるトラブルと対処法

「検証保留中」のまま証明書が発行されない

DNS検証を選んだのに証明書が「検証保留中」のまま変わらない場合、ほとんどのケースはCNAMEレコードの設定ミスです。

・レコード名のコピーミス: ACMが表示するCNAMEレコード名にはドメイン名部分が含まれています。DNSサービスによっては、自動でドメイン名が付加されるため二重になることがあります（例: _xxxx.example.com.example.comになってしまう）
・DNSの反映待ち: TTLの設定によっては反映まで時間がかかります。30分以上経っても変わらない場合はdigコマンドで確認してください

# CNAMEレコードが正しく設定されているか確認
dig CNAME _abcdef1234567890.example.com +short

CloudFrontに証明書が表示されない

CloudFrontのカスタムSSL証明書のプルダウンにACMの証明書が出てこない場合、リージョンが原因です。CloudFront用の証明書はus-east-1（バージニア北部）で発行する必要があります。東京リージョンで発行した証明書はCloudFrontでは使えません。

対処法は簡単です。us-east-1に切り替えて、同じドメインの証明書を追加で発行してください。ACMの証明書は無料なので、リージョンごとに発行してもコストは増えません。

自動更新に失敗する

自動更新が失敗する主な原因は以下の3つです。

・CNAMEレコードが削除されている: DNS管理者が不要と判断して消してしまうケース。ACM用のCNAMEレコードは証明書を使い続ける限り残しておく必要があります
・どのリソースにも紐付いていない: テスト用に発行した証明書など、使われていない証明書は更新されません
・Eメール検証で発行した: 更新時にメール承認が必要ですが、承認メールに気づかず期限切れになるケースがあります。DNS検証に切り替えることをおすすめします（既存証明書の検証方法は変更できないため、新しい証明書を発行し直す必要があります）

本記事のまとめ

AWS Certificate Manager（ACM）は、SSL/TLS証明書の取得・管理・更新を自動化するサービスです。オンプレ時代の証明書管理で苦労した経験がある方にとって、ACMのメリットは明確です。

運用で押さえるポイントは3つだけです。DNS検証で証明書を発行すること、CNAMEレコードを消さないこと、CloudFront用はus-east-1で発行すること。この3つを守れば、証明書管理はほぼ「やることがない」状態になります。

オンプレからクラウドへの移行で、証明書管理は確実に楽になる領域です。まだ手動で管理している方は、ACMへの移行を検討してみてください。

クラウドのセキュリティ設定については、セキュリティマスターズ.TOKYOでも基礎から解説しています。また、ACMを適用するEC2やALBの構築にはLinuxの知識も必要です。サーバー構築の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。