AWS Certificate Manager よくある質問

ACM は、パブリック証明書、プライベート証明書、インポートされた証明書を管理します。ACM の機能については、証明書の発行と管理のドキュメントを参照してください。

はい。各証明書には少なくとも 1 つのドメイン名が含まれている必要がありますが、必要な場合はさらにドメイン名を追加できます。例えば、両方のドメイン名でサイトにアクセスできるなら、"www.example.com" の証明書に "www.example.net" というドメイン名を追加できます。証明書リクエストに含まれるドメイン名すべてを所有または制御している必要があります。 

ワイルドカードドメイン名のワイルドカードは、ファーストレベルサブドメインまたはドメインのホスト名に一致します。ファーストレベルサブドメインは単一のドメイン名ラベルで、ピリオド (ドット) は含みません。例えば、*.example.com というドメイン名を使用すると、www.example.com、images.example.com、また .example.com で終わるその他あらゆるホスト名またはファーストレベルサブドメインを保護できます。詳細については、「ACM ユーザーガイド」をご覧ください。

はい。

いいえ。

いいえ。

いいえ。

ACM で発行された証明書は 13 か月間 (395 日間) 有効です。プライベート CA から直接プライベート証明書を発行し、証明書管理に ACM を使わずにキーと証明書を管理した場合は、任意の有効期間を選択できます。これは絶対終了日でも、日、月、年で指定する現時点からの相対時間でも構いません。

ACM で発行されるアルゴリズムは、デフォルトで RSA キーを 2048 ビットモジュールと SHA-256 で使用します。さらに、楕円曲線デジタル署名アルゴリズム (ECDSA) 証明書は、P-256 または P-384 のいずれかをリクエストすることができます。アルゴリズムの詳細については、「ACM ユーザーガイド」をご覧ください。

AWS サポートセンターにアクセスしてサポートケースを作成することで、パブリック証明書の取り消しを ACM にリクエストできます。AWS プライベート CA で発行したプライベート証明書を取り消すには、AWS プライベート CA ユーザーガイドをご覧ください。

いいえ。ACM 証明書は、使用するリソースと同じリージョンにある必要があります。グローバルサービスである Amazon CloudFront は唯一の例外で、米国東部 (バージニア北部) 地域の証明書を必要とします。CloudFront ディストリビューションに関連付けられたこのリージョンでの ACM の証明書は、お客様のディストリビューションに設定されたすべての地理的場所に配信されます。

はい。

プライベート CA で発行されたプライベート証明書は、EC2 インスタンス、コンテナ、ご自身のサーバーでお使いいただけます。現時点では、パブリック証明書は特定の AWS のサービス (AWS Nitro Enclaves など) に限り、お使いいただけます。ACM のサービスの統合をご覧ください。

ACM では、ドメイン名に Unicode でエンコードされた各地の言語の文字を使用することができませんが、ASCII でエンコードされた各地の言語の文字を使用することはできます。

ACM でドメイン名に使用できる文字形式は、UTF-8 でエンコードされた ASCII のみです。一般に Punycode と呼ばれる "xn–" が付くラベルも使用できます。ACM では、ドメイン名に Unicode 入力 (U ラベル) を使用することはできません。

はい。Amazon CloudFront や Elastic Load Balancing、Amazon API Gateway でサードパーティの証明書を使用する必要がある場合は、AWS マネジメントコンソール、AWS CLI、ACM API を使って証明書を ACM にインポートできます。インポートされた証明書の更新プロセスは、ACM で管理されません。AWS マネジメントコンソールを使ってインポートされた証明書の有効期限をモニタリングし、新しいサードパーティーの証明書をインポートして、期限が切れるものと置き換えられます。

パブリック、プライベート両方の証明書は、ネットワークでリソースを特定し、これらのリソース間での通信を安全にするのに役立ちます。パブリック証明書はインターネット上のリソースを特定します。

ACM で提供されるのは、SSL/TLS の終端となるウェブサイトやアプリケーションで使用する、ドメイン検証済み (DV) パブリック証明書です。ACM 証明書の詳細については、「Certificate Characteristics」をご覧ください。

ACM パブリック証明書は、最新のブラウザ、オペレーティングシステム、モバイルデバイスのほとんどで信頼されています。ACM により提供される証明書は、Windows XP SP3 以降、Java 6 以降を含む、99% のブラウザとオペレーティングシステムで利用されています。

