はじめに
目的
本記事は、2025年10月時点におけるAWSの「停止」に関する主要な情報をわかりやすく整理することを目的とします。サービスの廃止や新規受付停止、リソース停止の管理、過去の大規模障害例、運用や移行のポイントまでを網羅的に扱います。AWS利用者がリスクに備える参考資料として作成しています。
対象読者
- AWSを日常的に利用しているエンジニアや運用担当者
- 今後クラウド移行や見直しを検討する企画担当者
- 導入直後で障害対策や終了対応を知りたい方
本記事の範囲と注意点
内容は当初の依頼範囲に沿ってまとめています。具体的には、サポート終了や新規受付停止情報、EC2などのリソース停止管理とリスク、過去の大規模障害事例と影響、運用・移行のポイント、最後に最新動向の総括を扱います。記載は一般的なガイドであり、個別の契約や法的判断は別途確認してください。
読み進め方
各章は独立して読めるように構成しています。まず第2章で該当するサービスの停止情報を確認し、第3章以降で具体的な対応策や事例を参照してください。必要に応じて目次代わりに章見出しを戻ってご利用ください。
AWSサービスのサポート終了・新規受付停止情報
概要
AWSは2024〜2026年にかけて複数のサービスでサポート終了や新規受付停止を発表しています。該当サービスにはAWS RoboMaker（終了：2025/9/10）、AWS WAF Classic（終了：2025/9/30）、AWS App Mesh（終了：2026/9/30、2024/9/24以降新規受付停止）、Cloud9、CodeCommit、S3 Selectなどが含まれます。利用中のサービスがあれば影響範囲を早めに確認してください。
対象サービスと期限の例
- AWS RoboMaker：2025年9月10日終了
- AWS WAF Classic：2025年9月30日終了
- AWS App Mesh：2026年9月30日終了（2024/9/24以降は新規受付停止）
その他、Cloud9やCodeCommit、S3 Selectなども対象に含まれる可能性があります。
影響の見きわめ方
- 利用状況の棚卸し：どのアカウント／リージョンで使っているかを洗い出します。2. 依存関係の把握：アプリケーションや自動化ツール、CI/CDが影響を受けるか確認します。3. 優先度の判定：ビジネス影響が大きいものから対応計画を立てます。
移行検討のポイント
- 後継サービスや代替案の検討：マネージドの新サービスやオープンソースを比較してください。- テストと段階的な移行：いきなり本番切替せず、検証環境で動作確認を行います。- 自動化の更新：デプロイや監視のスクリプトを忘れずに修正します。
よくある対応例
- WAF Classic利用：新しいWAFや他社WAFへルールを移行する。- 開発環境（Cloud9）利用：ローカルIDEや別のクラウドIDEへ切替える。
期限は厳守されますので、早めに棚卸しと移行計画の作成をおすすめします。
AWSリソース（EC2等）の停止管理とリスク
概要
EC2などを「停止」したまま放置すると、運用コストやセキュリティ面で意外な問題が発生します。本章では代表的なリスクと、実務で取れる管理策をわかりやすく説明します。
主なリスク
- コストの継続発生：停止中でもEBS（ディスク）は残り、料金がかかります。複数インスタンスで累積すると無駄な支出になります。
- セキュリティの脆弱性：停止中はOSやミドルウェアの自動更新が適用されないことが多く、既知の脆弱性が放置されます。また、誤って起動されると未パッチの状態で公開される危険があります。
- 運用の複雑化：停止リソースが増えると在庫管理が難しくなり、どれが本番でどれが不要か分からなくなります。設定差（構成ドリフト）も起こりやすいです。
推奨対策
- 定期確認と削除ポリシー：停止したインスタンスに保有期間を決め、不要なら削除します。タグで所有者や用途を明示すると管理しやすくなります。
- 自動化の活用：スケジュール停止・起動や、一定期間停止で通知・削除する自動処理を導入します（例：Lambdaやスケジュール機能）。
- セキュリティ検査：AWS Security HubやConfigで停止中リソースのチェックルールを設定し、未パッチや不要リソースを検知します。ログやアラートで担当者に通知する運用を整えます。
- バックアップと権限管理：重要データはスナップショットで保護し、無意味な保持を減らすためにIAMで削除や起動の権限を最小化します。
実践ポイント（例）
- 月次で“停止リスト”を出力し、オーナーに確認を求める。不要ならスナップショット後に削除します。
- 停止から30日で自動通知、60日で自動削除などルール化すると運用負荷を下げられます。
以上を組み合わせることで、停止リソースによる無駄なコストやセキュリティリスクを低減できます。
AWSの大規模障害（サービス停止）事例と影響
発生概要
2025年10月20日、US-East-1リージョンで大規模なサービス停止が発生しました。多くのオンラインサービスがアクセス不能となり、復旧まで約15時間を要しました。影響は北米を中心に広がり、EC2、SQS、Lambda、ロードバランサー（ALB/ELB）などの主要サービスで停止や機能不全が発生しました。
障害の原因と連鎖的問題
AWS側の複数の要素に問題が重なり、単独の故障が波及しました。制御プレーンや内部管理処理で異常が起き、これが他のサービスの正常な起動や通信に影響を与えました。復旧作業中、EC2やロードバランサーの新規起動を制限する緊急措置が取られ、これが一時的に復旧を遅らせました。
影響の具体例
- WebサイトやAPIが応答しなくなり、ユーザーが利用できない状態になった
- メッセージキュー（SQS）で処理の遅延や滞留が発生した
- サーバーレス（Lambda）がトリガーされず、バッチ処理やイベント処理が停止した
AWSの緊急対応と復旧作業
AWSは段階的に障害箇所を特定し、制限措置や再配置を行いました。新規リソースの起動制限や手動介入で影響拡大を抑えつつ、順次サービスを復旧しました。結果として復旧完了まで長時間を要しました。
事業者が取るべき対策（短期〜中期）
- マルチリージョン構成でフェイルオーバーを用意する
- キューやバックプレッシャーに耐える設計にする（再試行やバックオフ）
- 容量の余裕と緊急時の代替ルートを準備する
- 障害時の手順書（Runbook）と定期的なフェイルオーバー検証を行う
- 監視で早期検知し、利用者への影響を最小化する手順を整備する
以上が、今回の大規模障害の主な事例と事業者にとって重要な影響・対策です。
AWS停止関連の運用・移行のポイント
1) 早めの調査と在庫化
停止予定や停止状態のリソースをまず洗い出します。例：停止中のEC2、未使用のEBS、古いS3バケット。AWS Security HubやConfigで状態を集約し、タグ付けで所有者と用途を明確にします。
2) 自動検出と整理のポリシー
未使用リソースを自動検出するルールを設定します。定期スキャンで“一定期間アクセスなし”や“停止状態”を検出し、通知→保留→削除のワークフローを作成します。例：30日アクセスなしで保留、さらに30日で削除。
3) 移行計画の作成
後継サービスへ段階移行します。まずテスト環境で移行手順を検証し、データ互換性と切替手順を文書化します。ロールバック手順も必ず用意します。
4) 事業継続（BCP）対策
重要サービスは冗長化とマルチリージョン配置で耐障害性を高めます。クロスアカウントのバックアップや定期的なDR訓練（フェイルオーバー検証）を実施します。
5) 運用自動化と監視
アラートと実行可能なRunbookを用意し、障害時は自動復旧やスクリプトで対応します。コストアラートも設定して不要な支出を抑えます。
6) コミュニケーションと権限管理
移行スケジュールと影響範囲を関係者へ共有し、アクセス権は最小権限にします。手順書と連絡網を用意して影響を最小化します。
まとめと最新動向
まとめ
本書で扱った停止・廃止・障害のリスクは、計画的な確認と運用の強化で大幅に軽減できます。重要なのは公式情報の定期確認、リソースの棚卸し、バックアップと復旧手順の整備、そして障害想定の検証です。2024〜2026年に複数サービスのサポート終了が予定されるため、早めの対応が安全です。
最新動向と推奨対応
- 情報収集：AWSのサービスアナウンスとPersonal Health Dashboardを定期確認してください。
- 運用強化：IaC（インフラ自動化）と監視を導入し、手作業を減らします。
- 移行準備：サポート終了対象は優先順位を付け、段階的に移行計画を作ります。
- 可用性対策：バックアップ、リージョン分散、フェイルオーバーテストを実施します。
- コストと契約：移行に伴うコスト見積りとサポート契約の確認を忘れないでください。
適切な準備と定期的な見直しで、停止リスクを最小化できます。必要な対応を早めに始めることをおすすめします。
