AWSのSSL証明書の選び方と運用判断軸｜ACM・更新漏れ防止・監視設計まで解説

Date 2026.05.21 　|　Update 2026.05.21

AWS保守

AWSでは、AWS Certificate Manager（ACM）を使うことでSSL/TLS証明書の発行・管理・更新を自動化できます。それにより、期限切れ対応や手動更新といった運用負荷を大幅に軽減できます。

しかし、CloudFrontやALB、API Gatewayなど複数サービスをまたぐ構成では、証明書の配置や更新責任が複雑になり、「どの方式を選ぶべきか」「本当に失効しないか」と悩むケースも少なくありません。

本記事では、「AWSでHTTPS化を検討しているインフラ担当者」「証明書運用を標準化したい方」「ACMを使うべきか判断に迷っている方」を対象に、以下を整理します。

なぜACMが第一候補になるのか
どのような場合に例外対応が必要か
証明書の選び方と運用設計の考え方

テクノプロはAWSの構築から運用まで幅広く支援しています

今すぐ問い合わせる

Index

AWSでSSL証明書を使うなら、まず何を選ぶべきか

AWS環境におけるSSL証明書設計では、最初に「原則」と「例外」を切り分けることが重要です。

結論から言えば、公開Webサイトや外部向けAPIでは、まずAWS Certificate Manager（ACM）を第一候補として検討するのが合理的です。

公開Web / APIではACMが第一候補になる理由

ACMはAWSサービスと統合されており、無料のパブリック証明書の発行に加え、証明書の更新が自動化されるため、手動更新の手間や期限切れリスクを大きく削減できます。

さらに、CloudFrontやElastic Load Balancing（ALB）、Amazon API Gatewayなどの主要サービスと容易に連携でき、証明書の発行も数クリックで完了するため、構築から運用までの負担を抑えられます。

こうした特性により、WebサイトのHTTPS化によるセキュリティ強化はもちろん、プライベートネットワーク内の通信保護やコンプライアンス要件への対応など、幅広いユースケースに対応できます。

テクノプロが支援してきたAWS環境でも、ACMを前提に設計することで、証明書更新に伴う障害や属人化した運用のリスクを抑えやすくなるケースが多く見られます。

一方で、EC2上でのアプリケーション終端、オンプレミスや他クラウドとの共通証明書利用、内部通信用途などでは、ACMだけでは要件を満たせない例外もあります。

本章では、後続の比較や設計検討を迷いなく進めるために、「ACMを標準とし、どこからが例外になるのか」という判断の起点を明確にします。

ACMの最大の特長はAWSサービスと統合されており、以下のような特徴があります。

無料のパブリック証明書を発行可能
証明書の更新が自動化されており、手動での更新作業が不要
AWSの主要サービス（ELB, CloudFront, API Gatewayなど）と簡単に連携可能
SSL証明書の発行プロセスが数クリックで完了

CloudFront、Elastic Load Balancing（ALB）、Amazon API Gatewayといったマネージドサービスと組み合わせることで、証明書の取得から更新までをAWS側に委ねられます。

これにより、手動更新や担当者依存の運用を排除でき、長期的な運用品質が安定します。

ACMでは足りない例外条件（EC2・オンプレミス・Private用途）

一方で、ACMは秘密鍵をエクスポートできないため、EC2でアプリケーションが直接TLS終端を行う構成や、オンプレミスとの共通証明書利用には制約があります。また、社内向け通信やmTLSが必要な場合は、AWS Private CAなど別の選択肢が必要になります。

「ACMで足りるかどうか」ではなく、「なぜ足りないのか」を要件として言語化することが重要です。

AWSで使えるSSL証明書関連サービスの全体像

AWSでは、SSL/TLS証明書の発行・管理・更新・監視に関して、複数のマネージドサービスが提供されています。代表的なものは以下の通りです。

AWSで使えるSSL証明書関連サービスの全体像

