公開2026.07.30更新2026.10.29 セキュリティ

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

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

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

Q: ACMで発行した証明書が一覧に表示されないのはなぜですか？

ACMEで発行した証明書は ListCertificates の既定出力に含まれません。 --certificate-key-pair-origins ACME を付けるか、既定でACME分を返す search-certificates を使ってください。コンソールでも同様に、鍵ペアの原点でフィルタを掛ける操作が要ります。もうひとつよくある原因はリージョン違いで、CloudFront用の証明書はus-east-1でしか見えません。

Q: 証明書の満了アラートはどこで設定できますか？

EventBridgeで source を aws.acm 、 detail-type を ACM Certificate Approaching Expiration にしたルールを作ります。届くのは、公開証明書なら満了30日前から日次、プライベートとインポート証明書なら45日前から日次。この起点は PutAccountConfiguration で変えられます。自動更新に人手が要る状況だけを拾いたいときは ACM Certificate Renewal Action Required を選んでください。

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を選ばない場面までを判断材料として整理します。各節には実際に打てるAWS CLIコマンドと、根拠となる公式ドキュメントの該当ページを置きました。

まとめ：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 G2ルートCAでクロス署名されています。Starfieldルートを含むAndroid（Gingerbread以降）とiOS 4.1以降、Amazonルートを含むiOS 11以降で信頼されます。

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

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

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

RSA 2048ビット（RSA_2048）。RequestCertificateの既定値
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という切り分けが実務的です。前提になる公開鍵暗号方式と共通鍵暗号方式の違いを踏まえると、鍵長の比較が数字だけの話でないことが見えます。

証明書の透明性ログへの記録が必須になった仕様変更と影響範囲の確認

以前のACMには、証明書の透明性（CT）ログへの記録をオプトアウトする設定がありました。RequestCertificate APIリファレンスは「Certificate transparency logging opt-out is no longer available」と明記しており、いまはすべてのパブリック証明書がCTログへ記録されます。

影響が出るのは、社外に出したくないホスト名をSANへ入れている構成です。api-internal.example.comのような命名はCTログ検索で誰でも引けます。公開したくない名前はワイルドカード証明書で覆うか、そもそもパブリック証明書を使わずAWS Private CAへ寄せる判断になります。命名規則の見直しは、証明書を発行する前に済ませてください。

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

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

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

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

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

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

AWS CLIでDNS検証の証明書を要求しCNAMEを取り出す手順

コンソールを開かずに済ませるなら、要求と検証レコードの取得は2コマンドで終わります。ValidationMethodに指定できるのはEMAIL・DNS・HTTPの3つで、ここでDNSを選んだかどうかが更新の自動化を決めます。

# DNS検証・エクスポート不可（無料）の証明書を東京リージョンで要求する
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS \
  --key-algorithm RSA_2048 \
  --region ap-northeast-1

# 返ってきたARNから検証用CNAMEのNameとValueだけを取り出す
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:111122223333:certificate/11111111-2222-3333-4444-555555555555 \
  --region ap-northeast-1 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord' \
  --output table

SANはひとつの証明書に最大100件まで入りますが、既定のクォータは10件です。11件目からはService Quotasでの引き上げ申請が要ります。ワイルドカードは1階層しか覆わないため、*.example.comはlogin.example.comを守ってもtest.login.example.comは守りません。裸のドメインも別途SANへ足してください。

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

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

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

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

2026年2月の既定有効期間の変更アナウンスで、ACMの運用前提が変わりました。数字を押さえます。

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

従来のACM証明書は395日有効で、満了60日前に更新が始まる設計でした。DNS検証ドメインの更新に関する公式ページは、198日の証明書が満了45日前に更新条件を判定されること、そして395日で発行済みの証明書は満了60日前に更新され、更新後は198日になることを注記しています。既存の証明書が即座に切り替わるわけではありません。

区分	有効期間	更新の起点
2026年2月18日以降の発行・更新	198日	満了45日前
それ以前に発行した証明書	395日	満了60日前
更新後に発行される証明書	198日	ACMが同一ARNで発行

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

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

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

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

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

満了45日前に更新されない証明書をCLIで洗い出す点検コマンド

適格性はDescribeCertificateのRenewalEligibilityで機械的に読めます。ELIGIBLEかINELIGIBLEのどちらかが返るので、InUseByが空でINELIGIBLEの行だけ拾えば、静かに満了する予備軍が出てきます。

# 保有証明書の更新適格性・満了日・紐付け先を1行ずつ並べる
aws acm list-certificates --region ap-northeast-1 \
  --query 'CertificateSummaryList[].CertificateArn' --output text \
| tr '\t' '\n' \
| while read -r arn; do
    aws acm describe-certificate --certificate-arn "$arn" \
      --region ap-northeast-1 \
      --query 'Certificate.[DomainName,Type,RenewalEligibility,NotAfter,InUseBy]' \
      --output text
  done

