【2026年7月16日】AWSで広範囲の障害|EC2・S3・DynamoDBなどの影響と確認方法

2026年7月16日、AWS Health Dashboardでは、複数のAWSサービスについてエラー率の上昇や可用性低下が発生していると案内されています。公式表示ではAmazon EC2、Amazon S3、Amazon DynamoDB、AWS Lambda、Amazon Kinesis、Amazon CloudWatch、Amazon RDS、AWS Management Console、AWS CLIなどが影響対象として挙げられています。

AWS上で稼働する業務システムは、同じクラウドを利用していても、使用リージョン、構成、キャッシュ、外部連携先によって影響の出方が異なります。ログインできない、画面が開かない、APIが失敗する、ファイル処理が止まるといった症状だけで、自社の設定ミスと決めつけないことが重要です。

AWS側の障害かを最初に切り分ける

1. 使っているAWSリージョンを確認する
   コンソール右上のリージョン表示、構成管理表、CloudWatchや障害通知の記録から、対象システムがどのリージョンで動いているかを確認します。
2. AWS Health Dashboardの最新表示を見る
   AWS Health Dashboardで、サービス名・リージョン・更新時刻を照合します。アカウント固有の影響は、ログイン後のAWS Health Dashboardにも表示されることがあります。
3. 自社側のエラー情報を残す
   発生時刻、画面のエラー文、HTTPステータス、AWSサービス名、リージョン、リクエストIDを記録します。復旧後に同じ操作を試す場合も、比較できる情報が残ります。
4. 影響範囲を業務単位で確認する
   ログイン、受注、ファイル保存、バッチ処理、通知、外部連携などを分け、止まっている機能と動く機能を社内へ共有します。

症状ごとの確認先

業務担当者が避けるべき対応

障害時は、何度も送信ボタンを押したり、処理を繰り返し実行したりすると、復旧後に重複登録や二重請求につながることがあります。受注、決済、在庫、ファイル更新などの処理は、再実行前にシステム担当者へ確認してください。

また、アクセスできないことを理由に、IAM権限、セキュリティグループ、DNS、ネットワーク設定を個人判断で変更するのは危険です。障害の影響なのか、自社設定の変更によるものなのかが分からなくなり、復旧を遅らせるおそれがあります。

復旧が見え始めた後の確認

AWSの公式表示が改善しても、自社サービスの処理待ちや再試行キュー、外部連携先の復旧には時間差が出ることがあります。まず読み取り系の画面、次に新規登録、最後に定期処理や外部連携の順で確認すると、業務影響を整理しやすくなります。

障害の前後で失敗した処理は、再実行の前に一覧化してください。処理ID、顧客番号、注文番号などの機微情報を外部へ共有せず、社内の障害対応チャンネルやチケットに必要最小限の情報を記録します。

社内や取引先へ共有する内容

AWSを直接管理していない業務担当者でも、障害時に「どの画面が使えないか」「いつから発生しているか」「代替作業が必要か」を簡潔に共有すると、システム担当者が判断しやすくなります。原因を推測して断定するより、確認できた事実と未確認事項を分けることが大切です。

外部の取引先へ連絡する場合は、自社の窓口ルールに従ってください。AWSの障害情報をそのまま転記するのではなく、自社サービスへの影響、注文・納品・連携処理で相手に必要な行動、次回案内時刻を明確にすると混乱を抑えられます。

復旧後に残すべき記録

復旧後は、いつ通常処理へ戻したか、どの処理を保留・再実行したかを記録します。障害中に手作業で受け付けた依頼や、利用者へ案内した代替手段も一覧に残してください。次回の同種障害で、二重登録を避ける手順や連絡先の優先順位をすばやく判断できます。

クラウド障害そのものを利用者が防ぐことはできませんが、リージョン、依存サービス、連絡経路、手作業へ切り替える条件を平時から整理しておくことは可能です。今回の対応記録は、業務継続計画や障害時の社内手順を見直す材料として活用してください。

よくある質問

Q. AWSの障害なら、自社で何もしなくてよいですか。
A. AWS側の復旧を待つだけではなく、自社の影響範囲、失敗処理、利用リージョンを確認する必要があります。設定変更や再実行は、担当者の判断で進めてください。

Q. AWS Health Dashboardに表示がない場合はAWS障害ではありませんか。
A. アカウント固有の情報や反映の時間差もあるため、直ちに否定はできません。自社のCloudWatch、アプリケーションログ、ネットワーク状況も併せて確認します。

まとめ

AWSで広い範囲の障害が報告されると、EC2、S3、DynamoDB、Lambdaなどを使う業務システムにも影響が及ぶ可能性があります。まず公式Health Dashboardでサービスとリージョンを照合し、自社側ではエラー時刻と影響範囲を記録してください。復旧途中の再実行や設定変更は、重複処理や別の障害を招くことがあるため、運用ルールに沿って進めることが大切です。