証明書の期限切れは、事前に必ず分かっていたはずの障害です。それでも起きるのは、管理者が部門ごとに分散し、「誰がいつ更新するのか」が曖昧なまま運用されているからです。
対策の第一候補になるのが、AWS Certificate Manager（ACM）。ただしACMがすべての要件を満たすわけではなく、EC2での秘密鍵の利用や組織の実在証明が必要な場面では、別の選択肢が要ります。本記事を読み終えるころには、自社の構成をどこまでACMに寄せられるか、どこから例外として切り分けるべきかを判断できる状態を目指します。

まず結論｜ACMを第一候補にすべき条件・そうでない条件

あるBtoBサービスを運営する企業では、ALBの証明書はインフラチームが、CloudFrontの証明書はマーケティング部門が委託した制作会社が、それぞれ個別に外部CAで取得・管理していました。
ある朝、突然ALBの証明書が期限切れとなり、サービスサイトにアクセスできなくなるという事態が発生しました。証明書の管理者が退職しており、更新のタイミングを把握していた人が社内に誰もいなかったためです。 この経験をきっかけに、同社は証明書管理をACM中心に統一する検討を始めました。

証明書管理を見直す際、多くの担当者が最初に迷うのは「結局ACMだけで完結できるのか」という点です。この章では、判断の前提となる結論を先に示します。

ACMは、AWSが提供する無料の証明書管理サービスです。多くのケースで第一候補になりますが、すべての要件を満たすわけではありません。

ACMが向くケース：

• ALB、CloudFront、API GatewayなどAWSマネージドサービスにTLS終端を任せられる
• 証明書の更新作業を自動化し、手動更新の負荷をなくしたい
• パブリックドメインの証明書を、複数サービスに使い回したい

ACMが向かないケース：

• EC2やオンプレミスサーバー上で秘密鍵を直接扱う必要がある
• 社内システム間の通信（mTLSなど、双方向で相手を認証し合う通信方式）向けに、社内限定の証明書が必要
• 組織の実在性を証明する証明書（商用CAが発行するOV／EV証明書）が求められる

先述の企業の例のように、証明書の管理者が分散していると、期限切れという単純な事故が大きなサービス停止につながります。ACMを中心に据えることで、こうした属人化のリスクを構造的に減らせます。

この記事で分かること

本記事では、ACMの基本機能や料金・制約、CloudFrontやALBなど終端先ごとの設計、Let’s EncryptやAWS Private CAとの比較、導入設計とガバナンスの実践、よくある質問までを取り上げ、ACMを第一候補としながら、例外的に他方式を組み合わせるべきかを一気通貫で解説します。読み終えるころには、自社の証明書運用をどこまでACM中心に寄せ、どの範囲を例外として切り分けるべきかを判断できる状態を目指します。

ACM（AWS Certificate Manager）とは何か

ACMを正しく使うには、まず基本的な仕組みと証明書の種類を理解しておく必要があります。

ACMでできることと役割

ACMは、SSL/TLS証明書の発行・更新・管理をAWS上で一元化するサービスです。従来、証明書の取得や更新は手動で行われることが多く、更新漏れによる通信エラーが運用上のリスクとなっていました。ACMを使うことで、対応するAWSサービスに証明書を紐づければ、更新作業の多くを自動化できます。

証明書の種類（パブリック／プライベート／インポート）の違い

ACMで扱える証明書は、大きく3種類に分かれます。

種類	概要	主な用途
パブリック証明書	ACMがドメイン検証を行い無料で発行する証明書	ALB、CloudFront等のパブリックエンドポイント
プライベート証明書	AWS Private CAを使って発行する社内向け証明書	社内システム間通信、mTLS
インポート証明書	外部CAで取得した証明書をACMに取り込んだもの	既存の商用CA証明書を活用したい場合

このうち、無料で自動更新の対象になるのはACM発行のパブリック証明書のみです。インポート証明書は自動更新の対象外となるため、この違いを理解しておくことが重要です（詳細は後述の「料金・制約・判断軸を一度に整理する」で解説します）。

料金・制約・判断軸を一度に整理する

ACMを第一候補にする前に、見落としやすい制約を先にまとめて確認しておきましょう。

無料で使える条件と課金が発生する条件

ACMでパブリック証明書を発行し、ALB・CloudFront・API GatewayなどのAWSサービスに関連付けて使う場合、証明書自体の発行・更新に料金はかかりません。

一方で、以下のケースでは課金が発生します。

