AWS ACM解説: パブリックとプライベート証明書の比較、料金、発行手順

AWS ACM基礎：パブリックとプライベート証明書の使い分け

ACMが提供するSSL/TLS証明書の種類と基本機能

AWS Certificate Manager (ACM) は、AWS環境内でのSSL/TLS証明書の発行、管理、デプロイを自動化・簡素化するサービスです。このサービスを活用することで、ユーザーは証明書の有効期限切れによるトラブルや手動更新の負担から解放されます。ACMが提供する証明書は大きくパブリック証明書とプライベート証明書の2種類に分けられ、それぞれの用途と信頼モデルが異なります。SSL/TLS証明書の主要な役割は、通信データの暗号化による盗聴防止と、サーバーの実在証明によるなりすまし防止です。これにより、ユーザーは安全な通信経路を確保し、ウェブサイトやアプリケーションが正規のものであることを確認できます。ACMは、これらの証明書のライフサイクル全体をマネージドサービスとして提供するため、運用負荷を大幅に軽減できるのが大きな利点です。

パブリック証明書とプライベート証明書の違いと選択基準

パブリック証明書は、インターネットに公開されるWebサイトやアプリケーション向けに設計されています。これは、Webブラウザが標準で信頼する外部の認証局（CA）によって発行・検証されるため、ユーザーが追加の設定なしにサイトの正当性を確認できます。ACMと統合されたAWSサービス（ELBやCloudFrontなど）で使用する場合、この証明書の発行と更新は費用がかかりません。一方、プライベート証明書は、社内システム、IoTデバイス間の通信、開発環境など、特定の閉域環境内で使用することを目的としています。これらは組織独自の認証局（CA）をAWS Private CAサービスで構築し、そのCAから発行されます。プライベート証明書は外部のCAによる信頼は得られませんが、特定の内部環境でのみ信頼される証明書を柔軟に管理できる点が特徴です。どちらを選択するかは、システムがインターネットに公開されるか、閉じた環境でのみ使用されるかによって決まります。

費用面から考えるパブリックとプライベート証明書の選択肢

AWS ACMのパブリック証明書は、ELBやCloudFrontといったACM統合サービスで使用する限り、発行・更新費用が無料です。これは、公開サイトのセキュリティ維持コストを大幅に削減できる大きなメリットです。しかし、この証明書をエクスポートしてAWS外の環境で使用する場合、1FQDNあたり月額7ドルの料金が発生します（2026年6月時点）。対照的に、プライベート証明書は、AWS Private CAの構築と運用が必要となるため、コスト構造が大きく異なります。Private CAは、汎用モードで月額400ドル、短期間モードで月額50ドルのCA運用費がかかるほか、発行される証明書の数に応じた従量課金が発生します（2026年6月時点）。このため、コストを抑えたい場合はパブリック証明書を検討し、社内システムなどでセキュリティ要件とコストのバランスを考慮してプライベート証明書を導入するかを判断することが重要です。

パブリック証明書の具体的な発行手順と設定方法

ACMでのパブリック証明書リクエストの基本ステップ

AWS ACMでパブリック証明書をリクエストする手順は非常にシンプルです。まず、AWSマネジメントコンソールにログインし、ACMサービスへ移動します。「証明書をリクエスト」を選択し、「パブリック証明書をリクエスト」を選択します。次に、証明書を適用したいドメイン名（例: example.com や *.example.com）を入力します。サブドメインも保護したい場合はワイルドカード（*.example.com）を含めることができます。検証方法として、DNS検証またはEメール検証のいずれかを選択します。DNS検証は自動化が容易で推奨されており、Route 53を使用している場合はACMが自動的にDNSレコードを追加することも可能です。Eメール検証の場合、ドメインのWHOIS情報に記載されたアドレスまたは一般的な管理用アドレス（admin@、hostmaster@など）に確認メールが送信されます。これらの設定が完了したら、リクエストを送信し、検証プロセスが完了するのを待つだけです。

DNS検証を用いた証明書の発行とデプロイ

DNS検証は、ドメイン所有権の確認を自動化できるため、ACMでのパブリック証明書発行において最も推奨される方法です。リクエストを送信すると、ACMはCNameレコードの生成を指示します。このCNameレコードを、ご自身のドメインを管理しているDNSサービス（Route 53やその他のDNSプロバイダ）に登録します。Route 53を使用している場合、「Route 53でレコードを作成」ボタンをクリックするだけで、ACMが自動的に必要なレコードを追加してくれるため非常に便利です。DNSレコードがインターネット上に伝播し、ACMがその存在を確認できると、証明書は「発行済み」ステータスに変わります。発行された証明書は、AWS Elastic Load Balancing (ELB) や Amazon CloudFront などのACM統合サービスに直接デプロイ可能です。ELBの場合、リスナー設定でACM証明書を選択するだけでSSL/TLS終端を設定できます。これにより、ウェブサイトはHTTPS通信で保護され、ユーザーに安全なアクセスを提供できます。

証明書をAWSサービスに連携し安全な通信を確立する