ACM 証明書を使用して SSL/TLS 経由で (例えば HTTPS を使用して) サイトに接続した場合、ACM 証明書を信頼するのブラウザの中にはロックアイコンが表示され、証明書の警告は表示されないものがあります。

ACM のパブリック証明書は、Amazon の認証機関 (CA) で検証されます。Amazon Root CA 1、Amazon Root CA 2、Amazon Root CA 3、Amazon Root CA 4、Starfield サービスルート認証機関証明書 - G2 を含むブラウザ、アプリケーション、OS では、ACM 証明書が信頼されます。ルート CA の詳細については、Amazon Trust Services Repository にアクセスしてください。

いいえ。

Amazon Trust Services Certificate Policies と Amazon Trust Services Certification Practices のドキュメントで説明されています。最新バージョンについては、Amazon Trust Services リポジトリをご覧ください。

いいえ。www.example.com と example.com の両方のドメイン名によってサイトが参照されるようにするには、両方のドメイン名が含まれる証明書をリクエストする必要があります。

ACM を使用すると、PCI、FedRAMP、HIPAA といった多くのコンプライアンスプログラムで一般的な要件である安全な接続を促進しやすくなり、企業が規制要件に準拠するのに役立ちます。コンプライアンスに関する具体的な情報については、http://aws.amazon.com/compliance を参照してください。

いいえ。ACM には SLA はありません。

いいえ。サイトシールが必要な場合は、サードパーティベンダーから入手できます。サイトのセキュリティやビジネス慣行またはその両方を評価し、それについて証言してくれるベンダーを選択するようお勧めします。

いいえ。このようなシールやバッジは、ACM サービスを使用していないサイトにコピーされたり、虚偽の信頼を確立するため不当に使用されたりするおそれがあります。Amazon のお客様と評価を保護するため、このような方法でロゴを使用することは禁止されています。

AWS マネジメントコンソール、AWS CLI、ACM API/SDK を使用できます。AWS マネジメントコンソールを使用するには、[Certificate Manager] を開いて [証明書のリクエスト] を選択し、[パブリック証明書のリクエスト] を選択し、サイトのドメイン名を入力してから、画面の指示に沿ってリクエストを実行します。サイトにアクセスする際に使用できる別のドメイン名がある場合は、リクエストにそのドメイン名を追加できます。リクエストされた証明書のドメイン名を所有または管理していることが確認されると、ACM で証明書を発行できます。証明書をリクエストするとき、DNS 検証か、E メール検証を選択できます。DNS 検証では、ドメインのパブリック DNS 設定にレコードを書き込み、そのドメインを所有または管理していることを立証します。DNS 検証を使用してドメインの管理を立証した後、レコードがあって証明書が使用中である限り、さらに証明書を得て ACM で既存の証明書を更新できます。ドメインの管理を再度検証する必要はありません。DNS 検証の代わりに E メール検証を選択する場合は、証明書発行の承認をリクエストするドメイン所有者に E メールが送信されます。リクエストした各ドメインを所有または管理していることが検証された後、証明書が発行され、Elastic Load Balancing や Amazon CloudFront といった他の AWS のサービスでプロビジョニングできるようになります。詳細については、ACM のドキュメントをご覧ください。

証明書は、サイトのアイデンティティ、ブラウザやアプリケーションとサイトとの間の接続を確立するのに使用します。公的に信頼できる証明書を発行するため、Amazon では証明書をリクエストする人が、リクエストしている証明書のドメイン名を管理していることを検証する必要があります。

証明書発行の前に、ACM はリクエストされた証明書のドメイン名が所有または管理されているかを検証します。証明書をリクエストするとき、DNS 検証か、E メール検証を選択できます。DNS 検証では、ドメインの所有権は CNAME レコードを DNS 設定に追加することで検証できます。詳細については、「DNS での検証」をご覧ください。ドメインに対してパブリック DNS 設定にレコードを書き込めない場合は、DNS 検証に代わって E メール検証を使用できます。E メール検証では、ACM は登録されたドメインの所有者に E メールを送り、所有者または権限を受けた代理人が、証明書のリクエスト内にある各ドメインの発行を承認します。詳細については、「E メールでの検証」をご覧ください。