• エクスポート可能なパブリック証明書：EC2やオンプレミスなど、ACM非対応の環境に証明書を持ち出したい場合に利用する機能で、有料
• AWS Private CA：社内向けのプライベート証明書を発行する基盤自体に、月額の利用料が発生

料金の詳細は変更される可能性があるため、最新の情報はAWS公式の料金ページで確認することをおすすめします。

リージョン制約（CloudFrontのus-east-1要件など）

ACMには、サービスごとに異なるリージョン制約があります。特に注意したいのがCloudFrontです。CloudFrontで使う証明書は、米国東部（バージニア北部、us-east-1）リージョンでACMから発行する必要があります。CloudFrontはグローバルサービスのため、他のリージョンで発行した証明書を直接指定することはできません。

一方、ALBやAPI Gatewayは、それぞれのリソースが存在するリージョンで証明書を発行する必要があります。マルチリージョン構成を取っている場合は、リージョンごとに証明書発行が必要になる点も覚えておきましょう。

更新自動化・秘密鍵管理・マルチアカウント運用の可否

ACM発行のパブリック証明書は、DNS検証を選択していれば自動更新の対象になります。更新のたびに手動で作業する必要がなく、証明書の期限切れによる障害を大幅に減らせます。

一方、インポート証明書は自動更新の対象外です。外部CAで取得した証明書を使い続ける場合、更新期限を自社で管理し、期限が近づいたら再度インポートする作業が必要になります。

秘密鍵についても、ACM発行の証明書はAWS側で管理されるため利用者が直接鍵を扱うことはありません（有料のエクスポート可能なパブリック証明書を選択した場合は、秘密鍵をエクスポートして取得できます）。一方、インポート証明書は鍵の管理責任が利用者側に残る点に注意が必要です。

マルチアカウント運用では、パブリック証明書はACMが発行する時点で1つのリージョン・1つのアカウントに紐づきます。そのため、アカウント間やリージョン間で証明書自体を共有・エクスポートすることはできません。社内向けのプライベート証明書については、AWS Private CA（認証局）をAWS Resource Access Manager（RAM）で共有し、各アカウントがその共有CAを使って証明書を個別に発行する運用にするかを検討します。

サービスごとに異なる証明書の設定と切替時の注意点

前述の企業では、期限切れをきっかけにALBの証明書をACMへ移行することを決めました。移行を担当したエンジニアは、いきなり本番環境の証明書を差し替えるのではなく、まず並行稼働の期間を設けるアプローチを取りました。
DNS検証用のレコードを事前に登録し、ACMでの検証が完了してから、既存の外部CA証明書と新しいACM証明書の両方をALBのリスナーに関連付けた状態で、数日間動作を確認しました。 問題がないことを確認したうえで旧証明書を切り離したところ、利用者に気づかれることなく移行を完了できました。

ACMで発行した証明書は、どのAWSサービスに適用するかによって設計上の注意点が変わります。同じACMでも、サービスごとの制約を理解していないと、切替作業でつまずくことがあります。

ALB・CloudFrontで使う場合の考え方と切替時の注意点

ALBは、証明書が配置されているリージョンと同一リージョンのリスナーにのみ証明書を関連付けられます。既存の外部CA証明書からACMへ切り替える際は、以下の手順で進めると、先述の企業のように事故を防ぎやすくなります。

切替の進め方：

1. 証明書の発行：ACMで新しいパブリック証明書をリクエストし、DNS検証用のCNAMEレコードをDNSに登録する
2. 検証完了の確認：ACMコンソールで証明書のステータスが「発行済み」になったことを確認する
3. リスナーへの関連付け：ALBのHTTPSリスナーに、新しい証明書を追加で関連付ける（既存証明書を残したまま並行稼働させる）
4. 動作確認：新しい証明書での接続を、社内環境やステージング環境で確認する
5. 旧証明書の切り離し：問題がなければ旧証明書の関連付けを解除する

事前に決めておきたい点：

• 切替のタイミング：アクセスが少ない時間帯にメンテナンスウィンドウを設定する
• DNS検証用のCNAMEレコードを事前登録できるか：社内のDNS管理者との調整に時間がかかる場合があるため、早めに着手する
• 旧証明書の失効タイミングと重複期間の設計：切替直後に問題が発覚しても旧証明書に戻せるよう、一定期間は両方を有効にしておく

