EC2 トラブルシューティング ​

Amazon EC2インスタンスの運用において、様々な問題が発生する可能性があります。以下、AWS公式ドキュメントに基づいた体系的なトラブルシューティング手法を解説します。

インスタンス起動に関する問題 ​

起動失敗の主な原因 ​

インスタンスの起動に失敗する場合、以下の要因が考えられます：

容量不足

• 選択したアベイラビリティーゾーンで指定したインスタンスタイプの容量が不足している場合
• 異なるアベイラビリティーゾーンで再試行するか、異なるインスタンスタイプを選択

制限の超過

• アカウントのインスタンス制限に達している場合
• AWS Service Quotasコンソールで現在の制限を確認し、必要に応じて制限の引き上げを申請

AMIの問題

• 指定したAMIが利用できない、または破損している場合
• 有効なAMI IDを確認し、適切なAMIを選択

EC2インスタンス起動の詳細問題 ​

Amazon EC2インスタンスの起動に関する問題は、様々な要因によって発生します。以下、AWS公式ドキュメントに基づいた詳細なトラブルシューティング手法を解説します。

Invalid Device Name エラー ​

エラーの詳細 ​

新しいインスタンスを起動しようとすると、Invalid device name device_name エラーが発生する場合があります。このエラーは、リクエストの1つ以上のボリュームに対して指定されたデバイス名が無効である場合に発生します。

主な原因 ​

AMIによる使用済みデバイス名

• デバイス名が選択したAMIによって既に使用されている
• AMIの既存のブロックデバイスマッピングと競合している

ルートボリューム用予約名

• デバイス名がルートボリューム用に予約されている
• オペレーティングシステム固有の予約デバイス名を使用している

重複するデバイス名

• リクエスト内の別のボリュームで同じデバイス名を使用している
• 複数のボリュームに対して一意でないデバイス名を指定している

オペレーティングシステム非対応

• 指定したデバイス名がオペレーティングシステムで有効でない
• 正しい形式に従っていないデバイス名

解決方法 ​

AMIのデバイス名確認

選択したAMIで使用されていないデバイス名であることを確認します：

aws ec2 describe-images --image-id ami-0abcdef1234567890 \
  --query 'Images[*].BlockDeviceMappings[].DeviceName'

予約デバイス名の回避

ルートボリューム用に予約されているデバイス名を使用していないことを確認します。利用可能なデバイス名については、AWS公式ドキュメントの「Available device names」を参照してください。

一意性の確保

リクエストで指定される各ボリュームのデバイス名が一意であることを確認し、正しい形式に従っていることを検証します。

Instance Limit Exceeded エラー ​

エラーの詳細 ​

新しいインスタンスを起動するか、停止したインスタンスを再起動しようとすると、InstanceLimitExceeded エラーが発生します。このエラーは、リージョンで起動できるインスタンス数の制限に達している場合に発生します。

原因の詳細 ​

デフォルト制限

AWSアカウントを作成するとき、リージョンごとに実行できるインスタンスの数についてデフォルトの制限が設定されます。これらの制限は以下の要因によって決まります：

• インスタンスファミリー別の制限
• vCPU数による制限
• リージョン固有の制限
• アカウントの利用履歴

異なるインスタンスファミリーでの制限

AWS制限はインスタンスタイプによって異なるため、特定のインスタンスファミリーで制限に達する可能性があります。

終了保留中のインスタンス

終了されたインスタンスが完全にリリースされるまで、クォータにカウントされ続ける場合があります。

解決方法 ​

Service Quotasでの制限確認

現在の制限を確認し、必要に応じて制限の引き上げを申請します：

1. AWS Service Quotasコンソールにアクセス
2. Amazon EC2サービスを選択
3. 該当するクォータを確認
4. 必要に応じて制限引き上げを申請

代替インスタンスタイプの使用

制限に達していないインスタンスファミリーを使用することで、一時的に問題を回避できます。

Insufficient Instance Capacity エラー ​

エラーの詳細 ​

新しいインスタンスを起動するか、停止したインスタンスを再起動しようとすると、InsufficientInstanceCapacity エラーが発生します。このエラーは、現在AWSにリクエストに対応するために必要な十分なオンデマンドキャパシティがない場合に発生します。

根本的な原因 ​

キャパシティの動的変動

AWSのキャパシティは頻繁に変化するため、特定の時点で特定のアベイラビリティーゾーンやインスタンスタイプでキャパシティが不足する可能性があります。