ドメインに対して DNS 設定の変更ができる場合は、DNS 検証をお勧めします。ACM からの検証 E メールを受け取れないお客様と、WHOIS でドメイン所有者のメールアドレスを公開していないドメインレジストラーを使用しているお客様は、DNS 検証を使用してください。DNS 設定を変更できない場合、E メールでの検証を使ってください。

できません。しかし、無料の証明書を新たに ACM からリクエストして、この新しいものに対して DNS での検証を選択できます。

証明書のリクエスト中にあるすべてのドメイン名が検証された後に証明書を発行する時間は、数時間以上になることがあります。

ACM では、リクエストの際に選ばれた DNS または E メール検証方法に従って、証明書のリクエストにある各ドメイン名の所有権や管理していることの検証を試みます。ACM がドメインの所有または管理を検証している間、証明書リクエストのステータスは Pending validation となります。検証プロセスの詳細については、以下の「DNS での検証」と「E メールでの検証」のセクションをご覧ください。証明書のリクエスト内にあるすべてのドメイン名が検証された後、証明書を発行する時間は、数時間以上になることがあります。証明書が発行されると、証明書リクエストのステータスは Issued に変わり、ACM に統合されている他の AWS サービスで使用開始できます。

はい。DNS Certificate Authority Authorization (CAA) レコードによって、ドメイン所有者は、ドメインに証明書を発行する権限を持つ認証機関を特定できます。ACM 証明書をリクエストすると、AWS Certificate Manager によってドメインの DNS ゾーン設定内の CAA レコードが検索されます。CAA レコードが存在しない場合は、Amazon がドメインに証明書を発行できます。ほとんどのお客様はこのカテゴリに属しています。

お客様の DNS 設定に CAA レコードが存在する場合、Amazon でドメインに証明書を発行する前に、そのレコードが amazon.com、amazontrust.com、awstrust.com、または amazonaws.com のいずれかの CA を指定している必要があります。詳細については、「AWS Certificate Manager ユーザーガイド」の「Configure a CAA Record」または「Troubleshooting CAA Problems」をご覧ください。

現時点では使用できません。

DNS 検証では、ドメインの所有権は CNAME レコードを DNS 設定に追加することで検証できます。DNS 検証によって、ACM からパブリック SSL/TLS 証明書をリクエストする際にドメインの所有を立証しやすくなります。

DNS 検証は、ドメインの所有または管理の検証を簡単にすることで、SSL/TLS 証明書を得られるようにします。DNS 検証では、DNS 設定に CNAME レコードを書き込むだけで、ドメイン名の管理を立証できます。DNS 検証プロセスを簡単にするため、Amazon Route 53 で DNS レコードを管理している場合には、ACM 管理コンソールで DNS レコードを設定できます。この場合は、マウスを数回クリックするだけでお使いのドメイン名の管理を立証できます。CNAME レコードの設定後、DNS 検証レコードがある限り、ACM は自動的に使用中の (AWS リソースに関連付けられている) 証明書を更新します。更新は完全に自動化されており、何も触る必要はありません。

ACM に証明書をリクエストし、リクエストしているドメインに対して DNS 設定の変更ができる人は DNS での検証を検討してください。

はい。ACM では、DNS 設定の変更ができないお客様のために E メールでの検証にも対応しています。

検証したいドメインに CNAME レコードを追加してください。例えば、www.example.com の名前を検証するには、example.com に対するゾーンに CNAME レコードを追加します。追加するレコードは、ドメインと AWS アカウントに対して特別に ACM が生成した、ユニークなトークンを含みます。CNAME レコードの 2 箇所 (名前とラベル) は ACM から得られます。詳細については、「ACM ユーザーガイド」をご覧ください。

DNS レコードの追加または変更の詳細については、お使いの DNS プロバイダにお問い合わせください。Amazon Route 53 DNS ドキュメントには、Amazon Route 53 DNS をご利用のお客様向けに詳細情報が記載されています。

はい。DNS レコードの管理に Amazon Route 53 DNS をご利用のお客様は、証明書をリクエストする際に ACM コンソールで DNS 設定にレコードを追加できます。ドメインに対して Route 53 DNS がホストするゾーンは、リクエストしているのと同じ AWS アカウントで設定されている必要があり、リクエストする方は Amazon Route 53 設定を変更できる権限を持っている必要があります。詳細については、ACM ユーザーガイドを参照してください。

