AWSでWebサイトをSSL化するなら、AWS Certificate Manager (ACM) の利用が最適です。ACMを利用すれば、SSL証明書を無料で取得できるだけでなく、面倒な更新作業も自動化されるため、運用コストと手間を大幅に削減できます。本記事では、ACMの基礎知識から、推奨されるDNS検証を用いた具体的な発行手順、ALBやCloudFrontへの適用方法までを初心者にも分かりやすく解説します。
この記事で分かること
- AWS ACMの仕組みと無料利用のメリット
- DNS検証によるSSL証明書の発行手順
- ALBやCloudFrontへの証明書適用方法
- 証明書の自動更新条件と仕組み
EC2インスタンスには直接インストールできないといった注意点や、よくある疑問についても回答しています。この記事を参考に、AWS環境でのセキュアな通信環境を構築しましょう。
AWS ACMとは？SSL証明書管理サービスの基本
AWS Certificate Manager（ACM）は、ウェブサイトやアプリケーションのセキュリティを確保するために不可欠なSSL/TLS証明書を、簡単に発行・管理・デプロイできるAWSのマネージドサービスです。通常、SSL証明書の導入には認証局（CA）への申請やサーバーへのインストール、そして定期的な更新作業といった煩雑な手間が発生しますが、ACMを利用することでこれらのプロセスを大幅に簡略化できます。
特に、Elastic Load Balancing（ELB）やAmazon CloudFront、Amazon API GatewayといったAWSの主要サービスとシームレスに連携できる点が大きな強みであり、AWS上でシステムを構築する際には事実上の標準となるサービスです。
AWS Certificate Managerの仕組みと特徴
ACMの仕組みは、証明書の発行から適用、更新までのライフサイクル全体をAWSが代行するというものです。ユーザーはマネジメントコンソールやCLI（コマンドラインインターフェース）を通じてリクエストを行うだけで、数分から数時間で証明書を利用可能な状態にできます。
従来の外部認証局を利用した場合と、AWS ACMを利用した場合の違いは以下の通りです。
| 比較項目 | 一般的な外部認証局 | AWS ACM |
|---|---|---|
| 発行スピード | 数日〜数週間かかる場合がある | ドメイン検証後、即時〜数時間 |
| インストール作業 | サーバーごとに手動でアップロード | AWSリソースへプルダウンで選択・適用 |
| 更新手続き | 有効期限前に手動更新・再インストール | 条件を満たせば自動更新（メンテナンスフリー） |
| 秘密鍵の管理 | ユーザー自身で厳重に管理が必要 | AWS KMS等で安全に保護・管理される |
このように、ACMはセキュリティリスクとなりやすい「証明書の更新忘れ」や「秘密鍵の紛失」といった人的ミスを防ぐ仕組みを備えています。詳しくはAWS Certificate Manager の公式サイトでも機能の詳細が解説されています。
無料で使えるパブリック証明書のメリット
ACMの最大の特徴でありメリットと言えるのが、パブリックSSL/TLS証明書を追加料金なしで利用できる点です。通常、信頼性の高い認証局から証明書を購入すると年間数千円から数万円のコストがかかりますが、ACMで発行したパブリック証明書は、ACMに対応するAWSリソース（ALBやCloudFrontなど）に関連付けて使用する場合、証明書自体の利用料は無料となります。
コスト面以外にも、ACMのパブリック証明書には以下のようなメリットがあります。
- 運用の自動化：DNS検証を利用することで、有効期限が切れる前にAWSが自動で証明書を更新します。
- 高い信頼性：Amazon Trust Servicesという信頼されたルート認証局から発行されるため、主要なブラウザやOSで警告が出ることなく安全に利用できます。
- 迅速なスケーリング：トラフィックが増加してロードバランサーやCDNを拡張する際も、証明書のコピーや再設定の手間がかかりません。
ただし、ACMで発行した証明書は「秘密鍵のエクスポートができない」という仕様があるため、EC2インスタンス内部のWebサーバー（ApacheやNginxなど）に直接インストールして使うことはできません。この点は後の章で解説する構成上の注意点として理解しておく必要があります。
AWS ACMを利用する前の前提条件と準備
AWS Certificate Manager（ACM）を利用してSSL証明書をスムーズに発行・運用するためには、事前にいくつかの環境を整えておく必要があります。リクエストボタンを押す前に、以下の前提条件が満たされているかを確認しましょう。
必要なAWSアカウントとIAM権限の設定
ACMを利用するには、有効なAWSアカウントが必要です。また、作業を行うユーザー（IAMユーザーまたはIAMロール）には、証明書のリクエストや管理を行うための適切な権限が付与されている必要があります。
具体的には、以下の権限設定を確認してください。
- ACMへのフルアクセス権限：「AWSCertificateManagerFullAccess」などのポリシーがアタッチされていること。
- DNS検証用の権限：Route 53を使用してドメイン認証を行う場合、Route 53のレコードを変更できる権限が必要です。
- 関連サービスへのアクセス権限：ELB（Elastic Load Balancing）やCloudFrontなど、証明書を紐付けるサービスへの設定権限も必要となります。
ドメイン名の取得とDNSサーバーへのアクセス権
ACMで発行できるパブリック証明書は、インターネット上で公開されているドメイン名（FQDN）に対してのみ有効です。そのため、事前にドメインを取得しておく必要があります。
ドメインはAWSの「Amazon Route 53」で取得することも、お名前.comやGoDaddyなどの外部レジストラで取得することも可能です。重要なのは、そのドメインのDNSレコードを編集できる権限、またはドメイン管理者宛のメールを受信できる環境があることです。
これは、証明書発行時の「ドメイン所有確認（検証）」プロセスで必須となります。
ACM証明書を適用可能なAWSサービスの確認
ACMを利用する上で最も誤解されやすいのが、証明書のインストール先です。ACMで発行したパブリック証明書は、秘密鍵をエクスポートできないため、Amazon EC2インスタンス内部のWebサーバー（ApacheやNginxなど）に直接インストールして利用することはできません。
ACM証明書は、対応しているAWSマネージドサービスに紐付けて使用します。導入予定の構成がACMに対応しているか、以下の表で確認してください。
| AWSサービス | ACM利用の可否 | 主な利用シーン |
|---|---|---|
| Elastic Load Balancing (ALB / NLB) | 利用可 | EC2への負荷分散とSSL終端 |
| Amazon CloudFront | 利用可 | CDNによるコンテンツ配信の高速化 |
| Amazon API Gateway | 利用可 | APIのカスタムドメイン設定 |
| AWS App Runner | 利用可 | コンテナアプリケーションの公開 |
| Amazon EC2 (直接インストール) | 利用不可 | ロードバランサーを使用しない単体構成など |
EC2インスタンス単体でSSL化を行いたい場合は、ACMではなくLet's Encryptなどの外部認証局を利用するか、前段にALB（Application Load Balancer）を配置する構成への変更を検討する必要があります。
利用するリージョンの選定（CloudFront利用時の注意点）
ACM証明書はリージョンごとのリソースです。基本的には、SSL証明書を利用したいリソース（ALBなど）が存在するリージョンと同じリージョンで証明書をリクエストする必要があります。
ただし、Amazon CloudFrontで使用する場合のみ、例外的なルールが存在します。CloudFrontに適用する証明書は、必ず「米国東部（バージニア北部）リージョン（us-east-1）」で発行しなければなりません。
東京リージョン（ap-northeast-1）で作成した証明書はCloudFrontには適用できないため、グローバル展開するコンテンツ配信ネットワークを利用する際は、リージョンの切り替えを忘れないようにしましょう。
AWS ACMでSSL証明書を発行する手順
AWS ACM（AWS Certificate Manager）を利用してSSL証明書を発行するプロセスは、AWSマネジメントコンソールから数ステップで完了します。操作自体はシンプルですが、発行するリージョンの選択やドメイン名の入力形式など、いくつか注意すべきポイントがあります。
ここでは、実際にコンソール画面を操作してパブリック証明書をリクエストする具体的な手順を解説します。
マネジメントコンソールでのリクエスト作成
まず、AWSマネジメントコンソールにログインし、サービス一覧から「Certificate Manager」を選択します。証明書のリクエストを開始する前に、最も重要な確認事項が「リージョンの選択」です。
ACMで発行した証明書は、適用したいAWSリソースと同じリージョンに存在する必要があります。ただし、CloudFrontで使用する場合のみ例外的なルールが適用されるため、以下の基準に従ってリージョンを切り替えてください。
- ALB（Application Load Balancer）やELBで使用する場合：ロードバランサーを設置しているリージョン（例：東京リージョン ap-northeast-1）を選択します。
- CloudFrontで使用する場合：必ず米国東部（バージニア北部）リージョン（us-east-1）を選択する必要があります。他のリージョンで発行してもCloudFrontには適用できません。
リージョンを確認したら、ダッシュボードにある「証明書をリクエスト」ボタンをクリックします。
次に、証明書のタイプを選択する画面が表示されます。「パブリック証明書をリクエスト」がデフォルトで選択されていることを確認し、「次へ」をクリックしてください。プライベート証明書は内部ネットワーク向けであり、一般的なWebサイトのSSL化にはパブリック証明書を使用します。
ドメイン名の追加と検証方法の選択
リクエストの詳細画面では、SSL化したいドメイン名を入力し、そのドメインの所有者であることを証明するための検証方法を選択します。
「完全修飾ドメイン名（FQDN）」の欄には、サイトのURLとなるドメインを入力します。この際、用途に合わせてワイルドカード証明書などを検討することで、運用の手間を削減できます。
| 入力タイプ | 入力例 | 特徴 |
|---|---|---|
| シングルドメイン | www.example.com | 特定のサブドメインのみを保護します。最も基本的な形式です。 |
| ワイルドカード | *.example.com | 同一階層のすべてのサブドメイン（mail.example.com, blog.example.comなど）を1枚の証明書で保護できます。 |
| ネイキッドドメイン | example.com | 「www」などのサブドメインが付かないドメインです。ワイルドカードと併用して追加することが推奨されます。 |
ドメイン名を入力したら、次に「検証方法」を選択します。AWSでは以下の2つの方法が提供されています。
- DNS検証（推奨）：DNSレコードに専用のCNAMEレコードを追加して検証する方法です。自動更新が可能になるため、基本的にはこちらを選択します。
- Eメール検証：ドメイン登録者のメールアドレスに承認メールを送信する方法です。更新のたびに手動対応が必要となるため、DNS操作ができない場合を除き推奨されません。
最後に「キーアルゴリズム」を選択しますが、通常はデフォルトの「RSA 2048」のままで問題ありません。設定内容を確認し、「リクエスト」ボタンをクリックすると、証明書の発行リクエストが作成されます。
この時点ではステータスが「保留中の検証（Pending validation）」となります。選択した検証方法（DNS設定またはメール承認）を完了させることで、ステータスが「発行済み（Issued）」に変わり、証明書が利用可能になります。
詳細な仕様や最新のUIについては、AWS公式ドキュメント：パブリック証明書をリクエストするもあわせてご確認ください。
DNS検証とEメール検証の違いと推奨設定
ACMでSSL証明書を発行する際、ドメインの所有権を証明するために「DNS検証」または「Eメール検証」のいずれかを選択する必要があります。AWSでは、管理の容易さと信頼性の観点からDNS検証を強く推奨しています。
それぞれの検証方法には、設定の手順や証明書の更新プロセスに大きな違いがあります。以下の表で主な違いを確認しましょう。
| 機能・特徴 | DNS検証（推奨） | Eメール検証 |
|---|---|---|
| 設定方法 | DNSサーバーにCNAMEレコードを追加 | 指定のメールアドレスで承認リンクをクリック |
| 証明書の更新 | 自動更新（対応不要） | 手動更新（メールのリンクをクリック） |
| 導入の手間 | DNS設定が必要（Route 53なら即時） | メール受信環境の準備が必要 |
| 適したケース | ほぼすべてのケース | DNS設定権限がない場合のみ |
DNS検証が推奨される理由
DNS検証が推奨される最大の理由は、証明書の自動更新が可能であることです。一度CNAMEレコードを設定すれば、ACMが定期的にDNSレコードを確認し、自動的に証明書の有効期限を更新してくれます。
一方、Eメール検証には以下のリスクや手間が伴います。
- 毎年の更新時に送られてくるメールを見逃すと、証明書が失効するリスクがある
- 担当者の退職やメールアドレスの変更により、承認メールを受け取れない場合がある
admin@domain.comなどの特定のメールアドレスを用意する必要がある
このように、運用負荷を下げ、証明書切れによるサイトダウンを防ぐためにも、基本的にはDNS検証を選択しましょう。詳細な仕様については、AWS公式ドキュメント（DNS検証）やEメール検証も参照してください。
Route 53を使用している場合の自動設定
AWSのDNSサービスであるAmazon Route 53を利用してドメインを管理している場合、DNS検証の設定は非常に簡単です。
ACMの管理画面で証明書をリクエストした後、表示される「Route 53 でのレコードの作成」ボタンをクリックするだけで、必要なCNAMEレコードが自動的にDNS設定に追加されます。手動でレコード名や値をコピー＆ペーストする必要がないため、設定ミスを防ぐことができます。
Route 53以外（お名前.comやGoDaddyなど）でドメインを管理している場合は、ACMが指定するCNAMEレコードの値をコピーし、各管理画面でレコードを追加してください。
発行した証明書をAWSリソースに適用する方法
AWS Certificate Manager (ACM) でステータスが「発行済み」となったSSL証明書は、そのままでは機能しません。適切なAWSリソースに関連付け（アタッチ）を行うことで、初めてHTTPS通信が可能になります。
重要な点として、ACMのパブリック証明書はEC2インスタンスへ直接インストールして使用することはできません。必ずロードバランサーやCDNなどのマネージドサービスを介して利用する仕組みになっています。ACMが対応している主なサービスは以下の通りです。
| サービス名 | 概要 | 主な用途 |
|---|---|---|
| Elastic Load Balancing (ALB/NLB) | 負荷分散装置 | Webサーバーへのトラフィック分散とSSL終端 |
| Amazon CloudFront | CDN (コンテンツ配信) | 静的コンテンツの高速配信とエッジでのSSL処理 |
| Amazon API Gateway | API管理 | カスタムドメインを使用したAPIの公開 |
ここでは、利用頻度が特に高い「Application Load Balancer (ALB)」と「Amazon CloudFront」への適用手順を解説します。
ALBへの証明書インストール手順
Webサーバー（EC2）の前段にALBを配置している場合、ALB側でSSL/TLSの暗号化・復号処理を行う「SSLオフロード」を設定します。これにより、バックエンドのEC2サーバーの負荷を軽減できるメリットがあります。
ALBへの適用は、EC2コンソールのロードバランサー設定画面から行います。具体的な手順は以下の通りです。
- AWSマネジメントコンソールで「EC2」を開き、左メニューから「ロードバランサー」を選択します。
- 対象のALBを選択し、「リスナーとルール」タブをクリックします。
- 「リスナーの追加」を選択し、プロトコルに「HTTPS」、ポートに「443」を指定します。
- 「セキュアリスナーの設定」セクションで、証明書ソースとして「ACMから」を選択し、発行済みの証明書をプルダウンから指定します。
- 設定を保存（追加）します。
すでにHTTPSリスナーが存在する場合は、リスナーの編集画面から証明書を差し替えることが可能です。また、ALBに関連付けられたセキュリティグループの設定で、ポート443（HTTPS）のインバウンド通信が許可されていることを必ず確認してください。
CloudFrontへの適用手順
Amazon CloudFrontを使用してコンテンツを配信する場合、エッジロケーションでSSL通信を行うためにACM証明書を設定します。CloudFrontへの適用には、他のリージョンとは異なる特別なルールが存在するため注意が必要です。
CloudFrontでACM証明書を利用する場合、必ず「米国東部（バージニア北部）リージョン (us-east-1)」で証明書を発行する必要があります。東京リージョンなどで発行した証明書は、CloudFrontの設定画面で選択肢に表示されません。
CloudFrontへの設定手順は以下の通りです。
- AWSマネジメントコンソールで「CloudFront」を開き、対象のディストリビューションIDをクリックします。
- 「一般 (General)」タブにある「編集 (Edit)」ボタンをクリックします。
- 「代替ドメイン名 (CNAMEs)」の項目に、証明書を取得したドメイン名が入力されていることを確認します。
- 「カスタムSSL証明書」のラジオボタンを選択します。
- 入力欄をクリックすると表示されるリストから、米国東部（バージニア北部）リージョンで発行したACM証明書を選択します。
- 画面下部の「変更を保存」をクリックします。
設定変更後、CloudFrontのステータスが「Deploying」から「Enabled」に戻るまで数分から数十分程度かかります。ステータスが完了した後、ブラウザからHTTPSでアクセスし、鍵マークが表示されることを確認してください。
詳細な仕様や最新の対応サービスについては、AWS Certificate Manager と統合されるサービスの公式ドキュメントも併せて参照してください。
AWS ACMの証明書自動更新の仕組み
AWS Certificate Manager (ACM) を導入する最大のメリットの一つは、SSL/TLS証明書の更新およびデプロイ作業を自動化できる点です。通常、SSL証明書には有効期限があり、期限切れによるサービス停止を防ぐためには定期的な更新作業が欠かせません。ACMはこの負担を大幅に軽減します。
ここでは、ACMがどのように証明書を自動更新するのか、そのタイミングや成功させるための条件について詳しく解説します。
自動更新が実行されるタイミング
ACMで発行されたパブリック証明書の有効期間は、発行日から13か月（395日）です。AWSは、証明書の有効期限が切れる60日前から自動更新プロセスを開始します。
自動更新プロセスが開始されると、ACMはドメインの所有権を再検証し、検証が成功すれば新しい有効期限を持つ証明書を発行します。その後、ACMは自動的に新しい証明書を、その証明書を使用しているAWSリソース（ALBやCloudFrontなど）へデプロイします。
自動更新が成功するための条件
ACMの証明書が自動的に更新されるためには、いくつかの条件を満たしている必要があります。特に「検証方法」によって自動更新の挙動が異なるため注意が必要です。
- 証明書がElastic Load Balancing (ELB) や Amazon CloudFront などのAWSリソースに関連付けられていること
- ドメインの検証設定が正しく維持されていること
- パブリック証明書であること（インポートした証明書は自動更新の対象外）
DNS検証を利用している場合（推奨）
DNS検証を選択している場合、自動更新は非常にスムーズに行われます。証明書発行時にDNSサーバーへ追加したCNAMEレコードがそのまま残っていれば、ACMは自動的にドメインの所有権を再確認し、証明書を更新します。
ユーザー側での追加作業は一切不要です。そのため、運用負荷を最小限に抑えたい場合はDNS検証が強く推奨されます。
Eメール検証を利用している場合
Eメール検証を選択している場合、自動更新プロセスが開始されると、ドメイン登録情報（WHOIS）に含まれる連絡先や、一般的な管理者アドレス（admin@ドメイン名など）宛に、AWSから承認リクエストメールが送信されます。
ドメイン所有者は、メール内のリンクをクリックして承認操作を行う必要があります。この操作を行わない限り、証明書は更新されません。メールを見逃すと証明書が期限切れになるリスクがあるため、注意が必要です。
検証方法による更新プロセスの違い
DNS検証とEメール検証における更新プロセスの違いを整理すると以下のようになります。
| 項目 | DNS検証 | Eメール検証 |
|---|---|---|
| ユーザーの対応 | 原則不要（完全自動） | 承認メールへの対応が必要 |
| 更新の確実性 | 高い（設定変更がなければ成功する） | 中（メール見逃しのリスクあり） |
| 推奨度 | 推奨 | 非推奨（特定の事情がある場合のみ） |
更新状況の確認と通知設定
自動更新が正常に行われたか、あるいは何らかの理由で失敗したかを把握するために、AWSからの通知を受け取れるようにしておくことが重要です。
ACMは、証明書の有効期限が近づくと（通常は45日前から）、AWS Health DashboardおよびAmazon EventBridgeを通じてイベントを発行します。これにより、更新が必要な証明書や、自動更新に失敗した証明書を検知することが可能です。
Amazon EventBridgeとAmazon SNSを組み合わせることで、証明書の期限切れが迫っている場合や更新に失敗した場合に、管理者のメールアドレスやSlackへアラートを飛ばす構成をとることが一般的です。
詳細な仕様については、AWS公式ドキュメント：ACM 証明書のマネージド更新もあわせてご確認ください。
AWS ACMに関するよくある質問
AWS ACM（AWS Certificate Manager）の導入や運用において、エンジニアがつまずきやすいポイントや疑問点をQ&A形式で解説します。
AWS ACMの利用料金はいくらですか？
AWS ACMで発行するパブリックSSL/TLS証明書自体は、無料で利用可能です。証明書の発行枚数や更新回数による課金はありません。
ただし、証明書単体では機能しないため、証明書を割り当てる以下のAWSリソースの利用料金が別途発生します。
- Elastic Load Balancing（ALB / NLB）
- Amazon CloudFront
- Amazon API Gateway
なお、組織内部向けに使用する「AWS Private CA」を利用してプライベート証明書を発行する場合は、月額料金と発行枚数に応じた従量課金が発生するため注意が必要です。
EC2インスタンスに直接インストールできますか？
いいえ、ACMで発行したパブリック証明書をAmazon EC2インスタンス内のWebサーバー（ApacheやNginxなど）に直接インストールすることはできません。
ACMのパブリック証明書は、セキュリティの観点から秘密鍵をエクスポートできない仕様になっています。そのため、EC2上のアプリケーションをSSL化したい場合は、前段にALBなどのロードバランサーやCloudFrontを配置して証明書を紐付ける構成にする必要があります。
証明書の有効期限と更新手続きについて教えてください
ACM証明書の有効期限は発行から13か月（395日）です。ACMには自動更新機能が備わっており、有効期限が切れる60日前から自動的に更新プロセスが開始されます。
基本的にユーザー側での作業は不要ですが、検証方法や利用状況によって自動更新が失敗するケースもあります。特にCNAMEレコードが削除されている場合や、証明書がどのAWSリソースにも関連付けられていない場合は更新されないため、定期的なステータス確認をおすすめします。
DNS検証とEメール検証はどちらを選ぶべきですか？
運用管理の容易さから、基本的には「DNS検証」の利用を推奨します。それぞれの特徴や違いは以下の通りです。
| 検証方法 | メリット | デメリット |
|---|---|---|
| DNS検証 | Route 53ならボタン一つで設定可能 自動更新がスムーズに行われる |
DNSレコードの変更権限が必要 |
| Eメール検証 | DNSの権限がなくても発行可能 | 更新時にメール承認作業が必要 担当者不在時の更新漏れリスク |
DNS検証を選択し、Route 53でドメイン管理を行っている場合、ACMが提示するCNAMEレコードを自動で追加できるため、設定ミスを防ぎながら迅速に発行できます。
CloudFrontでACM証明書が表示されないのはなぜですか？
CloudFrontの設定画面でACM証明書が選択肢に表示されない主な原因は、証明書を発行した「リージョン」の違いです。
CloudFrontはグローバルに配信されるサービスであるため、紐付けるACM証明書は必ず米国東部（バージニア北部）リージョン（us-east-1）で発行する必要があります。東京リージョン（ap-northeast-1）などで作成した証明書はCloudFrontでは利用できないため、コンソールのリージョン設定を切り替えてから再度リクエストを行ってください。
詳細な要件については、AWS公式サイトのドキュメントも併せてご確認ください。
代替ドメイン名と HTTPS の使用要件 - Amazon CloudFront
まとめ
本記事では、AWS Certificate Manager（ACM）を活用したSSL証明書の導入手順と運用のポイントについて解説しました。
記事の要点は以下の通りです。
- ACMを利用すれば、信頼性の高いパブリック証明書を無料で発行できる。
- 検証方法は、運用負荷が低く更新がスムーズなDNS検証が推奨される。
- ALBやCloudFrontと連携させるだけで、簡単にSSL化と自動更新が実現する。
- EC2インスタンス内部への直接インストールはできない点に注意が必要。
ACMは、AWS環境でのセキュリティ強化における最適解です。まずはRoute 53などのDNS設定を確認し、マネジメントコンソールから証明書のリクエストを始めてみましょう。
