SSL/TLS証明書の仕組みと更新手順

※本記事にはプロモーション（広告）を含みます。

SSL/TLS証明書の仕組みと更新手順を完全解説

Webサイトのセキュリティを維持する上で、SSL/TLS証明書は欠かせない要素です。証明書の有効期限が切れるとブラウザから警告が表示され、ユーザー離れに直結します。そのため、証明書の仕組みを理解し、適切な更新手順を実施することがインフラエンジニアにとって必須のスキルとなります。本記事では、SSL/TLS証明書の基礎から応用までを網羅的に解説し、実務で即活用できる知識を提供します。

SSL/TLS証明書とは何か
SSL/TLS証明書の仕組みと暗号化の流れ
SSL/TLS証明書の種類と特徴
SSL/TLS証明書の有効期限と期限切れのリスク
SSL/TLS証明書の更新手順（実践ガイド）
SSL/TLS証明書の自動更新と管理ツール
SSL/TLS証明書に関するトラブルシューティング
SSL/TLS証明書運用のベストプラクティス
よくある質問（FAQ）
まとめ

SSL/TLS証明書とは何か

SSL/TLS証明書は、Webサイトの所有者と暗号化された接続を確立するための電子証明書です。この証明書により、ブラウザとサーバー間の通信が暗号化され、第三者による傍受や改ざんを防止します。SSL（Secure Sockets Layer）は古いプロトコルですが、現在でも一般的に使用されており、TLS（Transport Layer Security）はその後継プロトコルです。実務では「SSL証明書」という呼称が広く浸透していますが、技術的にはTLS証明書が正しい表現です。

SSL/TLS証明書には、以下の主要な要素が含まれています。

所有者情報：ドメイン名、組織名、所在地など
公開鍵：暗号化に使用される鍵ペアの公開鍵部分
発行者情報：認証局（CA）の名前と署名
有効期限：証明書の発行日から失効日までの期間
署名アルゴリズム：証明書に使用された暗号化アルゴリズム

これらの情報は、認証局（Certificate Authority）によって発行され、信頼できる第三者機関として機能します。証明書の信頼性は、認証局の署名によって保証されています。

SSL/TLS証明書の仕組みと暗号化の流れ

SSL/TLS証明書の仕組みを理解するには、暗号化の基本的な流れを把握することが重要です。以下に、SSL/TLS接続の確立からデータ送受信までのプロセスを段階的に解説します。

1. SSL/TLSハンドシェイクの流れと証明書検証

SSL/TLS接続は「ハンドシェイク」と呼ばれるプロセスで開始されます。このプロセスでは、以下のステップが実行されます。

クライアントHello：クライアント（ブラウザ）がサーバーに接続を要求し、サポートしている暗号スイート（暗号化方式）のリストを送信します。
サーバーHello：サーバーがクライアントに対して、使用する暗号スイートを選択し、サーバーのSSL/TLS証明書を送信します。
証明書の検証：クライアントはサーバーから受け取った証明書を検証します。検証には以下の項目が含まれます。
- 証明書の有効期限が切れていないか
- 証明書が信頼できる認証局によって発行されているか
- 証明書のドメイン名が接続先のドメインと一致しているか
- 証明書が改ざんされていないか（署名の検証）
鍵交換：サーバーとクライアントは、セッションごとに使用される一時的な暗号鍵（セッション鍵）を生成します。この鍵交換には、以下の方式が使用されます。
- RSA方式：サーバーの公開鍵で暗号化されたセッション鍵をクライアントが生成し、サーバーに送信します。
- Diffie-Hellman（DH）方式：クライアントとサーバーがそれぞれの公開鍵を交換し、セッション鍵を生成します。この方式は「前方秘匿性（Forward Secrecy）」を提供します。
暗号化通信の開始：セッション鍵を用いて、クライアントとサーバー間の通信が暗号化されます。

このハンドシェイクプロセスにより、安全な暗号化通信が確立されます。ハンドシェイクが完了すると、データの送受信が開始されます。

2. 暗号化アルゴリズム

SSL/TLSで使用される暗号化アルゴリズムには、以下の種類があります。

