--- title: "AWS’s Tokyo fault ran 5 hours 45 minutes; some launches ‘succeeded’, then terminated" summary: "AWS’s seven status posts for its Tokyo region on 11 November: API errors, launches that reported success, slow network changes, and what running in several zones covered." url: https://www.thetechbag.com/blog/aws-tokyo-zone-5-hours-failed-launches format: Note desk: "Cloud & DevOps" region: Global published: 2026-11-12 facts_checked: 2026-11-12 author: TechBag (The TechBag Journal) tags: ["AWS outage","AWS Tokyo outage","EC2 launch failures","ap-northeast-1","EC2 outage","AWS","Amazon EC2","Availability Zone","apne1-az1","AWS Health Dashboard","RunInstances","Auto Scaling","Amazon ECS","Amazon EKS","NAT Gateway","Elastic Load Balancing","CloudWatch alarms","multi-AZ","Japan"] cover: https://www.thetechbag.com/blog/covers/aws-tokyo-zone-5-hours-failed-launches.png --- # AWS’s Tokyo fault ran 5 hours 45 minutes; some launches ‘succeeded’, then terminated *AWS’s seven status posts for its Tokyo region on 11 November: API errors, launches that reported success, slow network changes, and what running in several zones covered.* Note · Cloud & DevOps · By TechBag · Published 2026-11-12 · Facts checked 2026-11-12 · Canonical: https://www.thetechbag.com/blog/aws-tokyo-zone-5-hours-failed-launches Amazon Web Services’ Tokyo region spent 5 hours 45 minutes on 11 November failing to launch servers properly, mostly in one Availability Zone, apne1-az1. For the first three hours, from 14:46 to 17:46 UTC (11:46pm to 2:46am in Tokyo), EC2 API calls were throttled or returned server errors and instance launches failed. Some launch calls returned success, but the instance never came up and moved straight to TERMINATED.[1] For the next 2 hours 45 minutes, new instances, and existing ones whose network settings were changed, could not connect, because an internal system was slow to apply networking changes. AWS declared the issue resolved at 20:31 UTC, 2:01am IST on 12 November.[1] 5h 45m from first errors to resolution, 14:46 to 20:31 UTC AWS 3h of API errors and failed launches AWS 2h 45m of slow network changes for new or modified instances AWS 1 of 3 zones hit hardest; AWS said launch in the other two AWS ## A launch that said yes, then terminated Auto Scaling, ECS and RDS, which start instances through the same EC2 API, were affected, and ECS and Fargate tasks failed to launch.[1] The status checks were unreliable too: EC2 and EBS health data went missing or arrived late, CloudWatch alarms for the zone moved to INSUFFICIENT_DATA, and AWS told customers to “rely on your own health telemetry”, warning that alarms set to fire on missing data might do so.[1] Our viewWhy the false success matters Anything that adds capacity, a scaling policy, a deployment script or a cluster manager, usually trusts the API’s answer. On 11 November an answer of success could mean an instance that never served a request. The test is whether the instance reached running and passed your own health check, not whether the call returned 200. ## The second fault: network changes that did not arrive **Figure: AWS fixed the API errors after three hours; slow networking took 2 hours 45 minutes more** *AWS's status posts and stated impact windows for EC2 in Tokyo (AP-NORTHEAST-1), 11 November 2026, in UTC* | Date | Event | Detail | | --- | --- | --- | | 11 Nov, 14:46 UTC | Errors begin | API errors and failed launches, mostly apne1-az1 | | 11 Nov, 15:40 UTC | First status post | Launch failures concentrated in apne1-az1 | | 11 Nov, 16:40 UTC | Root cause found | Low-level launch failures in other zones; alarms at insufficient data | | 11 Nov, 17:38 UTC | Early recovery | EC2 and EBS health data reporting correctly | | 11 Nov, 17:46 UTC | API errors fixed | End of the first impact window | | 11 Nov, 18:54 UTC | New issue | Connectivity for new or modified instances in apne1-az1 | | 11 Nov, 19:54 UTC | Use the other zones | Launch in apne1-az2 and az3; no network changes in az1 | | 11 Nov, 20:31 UTC | Resolved | 5 hours 45 minutes after the first errors | Source: AWS Health Dashboard, EC2 (Tokyo) event thread, 11 November 2026 · as of 12 November 2026 · Tokyo is UTC+9 and India UTC+5:30; close events are spread apart so their labels stay legible Once the API recovered, AWS found that new instances, and running instances whose network configuration was modified, had intermittent connectivity. It traced this to delays in an internal subsystem that propagates instance networking changes, “related to the underlying root cause”. ECS, EKS, Elastic Load Balancing and NAT Gateway were hit, along with new clusters, gateways and VPC gateway endpoints. AWS asked customers not to attach or detach network interfaces or gateways, or change VPC peering, in the zone. Traffic to existing resources and between instances was not affected.[1] ## What running in several zones did and did not cover Spreading across zones protected what was already running: existing instances were not affected, and AWS pointed new launches at the two healthy zones. It did not cover everything. The API errors were reported for the region, and in its 16:40 UTC post AWS saw low levels of launch failures in other zones as well.[1] And apne1-az1 is a zone ID: AWS maps zone names such as ap-northeast-1a to physical zones differently for each account, so a team has to look up its own mapping to know which of its subnets sat in the affected zone.[2] Google’s [six-hour London outage](https://www.thetechbag.com/blog/google-cloud-london-6-hours-generators-no-signal) showed a related limit: Google named “control-plane dependencies across zonal boundaries” among its causes.[3] AWS has not published a root cause or said how many customers were affected. How we did this Figures as of 12 November 2026, 8:30pm IST Every fact about the incident is from AWS’s seven posts on its Health Dashboard, 07:40 to 13:11 PST on 11 November, read in the public RSS feed; the final post gives the windows 6:46 to 9:46am and 6:46am to 12:31pm PST. We converted PST (UTC−8) to UTC, Tokyo and IST; the 3 hours, 2 hours 45 minutes and 5 hours 45 minutes are our arithmetic on those windows. The final post refers to a list of affected services that the feed does not carry; we name only services AWS named in the posts. Spotted an error? Write to us; corrections are published at the foot of the piece. Sources 1. [AWS Health Dashboard: Elevated API issues and Launch Failures, Amazon EC2 (Tokyo), seven posts in the all-services RSS feed](https://status.aws.amazon.com/rss/all.rss) — 11 November 2026 2. [AWS Resource Access Manager User Guide: Availability Zone IDs for your AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) — undated page 3. [Google Cloud Service Health: incident report on europe-west2 (London)](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj) — 4 November 2026 **Disclosure.** TechBag is a software reseller: it earns when companies buy through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view. **Read this next:** [Ransomware hit a cloud provider: 206 of 495 customers had a copy it could return](https://www.thetechbag.com/blog/cloud-provider-ransomware-idc-frontier) — When a Japanese cloud provider itself was hit: ransomware at IDC Frontier’s cloud, where 206 of 495 customers had a copy it could return. Go deeper on TechBag - [AWS intel hub](https://www.thetechbag.com/aws) — TechBag’s pages on AWS services - [AWS Elastic Disaster Recovery](https://www.thetechbag.com/aws/aws-elastic-disaster-recovery) — recovery into another zone or region, for comparison - [Google Cloud’s 6-hour London outage began with generators that got no start signal](https://www.thetechbag.com/blog/google-cloud-london-6-hours-generators-no-signal) — another zone failure, and what multi-zone designs did