CloudFrontも同様の手順で切替が可能ですが、証明書のリージョンがus-east-1に限定される点は前述の通りです（リージョン制約については前章「料金・制約・判断軸を一度に整理する」を参照してください）。CloudFrontの場合は、ディストリビューションの設定変更が全世界のエッジロケーションに反映されるまで数分〜数十分かかることがあるため、切替直後は焦らず反映を待つことも重要です。

API Gateway・EC2／オンプレミスで使う場合の考え方

API Gatewayでも、カスタムドメイン設定にACM証明書を利用できます。エッジ最適化タイプの場合はCloudFrontと同様にus-east-1での証明書発行が必要ですが、リージョンタイプの場合は、API Gatewayが配置されているリージョンで証明書を発行します。どちらのタイプを選んでいるかによって、証明書発行のリージョンを間違えないよう注意しましょう。

EC2やオンプレミスサーバーでは、ACM発行の通常の証明書をそのままインストールすることはできません。TLS終端をEC2上のWebサーバーで行いたい場合は、以下のいずれかの選択肢を検討します。

選択肢	特徴	向いているケース
エクスポート可能なパブリック証明書	有料だが、ACMの管理下で証明書を発行しつつ外部へ持ち出せる	ACMの発行フローを維持しつつEC2にも適用したい場合
外部CA証明書を直接インストール	追加費用は証明書取得費のみ	すでに外部CAとの契約があり、継続利用したい場合
ALBを前段に配置しTLS終端を移す	構成変更が必要だが、ACMの自動更新をフル活用できる	構成変更の余地があり、長期的に運用負荷を減らしたい場合

構成変更が可能であれば、ALBを前段に配置してTLS終端をALB側に寄せる選択肢が、運用負荷の観点から最も推奨されます。EC2側ではHTTP通信のみを受け付け、ALBとEC2間の通信は同一VPC内で完結させることで、証明書更新の手間そのものをなくせるためです。

他方式との比較でACMを選ぶ基準

ACM以外の選択肢と比較することで、自社に合う方式がより明確になります。それぞれの方式が持つ制約や強みを理解したうえで、判断軸を整理しましょう。

Let’s Encrypt・商用CAとの違い

Let’s Encryptは無料で証明書を発行できるサービスですが、証明書の有効期間が短く（発行から90日程度）、更新サイクルが短い分、自動更新の仕組みを自前で構築する必要があります。多くの場合、サーバー上で更新スクリプトを定期実行する運用になり、スクリプトの障害や証明書の設置先変更に気づかないまま放置されるリスクがあります。

ACMはAWSサービスと連携する前提であれば、この自動更新の仕組みをAWS側に任せられる点が大きな違いです。特に、複数のAWSサービスにまたがって証明書を管理する場合、Let’s Encryptでは更新のたびに複数のサーバーへ証明書を配布する手間が発生しますが、ACMではAWSサービス側が証明書の参照を自動的に更新するため、この手間がありません。

商用CAは、組織の実在性を証明するOV（Organization Validation、組織の存在を確認したうえで発行される証明書）証明書やEV（Extended Validation、より厳格な審査を経て発行される証明書）証明書を発行できます。ACMのパブリック証明書はドメイン検証（DV、ドメインの所有権のみを確認する検証方式）のみのため、金融機関や特定の業界規制がある業種では、商用CAが必要になるケースがあります。

選定の実務判断ポイント：

• 自社の業界に、組織の実在証明が必要な規制やガイドラインがあるか、コンプライアンス部門に確認する
• 顧客や取引先から、特定の検証レベルの証明書を求められていないか確認する
• 該当する規制がない場合は、運用負荷の軽減を優先しACMを選ぶ方が合理的なケースが多い

比較項目	ACM	Let’s Encrypt	商用CA
費用	無料（一部機能は有料）	無料	有料
更新自動化	AWSサービス連携時は自動	自前の仕組みが必要	提供元により異なる
検証レベル	ドメイン検証（DV）のみ	ドメイン検証（DV）のみ	DV／OV／EVに対応
主な用途	AWSサービスでのTLS終端	汎用的なWebサーバー	組織の実在証明が必要な場合

AWS Private CAとの違い（社内向け証明書が必要なとき）

AWS Private CAは、社内システム間の通信や、mTLS（相互にクライアント証明書を検証し合う通信方式で、サーバーとクライアントの双方が正当な相手であることを確認し合う）のように、パブリックな検証が不要な証明書を発行するためのサービスです。ACMのパブリック証明書とは異なり、独自の認証局を構築できるため、社内ネットワーク限定の証明書発行に向いています。