ACMで発行されたパブリック証明書は、AWSの様々なサービスとシームレスに連携し、ウェブトラフィックの安全性を確保します。主要な連携先としては、Application Load Balancer (ALB)、Network Load Balancer (NLB)、Classic Load Balancer (CLB) といったELBシリーズ、そしてコンテンツ配信ネットワークであるAmazon CloudFrontが挙げられます。これらのサービスに証明書をデプロイすることで、エンドユーザーからのリクエストはHTTPSで暗号化され、セキュアな通信経路が確立されます。例えば、ALBに証明書を適用する場合、HTTPSリスナーを作成し、ACMで発行した証明書を選択するだけで設定は完了します。これにより、クライアントとALB間の通信が暗号化され、さらにALBからバックエンドのEC2インスタンスやECSコンテナへの通信も、必要に応じてHTTPSで保護することができます。ACMが証明書の自動更新を管理するため、手動で期限切れを心配する必要がなく、運用負担を軽減しながら高いセキュリティレベルを維持できます。

出典：Amazon Web Services

利用シーンで使い分け：パブリック・プライベート証明書活用例

インターネット公開Webサイトでのパブリック証明書の利用

インターネットに公開される企業ウェブサイト、ECサイト、ブログなどのほとんどのケースでは、AWS ACMのパブリック証明書が最適な選択肢です。これらのサイトは、世界中のユーザーからのアクセスを想定しており、主要なWebブラウザ（Chrome, Firefox, Edgeなど）によって信頼されている必要があります。ACMのパブリック証明書は、これらのブラウザが信頼する公的な認証局から発行されるため、ユーザーはセキュリティ警告なしにサイトにアクセスできます。特に、ACM統合サービス（ELBやCloudFront）を使用する場合、証明書の発行・更新費用は無料となるため、コスト効率も非常に優れています。例えば、ELBの背後にあるWebアプリケーションにパブリック証明書を適用すれば、クライアントからの通信を暗号化し、個人情報や決済情報などの機密データを保護できます。これにより、顧客の信頼を得て、ビジネスの安全性を高めることが可能です。

閉域ネットワークや内部システムでのプライベート証明書活用例

プライベート証明書は、インターネットに公開されない閉域ネットワーク内のシステムやデバイス間の通信セキュリティを確保する際に真価を発揮します。具体的な活用例としては、社内Webアプリケーション、VPN接続、IoTデバイス間の認証、マイクロサービス間のAPI通信などが挙げられます。これらの環境では、外部のCAによる信頼は不要であり、むしろ組織独自のセキュリティポリシーに基づいて証明書を発行・管理したいというニーズがあります。AWS Private CAを利用することで、組織は独自の認証局（CA）を構築し、そこからプライベート証明書を発行・配布できます。例えば、社内システムにアクセスするVPNクライアントにプライベート証明書を配布することで、正規のユーザーのみがアクセスできる厳格な認証メカニズムを確立できます。これにより、内部ネットワークのセキュリティを強化し、不正アクセスやデータ漏洩のリスクを低減することが可能になります。

ハイブリッド環境における証明書運用の考え方

オンプレミスとAWSクラウドを組み合わせたハイブリッド環境では、パブリック証明書とプライベート証明書の両方を適切に使い分けることが重要です。インターネットに公開されるAWS上のリソース（例: AWS WAFと連携したCloudFront）にはパブリック証明書を利用し、セキュアな外部アクセスを提供します。一方、オンプレミス環境とAWS間のVPN接続やDirect Connect経由でアクセスされる内部システム、あるいはAWS上のプライベートサブネットに配置されたマイクロサービス間通信には、プライベート証明書を適用することが考えられます。AWS Private CAで発行した証明書は、AWS内のリソースだけでなく、オンプレミスサーバーやデバイスにも配布して利用することが可能です。これにより、組織は単一のCAで証明書を一元管理し、ハイブリッド環境全体で一貫したセキュリティポリシーを適用できるようになります。ただし、プライベートCAの運用にはコストと管理の専門知識が必要になるため、導入前に十分に計画を立てることが肝要です。

AWS ACM利用で知るべき注意点：料金やエクスポート不可の制約

ACMパブリック証明書のエクスポート制約と代替案

AWS ACMで発行されるパブリック証明書は、基本的にAWS統合サービス（ELB, CloudFrontなど）での利用を前提としており、セキュリティ上の理由から秘密鍵をエクスポートすることはできません。これは、秘密鍵がAWS環境外に持ち出されることによるリスクを最小限に抑えるための重要な制約です。したがって、オンプレミスのWebサーバーやAWS外のクラウドサービスでSSL/TLS終端を行いたい場合、ACMの無料パブリック証明書を直接利用することはできません。このような場合、代替案としては、ACMではなく別のパブリック認証局から証明書を購入し、その証明書と秘密鍵を目的の環境にインストールする必要があります。または、AWS上にELBなどを配置し、そこでSSL/TLS終端を行ってから、バックエンドのオンプレミスサーバーへは内部通信で転送するといった構成も検討できます。エクスポートが必要な場合は、ACMの有料オプションとして1FQDNあたり月額7ドルでエクスポート可能な証明書も提供されていますが、基本的にはACMのマネージド運用メリットを最大限に活かすことが推奨されます（2026年6月時点）。