リージョン・AZ固有の制約

特定のリージョンやアベイラビリティーゾーンで、要求されたインスタンスタイプのキャパシティが一時的に不足している状況です。

段階的解決アプローチ ​

時間を置いた再試行

数分間待ってからリクエストを再度送信します。キャパシティは頻繁に変化するため、短時間で状況が改善される可能性があります。

リクエストサイズの調整

インスタンス数を減らして新しいリクエストを送信します：

• 15インスタンスの単一リクエストの代わりに、5インスタンスの3つのリクエストを作成
• または1インスタンスの15のリクエストを作成

アベイラビリティーゾーンの柔軟化

インスタンスを起動する場合、アベイラビリティーゾーンを指定しないで新しいリクエストを送信します。これにより、要求されたインスタンスタイプのキャパシティがあるAZで起動されます。

インスタンスタイプの変更

別のインスタンスタイプを使用して新しいリクエストを送信し、後でサイズを変更することを検討します。

プレイスメントグループでの特別な考慮事項 ​

クラスタープレイスメントグループにインスタンスを起動すると、容量不足エラーが発生する場合があります。この場合、プレイスメントグループ内のすべてのインスタンスを停止・開始して、すべての要求されたインスタンスのキャパシティを持つ新しいハードウェアに移行することを試行します。

On-Demand Capacity Reservations による予防策 ​

キャパシティ予約の活用 ​

重要なマシンでの容量不足エラーを回避するために、On-Demand Capacity Reservationsの使用を検討します。

Capacity Reservationの作成手順

1. 特定のアベイラビリティーゾーンでCapacity Reservationを作成
2. 重要なインスタンスをCapacity Reservationに起動
3. 予約されたキャパシティの継続的な利用可能性を確保

実装のベストプラクティス ​

予防的キャパシティ管理

• ビジネスクリティカルなワークロードには事前にキャパシティを予約
• ピーク時期やイベント前の事前準備
• 複数のAZでの冗長化されたキャパシティ予約

診断とモニタリング ​

CloudTrailでの起動イベント確認 ​

インスタンス起動の問題を診断するために、AWS CloudTrailでStartInstancesイベントを確認します。

AWS CLIによる詳細診断 ​

aws ec2 describe-instances --instance-id MYINSTANCE --output json

レスポンスのStateReasonメッセージを確認して、問題の具体的な原因を特定します。

起動問題の予防策 ​

推奨事項一覧 ​

継続的な改善 ​

• 起動パターンの分析と最適化
• キャパシティ需要の予測と事前準備
• 自動化されたフェイルオーバー戦略の実装
• 定期的な制限とキャパシティの見直し

インスタンス接続の問題 ​

SSH接続のトラブルシューティング ​

Linux インスタンスへのSSH接続で問題が発生する場合、以下の手順で診断を行います：

ユーザー名の確認

各AMIには適切なデフォルトユーザー名が設定されています：

セキュリティグループの確認

インスタンスに関連付けられたセキュリティグループが、適切なポートでのインバウンドSSHトラフィックを許可していることを確認します：

• SSH用のポート22が開放されていること
• 接続元のIPアドレスからのアクセスが許可されていること
• デフォルトのセキュリティグループはSSHトラフィックを許可しないため、適切なルールの追加が必要

インスタンスの状態確認

インスタンスが接続を受け入れる準備ができていることを確認します：

• インスタンスの状態が「running」であること
• ステータスチェックが両方とも合格していること
• インスタンス起動後、接続要求を受け入れる準備が整うまで数分かかる場合があります

インスタンスの停止に関する問題 ​

停止できない場合の対処法 ​

インスタンスが正常に停止しない場合、以下の手順を実行します：

強制停止の実行

• AWS Management Consoleまたはstop-instancesコマンドで強制停止を試行
• --forceオプションを使用して強制的に停止

根本原因の調査

• CloudWatchログでインスタンスの動作を確認
• システムログを確認してエラーメッセージを特定

インスタンス終了に関する問題 ​

終了保護の確認 ​

インスタンスが終了できない場合、終了保護が有効になっている可能性があります：

• インスタンスの終了保護設定を確認
• 必要に応じて終了保護を無効化してから終了を実行

到達できないインスタンス ​

ネットワーク接続の診断 ​

インスタンスに到達できない場合、以下の項目を確認します：

パブリックIPアドレスの確認

