技術記事 2026/7/30

自前のACME運用（cert-manager／Certbot）を続けるか、AWS Certificate Manager ACMEに寄せるか — 秘密鍵の所在で分ける設計判断

2026年6月30日GAのACM ACME対応。cert-manager/CertbotなどのACMEクライアントとの棲み分け、ELB/CloudFront向け無料証明書との境界線、EAB×IAMロールのガバナンスモデル、料金構造、有効期限45日の運用設計を一次情報に基づき判断する。

#AWS
#Certificate Manager
#ACME
#TLS
#PKI
#セキュリティ

CA/Browser Forumの規定により、AWS Certificate Manager（ACM）発行の公開証明書の最大有効期間は、2026年3月15日以降395日から198日へ短縮されました。この流れは続き、2027年に100日、2029年には47日まで段階的に短くなる予定です。手動更新が現実的でない期間に入りつつある中、2026年6月30日、ACMはACME（Automatic Certificate Management Environment）プロトコルに対応し、cert-manager・Certbot・acme.shなど任意のACMEv2互換クライアントから証明書を自動発行・更新できるようになりました。オンプレサーバーやKubernetesクラスタで自前のACMEクライアントを運用してきたチームには、「このままLet’s Encrypt等の運用を続けるか、AWSのACMEエンドポイントに寄せるか」という選択が新たに生まれたことになります。本記事は、この判断を秘密鍵の所在・AWS統合サービスとの境界線・ガバナンスモデル・料金構造の切り口で整理します。

背景：ACM ACMEとは何か

ACME（RFC 8555で定義されたプロトコル）は、証明書の発行・更新を自動化する仕組みで、Let’s Encryptが普及させたことで広く知られています。ACMは今回、このACMEプロトコルに対応したマネージドACMEサーバーを新たに提供する形になりました。対応するのは「任意のACMEv2互換クライアント」で、cert-manager for Kubernetes・Certbot・acme.shなど、Let’s Encrypt向けに使われてきたクライアントがそのままACMのエンドポイントに向けて動作します。

この機能は2026年6月30日にAWS News Blogで発表され、プレビューではなくGA（一般提供）として「all commercial AWS Regions」で即日利用可能とされています。一方、AWS GovCloud（US）・中国リージョン・AWS European Sovereign Cloudは「at a later date（後日）」としか案内がなく、提供時期は本稿執筆時点で不明です。対応リージョンに含まれるかは、導入前に公式情報での確認が必要です。

本論①：RequestCertificateかACMEか — 秘密鍵の所在で分かれる

ACM ACMEを検討するうえで最初に押さえるべきは、これが従来のRequestCertificate（ACM証明書発行APIの呼び出し）を置き換えるものではなく、用途によって使い分ける別の経路だという点です。公式docsは判断基準を明確に示しています。

ELB・CloudFront・API Gatewayなど、AWSのマネージドサービスに証明書をバインドする用途では、引き続きRequestCertificateを使います。この経路の証明書は無料で、秘密鍵はACMが保持し、更新までACMが自動的に面倒を見ます。

一方、オンプレサーバー・Kubernetesクラスタ・ハイブリッド環境など、秘密鍵を自分の管理下に置く必要があるインフラでは、ACMEを使います。この経路では秘密鍵はACMEクライアント側で生成・保持され、ACMは秘密鍵を一切見ません。「秘密鍵が第三者に渡らないこと」がコンプライアンス上の要件になっている環境で選ばれる経路です。

ここに、最も誤解しやすい落とし穴があります。ACMEで発行した証明書は、ELB・CloudFront・API GatewayといったAWS統合サービスにバインドできません。 「Managed automation with integrated services」の対象はRequestCertificate発行の証明書に限られ、ACME発行証明書はこの自動化の枠外です。「ACMがACME対応した＝Let’s Encryptを置き換えた」という単純化はできず、両者は秘密鍵の所在で明確に住み分けられた別の経路と捉える必要があります。

RequestCertificateとACMEの使い分け判断木。起点『証明書をどこで使うか』から、ELB/CloudFront/API GatewayなどAWS統合サービスならRequestCertificate（無料・秘密鍵はACM管理・自動更新）、オンプレ/Kubernetes/ハイブリッドで秘密鍵を自分で持つ必要があればACM ACME（有料・秘密鍵はクライアント管理）へ分岐する。ACME発行証明書は統合サービスにバインド不可と明示 — 図1: RequestCertificateとACMEの使い分け判断木。秘密鍵の所在が分岐点になる

本論②：ガバナンスモデル — PKI管理者とアプリ所有者の権限分離

標準的なACME運用（Let’s Encrypt等）では、証明書を要求するたびにクライアントがドメイン所有権を証明する必要があります。ACM ACMEは、この手順を組織のガバナンスに合わせて再設計しています。

まず、PKI管理者がACMEエンドポイントを作成し、CNAMEレコードによる検証でドメインを事前に承認します（AuthorizationBehavior: PRE_APPROVED）。この事前承認により、アプリ所有者は証明書を要求するたびにドメイン所有権を証明する必要がなくなります。