暗号化方式	説明	セキュリティレベル
RSA	公開鍵暗号方式の一種で、鍵交換と署名に使用されます。処理速度が速いですが、量子コンピュータに対する脆弱性が指摘されています。	中（将来的には低下する可能性あり）
ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）	楕円曲線暗号を使用したDiffie-Hellman鍵交換方式。高いセキュリティと処理速度を両立しています。	高
AES（Advanced Encryption Standard）	共通鍵暗号方式で、SSL/TLS通信のデータ暗号化に使用されます。128ビット、192ビット、256ビットの鍵長があります。	高
ChaCha20-Poly1305	ストリーム暗号と認証暗号を組み合わせた方式で、CPU負荷が低く、モバイルデバイスに適しています。	高

現在のベストプラクティスでは、ECDHE + AES-GCM（またはChaCha20-Poly1305）の組み合わせが推奨されています。これにより、高いセキュリティとパフォーマンスを両立できます。

3. SSL/TLSのバージョン別セキュリティ状況

SSL/TLSには複数のバージョンが存在しますが、現在では以下のバージョンが主に使用されています。

バージョン	リリース年	セキュリティ状況	推奨度
SSL 2.0	1995年	深刻な脆弱性が存在（例：POODLE攻撃）	非推奨
SSL 3.0	1996年	脆弱性が多く、TLS 1.0に置き換えられた	非推奨
TLS 1.0	1999年	脆弱性が見つかっており、廃止が進んでいる	非推奨
TLS 1.1	2006年	TLS 1.0の改良版だが、脆弱性が存在	非推奨
TLS 1.2	2008年	現在でも広く使用されているが、TLS 1.3への移行が進んでいる	推奨
TLS 1.3	2018年	最新バージョンで、セキュリティとパフォーマンスが向上	強く推奨

2024年現在、TLS 1.2とTLS 1.3が主流ですが、TLS 1.0と1.1は既に廃止されており、使用すべきではありません。TLS 1.2も将来的には廃止される可能性があるため、可能な限りTLS 1.3への移行を検討してください。

SSL/TLS証明書の種類と特徴

SSL/TLS証明書には、用途や検証レベルに応じて複数の種類が存在します。目的に応じて適切な証明書を選択することが、セキュリティとコストのバランスを取る上で重要です。

1. 検証レベルによる分類

SSL/TLS証明書は、発行元の認証局が行う検証レベルによって、以下の3つに大別されます。

証明書タイプ	検証内容	発行までの時間	コスト	主な用途
ドメイン検証（DV: Domain Validation）	ドメインの所有者であることを確認。メールやDNSレコードの確認が一般的。	数分〜数時間	安価（年間数千円〜）	個人サイト、ブログ、開発環境
組織検証（OV: Organization Validation）	ドメインの所有者に加え、組織の実在性を確認。法人登記簿などの提出が必要。	数日〜1週間	中程度（年間数万円〜）	企業サイト、ECサイト、法人向けサービス
拡張検証（EV: Extended Validation）	厳格な審査により、組織の実在性と法的責任を確認。ブラウザのアドレスバーに緑色の鍵マークが表示される。	2週間〜1ヶ月	高額（年間数十万円〜）	金融機関、大手企業、高い信頼性が求められるサイト

DV証明書は手軽に取得できますが、ブラウザのアドレスバーに組織名が表示されないため、ユーザーからの信頼性が低くなる場合があります。一方、EV証明書は高い信頼性を提供しますが、コストと審査期間がかかります。用途に応じて適切な証明書を選択しましょう。

2. 機能による分類

SSL/TLS証明書は、機能面でもいくつかの種類に分類されます。

シングルドメイン証明書

1つのドメイン（例：example.com）に対して発行される証明書です。サブドメイン（例：www.example.com）は含まれません。

ワイルドカード証明書

1つのドメインとそのすべてのサブドメインに対して発行される証明書です。例えば、*.example.comという証明書を取得すると、mail.example.com、blog.example.comなどすべてのサブドメインで使用できます。

注意点：ワイルドカード証明書はセキュリティリスクを伴う場合があります。なぜなら、1つの秘密鍵で複数のサブドメインをカバーするため、鍵が漏洩した場合の影響範囲が広くなるからです。運用時には鍵管理に十分注意してください。

マルチドメイン証明書（SAN/UCC証明書）