• インスタンスにパブリックIPアドレスが割り当てられていること
• Elastic IPアドレスが適切に関連付けられていること

ルートテーブルの確認

• VPCのルートテーブルが適切に設定されていること
• インターネットゲートウェイへのルートが存在すること

ネットワークACLの確認

• サブネットレベルでのネットワークACLがトラフィックを許可していること

ステータスチェックの失敗 ​

システムステータスチェック ​

システムステータスチェックが失敗する場合、AWS側のインフラストラクチャに問題がある可能性があります：

対処法

• インスタンスの停止と再起動を実行
• 問題が継続する場合は、AWSサポートに連絡

インスタンスステータスチェック ​

インスタンスステータスチェックが失敗する場合、インスタンス内の設定に問題があります：

一般的な原因

• ファイルシステムの破損
• 不適切なネットワーク設定
• カーネルの問題
• メモリ不足

EC2Rescue ツールの活用 ​

EC2Rescue for Linux ​

EC2Rescue for Linuxは、Amazon EC2 Linuxインスタンスで実行できる使いやすいオープンソースツールです：

主な機能

• 100を超えるモジュールを使用した一般的な問題の診断、トラブルシューティング、修復
• システムログとパッケージマネージャーログの収集
• リソース使用率データの収集
• 問題のあるカーネルパラメータと一般的なOpenSSHの問題の診断と修復

使用例

# EC2Rescueの実行
sudo ./ec2rl run

# 特定のモジュールの実行
sudo ./ec2rl run --only-modules=openssh

Systems Manager Automation ​

AWSSupport-TroubleshootSSH Amazon Systems Manager Automation runbookを使用することで、EC2Rescue for Linuxを自動的にインストールし、SSH接続を妨げる一般的な問題をチェックまたは修正できます。

EC2 シリアルコンソール ​

直接アクセスによる診断 ​

EC2シリアルコンソールは、ネットワーク接続に依存しない直接的なアクセス方法を提供します：

利用シーン

• SSH/RDP接続ができない場合
• ネットワーク設定の問題がある場合
• ブート問題の診断

アクセス方法

• AWS Management Consoleから「Connect」→「EC2 Serial Console」を選択
• AWS CLIを使用: aws ec2-instance-connect send-serial-console-ssh-public-key

診断割り込みの送信 ​

応答しないインスタンスの診断 ​

インスタンスが応答しない場合、診断割り込みを送信してカーネルダンプやメモリダンプを生成できます：

Linux インスタンス

• Non-Maskable Interrupt (NMI)を送信
• カーネルパニックやハングアップの診断に有効

Windows インスタンス

• ブルースクリーンを強制的に生成
• システムクラッシュの原因調査に使用

EC2 Windows固有の問題 ​

Amazon EC2 Windowsインスタンスでは、Linux環境とは異なる特有の問題が発生する可能性があります。ここではWindows特有のトラブルシューティング手法と解決策を解説します。

RDP接続の問題 ​

RDP接続トラブルシューティングの基本 ​

Windows インスタンスへのRDP接続で問題が発生する場合、AWS Systems ManagerのAWSSupport-TroubleshootRDP自動化ドキュメントを使用して、リモートデスクトッププロトコル（RDP）での接続に影響を与える可能性のある各種設定をチェックし、変更できます。

RDPサービスの確認 ​

Remote Desktop Servicesの動作確認

インスタンスでRDSが実行中であることを確認する必要があります：

1. Microsoft管理コンソール（MMC）のサービススナップイン（services.msc）を使用
2. サービスのリストで「リモートデスクトップサービス」が「実行中」であることを確認
3. サービスが停止している場合は開始し、スタートアップの種類を「自動」に設定

RDSサービスが無効化されている場合

サービスが開始された場合でも、無効になることがあります。この場合、以下の手順で対処します：

1. ルートボリュームをインスタンスからデタッチ
2. ボリュームからスナップショットを取得またはAMIを作成
3. 元のボリュームを同じアベイラビリティーゾーンの別のインスタンスにセカンダリボリュームとしてアタッチ
4. リモートレジストリを使用してリモートデスクトップを有効化
5. 完了後、元のインスタンスにルートボリュームを再アタッチ

Windowsファイアウォールの問題 ​

ファイアウォール設定の確認

Windowsファイアウォールまたは他のファイアウォールソフトウェアによって、インスタンスへのRDPトラフィックがブロックされていないことを確認します。Windowsファイアウォールを無効にし、セキュリティグループのルールを使用してインスタンスへのアクセスを制御することが推奨されます。