いいえ。プロバイダが CNAME レコードを DNS 設定に追加することを許す限り、どのような DNS プロバイダでも DNS 検証に使用できます。

1 つです。1 つの CNAME レコードを使用して、同じ AWS アカウントでの同じドメイン名に対し、複数の証明書を得られます。例えば、同じドメイン名に対する同じ AWS アカウントから 2 つの証明書をリクエストする場合、必要な DNS CNAME レコードはひとつだけです。

いいえ。各ドメイン名には固有の CNAME レコードが必要です。

はい。

DNS CNAME レコードには、名称とラベルの 2 つのコンポーネントがあります。ACM が生成した CNAME の名称のコンポーネントは、下線文字 (_) と、それに続いて、お使いの AWS アカウントとドメイン名に関連付けられた文字列であるトークンで構成されています。ACM は、ドメイン名の前に下線とトークンを加えて名称コンポーネントを構成します。ACM は、同じく AWS アカウントとドメイン名に関連付けられた別のトークンの前に付加された下線から、ラベルを作成します。ACM は、AWS が検証に使用する DNS ドメイン名 (acm-validations.aws) の前に、下線とトークンを付加します。次の例では www.example.com、subdomain.example.com、および *.example.com に対する CNAME の構成を示します。

_TOKEN1.www.example.com         CNAME     _TOKEN2.acm-validations.aws
_TOKEN3.subdomain.example.com CNAME     _TOKEN4.acm-validations.aws
_TOKEN5.example.com                 CNAME      _TOKEN6.acm-validations.aws

ワイルドカード名に対して CNAME レコードを生成するときに、ACM がワイルドカードラベル (*) を削除していることに注意してください。そのため、ACM がワイルドカード名 (例えば *.example.com) に対して生成した CNAME レコードは、ドメイン名にワイルドカードラベルが無いもの (example.com) に対して返されるレコードと同じになります。

いいえ。ホスト名とサブドメイン名を含む各ドメイン名は、固有の CNAME レコードで個別に検証する必要があります。

CNAME レコードを使うことで、ACM は CNAME レコードが存在する限り証明書を更新できます。CNAME レコードは AWS ドメイン (acm-validations.aws) での TXT レコードに転送しますので、ACM は必要に応じてお客様から何もやっていただかなくてもドメイン名を検証、再検証できます。

はい。ACM がオファーされているどのような AWS リージョンでも、1 つの DNS CNAME レコードを生成し、これを使用して同じ AWS アカウントで証明書を得られます。CNAME レコードを一度設定すると、別のレコードを作成することなく、その名称に対して ACM から発行、更新される証明書を得られます。

いいえ。各証明書に使える検証方法は 1 つのみです。

DNS 検証レコードがある限り、ACM は自動的に使用中 (AWS リソースに関連付けられている) の証明書を更新します。

はい。CNAME レコードを削除するだけです。CNAME レコードを削除した後は、ACM が DNS 検証を使用してドメインに証明書を発行したり更新したりすることはなく、この変更は DNS 全体に適用されます。レコードの削除を全体に適用する時間はお客様の DNS プロバイダによります。

CNAME レコードを削除されると、ACM では DNS での検証を用いてお客様のドメインに証明書を発行または更新できなくなります。

E メール検証では、証明書リクエストにある各ドメイン名について、登録されているドメイン所有者に承認リクエストの E メールが送信されます。ドメイン所有者か権限を受けた代理人 (承認者) は、E メールに記載された指示に沿って、証明書リクエストを承認できます。承認者は、指示に沿って E メールに記載されているリンクをクリックするか、E メールからリンクをコピーしてブラウザ貼り付けて、承認ウェブサイトを開きます。その後、ドメイン名、証明書 ID (ARN)、リクエスト実行元の AWS アカウントの ID など、証明書リクエストに関連する情報を確認し、情報が正確であればリクエストを承認します。

