はじめに
本書の目的
本ドキュメントは、AWS環境で発生する代表的な障害に対する現場での対応例を分かりやすくまとめたものです。EC2の内部調査、S3とLambdaを対象としたセルフサービス型トラブルシューティング、そしてECSタスクが予期せず停止する問題について、原因の探し方や実際に行った修復手順を具体的に示します。
対象読者
AWSを運用しているエンジニアや運用担当者、またはトラブル対応の手順を学びたい方を想定しています。クラウドの基本概念は知っている前提で、専門用語はできるだけ噛み砕いて説明します。
範囲と前提
対象は主にAWS上のEC2、S3、Lambda、ECSに関する典型的な障害です。個別の環境差異や権限設定に依存する事項は、注意点として補足します。実行するコマンドや手順は安全性を重視した例として提示します。
本書の構成
各章は以下の流れで進めます：問題の背景、使用したツールや手法、実施した修復手順、得られた成果と利点。手順は可能な限り再現性を意識して記載します。
利用上の注意
ここで示す手順は一例です。環境に応じて事前バックアップや適切な権限付与を行ってください。万が一分からない点があれば、ログや監視データを元に段階的に原因を絞り込むことをおすすめします。
Amazon Q Developer を使用した EC2 内部トラブルシューティング
概要
ALBのヘルスチェックがFailedになり、Webサーバへアクセスできない問題をAmazon Q Developerで診断・修復した事例を紹介します。ログイン不要で迅速に調査・修復を実行し、約2〜3分で復旧しました。
発生時の状況確認
- ALBのターゲットヘルスで対象インスタンスが”Unhealthy”になっていることを確認します。
- Amazon Q Developerからの指示で、AWS Systems ManagerのRun Command（AWS-RunShellScript）を使い、該当インスタンス上で以下を実行しました。
- curl -I http://localhost:80 （ローカルHTTP応答確認）
- sudo systemctl status nginx（プロセス確認）
- sudo nginx -t（設定ファイルの文法チェック）
よくある原因と対策（実例）
- 設定ミス
- nginxの仮想ホスト設定でヘルスチェックパス（例:/health）が存在しない、あるいは403/404を返している場合があります。設定ファイルを修正し、nginx -tで問題が無いことを確認してから再起動します。
-
実行例: sudo sed -i ‘s|return 404;|return 200;|’ /etc/nginx/conf.d/health.conf
-
サービスが落ちている
-
nginxやアプリが停止しているとヘルスチェックは失敗します。systemctl start nginxで起動し、statusで確認します。
-
ファイアウォールやSELinux
- ローカルのiptables/firewalldでポート80がブロックされていると外部からのヘルスチェックは通りません。sudo firewall-cmd –add-port=80/tcp –permanentなどで開けます。SELinux設定で拒否されるケースもあります。
自動化した修復手順（Run Commandの例）
- 事前チェック: curlでヘルスパスのHTTPステータスを取得します。
- 設定修正: 必要箇所をsedで編集し、nginx -tで文法チェック。
- 再起動: sudo systemctl restart nginx
- 監視ループ: 10秒間隔でcurlを繰り返し、Healthyに戻ったら終了
スクリプトをRun Commandで実行すると、SSHログイン不要で複数インスタンスに一括適用できます。復旧までの時間は設定修正と再起動で概ね2〜3分でした。
注意点
- 設定変更は必ず文法チェック（nginx -t）を行ってください。誤った再起動はサービス停止を長引かせます。
- 変更はインフラ管理者と共有し、必要なら事前にバックアップを取ってください。
以上がAmazon Q Developerを活用したEC2内部のトラブルシューティング事例の実務的な流れです。
AWS SAW によるセルフサービストラブルシューティング（S3 と Lambda）
概要
AWS SAW（Support Automation Workflows）は、よくある設定ミスや権限問題を自動で検出・修復する仕組みです。本章ではAmazon S3とAWS Lambdaに焦点を当て、現場で使える４つのワークフローを解説します。
対象の自動化ワークフロー
- S3の公開読み取り権限問題：バケットやオブジェクトが意図せず公開になっていないか検出し、必要に応じてACLやポリシーを修正します。例：社内資料が公開になっていた場合、検出して非公開に戻します。
- 同一アカウント内のS3アクセス権限問題：同一アカウント内のロールやユーザーからのアクセス失敗を診断し、想定される原因（バケットポリシーやKMS制約）を提示します。
- LambdaとS3イベント連携問題：S3イベントがLambdaへ届かないとき、イベント通知設定、フィルタ、権限の不一致を自動チェックします。
- Lambdaのインターネットアクセス問題：Lambdaから外部APIにアクセスできない場合、VPC設定やサブネットのルート、NATの有無を確認します。
実行モードと権限管理
検出モードと修復モードを選べます。検出のみで安全に調査し、問題を確認してから修復を実行する運用が可能です。修復はSSMオートメーションロール経由で行うため、必要最小限のAPI権限だけを付与できます。
利用手順（簡易）
- SAWコンソールでワークフローを選択します。2. 対象リソース（バケット名や関数名）を指定します。3. 検出モードで結果を確認し、承認して修復モードを実行します。
期待できる効果
機械的なチェックでヒューマンエラーを減らし、担当者の作業時間を短縮します。サポート対応時間の短縮や問題解決までの時間短縮が見込めます。
Amazon ECS タスク停止問題のトラブルシューティング
概要
Amazon ECSでタスクが繰り返し停止する場合、原因を順に潰すことで早く復旧できます。本章では、現場でよくある原因と実践的な対処手順を分かりやすく説明します。
よくある原因（具体例）
- ターゲットグループのリクエストタイムアウト：アプリが応答に30秒かかるのにALBのタイムアウトが15秒だと切断されます。
- ヘルスチェック失敗：ヘルスチェックのパスやタイムアウトが短く、起動直後に不合格になります。
- コンテナのブートストラップ時間不足：アプリ初期化に時間がかかると、ヘルスチェックやデプロイが失敗します。
トラブルシューティング手順（実践）
- ECSコンソールのサービス→イベントを確認し、停止理由を取得します。
- タスク詳細で「Stopped reason」やコンテナのログを確認します。CloudWatch Logsに出力しているかを確認してください。
- ALBのターゲットグループでヘルスチェックのパス、間隔、タイムアウトを確認・調整します。例：アプリ起動30秒ならタイムアウト10秒、間隔10秒、許容失敗数3にします。
- サービスのhealthCheckGracePeriodSecondsを延長し、起動猶予を与えます。短いと起動中に判定されます。
- コンテナの起動スクリプトを見直し、不要な初期処理を遅延させるか最適化します。
- 変更後は少数のタスクでデプロイして動作を確認し、ALB経由で疎通テストを行います。
補足
ログとイベントを最初に見る習慣をつけると原因特定が早まります。AWSナレッジセンターの関連記事も参考にしてください。したがって、まずはイベントとログの確認から始めることをおすすめします。