解決方法のオプション

以下のいずれかのオプションを試行できます：

1. AWSSupport-TroubleshootRDPを使用してSSM AgentによりWindowsファイアウォールプロファイルを無効化（インスタンスがAWS Systems Managerに設定されている必要があります）
2. AWSSupport-ExecuteEC2Rescueを使用
3. 手動でのレジストリ編集：
   • インスタンスを停止し、ルートボリュームをデタッチ
   • ボリュームをデータボリュームとして一時インスタンスにアタッチ
   • 一時インスタンスに接続し、ボリュームをオンライン化
   • データボリュームからレジストリハイブをロード
   • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicyStandardProfileで設定を変更

Windows管理者パスワードのリセット ​

EC2Configを使用したパスワードリセット ​

Windows Server 2016より前のWindows AMIを使用している場合、EC2Configエージェントを使用して新しいパスワードを生成できます。

前提条件の確認

パスワードリセットを試行する前に、EC2Configサービスがインストールされ、実行されていることを確認します：

1. Amazon EC2コンソールでインスタンスを選択
2. 「アクション」→「監視とトラブルシューティング」→「システムログを取得」を選択
3. EC2 Agentエントリ（例：「EC2 Agent: Ec2Config service v3.18.1118」）を確認
4. このエントリが表示されれば、EC2Configサービスが実行中

システムログが空の場合

システムログ出力が空の場合、またはEC2Configサービスが実行されていない場合は、インスタンスコンソールスクリーンショットサービスを使用してインスタンスをトラブルシューティングします。

EC2Launch使用時のパスワードリセット ​

Windows Server 2016以降のAMIを使用している場合は、EC2Launchを使用したパスワードリセット、またはEC2Rescueツールを使用できます。EC2RescueツールはEC2Launchサービスを使用して新しいパスワードを生成します。

Systems Manager自動化ドキュメント ​

手動手順を自動的に適用するAWS Systems Manager自動化ドキュメントが利用可能です。このドキュメントは、ローカル管理者パスワードをリセットするために必要な手動手順を自動的に適用します。

Sysprep問題のトラブルシューティング ​

Sysprepエラーの診断 ​

Amazon EC2 Windowsインスタンスからイメージを作成する際にシステム準備（Sysprep）エラーが発生した場合、以下のログを確認します：

ログファイルの場所

• %WINDIR%\Panther\Unattendgc
• %WINDIR%\System32\Sysprep\Panther
• C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt
• C:\ProgramData\Amazon\Ec2Config\Logs
• C:\ProgramData\Amazon\EC2-Windows\Launch\Log\EC2Launch.log
• %ProgramData%\Amazon\EC2Launch\log\agent.log

到達不可能なインスタンスでのログ確認 ​

Sysprepでイメージ準備中にエラーメッセージを受信した場合、OSに到達できない可能性があります。ログファイルを確認するには：

1. インスタンスを停止
2. ルートボリュームをデタッチ
3. 別のインスタンスにボリュームをアタッチしてログファイルにアクセス

AWSSupport-ExecuteEC2Rescue ​

自動化されたトラブルシューティング ​

AWSSupport-ExecuteEC2Rescue自動化ドキュメントでは、EC2Rescue for Windows Serverを使用してEC2インスタンスの接続とRDPの問題のトラブルシューティングと復元が自動的に行われます。

重要な注意事項 ​

• インスタンスの停止と再起動が必要
• Systems Manager Automationがインスタンスを停止してAmazon マシンイメージ（AMI）を作成
• インスタンスストアボリュームに保存されているデータは失われる
• Elastic IPアドレスを使用していない場合、パブリックIPアドレスが変更される

Windows起動エージェント ​

起動エージェントの設定 ​

各AWS Windows AMI（およびAWS Marketplaceで利用可能な多くのAMI）には、デフォルト設定で事前構成されたWindows起動エージェントが含まれています。起動エージェントは以下のタイミングで実行されます：

• インスタンス起動時
• インスタンスが停止後に開始された時
• インスタンスが再起動された時

EC2 Fast Launch for Windows ​

すべてのAmazon EC2 Windowsインスタンスは、標準のWindows オペレーティングシステム（OS）起動手順を経る必要があり、これには複数回の再起動が含まれ、完了まで15分以上かかることがよくあります。EC2 Fast Launch機能が有効になっているAmazon EC2 Windows Server AMIは、これらの手順と再起動の一部を事前に完了し、インスタンスの起動時間を短縮します。

