社内システムやマイクロサービス間の通信を暗号化しようとしたとき、最初に壁になるのが「プライベート証明書をどう管理するか」という問題だ。オンプレミス時代は自前でCAサーバーを立て、証明書の発行・更新・失効をすべて手作業でこなしてきた。しかしクラウド移行が進むと、その運用コストがじわじわと効いてくる。証明書の有効期限失念による本番障害、CAサーバー自体のパッチ対応、HSMの保守費用――こういった負債を解消するのが、AWSのマネージドプライベートCA「AWS Private Certificate Authority（ACM Private CA）」だ。
この記事では、ACM Private CAの仕組みから、階層CA設計・mTLS実装・証明書ライフサイクル管理・料金試算まで、オンプレのCA運用を知っているインフラエンジニアが移行判断を下せるレベルまで体系的に解説する。
なぜACM Private CAが必要なのか？ — オンプレCAの課題とクラウド移行の文脈
オンプレのプライベートCA運用で現場がよく直面する課題を整理しておく。
・証明書の有効期限管理: スプレッドシートで管理していると、年に1度の更新漏れが本番障害に直結する。
・CAサーバーのハードウェア保守: HSMや専用サーバーの保守契約、OS更新が毎年発生する。
・マイクロサービス化への対応: サービス数が増えると証明書の数も数百・数千単位に膨らみ、手動運用が追いつかなくなる。
・失効（CRL/OCSP）のインフラ維持: 証明書の失効情報を配布するCRLサーバーやOCSPレスポンダーを自前で維持する必要がある。
ACM Private CAはこれらをすべてAWSが管理するマネージドサービスとして提供する。CA秘密鍵はAWS管理のHSMで保護され、CRLはS3に自動配信、証明書のライフサイクル管理はAPI・CLI・Terraformから自動化できる。オンプレCAを「自前で立てる」選択肢と「マネージドに任せる」選択肢を比較したとき、クラウドネイティブな環境では後者の費用対効果が高い場面が多い。
ACM Private CAの基本的な仕組み
1. 公開CAとプライベートCAの違い
一般的なWebサイトのHTTPS化に使うACM（公開証明書）は、Let’s EncryptやAmazonが信頼されたルートCAとして機能し、ブラウザが最初から信頼している。一方、ACM Private CAが発行する証明書は「プライベートCA」が署名するため、そのCAを明示的に信頼させた環境（内部システム・デバイス・サービスメッシュ）でしか有効に機能しない。
言い換えると、インターネット向けの公開WebサイトのSSL化にはACM公開証明書を使い、社内APIサーバー間のmTLS認証や社内Webポータルにはプライベート証明書を使う、という棲み分けになる。詳しくはAWS Certificate Manager（ACM）入門も参照してほしい。
2. 階層CA構造の設計
ACM Private CAでは、現実的な運用に合わせて「CA階層（CA Hierarchy）」を構成できる。典型的な2段階構成は次のとおりだ。
| CA層 | 役割 | 証明書発行頻度 |
|---|---|---|
| ルートCA（Root CA） | 信頼の起点。下位CAへの署名のみ実施 | 極めて少ない（CA証明書更新時のみ） |
| 下位CA（Subordinate CA） | エンドエンティティ証明書（サーバー・クライアント証明書）を日常的に発行 | 多い（サービスごと・デバイスごと） |
ルートCAをAWS内でホストする「完全マネージド構成」と、既存のオンプレルートCAからACM Private CAの下位CAに署名させる「ハイブリッド構成」のどちらも取れる。オンプレのルートCAが組織のポリシー上維持が必要な場合は後者を選ぶ。
3. 証明書の発行フロー
ACM Private CAから証明書を発行する主な方法は3つある。
・ACMとの統合（推奨）: ACM Private CAをACMに関連付けると、ACMコンソール・APIから通常の証明書発行と同じ手順でプライベート証明書を発行できる。ELB・API Gateway・App Runnerへの自動デプロイも可能。
・ACM Private CA API（IssueCertificate）: CSR（Certificate Signing Request）を渡して証明書を返すAPIを直接呼び出す。自前のCI/CDパイプラインや証明書管理ツールとの統合に向く。
・cert-manager（Kubernetes）: EKSやAKS上のKubernetes環境では、cert-managerのIssuerリソースとACM Private CAを組み合わせて、PodへのmTLS証明書配布を自動化できる。
実際の構成と設定手順
1. ルートCAの作成（AWS CLI）
まずルートCAを作成する。CA作成直後はPENDING_CERTIFICATE状態であり、ルートCA証明書を発行してインポートするまで使えない。
# AWS CLI: ルートCA作成 aws acm-pca create-certificate-authority \ --certificate-authority-configuration \ "KeyAlgorithm=RSA_2048,SigningAlgorithm=SHA256WITHRSA,Subject={Country=JP,Organization=ExampleCorp,CommonName=Example Root CA}" \ --certificate-authority-type ROOT \ --revocation-configuration \ "CrlConfiguration={Enabled=true,ExpirationInDays=7,S3BucketName=my-crl-bucket}" \ --region ap-northeast-1 # CSRを取得してルートCA証明書を発行（有効期間10年） aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn $CA_ARN \ --output text > root-ca.csr aws acm-pca issue-certificate \ --certificate-authority-arn $CA_ARN \ --csr fileb://root-ca.csr \ --signing-algorithm SHA256WITHRSA \ --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \ --validity Value=3650,Type=DAYS \ --region ap-northeast-1 # CA証明書をインポートしてアクティブ化 aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn $CA_ARN \ --certificate fileb://root-ca-cert.pem \ --region ap-northeast-1
2. 下位CA（Subordinate CA）の作成
日常的な証明書発行はルートCAに直接させず、下位CAを経由させるのがセキュリティのベストプラクティスだ。ルートCAはアクセス制限状態に置き、下位CAが万一侵害されてもルートを差し替えれば被害を局所化できる。
# 下位CA作成（SUBORDINATE タイプ） aws acm-pca create-certificate-authority \ --certificate-authority-configuration \ "KeyAlgorithm=RSA_2048,SigningAlgorithm=SHA256WITHRSA,Subject={Country=JP,Organization=ExampleCorp,CommonName=Example Issuing CA}" \ --certificate-authority-type SUBORDINATE \ --region ap-northeast-1 # 下位CAのCSRをルートCAで署名（PathLen0テンプレート使用） aws acm-pca issue-certificate \ --certificate-authority-arn $ROOT_CA_ARN \ --csr fileb://subordinate-ca.csr \ --signing-algorithm SHA256WITHRSA \ --template-arn arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1 \ --validity Value=5,Type=YEARS \ --region ap-northeast-1
3. エンドエンティティ証明書の発行
下位CAが有効になったら、サービスごとのTLSサーバー証明書やmTLSクライアント証明書を発行する。ACMと統合していればコンソールから発行できる。API経由の場合は次のようになる。
# CSRを生成（OpenSSL） openssl req -new -newkey rsa:2048 -nodes \ -keyout service-api.key \ -out service-api.csr \ -subj "/C=JP/O=ExampleCorp/CN=api.internal.example.com" # ACM Private CA APIで証明書を発行（有効期間1年） aws acm-pca issue-certificate \ --certificate-authority-arn $SUBORDINATE_CA_ARN \ --csr fileb://service-api.csr \ --signing-algorithm SHA256WITHRSA \ --validity Value=365,Type=DAYS \ --region ap-northeast-1
料金の仕組みとコスト試算
ACM Private CAの料金は2026年8月時点（東京リージョン・ap-northeast-1）で次のとおりだ。
| 項目 | 料金 | 備考 |
|---|---|---|
| CA運用費（一般モード） | $400/月・CA1台あたり | 有効期限13日超の証明書を発行するCA |
| CA運用費（短命証明書モード） | $50/月・CA1台あたり | 有効期限7日以内の証明書のみ発行するCA。mTLS向け |
| エンドエンティティ証明書 | $0.75/枚（月1,000枚まで） | 1,000枚超は$0.001/枚に逓減 |
| ACM管理証明書（ACM経由発行） | 無料 | ELB等へのデプロイはACM無料枠で対応可 |
たとえばルートCA×1・下位CA×2（計3台・一般モード）を運用し、月100枚の証明書を発行するケースでは：$1,200（CA費）+ $75（証明書費）≒ 月$1,275（約19万円） になる。証明書数が少ない環境ではCA固定費の比重が大きくなるため、ROI計算は必須だ。
一方、マイクロサービスが数十あり月1万枚の証明書を発行する場合、オンプレCAのHSM保守・人件費・インフラ費と比べてACM Private CAのほうが割安になるケースも多い。CA台数を絞り（ルートCA1台＋下位CA1台）短命証明書モードを活用すると $50×2台 + $10（証明書費）≒ 月$110（約1.7万円）まで抑えられる。
なお、秘密鍵をより厳格に管理したい場合はAWS CloudHSMと組み合わせる構成になり、CloudHSMクラスターの追加費用（月$1.45/HSMインスタンス×最小2台）も発生する。
主要ユースケースと設計パターン
1. マイクロサービス間のmTLS
「Aサービス→Bサービス」という内部通信をmTLS（相互TLS認証）で暗号化・認証するには、各サービスがクライアント証明書を持つ必要がある。ACM Private CAとcert-managerを組み合わせたEKS構成が典型的だ。
・cert-manager + ACM PCA Issuer: KubernetesのCertificateリソースを定義すると、cert-managerがACM Private CAに証明書をリクエストし、Secretに格納するまで自動化できる。
・有効期限の短命化: mTLS証明書は7日以内の短命証明書にすると、失効リストの管理が不要になり運用負荷が下がる。この場合「短命証明書モード」（$50/月）がコスト面で有利だ。
・サービスメッシュとの連携: IstioのPeerAuthentication + DestinationRuleでmTLSを強制しつつ、CA証明書をACM Private CAから配布することで中央集権的なPKI管理とサービスメッシュを統合できる。サービスメッシュ入門も合わせて参照してほしい。
2. IoTデバイス証明書管理
製造ラインや店舗端末などIoTデバイスに証明書を埋め込む場合、デバイス数が数万台になると証明書の一括発行・更新が課題になる。ACM Private CAはAPI経由で証明書を大量発行でき、AWS IoT Coreと統合してデバイス認証基盤を構築できる。デバイスが漏えいした際の個別失効もCRL経由で実現できる。
3. 社内VPN・内部Webサービスへの証明書配布
社員が接続する社内ポータルや開発環境のWebサービスに、オンプレCAが発行したプライベート証明書を配布していたケースをACM Private CAに移行できる。Application Load BalancerへのACM管理証明書配布はコンソール操作のみで完結する。ブラウザ側にはルートCA証明書をActive DirectoryのグループポリシーやJamf等のMDMで配布すれば、「信頼されていません」の警告が出なくなる。
オンプレCAからの移行設計
既存のオンプレCAを段階的にACM Private CAへ移行する際の判断フローを整理する。
| ステップ | 内容 | 判断ポイント |
|---|---|---|
| 1. 現状棚卸し | 発行済み証明書の数・有効期限・用途を一覧化 | 証明書数×料金でROIを試算 |
| 2. CA構成設計 | 完全移行 or ハイブリッド（既存ルートCAを使用）を選択 | 組織のCA管理ポリシー・監査要件確認 |
| 3. パイロット移行 | 新規サービス・低リスクサービスからACM Private CA化 | CRL/OCSP配布の動作確認 |
| 4. トラストストア配布 | 新しいルートCA証明書をクライアント・デバイスに配布 | MDM/GPO・コンテナイメージ更新計画 |
| 5. 旧CA廃止 | 既存証明書の有効期限到来に合わせて旧CAを段階廃止 | CRLの引き続き提供期間を確保する |
「完全移行」でオンプレルートCAをACM Private CAに置き換える場合、既存の信頼チェーンが切れるため、すべての依拠者（サービス・デバイス・ブラウザ）に新ルートCA証明書を配布するまでの期間を十分確保する必要がある。本番環境での一斉切り替えはリスクが高いため、個別サービスごとにCA移行→テスト→全体展開を繰り返す段階的アプローチを推奨する。
KMSとACM Private CAの関係についてはAWS KMS入門も合わせて確認しておくとよい。CA秘密鍵管理にKMSを使うケース（ACM Private CAデフォルト）とCloudHSMを使うケースの違いを整理しておくと、移行設計の選択肢が明確になる。
【重要】運用設計の落とし穴と対処法
1. CRL配信用S3バケットの公開設定ミス
ACM Private CAのCRLはS3バケットに配置される。CRLを確認するクライアントが読める必要があるが、内部サービスのみが参照する場合はVPCエンドポイント経由でアクセスさせることを検討する。誤ってバケットを全公開にしてもCRL自体に秘密情報は含まれないが、失効した証明書のシリアル番号が外部から参照できる状態になる。
2. 証明書有効期限の一斉切れ
証明書を一括発行すると有効期限も同じ日に揃ってしまい、更新作業が一斉に発生するリスクがある。ACMマネージド証明書は自動更新されるが、API経由発行の証明書は自動更新されない。有効期限を意図的にずらす、またはCI/CDパイプラインで有効期限30日前に自動更新をトリガーする仕組みを組み込む必要がある。
3. CAを削除すると復元不能
ACM Private CAには「削除待機期間（7～30日）」があり、その間は復元できる。しかし削除が確定すると秘密鍵は永久に失われる。CA削除の前に、そのCAが発行した証明書をすべて失効させ、依拠するシステムからCAへの参照を切り離しておく必要がある。本番CAの誤削除防止にはSCPでDeleteCertificateAuthorityアクションを制限するガードを設けることを強く推奨する。
4. 下位CA証明書の有効期限管理の見落とし
下位CA証明書の有効期限が切れると、その下位CAが発行したエンドエンティティ証明書もすべて検証エラーになる。ルートCAより下位CAの有効期限が短いため、CA証明書のCloudWatchアラート（残り90日前通知）は必ず設定する。
本記事のまとめ
ACM Private CAは、オンプレCAの運用負債を解消しつつ、マイクロサービスのmTLSやIoTデバイス証明書管理に対応できるマネージドサービスだ。要点をまとめると次のとおりだ。
・CA階層設計: ルートCA＋下位CAの2段構成が基本。既存オンプレルートCAとのハイブリッドも可能
・mTLS実装: cert-manager・サービスメッシュと組み合わせると証明書配布の自動化が実現できる
・料金: CA1台あたり月$400（一般）または$50（短命証明書モード）。証明書数が少ない環境では固定費が重く、ROI計算が重要
・移行設計: 段階的移行と新ルートCA証明書の配布計画が鍵。一斉切り替えは避ける
・落とし穴: CA誤削除防止・CRL配信設計・下位CA有効期限監視の3点は設計段階で必ず対処する
証明書が切れていた、という本番障害はどのエンジニアも経験したくないもの。ACM Private CAへの移行を検討するなら、まず既存証明書の棚卸しから始め、新規サービス向けのパイロット導入で運用感を掴んでほしい。
PR
AWSではじめるクラウドセキュリティ（松本照吾ほか／日経BP）
ACM Private CAを含むAWSセキュリティサービスの設計思想と実装パターンを体系的に学べる一冊。IAM・KMS・暗号化設計を実務で使いこなしたいエンジニアに最適。
