AWS の東京リージョン（ap-northeast-1）の Amazon EC2 で、2026年11月12日の未明に API エラー率の上昇と、新規インスタンスの起動失敗が発生しました。影響は主に単一のアベイラビリティゾーン（apne1-az1）に集中し、AWS の最終報告では 11-12 05:31 JST に完全復旧しています（status 0 = RESOLVED）。主な時間帯から数えると約5.7時間の障害でした。稼働中の EC2 インスタンスと既存のワークフローには影響はなかった、というのがこの件の要点です。

WHAT HAPPENED (RESOLVED)AWS 公式の最終報告（2026-11-12 復旧済み）

東京リージョンの EC2 でAPI エラーと起動失敗、apne1-az1 中心

  1. 対象

    Amazon EC2・リージョン Tokyo（ap-northeast-1）。主に単一 AZ（apne1-az1）

  2. いつ

    11-11 23:46 〜 11-12 02:46 JST が主な時間帯。接続問題は 05:31 JST に完全復旧

  3. 症状

    API エラー率の上昇と、新規インスタンス等の起動失敗。稼働中のものは影響なし

  4. 結果

    根本原因を特定して緩和。status 0（RESOLVED）で解決

出典: AWS Health の解決時イベント（ec2-ap-northeast-1 = RESOLVED、2026-11-12 取得）。時刻は UTC を JST に換算

30秒でわかる（復旧済み・2026-11-12）

  • ・何が：AWS 東京リージョン（ap-northeast-1）の EC2 で API エラー増加・起動失敗。主に apne1-az1 に集中
  • ・いつ：主な時間帯は 11-11 23:46 〜 11-12 02:46 JST。接続問題を含め 05:31 JST に完全復旧
  • ・影響：新規の EC2 起動・ECS/Fargate タスク・ELB プロビジョニング・NAT Gateway 作成など。稼働中インスタンスは無事
  • ・教訓：正常な AZ（apne1-az2 / apne1-az3）で新規起動できた。マルチ AZ 設計が効く

この記事は AWS 公式 Health のイベントデータ（第三者トラッカーではなく AWS 自身の出力）を根拠にしています。依存先のクラウドが落ちたときの備え方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 とは論点が違いますが、単一障害点を減らす設計の発想は共通します。

復旧までの経過（AWS 最終報告）

AWS の解決時の報告（日本語・英語の両方）をまとめると、次の流れでした。

時刻（JST） 内容
11-11 23:46 API エラー率の上昇と起動失敗が発生（主に apne1-az1）
11-12 00:47 根本原因を特定し、緩和策の実施を開始
11-12 02:46 API が広範に回復。新規 EC2 起動が成功するように
11-12 02:46〜 apne1-az1 の新規起動インスタンスで接続の問題（同一の根本原因）
11-12 04:51 接続問題の回復の最初の兆候
11-12 05:31 接続問題も完全復旧。解決（status 0）

出典: AWS Health の解決時イベント（ec2-ap-northeast-1 が status 0 = RESOLVED、2026-11-12 取得）

AWS の最初の告知は 11-12 00:40 JST で、「AP-NORTHEAST-1 リージョンで API エラー率の上昇と起動失敗が起きていて、起動失敗は単一の AZ（apne1-az1）に集中している。原因の特定と緩和を進めている」というものでした。API は 02:46 JST にいったん広く回復しましたが、その後に apne1-az1 の新規起動インスタンスの接続問題（最初と同じ根本原因）が残り、これが 05:31 JST に解消して全体の解決となりました。

ここで時刻が2つ出てきます。初回の Health イベントが掲示された 00:40 JST と、最終報告が障害の発生時刻とした 23:46 JST です。約54分の差があります。これは、AWS が後からまとめた最終報告で「症状が始まった時刻」を 23:46 JST とした一方、公式イベントとして最初に掲示されたのが 00:40 JST だった、という違いです。AWS はこの差の理由を明記していないため、本記事では両方を併記します（経過は 23:46 JST 起点、公式イベントの初出は 00:40 JST）。

何に影響し、何に影響しなかったか

影響が出たのは、新しく作る・変える操作です。