AWS Private CAの導入を検討すべき実務上のシグナル：

• マイクロサービス間の通信で、サービスごとに身元を確認し合う必要が出てきた
• 社内の複数システムで、外部から取得した自己署名証明書がバラバラに管理されており、統制が取れていない
• コンテナ環境（ECSやEKSなど）で、Pod間・サービス間通信の暗号化と認証を標準化したい

インポート証明書の自動更新可否については前章で解説した通り対象外ですが、AWS Private CAで発行した証明書はACM経由で管理でき、更新の自動化も可能です。社内向け証明書が必要になった時点で、AWS Private CAの導入を検討するとよいでしょう。なお、AWS Private CAは月額の基本料金が発生するため、社内向け証明書の発行数が少ない場合は、コストと運用負荷のバランスを見て導入時期を判断することをおすすめします。

導入設計とガバナンスの実践

ACMを安全に運用するには、導入時の設計と、運用フェーズでのガバナンス整備の両方が欠かせません。ここでの設計が甘いと、証明書の存在自体を見落としたまま期限切れを迎えるといった事故につながります。

対象棚卸しとDNS検証の進め方

導入の第一歩は、現在使用しているすべての証明書を棚卸しすることです。以下の項目を一覧化し、どれをACMに移行できるかを整理します。

棚卸しシートの項目例：

• ドメイン名（サブドメインも含めて漏れなく）
• 適用先のサービス（ALB／CloudFront／API Gateway／EC2など）
• 証明書の発行元（ACM／外部CA／自己署名など）
• 有効期限
• ACMへの移行可否（移行できない場合はその理由も記載）

DNS検証は、ACMが推奨する検証方式です。証明書発行時に指定されたCNAMEレコードをDNSに登録することで、ドメインの所有権を確認します。DNS検証を選ぶメリットは、検証が完了すれば以降の更新確認が自動化される点にあります。

DNS検証の実施手順：

1. ACMで証明書をリクエストする際、検証方法として「DNS検証」を選択する
2. ACMが指定するCNAMEレコード（名前と値のペア）を確認する
3. 自社が管理するDNSサービス（Route 53や外部DNSサービス）に、指定されたレコードを登録する
4. ACMが自動的にレコードを確認し、検証が完了すると証明書のステータスが「発行済み」に変わる

メール検証という方式もありますが、ドメインの管理者宛のメールに手動で対応する必要があるため、自動更新を重視するならDNS検証を選ぶことをおすすめします。特にRoute 53を利用している場合は、ACMコンソールからワンクリックでレコードを追加できるため、作業の手間がさらに少なくなります。

権限設計とIaCによるライフサイクル管理

証明書の発行・削除には、IAM（AWSのアクセス権限を管理する仕組み）で適切な権限設計を行う必要があります。以下のような権限分掌の考え方が一般的です。

権限設計の考え方：

• 証明書の発行・削除：インフラ管理チームなど、限られたメンバーのみに許可する
• 証明書の閲覧・ステータス確認：開発チームなど、幅広いメンバーに許可してもよい
• DNS検証用レコードの登録：DNS管理者と証明書担当者で作業を分担する場合、両者の連携フローを事前に決めておく

最小権限の原則に基づいて設定することで、意図しない証明書の削除や誤った紐づけを防ぎます。

また、証明書の発行やAWSサービスへの関連付けを、CloudFormationやTerraformなどのコードで管理する運用（インフラをコードとして管理する考え方）も有効です。手動作業を減らし、変更履歴をコードの差分として追跡できるようになるほか、証明書のリクエストからALB・CloudFrontへの関連付けまでを一連のテンプレートとして定義しておけば、複数環境への展開や再現も容易になります。

期限監視と変更管理、マルチアカウント運用の標準化

自動更新の対象であっても、更新が正常に完了したかを監視する仕組みは別途必要です。以下のような組み合わせが一般的です。

監視・通知の仕組み：

1. Amazon EventBridgeでACMの証明書イベント（発行、更新、失効間近など）を検知する
2. Amazon CloudWatchで証明書の有効期限をメトリクスとして可視化し、一定日数を切ったらアラームを発火させる
3. Amazon SNSを通じて、担当者にメールやチャットツールへの通知を送る

この組み合わせにより、自動更新の対象外となるインポート証明書についても、期限が近づいたタイミングで担当者に気づかせる仕組みを作れます。