E メール検証を使用して証明書をリクエストすると、証明書リクエストに記載された各ドメイン名に対して WHOIS ルックアップが実行され、そのドメインの連絡先情報が取得されます。E メールは、記載されているそのドメインの登録者、管理者、技術担当者の連絡先に送信されます。リクエストされたドメイン名の前に admin@、administrator@、hostmaster@、webmaster@、postmaster@ を付加して生成された 5 つの特別なメールアドレスにも、E メールが送られます。例えば、server.example.com の証明書をリクエストした場合、E メールの送信先は、その example.com ドメインに対する WHOIS クエリで返された連絡先情報を使用するそのドメインの登録者、技術担当者、管理者の連絡先、admin@server.example.com、administrator@server.example.com、hostmaster@server.example.com、postmaster@server.example.com、および webmaster@server.example.com となります。

5 つの特別な E メールアドレスは、「www」で始まるドメイン名またはアスタリスク (*) で始まるワイルドカード名については、別に構成されます。ACM によって先頭の「www」またはアスタリスクは除去され、E メールは残りのドメイン名の先頭に admin@、administrator@、hostmaster@、postmaster@、webmaster@ を付加して生成された管理アドレスに送信されます。例えば www.example.com の証明書をリクエストした場合、E メールは前述のとおり WHOIS の連絡先と、admin@www.example.com ではなく admin@example.com に送信されます。残りの 4 つの特別な E メールアドレスも同様に構築されます。

証明書をリクエストした後、ACM コンソール、AWS CLI、AWS API を使用して、各ドメインに関する E メールの送信先となった E メールアドレスのリストを表示できます。

いいえ。ただし、検証メールの送信先とするベースドメイン名は設定できます。ベースドメイン名は、証明書リクエストに記載されたドメイン名のスーパードメインである必要があります。例えば server.domain.example.com の証明書をリクエストする場合、AWS CLI や AWS API を使用して、承認メールを admin@domain.example.com に転送するよう設定できます。詳細については、ACM CLI リファレンスと ACM API リファレンスをご覧ください。

はい。ただし、プロキシにより E メールの配信が遅れる可能性があります。また、プロキシ経由で送信される E メールは、迷惑メールフォルダに分類される可能性があります。トラブルシューティングのアドバイスについては、ACM ユーザーガイドを参照してください。

いいえ。ドメイン所有者のアイデンティティを検証するための手順とポリシーは非常に厳格で、公的に信頼されている認証機関のポリシー基準を設定する CA/ブラウザフォーラムにより決定されています。詳細については、Amazon Trust Services Repository にある最新の Amazon Trust Services Certification Practices を参照してください。

トラブルシューティングのアドバイスについては、ACM ユーザーガイドを参照してください。

ACM により提供される証明書ごとに、キーペアが作成されます。ACM は、SSL/TLS 証明書で使用されるプライベートキーを保護し管理するよう設計されています。プライベートキーを保護および保存する際には、強力な暗号化とキー管理に関するベストプラクティスが使用されます。

いいえ。各 ACM 証明書のプライベートキーは、証明書をリクエストしたリージョンで保存されます。例えば米国東部 (バージニア北部) リージョンで新しい証明書を取得した場合、ACM はプライベートキーをバージニア北部リージョンに保存します。ACM 証明書がリージョンをまたいでコピーされるのは、証明書が CloudFront ディストリビューションと関連付けられている場合に限られます。この場合、CloudFront により、ディストリビューションの対象として設定されている地理的場所に ACM 証明書が配信されます。

ACM が管理する更新とデプロイでは、SSL/TLS ACM 証明書の更新処理と、更新後の証明書のデプロイを管理します。

ACM では、SSL/TLS 証明書の更新とデプロイを管理できます。ACM により、安全なウェブサービスやアプリケーションに対する SSL/TLS の設定と維持が自動化されるため、エラーが発生しやすい手動プロセスと比較して、運用の信頼性が高まります。更新とデプロイが自動的に管理されることは、証明書の期限切れによるダウンタイムをなくすのにも役立ちます。ACM は、他の AWS のサービスと統合されたサービスとして動作します。つまり、AWS マネジメントコンソール、AWS CLI、AWS API を使用して、証明書を AWS プラットフォームで集中的に管理およびデプロイできることになります。プライベート CA では、プライベート証明書を作成し、エクスポートできます。エクスポートした証明書は ACM が更新するため、クライアント側の自動化コードでこれらの証明書をダウンロードし、デプロイできます。

パブリック証明書

ACM では、パブリック ACM 証明書を、ドメイン所有者から追加の検証なしで更新、デプロイできます。追加の検証がないと更新できない証明書については、ACM は証明書に記載された各ドメイン名のドメイン所有者を検証して更新プロセスを管理します。証明書に記載された各ドメイン名が検証されると、証明書が更新され、AWS リソースに自動的にデプロイされます。ACM がドメインの所有を検証できない場合はお客様 (AWS アカウントの所有者) にお知らせします。

証明書のリクエストで DNS 検証を選択した場合、ACM では証明書が使用中で (AWS リソースに関連付けられていて)、CNAME レコードがある限り、お客様からは何らの追加介入もなくその証明書を無期限で更新します。証明書をリクエストする際に E メールでの検証を選択された場合、その証明書が使用中であり、証明書に記載されたすべてのドメイン名がお客様のサイトに解決でき、すべてのドメイン名がインターネットから到達可能であることを示して、ACM 証明書が自動的に更新、デプロイできる可能性を向上できます。

プライベート証明書

ACM では、AWS プライベート CA で発行するプライベート証明書の管理に 2 つのオプションがあります。ACM は、プライベート証明書の管理方法に応じて、様々な更新の機能を提供します。発行される各プライベート証明書に対して最上の管理オプションを選択してください。

1) ACM は、お使いの AWS プライベート CA が発行するプライベート証明書で、Elastic Load Balancing や API Gateway などの ACM 統合サービスで使われるものを、完全に自動的に更新、デプロイします。ACM で発行されたプライベート証明書は、証明書を発行したプライベート CA がアクティブなステートである限り、ACM での更新とデプロイが可能です。

2) ACM からエクスポートし、オンプレミスリソース、EC2 インスタンス、IoT デバイスで使用するプライベート証明書については、ACM が自動的に更新します。新規証明書とプライベートキーの取得、アプリケーション中でのデプロイメントはお客様が行ってください。

ACM は、証明書の有効期限切れの最大 60 日前に更新プロセスを開始します。現在、ACM 証明書の有効期間は 13 か月 (395 日) です。マネージド更新の詳細については、「ACM ユーザーガイド」をご覧ください。

いいえ。ACM による証明書の更新やキーの再設定、古い証明書の差し替えは、事前の通知なしに行われる可能性があります。

パブリック証明書に対する証明書のリクエストで DNS での検証を選択された場合、ACM では証明書が使用中で (AWS リソースに関連付けられている)、お客様の CNAME レコードがある限り、お客様からは何らの追加介入もなくその証明書を更新します。

ベアドメインのパブリック証明書をリクエストする際に E メール検証を選択した場合は、ベアドメインの DNS ルックアップがその証明書に関連付けられた AWS リソースに解決されるようにしておいてください。Route 53 や、ベアドメインを AWS リソースにマッピングするエイリアスリソースレコード (または同等の機能) をサポートするその他の DNS プロバイダーを使用しないと、ベアドメインから AWS リソースへの解決が困難な場合があります。詳細については、Route 53 開発者ガイドを参照してください。

いいえ。新しい証明書がデプロイされた後に確立された接続では、新しい証明書を使用しているため、既存の接続に影響はありません

はい。

はい。しかし AWS プライベート CA でプライベート証明書を発行すると、ACM は検証なしでこれを更新できます。インターネットから到達できないパブリック証明書と、プライベート証明書について、ACM が更新をどのように取り扱うのかの詳細については、「更新とデプロイの管理」をご覧ください。

はい。AWS CloudTrail を使用してログを確認すると、証明書のプライベートキーがいつ使用されたかを確認できます。

AWS CloudTrail をサポートするサービスで AWS API を呼び出したユーザーやアカウント、呼び出し元であるソース IP アドレス、呼び出しが発生した時間を特定できます。例えば、ACM により提供された証明書を Elastic Load Balancing と関連付ける API 呼び出しを行ったユーザーや、Elastic Load Balancing service で KMS API 呼び出しを使ってキーが暗号化された時間を特定できます。

Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway サービスなどの ACM 統合サービスで使用される、AWS Certificate Manager を通じてプロビジョニングされたパブリック証明書とプライベート証明書は無料です。お支払いいただくのは、アプリケーションを実行するために作成した AWS リソースの料金です。AWS プライベート CA は従量制料金です。詳細と例については、AWS プライベート CA の料金ページにアクセスしてください。

AWS プライベート CA の使用に関するよくある質問については、「AWS Private CA FAQs」をご覧ください。