IMPACTED SERVICES公式が「影響あり」とした東京リージョンの8サービス

ネットワークとコンテナ基盤に影響。まず AZ を確かめる

  1. 1.コンテナ・サーバーレス

    Amazon ECS・AWS Fargate。タスクやインスタンスの新規起動が失敗しうる

  2. 2.ネットワーク

    AWS NAT Gateway・VPCE PrivateLink・Traffic Mirroring・Reachability Analyzer

  3. 3.ロードバランサ・小規模サーバー

    Amazon Elastic Load Balancing・Amazon Lightsail

  4. 4.まず確かめること

    自分のリソースが apne1-az1 に偏っていないか。新規起動は別の AZ で試す。既存の稼働中インスタンスは動き続けることが多い

出典: AWS Health の現在イベントの impacted_services（2026-11-12 01:00 JST 時点）。AZ 名の対応は環境ごとに異なる
  • 影響したもの：新規 EC2 の起動、Amazon ECS・AWS Fargate のタスク起動、Elastic Load Balancing のプロビジョニング遅延、NAT Gateway の作成・関連付け解除、Managed Flink の状態遷移の遅延。公式は東京リージョンの NAT Gateway・VPCE PrivateLink・Traffic Mirroring・ELB・ECS・Reachability Analyzer・Lightsail・Fargate の8サービスを影響ありとしていました。
  • 影響しなかったもの：稼働中の EC2 インスタンス、インスタンス間の接続、障害前に起動したインスタンスへの接続。すでに動いているものは、おおむね動き続けました。

この間、影響 AZ では EC2・EBS のヘルスデータが欠損・遅延し、CloudWatch アラームが INSUFFICIENT_DATA に、DescribeInstanceStatus が Insufficient Data を返しました。「アラームが鳴らない／状態が取れない」こと自体が、障害のサインになっていた形です。

監視データ自体が欠けたとき——何を信じるか

今回のように、AWS 側のヘルスデータが欠損し、アラームが「異常」ではなく「データなし（INSUFFICIENT_DATA）」になることがあります。StatusCheckFailed や CloudWatch アラームは、正常を示しているのではなく、判断の材料そのものが来ていない状態です。これを「問題なし」と読むと、障害を見逃します。

こういうときに頼れるのは、AWS のメトリクスとは別の経路で「実際に使えているか」を見る指標です。

  • 外形監視（Synthetic Monitoring）：利用者と同じようにエンドポイントへアクセスし、応答とレイテンシを測る。AWS 内部のヘルスデータに依存しない
  • アプリ側の実利用の指標：ログインや注文の成功率、エラー率など、アプリが自分で出す数字
  • ロードバランサの実観測：ALB の HTTPCode_Target_5XX・TargetResponseTime など、実トラフィックに基づくもの
  • 複数ソースの突き合わせ：1つのメトリクスだけで判断せず、外形監視・アプリ指標・AWS メトリクスの食い違いで異常を察知する

INSUFFICIENT_DATA を「異常」側に寄せてアラートする設計（CloudWatch アラームの欠損データの扱いを breaching にする）も有効です。監視が沈黙したときに気づける仕掛けを、先に入れておきます。

どこで起きたか——リージョンと AZ で整理する

場所を階層で見ると、影響は東京リージョン（ap-northeast-1）だけで、その中でも起動失敗は1つの AZ（apne1-az1）に集中していました。

階層 今回の範囲
AWS 全体 東京リージョン以外は、この件の対象外
東京リージョン（ap-northeast-1） EC2 で API エラー率の上昇と起動失敗。影響は前掲の8サービス
AZ（4つのうち） 主に apne1-az1。正常な apne1-az2・apne1-az3 では新規起動ができた
既存の稼働 稼働中インスタンス・既存の接続は影響なし

ひとことで言うと、「東京リージョンの、特定の1区画（apne1-az1）で、新しく立てる操作が失敗しやすい」障害でした。だからこそ、複数の AZ に分けておく設計が効きます。

次に単一AZ障害が起きたら——確認の順番

