AWS Certificate Managerとは？有効期間198日化とACME対応・料金と採用判断を実装者目線で解説

AWS Certificate Manager（ACM）は、AWSが管理するパブリックCAからSSL/TLS証明書を発行し、ELBやCloudFrontへの紐付けと更新まで引き受けるマネージドサービスです。2026年2月18日を境に、パブリック証明書の有効期間は395日から198日へ短縮され、更新の起点も満了45日前へ前倒しされました。2026年7月にはACMEプロトコル対応が加わり、オンプレミスやKubernetes上のサーバーでもCertbotやcert-managerから証明書を取得できます。発行と検証の仕組み、自動更新が働く条件、無料になる範囲とエクスポート時の課金、ACMを選ばない場面までを判断材料として整理します。

まとめ：ACMで無料になる範囲と198日運用への切り替え判断

ELB・CloudFront・API Gatewayなど統合サービスでTLSを終端する構成なら、ACMのパブリック証明書は発行も更新も無料です。DNS検証を選べば更新は人の手を離れます。証明書の購入費と更新作業をここに残す理由はありません。

証明書を自社サーバーへ配る場合は2択になります。ACME経由なら45日の証明書をCertbotやcert-managerが自動更新し、FQDN 1件1.00USDから。エクスポート方式は1件7.00USDで、統合サービスとの併用ができます。配布先が10台を超えるならACMEが妥当な線引きです。

有効期間の短縮は一度で終わりません。CA/Browser Forumのスケジュールでは2027年3月に100日、2029年3月に47日まで縮みます。手作業で証明書を差し替えている工程は、2026年のうちにDNS検証かACMEへ寄せる判断が要ります。

ACMが担うのは発行と検証と更新・DV証明書に限られる提供範囲

ACMを「無料のSSL証明書サービス」と要約すると判断を誤ります。担う範囲と担わない範囲を先に確定させます。

ACMの3つの役割とAmazon Trust Services由来の証明書階層

ACMが引き受ける仕事は、証明書の発行、ドメイン所有権の検証、更新とデプロイの3つです。発行元はAmazonが運営するパブリックCA（Amazon Trust Services）で、Amazon Root CA 1〜4はStarfield Services Root Certificate Authority – G2でクロス署名され、Androidの旧版やiOS 4.1以降でも信頼されます。

押さえておきたい仕様がひとつ。ACMは中間CAの情報を公開しません。証明書種別に応じて中間CAがランダムに割り当てられ、Amazonは予告なく中間CAを廃止することがあるためです。証明書ピンニングを前提にした設計は成立しません。プロトコル側はTLSのハンドシェイクとバージョン選定を押さえておくと、ACMがどこを代行しているか掴めます。

新規発行できる鍵アルゴリズムはRSA 2048とECDSAの2種

ACMが新規に発行できる鍵の種類は限られています。

• RSA 2048ビット（RSA_2048）
• ECDSA 256ビット（EC_prime256v1）
• ECDSA 384ビット（EC_secp384r1）
• RSA 1024・3072・4096とECDSA 521は、インポートした証明書でのみ扱える

NISTの対応表では3072ビットRSAと256ビットECDSAが同強度（2の128乗）にあたります。鍵が小さいECDSAが有利に見えますが、対応しないクライアントも残ります。公開サイトはRSA 2048、内部APIや管理下のクライアントのみならECDSA 256という切り分けが実務的です。

DNS検証とEmail検証とHTTP検証の違いと運用で選ぶ基準

検証方式の選択が、そのまま後の運用工数を決めます。自動更新が働くかどうかがここで分岐します。

DNS検証のCNAMEレコードが自動更新の前提になる仕組みと注意点

DNS検証では、ACMが一意のキーと値の組を含むCNAMEレコードを提示し、それをDNSへ登録して所有権を示します。手順は4段階です。

1. RequestCertificateでドメイン名を指定して証明書を要求する
2. ACMが返すCNAMEレコードをDNSゾーンへ登録する
3. ACMが公開DNSからレコードを参照し、所有権を確認して証明書を発行する
4. レコードを残したまま運用し、更新時の再検証をACMに任せる

4番目を落とす事故がいちばん多い。検証が済んだからとCNAMEを消すと、更新時の再検証に失敗します。Route 53ならコンソールから1クリックで作れますが、DNSが外部事業者にある構成では、レコードを棚卸し対象として管理台帳へ載せる必要があります。

Email検証で自動更新が止まる条件とCloudFormationの停止

Email検証を選ぶと、ACMは自動更新を行わず、満了が近づいた時点で通知メールを送るだけになります。WHOISの連絡先やadmin宛で受け取り、リンクを開いて承認する作業が更新ごとに発生します。198日ごとに人の承認が要る、と読み替えてください。