Windows固有のシステム設定 ​

Windows管理者パスワードの変更 ​

Windowsインスタンスに接続する際は、インスタンスへのアクセス権限を持つユーザーアカウントとパスワードを指定する必要があります。初回接続時は管理者アカウントを使用し、デフォルトパスワードを提供する必要があります。初回接続時には、管理者パスワードをデフォルト値から変更することが推奨されます。

Windowsシステムコンポーネントの追加 ​

Windows Serverオペレーティングシステムには多くのオプションコンポーネントが含まれています。各AWS Windows Server AMIにすべてのオプションコンポーネントを含めることは実用的ではないため、Windowsインスタンスでコンポーネントを設定またはインストールするために必要なファイルを含むインストールメディアEBSスナップショットを提供しています。

WindowsでのWSLインストール ​

Windows Subsystem for Linux（WSL）は、Windowsインスタンスにインストールできる無料ダウンロードです。WSLをインストールすることで、Windowsインスタンス上で直接ネイティブLinuxコマンドラインツールを実行し、従来のWindowsデスクトップと並行してスクリプト作成にLinuxツールを使用できます。

トラブルシューティングのベストプラクティス ​

推奨事項一覧 ​

継続的な管理 ​

• 定期的なWindows Updateの適用
• セキュリティパッチの迅速な適用
• 起動エージェントの設定確認
• バックアップとスナップショットの定期作成
• Systems Managerエージェントの適切な設定

EC2 EBS関連の問題 ​

Amazon EBSボリュームに関する問題は、EC2インスタンスの運用において頻繁に発生する重要な課題です。ここではEBS関連の問題を迅速に診断し、適切な解決策を実装するためのポイントを解説します。

EBSボリュームのステータスチェック ​

ボリュームステータスチェックは、Amazon EBSボリューム上のデータの潜在的な不整合をより適切に理解、追跡、管理できるように設計された機能です。これらのチェックは、Amazon EBSボリュームが障害を起こしているかどうかを判断し、潜在的に不整合なボリュームの処理方法を制御するために必要な情報を提供します。

ステータスチェックの動作

ボリュームステータスチェックは、5分ごとに実行される自動テストで、合格または不合格のステータスを返します：

• すべてのチェックが合格: ボリュームのステータスはok
• チェックが不合格: ボリュームのステータスはimpaired
• データ不足: ステータスはinsufficient-data（チェックがまだ進行中の可能性）

I/O無効化メカニズム ​

Amazon EBSがボリュームのデータに潜在的な不整合があると判断した場合、デフォルトでは、アタッチされたEC2インスタンスからボリュームへのI/Oを無効にしてデータの破損を防ぎます。I/Oが無効になると、次のボリュームステータスチェックが失敗し、ボリュームステータスがimpairedになります。

障害のあるEBSボリュームの操作 ​

データ整合性の問題への対処 ​

ボリュームのデータが整合していない可能性があるためにボリュームに障害がある場合、以下のオプションを使用できます。

オプション1: アタッチされたボリュームでの整合性チェック

最も単純なオプションは、ボリュームがAmazon EC2にアタッチされているときに、I/Oを有効にしてからボリュームでデータの整合性チェックを実行する方法です。

手順

1. アプリケーションによるボリュームの使用を停止
2. ボリュームのI/Oを有効化
3. ボリュームのデータを確認
4. fsck（Linuxインスタンス）またはchkdsk（Windowsインスタンス）コマンドを実行
5. 関連するエラーメッセージがないか、利用可能なアプリケーションログまたはシステムログを確認

重要な注意事項

ボリュームに20分以上障害が発生した場合は、AWSサポートセンターに問い合わせることが推奨されます。

EBSボリュームサイズの問題 ​

ディスク容量不足の診断 ​

EBSボリュームの容量不足は、Webサイトやアプリケーションの停止を引き起こす重要な問題です。以下のようなエラーメッセージが表示される場合があります：

• "No space left on device"
• "Failed to write to database: Disk full"
• "Error: Could not create temp file – disk quota exceeded"

診断コマンド

df -h

このコマンドでディスク使用量を確認し、100%使用率が表示された場合は、ボリュームサイズの拡張が必要です。

EBSボリュームサイズの拡張 ​