変更管理の面では、AWS Configで証明書リソースの設定変更を記録し、AWS CloudTrailで「誰が」「いつ」証明書関連の操作を行ったかを追跡できるようにしておくと、監査対応がしやすくなります。特に、証明書の削除や権限変更といった重要な操作については、CloudTrailのログをもとに定期的にレビューする運用を組み込んでおくと安心です。

マルチアカウント運用では、証明書発行のルールやIAM権限設計をアカウント間で統一し、標準化したテンプレートをCloudFormationやTerraformで配布する運用が、事故を防ぐうえで効果的です。AWS Organizationsを利用している場合は、共通のガードレール（禁止事項や必須設定のルール）として証明書関連の設定を組み込むことも検討できます。

ACMでよくある質問

Q.CloudFrontでus-east-1が必要なのはなぜか

A.CloudFrontはグローバルサービスとして提供されているため、証明書の管理を一つのリージョンに統一する必要があり、米国東部（us-east-1）リージョンでの発行が必須とされています。詳しい制約の内容は、前述の「料金・制約・判断軸を一度に整理する」セクションをご覧ください。

Q.インポート証明書は自動更新できるか

A.インポート証明書は自動更新の対象外です。外部CAで取得した証明書を使う場合は、期限管理を自社で行い、期限が近づいたら手動で再インポートする必要があります。詳細は「料金・制約・判断軸を一度に整理する」の解説を参照してください。

Q.DNS検証が通らないときは何を確認するか

A.DNS検証が完了しない場合、以下の点を確認しましょう。

• 指定されたCNAMEレコードが、正しいDNSゾーンに登録されているか
• レコードの反映に時間がかかっている可能性がないか（反映まで数分〜数時間かかることがある）
• ドメインの委任先DNSサーバーが、実際に運用しているDNSサービスと一致しているか

基本的な検証の進め方自体は、前述の「対象棚卸しとDNS検証の進め方」で解説しています。

Q.EC2やオンプレミスでACM証明書はそのまま使えるか

A.通常のACM証明書は、秘密鍵をAWSの外部に持ち出せない仕組みになっているため、EC2やオンプレミスサーバーに直接インストールすることはできません。持ち出しが必要な場合は、有料のエクスポート可能なパブリック証明書を利用するか、ALBなどACM対応サービスを前段に配置する構成を検討してください。

まとめ｜ACMを第一候補にするための最終チェックリスト

ACMが最適な条件／ACM以外を選ぶべき条件

ここまでの内容を、最終的な判断軸として整理します。

ACMが最適な条件：

• ALB、CloudFront、API Gatewayなど、ACM対応のAWSサービスでTLS終端が完結する
• 証明書更新の自動化によって、運用負荷と更新漏れのリスクを減らしたい
• 費用を抑えつつ、標準的なドメイン検証（DV）で十分な要件である

ACM以外を選ぶべき条件：

• EC2やオンプレミスで秘密鍵を直接扱う必要がある（エクスポート可能な証明書または外部CAが必要）
• 組織の実在証明（OV／EV）が求められる（商用CAが必要）
• 社内限定のプライベート証明書やmTLSが必要（AWS Private CAが必要）

次にやること（棚卸し→PoC→段階移行）

証明書管理の見直しは、一度にすべてを切り替える必要はありません。次の3ステップで進めるのが現実的です。

1. 棚卸し：現在使用中の証明書を一覧化し、ACMに移行できる範囲と、例外として残る範囲を仕分ける
2. PoC：影響の小さいサービスから移行を検証し、切替手順と並行稼働の期間を確定させる
3. 段階移行：検証結果をもとに、本番環境へ順次展開する

このうち最もつまずきやすいのが、最初の棚卸しです。証明書の管理者が部門をまたいで分散していると、そもそも「何が、どこで、いつまで有効なのか」を把握するだけで数週間を要することも珍しくありません。ACMに寄せられるか否かの判断も、ALB・CloudFront・EC2といった終端先ごとの構成を踏まえる必要があります。

テクノプロのAWSソリューション事業では、証明書の棚卸しから移行可否の判断、PoCの設計、本番移行の伴走までを一貫してご支援しています。AWS認定資格を持つエンジニアが、現行構成を確認したうえで、ACM中心に統一できる範囲と、AWS Private CAや外部CAとの組み合わせが必要な範囲を整理します。

「まず自社の構成で何ができるか知りたい」という段階でも構いません。テクノプロのAWSソリューション事業までお気軽にご相談ください。