CloudFormationとの組み合わせではさらに厄介です。テンプレートでACM証明書を作成すると、検証メールの承認が済むまでスタックがCREATE_IN_PROGRESSのまま止まります。IaCで証明書を扱うなら検証方式はDNS一択です。なおCloudFront向けにはリダイレクトを使うHTTP検証も選べますが、Distribution Tenants経由に限られ、ワイルドカードには対応しません。

有効期間198日化で変わる更新の起点と自動更新の適格条件の見分け方

2026年2月18日のアナウンスで、ACMの運用前提が変わりました。数字を押さえます。

395日から198日への短縮と更新45日前という新しい起点の整理

従来のACM証明書は395日有効で、満了60日前に更新が始まる設計でした。198日化後は満了45日前が起点になります。既存の証明書は即座に切り替わらず、満了までは395日のまま使えます。

年に1回だった更新が年2回弱に増えます。自動更新に乗っていれば回数は影響しません。効いてくるのは、監視の閾値や棚卸しサイクルを1年ごとで組んでいた場合です。満了45日前を検知の起点として設計を見直してください。

自動更新の適格と不適格を分ける使用状況とエクスポート履歴の確認

ACMのマネージド更新は、すべての証明書に無条件で働くわけではありません。公式ドキュメントは適格性（eligibility）を明示しています。

• 適格：ELBやCloudFrontなど他のAWSサービスに関連付けている
• 適格：発行または前回更新以降に一度エクスポートしている
• 不適格：ACMへインポートした証明書
• 不適格：AWS Private CAのIssueCertificateで発行したプライベート証明書
• 不適格：すでに満了している証明書
• 対象外：ACMEで発行した証明書（更新はクライアント側）

どのサービスにも紐付いておらずエクスポートもしていない証明書は、DNS検証であっても自動更新されません。発行だけして寝かせてある証明書が静かに満了する落とし穴がここです。使う予定のない証明書は削除し、1リージョン2,500本のクォータを空けておきます。

統合サービスへの紐付けとCloudFrontのバージニア北部制約

ACMの価値は統合サービスへの自動デプロイに集約されます。射程を確認します。

ELBとAPI GatewayとCloudFrontで紐付けが完結する範囲

ACM証明書を直接指定できるサービスは次の通りです。

• Elastic Load Balancing（HTTPSリスナー）
• Amazon CloudFront（ディストリビューション）
• Amazon API Gateway（カスタムドメイン名）
• AWS App Runner・Elastic Beanstalk・Amplify（内部で証明書を生成）
• Amazon Cognito（CloudFrontプロキシ経由のカスタムドメイン）
• AWS Network Firewall（TLS検査での復号と再暗号化）
• Amazon EKS（AWS Controllers for Kubernetes経由でSecretへ反映）

実務でいちばん使うのはELBのHTTPSリスナーです。リスナールールと証明書の対応関係はALBとELBの違いとロードバランサーの使い分けで整理した構成に沿うと迷いません。App Runnerには癖があり、関連付けを解除してもサービス削除から7日間は内部生成した証明書が残ります。

CloudFrontはバージニア北部発行という制約と回避できない事情

CloudFrontで使う証明書は、us-east-1（バージニア北部）で要求またはインポートしなければなりません。東京リージョン（ap-northeast-1）で作った証明書はCloudFrontの候補に出てきません。

CloudFrontがグローバルサービスとして設定の実体をus-east-1に置いているためで、回避策はありません。ALBは東京、CloudFrontはバージニア北部と、同じドメインの証明書を2本持つ構成が普通に発生します。証明書はリージョンリソースなので、この2本はそれぞれ独立に更新されます。片方だけ検証用CNAMEを消す事故が起きやすい箇所です。

EC2に直接紐付けるにはNitro Enclavesが必要という設計制約

EC2上のnginxやApacheでTLSを終端する場合、ACM管理証明書をそのまま置くことはできません。直接関連付けるにはAWS Nitro Enclavesが必要で、秘密鍵をエンクレーブ内に隔離する構成が前提です。ハードルが高いため、AWSはEC2上のパブリック証明書にACMEを推奨しています。

ACME対応で自社管理サーバーの証明書自動化が変わる運用手順

2026年7月に追加されたACME対応は、ACMの適用範囲を自社管理インフラへ広げました。仕組みと制約を押さえます。

ACMEエンドポイントとEABで権限を分ける管理者と利用者の分業

ACMが提供するのはRFC 8555準拠のマネージドACMEサーバです。Let’s Encryptと違い、クライアントが毎回所有権を証明するのではなく、PKI管理者が事前に承認したドメインの範囲でしか発行できません。設定は5段階です。