複数のドメイン（例：example.com、example.org、example.net）に対して発行される証明書です。SAN（Subject Alternative Name）と呼ばれる拡張機能を使用して、複数のドメインを1つの証明書でカバーします。

マルチドメイン証明書は、複数のWebサイトを運営している場合に便利です。例えば、企業が複数のドメインを所有している場合や、クラウドサービスを提供している場合に適しています。

コードサイニング証明書

ソフトウェアやアプリケーションに署名するための証明書です。ユーザーは署名されたソフトウェアが改ざんされていないことを確認できます。主に開発者や企業が使用します。

S/MIME証明書

電子メールの暗号化と署名に使用される証明書です。メールの送受信時に暗号化を行い、なりすましを防止します。

3. 発行元による分類

SSL/TLS証明書は、発行元の認証局によっても分類されます。主要な認証局には以下のようなものがあります。

グローバル認証局：DigiCert、Sectigo（旧Comodo）、Let’s Encrypt、GlobalSign、Entrustなど
ローカル認証局：日本の場合、JPRS（Japan Registry Services）が発行するJPドメイン向けの証明書など
プライベート認証局：企業内で独自に運用する認証局。社内システムやテスト環境で使用されます。

グローバル認証局の証明書は、ほとんどのブラウザやデバイスにデフォルトで信頼されています。一方、ローカル認証局やプライベート認証局の証明書は、信頼ストアに追加する必要があります。

SSL/TLS証明書の有効期限と期限切れのリスク

SSL/TLS証明書には有効期限が設定されており、期限が切れるとブラウザから警告が表示されます。有効期限の管理は、Webサイトのセキュリティと信頼性を維持する上で極めて重要です。

1. 一般的な有効期限

SSL/TLS証明書の有効期限は、発行元の認証局や証明書の種類によって異なります。以下に一般的な有効期限を示します。

証明書タイプ	一般的な有効期限	最大有効期限（2024年現在）
DV証明書	1年	1年（Let’s Encryptは90日）
OV証明書	1〜2年	2年
EV証明書	1〜2年	2年

2020年以降、AppleやGoogle、Mozillaなどの主要ブラウザベンダーは、SSL/TLS証明書の有効期限を最大1年に制限する方針を発表しました。これは、証明書の定期的な更新を促し、セキュリティリスクを低減するためです。このため、多くの認証局が1年を超える有効期限の証明書を発行していません。

例外として、Let’s Encryptは90日間の有効期限を採用しています。これは、セキュリティを向上させるための仕組みで、定期的な更新を強制することで証明書の漏洩リスクを低減しています。

2. 期限切れのリスク

SSL/TLS証明書が期限切れになると、以下のような深刻な問題が発生します。

1. ブラウザからの警告表示

期限切れの証明書を使用しているWebサイトにアクセスすると、ブラウザから警告が表示されます。主要なブラウザ（Chrome、Firefox、Safari、Edge）では、以下のような警告が表示されます。

Chrome：「このサイトへの接続はプライベートではありません」という警告と、赤いロックアイコン
Firefox：「この接続は安全ではありません」という警告と、灰色のロックアイコン
Safari：「このWebサイトへの接続は安全ではありません」という警告

この警告により、ユーザーはサイトに対する信頼を失い、離脱する可能性が高くなります。特にECサイトや金融機関のWebサイトでは、売上や顧客満足度に大きな影響を与える可能性があります。

2. SEOへの悪影響

Googleなどの検索エンジンは、SSL/TLS証明書が期限切れのWebサイトを低く評価します。これは、セキュリティが確保されていないサイトはユーザーにとって安全ではないと判断されるためです。

Googleの検索エンジン最適化（SEO）ガイドラインでは、SSL/TLS証明書の使用が推奨されており、期限切れの証明書はランキングに悪影響を与える可能性があります。

3. サービスの停止

期限切れの証明書を使用していると、APIサービスやバックエンドシステムとの通信が中断される可能性があります。例えば、モバイルアプリやWebサービスがAPIを介してデータを取得する際に、SSL/TLSの検証に失敗し、接続が拒否されることがあります。

4. セキュリティリスクの増大

期限切れの証明書は、古い暗号化方式や脆弱なアルゴリズムが使用されている可能性があります。これにより、中間者攻撃（Man-in-the-Middle Attack）やデータの傍受、改ざんのリスクが高まります。