AWS Private CAのコスト管理と運用の落とし穴

AWS Private CAは、社内システム向けの証明書発行・管理に非常に有用ですが、そのコスト構造を正しく理解しておくことが不可欠です。Private CAは、作成した時点からCA自体に月額料金が発生します。汎用モードでは月額400ドル、短期間モードでは月額50ドルが1CAあたりに課金されます（2026年6月時点）。これに加えて、発行する証明書の数に応じた従量課金も発生します。特に注意すべきは、テスト目的でPrivate CAを安易に作成・削除を繰り返すと、意図しない課金が積み重なる可能性がある点です。不要になったCAは、料金発生を停止するために速やかに削除する必要がありますが、削除後30日以内であれば復元が可能です。ただし、復元時の取り扱いには注意が必要です。また、各リージョンで最初のCAに適用される無料トライアルの条件を正確に把握し、無駄な課金を避けるための運用計画を立てることが重要です。

システム全体のセキュリティ責任とセキュア・バイ・デザインの重要性

SSL/TLS証明書を導入したからといって、システム全体のセキュリティが完全に保証されるわけではありません。証明書は通信の暗号化と実在証明を提供しますが、アプリケーションの脆弱性、不適切なアクセス制御、OSのパッチ適用漏れなど、他の多くのセキュリティリスクは別途対策が必要です。経済産業省の「サイバーインフラ事業者に求められる役割等に関するガイドライン」にもある通り、システム開発の初期段階からセキュリティを考慮する「セキュア・バイ・デザイン」の考え方に基づき、システム全体の脆弱性対策やアクセス制御を適切に行うことが求められます。組織全体でセキュリティ統治を行い、多層防御の観点から包括的なセキュリティ対策を実施することが不可欠です。例えば、AWS WAFやSecurity Hubなどのサービスと連携し、脅威の監視と対応を継続的に行うことで、より強固なセキュリティ態勢を築くことができます。

出典：Amazon Web Services、経済産業省

【ケース】内部向けシステムでパブリック証明書を誤用した事例

架空のケース：内部向けツールにパブリック証明書を適用した経緯

これは架空のケースですが、ある企業Aでは、社内向けの業務管理ツールをAWS上に構築していました。当初、このツールは社内ネットワークからのみアクセスを想定しており、HTTPでの運用を計画していましたが、セキュリティ部門から「HTTPS化は必須」との指示が出ました。開発チームは、手軽さとコストの観点から、AWS ACMで無料のパブリック証明書をリクエストし、ELB経由で社内ツールに適用しました。インターネットに公開されているわけではないものの、Webブラウザからのアクセス時に「安全な接続」と表示されることを優先したためです。この選択は、社内システムに対するセキュリティ意識の高さを示す一方で、パブリック証明書とプライベート証明書の使い分けに関する理解不足が潜在的なリスクとして存在していました。この時点では、特に問題なくツールは稼働し、社内ユーザーもHTTPSでアクセスできることに満足していました。

誤用が招いた潜在的リスクとセキュリティ上の課題

社内ツールにパブリック証明書を適用したこと自体は、通信の暗号化という点では問題ありません。しかし、このケースでは、パブリック証明書を内部向けシステムに適用したことで、本来不要な外部依存が生じ、将来的な運用リスクを抱えることになりました。パブリック証明書は、世界中のWebブラウザに信頼される一方で、その発行プロセスにはドメインのインターネット上での存在確認が必須です。もし社内ツールのドメインが何らかの理由で外部からアクセス可能な状態になった場合、そのドメインに対して第三者がパブリック証明書をリクエストし、悪用する可能性がゼロではありませんでした。また、本来プライベートCAで統制すべき内部システムの証明書が外部のCAに依存することで、将来的な証明書ポリシーの変更や内部統制の観点から、柔軟性に欠けるという課題も浮上しました。このような構成は、システムの内部設計と外部公開ポリシーが混在する「あいまいな状態」を生み出します。

適切な証明書選択への改善とセキュリティ強化のステップ

この架空のケースにおいて、企業Aはその後、システム全体のセキュリティレビューを実施し、内部向けツールへの証明書適用方法を見直しました。結論として、社内ツールはインターネット公開を意図しないシステムであるため、AWS Private CAを構築し、そこから発行されるプライベート証明書を使用する方針へと転換しました。この変更により、ドメインが外部に公開されていなくとも、社内CAの信頼に基づいた証明書をセキュアに発行・管理できるようになりました。さらに、これにより組織独自のセキュリティポリシーを証明書運用に反映させることが可能になり、内部統制の強化にもつながりました。この経験から、開発チームとセキュリティ部門は、システムがインターネット公開されるか否かを明確に判断基準とし、それに応じてパブリック証明書とプライベート証明書を適切に使い分けることの重要性を再認識しました。

出典：Amazon Web Services、総務省