アプリ所有者側は、PKI管理者が発行した**External Account Binding（EAB）**の資格情報（キーIDとMACキー）でACMEアカウントを登録するだけで、証明書を要求できます。EABはIAMロールに紐付き、そのロールのacm:RequestCertificate・acm:RevokeCertificate権限やAWS OrganizationsのSCP（サービスコントロールポリシー）が発行・失効のたびに適用されます。ドメインの許可範囲も、完全一致のみ・サブドメイン許可・ワイルドカード許可の3種類を独立して組み合わせられます。

ACM ACMEのガバナンスモデル図。PKI管理者がACMEエンドポイント作成→CNAMEでドメイン事前承認→EAB発行、という流れから、アプリ所有者がEAB資格情報でACMEクライアントを登録→証明書要求、という権限分離のフローを示す。IAMロールとドメインスコープが効くポイントを明示 — 図2: ACM ACMEのガバナンスモデル。PKI管理者とアプリ所有者の権限分離

つまり「誰が証明書を要求できるか」の統制点は、標準ACMEのようなドメイン所有権の証明そのものではなく、PKI管理者が管理するEAB発行とIAMロールの権限設計に移ります。

本論③：料金構造 — 統合サービス向けは無料のまま

料金体系はRequestCertificateとACMEで明確に分かれます。ELB・CloudFront・API Gatewayなど統合サービス向けの証明書は引き続き無料です。一方、ACME発行証明書は有料で、公式Pricingページ記載時点では次の階層課金になっています（単価は変更される可能性があり、導入前に公式情報の確認が必要です）。

項目	単価（記載時点・要時点確認）
FQDN証明書（先頭1,000ドメインまで）	$1.00／ドメイン
FQDN証明書（次の3,000ドメイン）	$0.50／ドメイン
FQDN証明書（4,000ドメイン超）	$0.25／ドメイン
ワイルドカード証明書（先頭500ドメインまで）	$5.00／ドメイン
ワイルドカード証明書（500ドメイン超）	$2.50／ドメイン
APIコール	月3万件まで無料、以降1万件ごとに$0.50

証明書の発行数が多い環境ほど、FQDN単位かワイルドカード単位かでコスト構造が変わります。ワイルドカードは単価が高い代わりに複数のサブドメインをまとめてカバーでき、ドメイン構成に応じた試算が必要です。

落とし穴・誠実な留保

有効期限の数字は3種類あり、混同しやすいので注意が必要です。 ACM標準の公開証明書は2026年3月15日以降、最大有効期間が198日です。ACMEで発行される証明書はさらに短く、最大45日です。加えてCA/Browser Forumの規定では、2027年に100日、2029年には47日まで段階的に短縮される予定であり、ACMEの45日はこの流れを先取りする位置づけです。3つの数字は別の対象・別の時期を指しており、同一視できません。45日は手動更新では現実的に運用できない長さで、自動化が前提になります。

AWS Private CA（社内向けプライベート証明書）とACMEの連携可否は、公式docsで明示的な記載が確認できませんでした。 ACMEエンドポイント作成時のパラメータにはPublicCertificateAuthorityのみが登場し、Amazon Trust Servicesが発行する公的信頼証明書向けと説明されています。内部PKIは引き続きAWS Private CAを別立てで運用する前提と考えられますが、断定はできず、公式情報での時点確認が必要です。

このほか、ドメイン検証のCNAME確認は作成から72時間以内に完了しないとタイムアウトしINVALIDになります。失効確認はOCSP・CRL（*.amazontrust.com宛の通信）で行われ、制限的なファイアウォール環境では追加のアウトバウンド許可が必要になる場合があります。ACMEクライアント側が秘密鍵を保持するため、ACM APIのExportCertificate・RevokeCertificate・RenewCertificateはACME発行証明書には使えません。GovCloud・中国リージョン・European Sovereign Cloudでの提供時期も、現時点では「後日」としか案内がありません。

判断チェックリスト

証明書の用途がELB・CloudFront・API Gatewayで完結する → RequestCertificateのままで変更不要です。
オンプレサーバー・Kubernetesクラスタ・ハイブリッド環境で、秘密鍵を自分の管理下に置く必要がある → ACM ACMEを検討します。
既存のLet’s Encrypt／cert-managerの運用が安定していて、EABによる権限分離やCloudTrail監査といった統制要件が特に無い → 移行の必然性は薄いと考えられます。

判断の起点は「証明書をどこで使うか」と「秘密鍵を誰が持つ必要があるか」の2点で、どちらか一方だけでは決まりません。技術選定を判断フレームに落とす考え方は、アーキテクチャ判断を言語化する記事とも共通します。証明書という鍵ガバナンスの隣接領域には、暗号鍵の設計（KMS）やシークレットの保管先選定もありますが、これらは別記事のテーマです。

まとめ

ACM ACMEは、Let’s Encrypt等の代替品ではなく、秘密鍵を自分で持つ必要があるインフラ向けに新たに増えた経路です。AWS統合サービス向けの無料証明書（RequestCertificate）とは住み分けが明確で、ACME発行証明書はELB・CloudFront・API Gatewayにバインドできません。有効期限は198日・45日・将来の100日/47日という異なる数字が並ぶため混同を避け、料金・Private CA連携・対応リージョンといった未確定要素は、公式情報での時点確認を前提に導入判断を進める必要があります。