1. PKI管理者がACMEエンドポイントを作成する
2. 管理者がドメイン検証を作成し、指示されたCNAMEレコードをDNSへ登録する
3. 管理者が外部アカウントバインディング（EAB）の資格情報を生成する
4. EAB資格情報をアプリケーション担当者へ渡す
5. 担当者がACMEクライアントにEABを設定し、証明書要求を行う

この分業の意味は、DNSの資格情報をアプリチームへ配らずに発行を委譲できることです。ワイルドカードの可否も管理者側のポリシーで縛れます。発行はCloudTrailに記録され、成否はCloudWatchメトリクスで追えます。EAB資格情報の保管先はAWS Secrets Managerのローテーション設計と揃えておくとよいでしょう。

ACME証明書45日の有効期間と統合サービスに紐付けられない制約

ACMEで発行される証明書の有効期間は45日です。通常のパブリック証明書（198日）より短いのは、CertbotやKubernetes向けcert-managerといったACMEv2互換クライアントが自動更新する前提があるからで、2029年初頭までに最大47日が義務化されるスケジュールに合わせた値でもあります。

制約は明確です。ACME発行証明書はCertificateKeyPairOriginがACMEとなり、ELB・CloudFront・API Gatewayへは紐付けられません。秘密鍵はクライアントが生成・保持し、ACMは触れません。ExportCertificateとRenewCertificateも非対応で、失効はACMEエンドポイントのrevoke-cert URLから行います。証明書数クォータ2,500本には計上されず、ACMEエンドポイントが1アカウント50個、1証明書のドメイン名が100個固定という別の上限がかかります。

エクスポート可能な証明書とPrivate CAで発生する費用の境界

ACMの料金は4系統に分かれます。課金がどこから始まるかを整理します。

統合サービス向けは無料でエクスポートは7ドルという価格差の整理

統合サービスへ紐付けるだけのパブリック証明書は、発行も更新も無料です。課金が始まるのは、証明書を外へ持ち出す構成に切り替えたときです。

エクスポート可能証明書は、198日化のタイミングでFQDNが15.00USDから7.00USD、ワイルドカードが149.00USDから79.00USDへ下がりました。更新回数が増えるぶんを織り込んだ改定です。それでもACMEの1.00USDとは7倍差があり、数十枚以上を配るならACMEが優位に立ちます。

発行後に変更できないエクスポート設定と再エクスポートの手当て

エクスポートの可否はRequestCertificateの時点で決まり、発行後は変更できません。Disable exportを選んだ証明書を後から切り替える手段はありません。2025年6月17日より前に作成した証明書も対象外です。持ち出す可能性が少しでもあるなら、発行時にEnable exportを選ぶ判断になります。

取り出しはExportCertificateで行い、秘密鍵にはパスフレーズが必須です（#、$、%以外のASCII文字）。出力はPEM形式で、証明書・チェーン・暗号化秘密鍵が返ります。更新は自動ですが、再エクスポートは自動化されません。EventBridgeで更新イベントを拾い、Lambdaで配布まで通す仕組みをあわせて見積もってください。取り出した秘密鍵は自社の管理下に移るため、権限設計はAWS KMSのキーポリシー設計の考え方を持ち込むと穴が減ります。

Private CAの月額400ドルと短期証明書モード50ドルの使い分け

内部通信向けのプライベート証明書はAWS Private CAの領域で、こちらは固定費が発生します。

• 汎用モードのCAは月額400USD、任意の有効期限の証明書を発行できる
• 短期証明書モードのCAは月額50USD、有効期限は最大7日に限られる
• 発行の従量課金は汎用モードが1枚0.75USDから0.001USDの3段階、短期証明書モードは1枚0.058USD

月400USDは小規模な内部PKIには重い金額です。サービスメッシュのように短命な証明書を大量に回すなら、短期証明書モードの50USDと1枚0.058USDで収まります。Kubernetes・Active Directory・SCEPのコネクタは追加料金なしのため、既存の配布経路がある環境ではコネクタ側から入るのが楽です。相互認証まで踏み込む設計はmTLSとクライアント証明書の導入判断と直結します。

ACMを選ばない場面と47日化に備える移行設計の判断基準の整理

ここは判断を言い切ります。ACMは万能ではなく、外す条件が明確にあります。

ACMを採用しない3つの場面とEV証明書が必要な案件の切り分け

次の3つに当たる案件では、ACMを主役に据えるべきではありません。

• EV証明書やOV証明書が要件に含まれる案件。ACMはDV（ドメイン検証）のみで、組織情報を証明する手段を持たない
• 中間CAの固定や証明書ピンニングを求められる環境。Amazonは予告なく中間CAを差し替えるため設計が破綻する
• ワイルドカード証明書を大量にエクスポートして配布する構成。1件79.00USDが積み上がり、ACMEの5.00USDと合わない