サービス名	主な役割	運用上のポイント
AWS Certificate Manager（ACM）	パブリックSSL証明書の発行・管理・自動更新	公開Web/APIの第一候補。対応サービスに限定あり
エクスポート可能なパブリック証明書（ACM）	証明書をEC2・オンプレミスでも利用	ACM中心設計を維持しつつ例外対応
インポート証明書	外部CA証明書の取り込み管理	更新・期限管理は利用者責任
AWS Private CA	社内向け通信・mTLS用認証局	コストと運用負荷を要検討
Elastic Load Balancing（ALB/NLB/CLB）	TLS終端でACM証明書を利用	更新はACMに依存、設計はシンプル
Amazon CloudFront	CDN終端でHTTPS通信	証明書はus-east-1限定
Amazon API Gateway	API公開時のHTTPS終端	エンドポイント種別で構成が変わる
Amazon Route 53	DNS検証による証明書自動更新	自動更新の要
Amazon CloudWatch / EventBridge	有効期限・更新イベントの監視	失効事故防止の仕組み
AWS Config / Security Hub / CloudTrail	構成変更検知・監査・可視化	監査・ガバナンス用途

AWSで使えるSSL証明書の選択肢と判断軸

AWSでは、用途に応じて複数の証明書方式を選択できます。判断の軸となるのは、機能差ではなく、更新・監視・責任分界をどこまでAWSに任せられるかです。

ACM（パブリック証明書）が標準になる理由と制約

ACMのパブリック証明書は、公開用途に必要な機能を網羅し、更新も自動です。一方で、対応サービスが限定される点や、証明書を外部へ持ち出せない点は理解しておく必要があります。

外部CAインポート・Private CA・エクスポート証明書が必要になるケース

外部CA証明書のインポートは、企業ポリシーや既存契約が理由になることが多く、AWS外も含めた共通運用が可能です。AWS Private CAは社内向け通信やmTLS用途で有効ですが、運用責任は自社側に残ります。

エクスポート可能なACM証明書は、ACM中心設計を維持しながらEC2やオンプレミスまで範囲を広げたい場合の現実的な選択肢です。

証明書設計で判断に影響する発行・検証のポイント

ACMでの証明書発行の基本手順

ACMを利用したSSL/TLS証明書の発行は、複雑な作業を必要とせず、基本的には以下の流れで進められます。

1．ドメインの所有確認
ACMで証明書を発行するには、対象ドメインの所有権を確認する必要があります。検証方法としては、DNS検証またはメール検証が利用可能です。特に自動更新を前提とする場合は、DNS検証が推奨されます。

2．証明書のリクエスト
AWSマネジメントコンソールから対象ドメインを指定し、数クリックで証明書の発行リクエストを送信できます。

3．AWSサービスへの適用
発行された証明書は、Elastic Load Balancing（ALB）やCloudFront、API Gatewayなどに適用することで、HTTPS通信に利用されます。

DNS検証とメール検証の選択が運用に与える影響

DNS検証とメール検証は、取得手順の違いだけでなく、運用負荷や更新リスクに大きく影響します。

DNS検証は、Route 53などのDNS管理と連携することで検証情報を維持でき、ACMの自動更新と相性がよく、長期運用に適しています。

一方、メール検証は導入が容易な反面、担当者変更や確認漏れにより更新が滞るリスクがあります。

このように、検証方式の選択は、証明書更新を自動化するか、人手に依存するかという運用方針に直結します。

単一ドメイン・SAN・ワイルドカードをどう考えるか

証明書のドメイン構成の選び方は、管理対象だけでなく、影響範囲や運用のしやすさにも影響します。

単一ドメイン証明書は影響範囲が限定されるため管理しやすい一方、数が増えると運用負荷が高くなります。

SAN証明書は複数ドメインをまとめて管理できますが、1つの証明書に依存する分、更新時の影響が広がります。ワイルドカード証明書はサブドメイン増減に対応しやすい反面、適用範囲が広く管理が難しくなる傾向があります。

重要なのは、証明書の「優劣」ではなく、どの単位で管理し、どこまで影響を許容するかを設計時に決めることです。

TLS終端先ごとの構成判断（AWSサービス別）

AWSでは、CloudFrontやElastic Load Balancing（ALB）、Amazon API Gatewayなど、複数のサービスでTLS終端を行うことができます。

しかし、どのサービスでTLSを終端するかによって、証明書の配置場所や更新方法、運用負荷が大きく変わります。設計段階でこの違いを正しく理解していないと、証明書管理が分散したり、更新漏れのリスクが高まる要因にもなります。