3. 有効期限の確認方法

SSL/TLS証明書の有効期限を確認する方法は以下の通りです。

ブラウザを使用した確認

Webサイトにアクセスします。
アドレスバーのロックアイコン（🔒）をクリックします。
「証明書」または「Certificate」を選択します。
証明書の詳細情報が表示され、有効期限が確認できます。

コマンドラインを使用した確認

LinuxやmacOSのターミナル、WindowsのPowerShellから以下のコマンドを実行します。

Linux/macOS（opensslコマンド）：

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates

このコマンドを実行すると、証明書の発行日と有効期限が表示されます。

Windows（PowerShell）：

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2; $cert.Import([System.IO.File]::ReadAllBytes("C:\path\to\certificate.cer")); $cert.NotAfter

このコマンドを実行すると、証明書の有効期限（NotAfter）が表示されます。

オンラインツールを使用した確認

以下のオンラインツールを使用して、SSL/TLS証明書の有効期限を確認できます。

4. 有効期限切れの防止策

SSL/TLS証明書の有効期限切れを防ぐためには、以下の対策を実施しましょう。

自動更新の設定：多くの認証局や証明書管理ツールでは、自動更新機能を提供しています。これにより、手動での更新作業を削減できます。
期限監視システムの導入：証明書の期限が近づいた際にアラートを送信するシステムを構築します。例えば、Prometheus + AlertmanagerやZabbixなどの監視ツールを使用します。
証明書管理台帳の作成：すべての証明書の発行日、有効期限、更新日を一覧化した台帳を作成します。これにより、期限管理が容易になります。
Let’s Encryptの活用：Let’s Encryptは90日間の有効期限で、自動更新が可能です。コストを抑えつつ、セキュリティを向上させることができます。
テスト環境での検証：証明書を更新する前に、テスト環境で動作確認を行います。これにより、本番環境でのトラブルを未然に防ぎます。

これらの対策を実施することで、SSL/TLS証明書の期限切れによるリスクを最小限に抑えることができます。

SSL/TLS証明書の更新手順（実践ガイド）

SSL/TLS証明書の更新は、定期的な作業ですが、手順を間違えるとサイトのダウンタイムやセキュリティリスクにつながる可能性があります。本セクションでは、実務で使用される更新手順を、具体的な手順と注意点を含めて解説します。

1. 更新前の準備

証明書を更新する前に、以下の準備を行います。

1. 現在の証明書の情報を確認する

以下の情報を確認し、メモしておきます。

証明書の発行元（認証局）
証明書の種類（DV、OV、EV）
ドメイン名（シングルドメイン、ワイルドカード、マルチドメイン）
有効期限
秘密鍵とCSR（Certificate Signing Request）の保存場所

これらの情報は、新しい証明書を発行する際に必要になります。

2. 秘密鍵とCSRのバックアップ

証明書の更新時には、新しいCSRを生成するか、既存の秘密鍵を再利用するかを選択できます。秘密鍵はサーバー上で管理されているため、バックアップを取っておくことを推奨します。

注意点：秘密鍵は極めて重要な情報です。バックアップは暗号化された状態で保管し、アクセス制限を設けてください。

3. 新しいCSRの生成

新しい証明書を発行する際には、CSR（Certificate Signing Request）が必要です。CSRは、以下のコマンドで生成できます。

Apache/Nginx（OpenSSL）：

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

このコマンドを実行すると、以下の情報を入力するよう求められます。

Country Name (2 letter code) [XX]: JP
State or Province Name (full name) []: Tokyo
Locality Name (eg, city) []: Shibuya-ku
Organization Name (eg, company) []: Example Inc.
Organizational Unit Name (eg, section) []: IT Department
Common Name (eg, YOUR name) []: example.com
Email Address []: admin@example.com
（追加で2つの質問がありますが、空白のままEnterを押しても問題ありません）

生成されたCSRファイル（example.com.csr）は、認証局に送信します。秘密鍵（example.com.key）はサーバー上で安全に保管してください。

Windows（IIS）：

IISマネージャーを開きます。
「サーバー証明書」を選択します。
「証明書の作成」をクリックします。
必要な情報を入力し、CSRを生成します。

4. 認証局への申請