証明書はリージョンリソースです。--regionを変えて、少なくともALBを置いたリージョンとus-east-1の両方で回してください。ListCertificatesのレート上限は8リクエスト毎秒、DescribeCertificateは10リクエスト毎秒なので、数百本あるアカウントではスリープを挟みます。

EventBridgeの満了30日前イベントで更新失敗を検知する設計

棚卸しを手で回すより、イベント駆動で拾うほうが確実です。EventBridgeサポートのドキュメントによれば、ACM Certificate Approaching Expirationは公開証明書で満了30日前から日次、プライベートとインポート証明書では45日前から日次で発行されます。この起点はPutAccountConfigurationで変更できます。

# 満了が近い証明書と人手が要る証明書を1本のルールで拾う
{
  "source": ["aws.acm"],
  "detail-type": [
    "ACM Certificate Approaching Expiration",
    "ACM Certificate Renewal Action Required"
  ]
}

後者は自動更新に失敗したときだけ出ます。CAAレコードで発行が拒否された、DNS検証のCNAMEが消えている、といった人手の介入が要る状況です。公開証明書では30日前に失敗した後、15日前・3日前・1日前にも再発報されます。イベント量は証明書本数×日数で効いてくるため、EventBridgeの課金が発生する条件を先に確認しておくと見積もりがぶれません。

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

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

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

統合サービスの一覧にあるとおり、ACM証明書を直接指定できるサービスは次の通りです。

Elastic Load Balancing（HTTPSリスナー）
Amazon CloudFront（ディストリビューション）
Amazon API Gateway（カスタムドメイン名。設定手順は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を消す事故が起きやすい箇所です。オリジン側の締め方はCloudFront OACとS3バケットポリシーの設定と合わせて設計してください。

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

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

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

2026年7月に追加されたACME対応は、ACMの適用範囲を自社管理インフラへ広げました。任意のACMEv2互換クライアントから発行と更新を回せます。仕組みと制約を押さえます。

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

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

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

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

CertbotにEAB資格情報を渡して証明書を取得するコマンド例

ACMEでの証明書発行ドキュメントが示すCertbotの実コマンドは次の形です。エンドポイントのディレクトリURL、EABのキーIDとMACキー、そして発行タイムアウトの3点を渡します。

# EAB資格情報でACMEアカウントを登録し証明書を取得する
certbot certonly \
  --standalone --non-interactive --agree-tos \
  --email [email protected] \
  --server https://acm-acme-enroll.ap-northeast-1.api.aws/ENDPOINT-ID/directory \
  --eab-kid AAABBBCCC111222333 \
  --eab-hmac-key BASE64ENCODEDMACKEY \
  --issuance-timeout 120 \
  --domain www.example.com

# 更新はcronやsystemd timerからの定期実行に任せる
certbot renew --quiet

ここで落ちやすいのが--issuance-timeoutです。ACMのACMEエンドポイントは発行に最大2分かかると公式に書かれており、多くのACMEクライアントの既定値である30〜90秒では足りません。cert-managerなど他のクライアントを使う場合も、同じ観点でタイムアウト設定を見直してください。同一のACMEアカウントから同じドメイン名と鍵アルゴリズムで再発行した場合、ACMは既存のARNを維持します。

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

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

制約は明確です。ACME証明書自動化のドキュメントによれば、ACME発行証明書はCertificateKeyPairOriginがACMEとなり、ELB・CloudFront・API Gatewayへは紐付けられません。秘密鍵はクライアントが生成・保持し、ACMは触れません。ExportCertificate・RevokeCertificate・RenewCertificate・ResendValidationEmailも非対応で、失効はACMEエンドポイントのrevoke-cert URLから行います。満了から1年経った証明書はACMが自動で削除します。

ACME証明書が一覧に出ない既定挙動とクォータ50・1,500の上限

運用開始後に戸惑うのが、ACME発行証明書がListCertificatesの既定出力に現れないことです。原点フィルタを明示して初めて返ります。search-certificatesのほうは既定で含みます。

# ACME発行証明書は既定の一覧に出ないため原点を明示して絞り込む
aws acm list-certificates \
  --certificate-key-pair-origins ACME \
  --region ap-northeast-1

# search-certificatesなら既定で返り、フィルタ文で条件も足せる
aws acm search-certificates \
  --filter-statement '{"Filter":{"AcmCertificateMetadataFilter":{"CertificateKeyPairOrigin":"ACME"}}}' \
  --region ap-northeast-1

クォータも別体系です。ACMのクォータ一覧では、ACMEエンドポイントが1アカウント1リージョンあたり50個、EABがエンドポイントあたり1,000個、ドメイン検証がエンドポイントあたり1,500個と定められています。ACME発行証明書は2,500本の証明書クォータに計上されず、1証明書あたりのドメイン名は100個固定で引き上げられません。プロトコル側ではFinalizeOrderが1リクエスト毎秒に制限されるため、数百台へ一斉に配る設計では発行を時間分散させます。

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

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

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

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

対象	発行・更新1件あたり
統合サービス向け（持ち出し不可）	無料
エクスポート可能・FQDN	7.00USD
エクスポート可能・ワイルドカード	79.00USD
ACME・FQDN 最初の1,000件	1.00USD
ACME・FQDN 次の3,000件	0.50USD
ACME・FQDN 4,000件超	0.25USD
ACME・ワイルドカード 500件まで	5.00USD

エクスポート可能証明書は、198日化のタイミングでFQDNが15.00USDから7.00USD、ワイルドカードが149.00USDから79.00USDへ下がりました。更新回数が増えるぶんを織り込んだ改定です。それでもACMEの1.00USDとは7倍差があり、数十枚以上を配るならACMEが優位に立ちます。ACMEは件数が増えるほど単価が下がる階段になっていて、4,000件を超えると0.25USDです。export-certificateのAPI呼び出しは最初の10,000回が無料で、以降1万回ごとに0.50USDかかります。

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

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

更新は自動ですが、再エクスポートは自動化されません。EventBridgeのACM Certificate Availableイベント（ActionがRENEWAL）を拾い、Lambdaで配布まで通す仕組みをあわせて見積もってください。取り出した秘密鍵は自社の管理下に移るため、権限設計はAWS KMSのキーポリシー設計の考え方を持ち込むと穴が減ります。

AWS CLIで証明書を取り出し秘密鍵を復号するまでのコマンド手順

取り出しはExportCertificateで行い、秘密鍵にはパスフレーズが必須です。export-certificateのCLIリファレンスによれば、長さは4〜128文字、使える文字は#・$・%を除くASCIIです。戻り値はCertificate・CertificateChain・PrivateKeyの3要素で、秘密鍵はPKCS #8のBase64 PEMとして暗号化されています。

# パスフレーズはファイル渡し（#・$・%以外のASCII・4〜128文字）
printf '%s' 'YourStrongPassphrase' > ./pass.txt

aws acm export-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:111122223333:certificate/11111111-2222-3333-4444-555555555555 \
  --passphrase file://./pass.txt \
  --region ap-northeast-1 > export.json

# 暗号化されたPKCS #8秘密鍵を取り出して復号する
python -c "import json;print(json.load(open('export.json'))['PrivateKey'])" > key.enc.pem
openssl rsa -in key.enc.pem -out key.pem

復号したkey.pemを平文のままデプロイ経路へ流さないでください。パスフレーズ付きのまま配り、配布先で復号するか、KMSで再暗号化してから運ぶ設計にします。配布スクリプトのログに秘密鍵が残っていないかも、初回の実装時に必ず確認します。

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

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

汎用モードのCAは月額400USD、任意の有効期限の証明書を発行できる
短期証明書モードのCAは月額50USD、有効期限は最大7日に限られる
汎用モードの発行従量は1〜1,000枚が0.75USD、1,001〜10,000枚が0.35USD、10,001枚以上が0.001USD
短期証明書モードの発行従量は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日枠に合わせた値で、ここから着手の順序は逆算できます。ACMを使わずcertbotとnginxで更新する場合の手順と反映確認はSSL証明書の更新手順：certbotの自動更新と反映されない原因の確認にまとめています。

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

2027年に100日へ縮むと年3回以上の更新になります。人が介在する工程を残したまま迎えれば、更新漏れの確率は回数分だけ上がります。2029年の47日は年8回で、手作業の余地はありません。移行の締め切りは2029年ではなく2027年3月と置くのが実務的です。3番目のEC2からELB・CloudFrontへの寄せ替えは既存構成の組み替えを伴うため、社内に手が足りなければAWSのインフラ構築から設計と移行を請け負う選択肢もあります。

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

証明書の設定不備は、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で、4,000件を超えると0.25USDまで下がります。

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

2026年9月時点で使える方法は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リージョンに持つ前提で管理してください。

ACMで発行した証明書が一覧に表示されないのはなぜですか？

ACMEで発行した証明書はListCertificatesの既定出力に含まれません。--certificate-key-pair-origins ACMEを付けるか、既定でACME分を返すsearch-certificatesを使ってください。コンソールでも同様に、鍵ペアの原点でフィルタを掛ける操作が要ります。もうひとつよくある原因はリージョン違いで、CloudFront用の証明書はus-east-1でしか見えません。

証明書の満了アラートはどこで設定できますか？

EventBridgeでsourceをaws.acm、detail-typeをACM Certificate Approaching Expirationにしたルールを作ります。届くのは、公開証明書なら満了30日前から日次、プライベートとインポート証明書なら45日前から日次。この起点はPutAccountConfigurationで変えられます。自動更新に人手が要る状況だけを拾いたいときはACM Certificate Renewal Action Requiredを選んでください。