今回は復旧済みですが、同じ型の障害は繰り返します。自分の環境が単一 AZ に偏っていないかを確かめる手順です。

WHAT TO CHECKどこを確認するか（順番に）

東京か → どの AZ が apne1-az1 か → 別 AZ で起動

  1. 1

    東京リージョンを使っているか

    ap-northeast-1 を使っていなければ基本は無関係。コンソール右上のリージョンと稼働中インスタンスを確認

  2. 2

    自分の apne1-az1 はどの AZ か

    「1a / 1c」の表示名と apne1-az1 の対応はアカウントごとに違う。describe-availability-zones の ZoneId で突き合わせる

  3. 3

    新規起動は別の AZ で

    Auto Scaling・ECS/Fargate・新規 EC2 が失敗するなら、2 で分かった AZ を外して別の AZ を指定する

  4. 4

    動いているものは触らない／公式で追う

    再起動は戻せない恐れ。最新は AWS Health Dashboard とアカウント個別の Health イベントで

出典: AWS Health の記載（apne1-az1 集中）をもとにした手順。ZoneId と ZoneName の対応はアカウントごとに異なる

① 東京リージョンを使っているか。 ap-northeast-1 を使っていなければ、基本は無関係です。稼働中のインスタンスと、その AZ を一覧で見ます。

aws ec2 describe-instances --region ap-northeast-1 \
  --query 'Reservations[].Instances[].{id:InstanceId,az:Placement.AvailabilityZone,state:State.Name}' \
  --output table

② 問題の AZ が、自分のどの AZ か。 要点です。コンソールに出る「ap-northeast-1a / 1c / 1d」という名前と、AWS が言う apne1-az1 の対応はアカウントごとに違います。ID で突き合わせます。

aws ec2 describe-availability-zones --region ap-northeast-1 \
  --query 'AvailabilityZones[].{name:ZoneName,id:ZoneId}' --output table

ZoneId が、AWS が名指しした AZ（今回は apne1-az1）の行の ZoneName（例：ap-northeast-1c など）が、あなたにとっての「避けるべき AZ」です。①の一覧でそこに寄っているインスタンスが、影響を受けやすいものです。

③ 新規起動は正常な別の AZ で。 Auto Scaling・ECS/Fargate のタスク・新規 EC2 で起動が失敗するなら、問題の AZ を外して別の AZ を指定します。今回は apne1-az2・apne1-az3 が正常でした。マルチ AZ の構成なら、片方を避けるだけで回避できることがあります。

④ 動いているものは無理に触らない／公式で追う。 稼働中のものを再起動すると、戻すときに起動失敗を踏む恐れがあります。急がないなら収束を待つ判断もあります。状況は AWS Health Dashboard と、アカウント個別の Health イベント（Personal Health Dashboard）で追います。後者は「あなたのリソースへの影響」を具体的に出します。

サービス別に見る確認ポイント

EC2 の上に乗るサービスは、それぞれ「どこで AZ に縛られているか」が違います。影響 AZ が分かったら、サービスごとに次を確かめます。

サービス 確認・対応
ECS サービス タスクを置くサブネット（＝AZ）の割り当てを確認。影響 AZ のサブネットを一時的に外す
Fargate 正常な AZ でタスクを起動できるか。キャパシティが足りるかも合わせて見る
ALB 有効なサブネット（AZ）のうち正常な AZ が含まれるか。ターゲットの健全数（HealthyHostCount）を確認
Auto Scaling 正常な AZ で必要な台数を確保できるか。希望台数・上限と空き容量を確認
NAT Gateway NAT は AZ ごとに置くもの。影響 AZ の NAT に依存する経路がないか確認

AZ を外せば必ず直るわけではありません。サブネットの空き IP、ルートテーブルの経路、他 AZ のキャパシティ（一斉に寄せると足りなくなる）も合わせて見ます。新規作成・変更が失敗するなら、無理に繰り返さず、収束を待つ判断も要ります。

今回の障害から持ち帰れるのは、「複数の AZ に分けておけば、単一 AZ の障害で止まりにくい」という当たり前の原則です。1つの AZ に寄せている構成があれば、分散を検討するよい機会です。

参照ソース