1つ目は交渉の余地がありません。OV以上を指定されたら、商用CAから調達してACMへインポートする形に切り替えます。ただしインポート証明書は自動更新の対象外で、満了管理を自前で持つ覚悟が要ります。3つ目は判断が分かれますが、配布先が10台を超えるならACMEへ寄せるのが妥当です。

47日化のスケジュールから逆算する証明書自動化への移行判断の順序

CA/Browser ForumのBallot SC-081v3は、2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日という短縮を定めています。ACMの198日はこの200日枠に合わせた値で、ここから着手の順序は逆算できます。

1. 保有証明書を棚卸しし、検証方式と紐付け先を一覧化する
2. Email検証の証明書をDNS検証へ切り替え、CNAMEを恒久的な管理対象に載せる
3. 統合サービスに載せられる終端点は、EC2からELBやCloudFrontへ寄せる
4. 自社管理サーバーに残る終端点はACMEエンドポイントとクライアントへ移す
5. それでも手作業が残る箇所だけ、EventBridgeとLambdaで再配布を自動化する

2027年に100日へ縮むと年3回以上の更新になります。人が介在する工程を残したまま迎えれば、更新漏れの確率は回数分だけ上がります。2029年の47日は年8回で、手作業の余地はありません。移行の締め切りは2029年ではなく2027年3月と置くのが実務的です。

証明書設定の点検を外部委託する判断と脆弱性診断で見るべき観点

証明書の設定不備は、ACMが自動化してくれる範囲の外側に残ります。有効期間と更新はACMが見ますが、TLSバージョンや暗号スイートの選択、リダイレクトの抜け、混在コンテンツ、チェーンの不整合は設定側の問題です。ALBのセキュリティポリシーが古いままなら、証明書が新しくても評価は下がります。

自社に検証環境と手順がない場合、外部の脆弱性診断・セキュリティ診断で棚卸しするほうが早く確実です。委託する際は、満了日だけでなくTLSバージョンと暗号スイート、HSTS、同一ドメイン証明書の複数リージョン整合、検証用CNAMEの残存を診断対象に含めるよう明示してください。更新頻度が上がるほど、点検の周期も短く設計します。

よくある質問

ACMの導入検討でよく挙がる質問に、公式ドキュメントと料金表の記述をもとに答えます。

ACMのパブリック証明書は本当に無料ですか？

統合サービス（ELB・CloudFront・API Gatewayなど）に紐付けて使う証明書は、発行も更新も無料です。課金は証明書を持ち出す構成に切り替えたときに始まります。エクスポート可能な証明書はFQDN 1件7.00USD、ワイルドカード1件79.00USD。ACME経由はFQDNが最初の1,000件まで1件1.00USDです。

ACMの証明書をオンプレミスのサーバーで使えますか？

2026年7月時点で使える方法は2つです。1つはACMEエンドポイントを作り、CertbotなどのクライアントからEAB資格情報で取得する方式で、45日の証明書が自動更新されます。もう1つは発行時にエクスポートを許可した証明書をExportCertificateで取り出す方式で、こちらは再配布の自動化を別途組む必要があります。

有効期間が198日に短くなると更新作業は増えますか？

DNS検証で統合サービスに紐付けている証明書なら、作業は増えません。更新の起点が満了45日前へ前倒しされるだけで、ACMが同一ARNで発行しデプロイまで済ませます。増えるのはEmail検証の承認対応と、エクスポートして自社配布している証明書の再配布で、いずれも年2回弱の頻度になります。

ACMでEV証明書やOV証明書は発行できますか？

できません。ACMが発行するのはドメイン検証（DV）証明書のみで、組織の実在性は示せません。OV証明書やEV証明書が要件なら、商用CAから調達してACMへインポートする形になります。ただしインポート証明書はマネージド更新の対象外です。ACMは満了通知を送りますが更新は行わないため、差し替えは自前で管理してください。

CloudFront用の証明書を東京リージョンで作れませんか？

作れません。CloudFrontで使う証明書はus-east-1（バージニア北部）での要求またはインポートが必須で、ap-northeast-1で作った証明書は選択候補に出てきません。ALBとCloudFrontを併用するなら、同一ドメインの証明書を2リージョンに持つ前提で管理してください。

関連記事

• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】：証明書を使う側のプロトコル仕様。
• mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説：Private CAで発行する内部証明書の使いどころ。
• AWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説：構成の逸脱を検出する仕組み。
• IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説：TLS以外の暗号化経路との使い分け。
• クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方：責任共有モデルにおける証明書管理の位置。