画像は Gemini 2.5 Flash で作成した サーバーのお化けです。 

自己紹介 赤池 悠 (あかいけ はるか) 　1998/07/29生まれ 所属：クラスメソッド株式会社 　　　クラウド事業本部コンサルティング部 ブログ：https://dev.classmethod.jp/author/akaike/ Twitter：@lamaglama39 最近怖かった出来事： 自宅のProxmoxクラスターが突然めっちゃ不安定になっ て、私の心も不安定になりました。 （再起動したら直りました） 

これは前職で私が 
 実際に経験したお話しです…。 

私が担当していたシステム、および環境 ● Direct Connectでの オンプレミス ↔ AWS 接続 ● 複数システム共通VPC + AWSサービス別サブネット 

その日私がやっていた作業 ● 新規システム用のDirect Connect + AWSリソースの作成作業 ● 人生初Direct Connectに胸を躍らせる 

起きた事件。 

それは唐突に起きました。 私が作業を完了させてから約 1時間後に既存のDirectConnectが突如ダウンし、 オンプレから既存システムへの通信がすべてダウン …。 

それは唐突に起きました。 ● 障害状況 ○ 既存DirectConnectのステータスがダウン ○ オンプレから既存システムへの疎通NG ● 騒然とする現場 ○ 大量の障害検知に対応する運用部門 ○ 各システムのアプリ担当者からの問い合わせ ○ いつになく殺気立つPM (普段は仏) ● 調査に駆り出される私 ○ 直前でDirectConnectに関連する作業を実施していたため、逃れられない (別回線の作業だから俺は絶対関係ないだろ… と思いながら調査したのはここだけの秘密です。) ○ AWSサポートにて電話しながらの調査実施 

第1の障害原因 
 AWS Direct Connect ロケーション 
 

第1の障害原因はなんだったのか。 「AWS Direct Connect ロケーション側の問題」により障害が発生していた。 

無事解消するまでの話。 ● AWSサポートとのやり取り ○ 「AWS側での障害は確認していない」との回答 ○ AWS上でそれらしい障害原因が見つからないため、 それ以上調査が進まない… ● 回線事業者への問い合わせと連絡 ○ マネージャー陣によって別途回線事業者へ問い合わせ ○ AWS Direct Connect ロケーション側で問題が発生していたことが判明 ○ しばらくした後、Direct Connectのステータスがアップし、 回線事業者からも復旧の連絡があった ○ オンプレから各システムへの疎通もOK 

すべて解消した！ 
 そう思われていたが…。 
 

障害はまだまだ終わらない…。 なぜか特定のサブネット上のリソースだけ、疎通が通らない …。 

障害はまだまだ終わらない…。 ● 障害状況 ○ オンプレミスから特定のサブネットへの疎通だけ通らない ○ それ以外のサブネットへは、正常に疎通できる ● 疲弊し始める現場 ○ ほっと一息ついた10分後には、おかわり障害対応 ○ 困惑するPM ● 引き続き調査に駆り出される私 ○ これにより、ほぼまるまる1日の障害対応が確定 ○ とりあえずネットワーク周りの設定から調査し始めた 

第2の障害原因 
 ヒューマンエラー 
 

第1の障害の裏側で起きていたこと。 エンジニア〇〇さんが、 新規システム向けにサブネットなどのリソースを作成していた。 (マネジメントコンソールから手動作業) 

第1の障害の裏側で起きていたこと。 オンプレミス向けのRoute Tableは各サブネット共通で利用しており、 新規サブネットに関連づける際に、誤って既存のサブネットの関連付けを解除してしまった。 

無事解消するまでの話。 ● 調査方法 ○ 問題のサブネットにルートテーブルが関連づけられていないことを確認 ○ CloudTrail + Configにて、 該当のサブネットとルートテーブルの設定履歴を確認 ● 解消方法 ○ サブネットにルートテーブルを関連付け ○ 無事疎通が通るようになり、障害解消 

結論
 人間が一番の単一障害点 
 

どう対策するべきか。 ● 作業プロセスの改善 ○ 事前準備の強化 ■ 作業前にシステム全体の依存関係を図式化し、影響範囲を明確化 ○ 作業手順の標準化 ■ チェックリスト形式の作業手順書を作成し、確認すべき項目を明文化 ■ 重要な設定変更は、作業前後の状態を必ず記録 

どう対策するべきか。 ● 監視・検知体制の構築 ○ 疎通確認の自動化 ■ 各サブネットからオンプレミスへの疎通を定期的に自動チェック （スクリプト、Network Synthetic Monitorなど） ● 作業体制の見直し ○ 複数人での相互確認 ■ 重要なインフラ作業は必ず複数人でレビュー ■ 設定変更前後の状態を相互確認する体制を作る ○ 段階的作業とロールバック準備 ■ 作業を小さな単位に分割し、各段階で動作確認を実施 ■ 即座に元の状態に戻せるよう、作業前の設定を必ず保存 

どう対策するべきか。 ● 技術的な対策 ○ Infrastructure as Code（IaC）の活用 ■ TerraformなどのIaCを使用して設定を管理し、 手動での設定ミスを防止 ■ 変更履歴も自動的に管理 ○ 作業時の権限の最小化 ■ 作業に必要最小限の権限のみを付与 ■ 重要な設定変更には承認フローを組み込む 

ありがとうございました。 作業ミスに気をつけて、 用法用量を守って正しくAWSを利用しましょ う。