ステップ1: AWSコンソールでのボリューム拡張

1. EC2コンソールを開く
2. ナビゲーションペインで「インスタンス」を選択し、インスタンスを選択
3. 「ストレージ」タブを選択し、ボリュームを選択
4. 「ボリューム」ペインで、拡張するボリュームのチェックボックスを選択
5. 「アクション」から「ボリュームの変更」を選択
6. 「ボリュームの詳細」で、ボリュームタイプに基づいてサイズとIOPSを入力
7. 「変更」を選択し、ダイアログボックスで「変更」を選択

ステップ2: ファイルシステムの拡張

ボリュームサイズを拡張した後、ファイルシステムも拡張する必要があります：

Linuxの場合

# ファイルシステムタイプの確認
cat /etc/fstab

# ext4ファイルシステムの場合
sudo resize2fs /dev/xvdf

# XFSファイルシステムの場合
sudo xfs_growfs /mount/point

EBSボリュームのアタッチメント問題 ​

ボリュームが認識されない問題 ​

新しくアタッチしたEBSボリュームがインスタンス内で認識されない場合、以下の手順で対処します：

ブロックデバイスの確認

lsblk

ボリュームのフォーマット

# ファイルシステムの作成（ext4の場合）
sudo mkfs -t ext4 /dev/xvdf

# マウントポイントの作成
sudo mkdir /data

# ボリュームのマウント
sudo mount /dev/xvdf /data

永続的なマウントの設定

# /etc/fstabに追加
echo '/dev/xvdf /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

ルートボリュームと追加ボリュームの区別 ​

多くのユーザーが混同する問題として、ルートボリューム（通常8GB）と追加でアタッチしたEBSボリュームの区別があります。

典型的な状況

• /dev/xvda1: ルートボリューム（8GB、100%使用）
• /dev/xvdf: 追加ボリューム（200GB、5%使用）

この場合、追加ボリュームは利用可能ですが、ルートボリュームの容量不足が問題となっています。

EBSボリュームのパフォーマンス問題 ​

IOPSとスループットの最適化 ​

EBSボリュームのパフォーマンス問題は、以下の要因で発生する可能性があります：

ボリュームタイプの不適切な選択

• 高IOPS要件にgp2を使用
• 大容量データ転送にio1を使用

インスタンスタイプの制限

• EBS最適化が無効
• インスタンスのネットワーク帯域幅制限

パフォーマンス監視 ​

CloudWatchメトリクス

• VolumeReadOps/VolumeWriteOps
• VolumeReadBytes/VolumeWriteBytes
• VolumeTotalReadTime/VolumeTotalWriteTime
• VolumeQueueLength

EBSスナップショット関連の問題 ​

スナップショット作成の失敗 ​

スナップショット作成が失敗する主な原因：

権限不足

• IAMポリシーでスナップショット作成権限が不足
• KMS暗号化キーへのアクセス権限不足

ボリュームの状態

• ボリュームがimpaired状態
• 大量のI/O処理中

スナップショットからの復元問題 ​

暗号化の不整合

• 暗号化されたスナップショットから非暗号化ボリュームを作成しようとする
• 異なるKMSキーでの暗号化

EBS問題のトラブルシューティング手順 ​

段階的診断アプローチ ​

予防的措置 ​

監視とアラート

• CloudWatchアラームでディスク使用率監視
• 80%使用率でアラート設定
• 定期的なボリュームステータスチェック

バックアップ戦略

• 定期的なスナップショット作成
• クロスリージョンスナップショットコピー
• 自動スナップショット管理（DLM）の活用

容量計画

• 成長予測に基づく容量計画
• 自動スケーリング戦略の検討
• 適切なボリュームタイプの選択

ベストプラクティス ​

運用管理 ​

定期的なメンテナンス

• ファイルシステムの定期チェック
• 不要ファイルの削除
• ログローテーションの設定

パフォーマンス最適化

• 適切なボリュームタイプの選択
• EBS最適化インスタンスの使用
• プロビジョンドIOPSの適切な設定

災害復旧

• 定期的なスナップショット作成
• 復旧手順の文書化とテスト
• マルチAZ構成での冗長化

参考：

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-troubleshoot.html
• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
• https://docs.amazonaws.cn/en_us/AWSEC2/latest/UserGuide/Linux-Server-EC2Rescue.html
• https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-troubleshoot.html
• https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-connection-troubleshooting/
• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-ts-common-issues.html