本章では、主要なAWSサービスごとの違いと、証明書運用の観点で押さえておくべき判断ポイントを整理します。

CloudFront / ALB / API Gatewayで何が違うか

CloudFront、ALB、API GatewayではTLS終端位置と証明書管理方式が異なります。どこでTLSを終端するかは、性能やセキュリティだけでなく、証明書更新の責任をどこに集約するかという運用判断でもあります。

リージョン制約（us-east-1問題）と設計時の落とし穴

CloudFrontで利用する証明書はus-east-1リージョンで管理する必要があります。この制約を見落とすと、後から証明書を作り直す必要が出てきます。

失効させないための更新・監視・監査設計

ACM自動更新が成立する条件と失敗例

ACMは自動更新されますが、DNS検証が維持されていること、正しくリソースに紐付いていることが前提です。構成変更後に更新が止まっていたケースも実際に存在します。

インポート証明書を含む場合の更新・監視設計

インポート証明書やPrivate CAを利用する場合、更新計画と監視は自社責任になります。CloudWatch、EventBridge、AWS Config、CloudTrailなどを組み合わせ、仕組みとして失効を防ぐ設計が必要です。

セキュリティ・権限・TLSポリシーの判断軸

秘密鍵管理とIAM権限分離の考え方

ACM中心設計により、秘密鍵管理をAWSに委ねられる点は大きなメリットです。エクスポートが必要な場合でも、IAMの最小権限設計が不可欠です。

TLSポリシーとコンプライアンス要件への対応

暗号スイートやTLSバージョンは、業界基準や社内規程から逆算して設計します。

方式別のコストと運用負荷をどう比較するか

SSL証明書の費用は、証明書そのものの価格だけでなく、運用コストを含めた投資対効果（ROI）で評価することが重要です。ACMは証明書費用が無料であり、更新自動化によって人件費と障害リスクを大幅に抑えられます。

SSL証明書方式別の費用・運用比較

方式	証明書費用	運用負荷	ROI傾向
ACM	低	低	高
外部CA	中	中	中
Private CA	中～高	高	用途依存

ユースケース別の推奨構成と次のアクション

代表的ユースケース別の推奨構成

公開Web：CloudFront + ACM
API公開：API Gateway または ALB + ACM
内部通信：AWS Private CA またはエクスポート可能なACM証明書

よくある質問（FAQ）

Q１：EC2でACM証明書は直接使えますか？

A：原則として、通常のACMパブリック証明書はEC2に直接配置して使用することはできません。
ACMパブリック証明書は、CloudFront、ALB、API Gatewayといった対応するマネージドサービスでの利用を前提としています。EC2上のアプリケーションでTLS終端を行う場合は、外部CA証明書や、エクスポート可能なパブリック証明書（ACM）を利用する構成が選択肢になります。

EC2で直接終端するか、ALBなどで終端するかは、性能要件だけでなく、証明書更新・秘密鍵管理の責任をどこに持たせるかという運用観点で判断することが重要です。

Q2：CloudFrontで使う証明書がus-east-1 に限定されるのはなぜですか？

A：CloudFrontはグローバルサービスであり、証明書管理をus-east-1 リージョンに集約する設計になっているためです。
CloudFrontに紐づけるACM証明書は、必ず米国東部（バージニア北部）リージョンで発行・管理する必要があります。この制約を理解していないと、「別リージョンで証明書を作ったため使えない」といった手戻りが発生します。設計段階でCloudFront利用が決まっている場合は、初期からus-east-1 を含めた証明書管理方針を決めておくことが重要です。

Q3：DNS検証とメール検証は、どちらが運用しやすいですか？

A：長期運用を前提とする場合は、DNS検証のほうが運用しやすいケースが一般的です。
DNS検証は、Amazon Route 53などでDNS管理ができていれば、証明書の更新を完全に自動化できます。一方、メール検証は初期取得が手軽な反面、担当者変更やメール見落としにより更新が滞るリスクがあります。
特にACMの自動更新を安定して成立させたい場合、DNS検証を前提に設計することが、更新漏れ防止の観点で有効です。