CSRを生成したら、認証局に申請を行います。申請方法は認証局によって異なりますが、一般的な流れは以下の通りです。

認証局のWebサイトにログインします。
「証明書の新規発行」または「リニューアル」を選択します。
CSRファイルをアップロードします。
ドメイン検証（DVの場合）や組織検証（OV/EVの場合）を行います。
支払いを行い、発行を待ちます。

DV証明書の場合、検証は数分で完了します。OV/EV証明書の場合、数日から数週間かかる場合があります。

2. 証明書の発行とダウンロード形式

認証局による検証が完了すると、証明書が発行されます。発行された証明書は、以下の形式でダウンロードできます。

.crt形式：PEM形式の証明書ファイル
.cer形式：DER形式の証明書ファイル
.p7b形式：PKCS#7形式の証明書ファイル（チェーン証明書を含む）

ダウンロードした証明書ファイルは、サーバーにアップロードします。証明書ファイルには、以下の情報が含まれています。

サーバー証明書
中間証明書（チェーン証明書）
ルート証明書（通常は含まれていない場合があります）

3. サーバーへの証明書の適用

SSL/TLS証明書の自動更新と管理ツール

SSL/TLS証明書の自動更新は、手動での更新作業を軽減し、証明書の有効期限切れによるサービス停止リスクを低減する重要なプロセスです。多くの組織では、証明書のライフサイクル管理を自動化することで、運用負荷の軽減とセキュリティの維持を両立させています。特にクラウド環境やコンテナ化されたシステムでは、証明書の自動更新が標準的な運用手法として採用されています。

自動更新を実現するための代表的な方法として、CertbotやLet’s Encryptが提供するACME（Automatic Certificate Management Environment）プロトコルが広く利用されています。これらのツールは、証明書の発行・更新・インストールを自動化し、DNS-01やHTTP-01といったチャレンジ方式を用いてドメイン所有者の検証を行います。また、企業向けのソリューションとして、DigiCertやGlobalSignなどの商用CA（認証局）が提供する管理ツールも存在します。

自動更新の仕組みを導入する際には、以下の点に留意することが重要です。まず、証明書の更新タイミングを適切に設定し、有効期限切れ直前の更新を避けることで、システムへの影響を最小限に抑えます。また、更新プロセスが正常に完了したことを確認するための監視体制を整備し、万が一の失敗時に備えたロールバック手順を用意しておくことが推奨されます。さらに、複数の証明書を管理する場合は、一元的な管理画面やAPIを活用して運用効率を向上させることができます。

自動更新の導入前に、対象となるサーバーやサービスがACMEプロトコルに対応しているか確認し、必要に応じて設定ファイルやミドルウェアのアップデートを行う。

SSL/TLS証明書に関するトラブルシューティング

SSL/TLS証明書に関するトラブルは、主に証明書の有効期限切れや構成ミス、鍵の不一致などが原因で発生します。まず、ブラウザやサーバーのエラーメッセージを確認し、具体的なエラー内容を特定することが重要です。例えば、ERR_CERT_AUTHORITY_INVALIDやNET::ERR_CERT_DATE_INVALIDなどのメッセージが表示される場合は、証明書の発行元や有効期限に問題がある可能性が高いです。

次に、サーバー側の設定を確認します。ApacheやNginxなどのWebサーバーでは、証明書ファイルと秘密鍵ファイルのパスが正しく設定されているか、中間証明書が適切に連結されているかを確認します。また、SSL/TLSのプロトコルバージョンや暗号スイートの設定が古い場合、最新のセキュリティ基準に対応していない可能性があります。この場合は、サーバーソフトウェアの公式ドキュメントを参照し、推奨される設定への更新を検討してください。

トラブルの原因を特定する際には、以下の項目を順に確認すると効果的です。

証明書の有効期限（openssl x509 -enddate -noout -in 証明書ファイルで確認可能）

これらの手順で問題が解決しない場合は、証明書の発行元（CA）に問い合わせるか、専門家にサポートを依頼することを検討してください。また、定期的な監視ツールを導入することで、証明書の有効期限切れや構成エラーを事前に検知できるようになります。

SSL/TLS証明書運用のベストプラクティス

SSL/TLS証明書の運用においては、セキュリティと可用性のバランスを考慮した管理が求められます。まず、証明書の有効期限を常に把握し、期限切れによるサービス停止を防ぐための監視体制を整えることが重要です。多くの組織では、自動更新機能を活用することで人的ミスを軽減しています。また、証明書の発行元である認証局（CA）の信頼性や、使用する暗号スイートの強度についても定期的に見直す必要があります。

運用時には、証明書の配備先であるサーバやデバイスの構成管理を徹底し、古いプロトコルや脆弱な暗号の使用を排除することが求められます。例えば、TLS 1.0や1.1のような古いバージョンは、既に脆弱性が指摘されているため、TLS 1.2以上への移行が推奨されます。さらに、証明書の発行・更新・失効といったライフサイクル全体を文書化し、関係者間で共有することで、運用の透明性を高めることができます。

以下の点にも注意を払いましょう。

証明書の秘密鍵は安全に保管し、定期的にローテーションを行う

よくある質問（FAQ）

SSL/TLS証明書に関する導入や運用で多く寄せられる疑問について、実務的な観点から回答します。

Q1. SSL/TLS証明書の更新を忘れた場合、どのような影響がありますか？

SSL/TLS証明書の有効期限が切れると、Webサイトへのアクセス時にブラウザから「接続が安全ではありません」といった警告が表示される場合があります。これにより、ユーザーの信頼低下やアクセス数の減少につながる可能性があります。また、一部のブラウザでは期限切れの証明書を拒否する動きも見られます。更新のタイミングは、証明書発行元からの期限通知に加え、自動監視ツールの活用が推奨されます。

Q2. 無料のSSL/TLS証明書（Let’s Encrypt等）と有料の証明書の違いは何ですか？

無料の証明書は、主にドメイン認証（DV）タイプで提供され、基本的な暗号化機能を備えています。一方、有料の証明書は、企業認証（OV）やEV（Extended Validation）などの高度な認証レベルを選択でき、ブラウザのアドレスバーに組織名が表示されるなどのメリットがあります。また、サポート体制や保証内容、発行元の信頼性にも違いがあります。用途に応じて適切な証明書を選択することが重要です。

Q3. SSL/TLS証明書の更新手順を教えてください。

更新手順は、使用する証明書の種類や発行元によって異なりますが、一般的には以下の流れで行います。まず、現在の証明書の有効期限を確認し、新しい証明書を発行元からリクエストします。次に、新しい証明書ファイル（通常は.crtや.pem形式）をサーバーにアップロードし、秘密鍵と組み合わせて設定ファイルに反映させます。最後に、サーバーを再起動または設定を再読み込みして、新しい証明書が適用されているか確認します。詳細は、ご利用のサーバーソフトウェアや証明書発行元の公式ドキュメントをご確認ください。

Q4. SSL/TLS証明書の選び方で重要なポイントは何ですか？

SSL/TLS証明書を選ぶ際は、まず暗号化の強度（鍵長やアルゴリズム）を確認します。次に、認証レベル（DV、OV、EV）を用途に合わせて選択します。例えば、個人ブログではDVで十分ですが、ECサイトなどでは顧客の信頼を高めるためにOVやEVが適しています。また、発行元の信頼性やサポート体制、価格、発行までの期間も考慮すべきポイントです。複数の証明書を比較検討し、自社のニーズに合ったものを選びましょう。

まとめ

SSL/TLS証明書は、インターネット上での通信を暗号化し、データの安全性を確保するために不可欠な技術です。Webサイトとユーザー間の通信が暗号化されることで、第三者による傍受や改ざんを防ぎ、信頼性の高いデータ送受信が可能になります。証明書は信頼できる認証局（CA）によって発行され、ドメインの所有者を証明する役割を果たします。また、証明書の有効期限が切れる前に定期的な更新を行うことで、常に最新の暗号化技術を維持し、セキュリティリスクを低減できます。

証明書の更新手順を正しく理解し、実施することが重要です。多くのCAでは自動更新オプションを提供しており、運用負荷を軽減できます。また、証明書の種類や用途に応じて適切な暗号化方式を選択することで、より強固なセキュリティを実現できます。SSL/TLS証明書の仕組みと更新方法を適切に管理することで、安心して安全なWebサービスを提供する基盤を整えることができます。

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク