The AWS eu-south-2 outage on Sunday, October 4, 2026 was a networking fault in one Availability Zone of Amazon Web Services’ Spain region, not a region-wide failure. From 15:48 to 18:28 UTC the zone with the ID eus2-az1 had elevated packet loss, which AWS says “resulted in elevated API latencies and error rates for multiple workflows and AWS Services,” including EC2. AWS traced it to a networking configuration change and reverted it.

As of November 8, 2026, the event is still listed as resolved in the AWS Health Dashboard service history, nothing else has been posted for eu-south-2 since, and AWS has not published a longer post-event summary.

AWS filed the event under AWS Internet Connectivity in Spain. The Spain-region service feeds of the dashboard also list it for Amazon EC2, ECS, EKS, DynamoDB, VPC, NAT Gateway, Direct Connect, Redshift and SageMaker, among others. For EC2, AWS rates the maximum impact level as “Service impact.”

What AWS says happened

AWS’s resolution note, posted at 11:56 AM Pacific time, is short. Its systems alerted engineers automatically six minutes after the packet loss began, and the team worked “multiple parallel paths” to reduce the impact before it knew the cause. Those efforts brought some improvement after about 70 minutes. The root cause, “a networking configuration change,” was identified about 40 minutes after that, and reverting the change ended the impact. The note does not say how many customers or requests were affected.

Why AWS has not published a longer report

AWS’s Post-Event Summaries page sets the bar for a public write-up: an issue with “broad and significant customer impact,” such as the failure of a significant percentage of control-plane API calls, of a service’s infrastructure or APIs, or a total power or significant network failure. Events that clear it get a summary of scope, contributing factors and follow-up actions, kept online for at least five years.

When we checked the page on November 8, 2026, the newest summary was still the October 2025 DynamoDB disruption in us-east-1, which our tracker covers in its AWS outage entry for 20 October 2025. There is nothing for eu-south-2. A single-zone event that AWS mitigated in under three hours may never get one, so the dashboard note is likely to stay the only official account. That is also why this incident has no entry in our cloud outage tracker, which lists only outages with a provider’s own report; other AWS events there include December 2021, June 2023 and July 2024.

Timeline from the AWS Health Dashboard

AWS posted its updates in Pacific Daylight Time. Converted to UTC, with the public posts taken from the dashboard’s event log:

  • 15:48: elevated packet loss begins in eus2-az1.
  • 15:54: AWS is automatically alerted.
  • 16:14: first public post: “We are investigating elevated packet loss in the EU-SOUTH-2 Region.”
  • 16:36: AWS confirms the problem is limited to a single Availability Zone and is raising API latencies and error rates for other AWS services.
  • 17:00: mitigation work starts to show improvement.
  • 17:06: public post reports “some signs of improvement” but no root cause yet.
  • 17:38: the root cause, a networking configuration change, is identified and reverted.
  • 17:56: public post says the root cause has been identified, without naming it.
  • 18:28: full mitigation.
  • 18:45: public post reports “early signs of recovery.”
  • 18:56: the event is marked resolved, and the cause is named for the first time.

That is two hours and 40 minutes of impact by AWS’s own times. The first public post went up 26 minutes after the packet loss began, and the update that named the single affected zone came 48 minutes in. The dashboard said “early signs of recovery” 17 minutes after AWS’s own record puts full mitigation, and readers learned the cause only in the closing note. That gap is normal for provider status pages; our explainer on why a status page lags behind an outage walks through where the minutes go.

How to check whether it hit your EC2 instances

The public dashboard shows events that are not tied to any account. AWS’s documentation for the Service health page says it lists public events and keeps a service history for the last 12 months, so this event should stay visible there until about October 2027. To see whether AWS linked the event to your own resources:

  • Sign in and open Your account health. AWS’s getting-started guide says the signed-in dashboard shows events specific to your account, with an event log covering the past 90 days. Counted from October 4, that window closes around January 2, 2027, so save anything you need for an incident review or a credit claim before then.
  • Map the zone ID to your zone names. A zone name such as eu-south-2a is mapped to a physical zone separately for each AWS account, so one customer’s “a” zone may be another’s “b.” AWS’s documentation on Availability Zone IDs says an AZ ID “represents the same physical location in every AWS account.” Find which of your zone names is eus2-az1 in the VPC console or with the aws ec2 describe-availability-zones command.
  • Match the window against your own logs. Look at 15:48 to 18:28 UTC on October 4 for timeouts, retries and failed API calls from instances and services in that zone, and keep AWS’s documented impact separate from what your logs show. Our guide on how to read a post-incident report covers that habit.
  • Get the next one by event, not by refresh. The AWS Health overview says every customer can receive AWS Health events through Amazon EventBridge at no extra cost, so an alert can reach a team channel without anyone watching the dashboard.

Whether a single-zone event like this earns a service credit depends on the provider’s SLA terms; our explainer on cloud SLA credits covers how those claims work.

What it means for teams in the Spain region

A single-zone event is the case multi-zone designs exist for. Workloads spread across zones, with load balancers and databases able to shift away from the troubled one, should have seen errors drop as traffic moved. The AWS note also mentions API latencies and errors in other services, though, so control-plane calls such as launching instances or changing configuration could still have failed or slowed from healthy zones during the window. Our explainer on availability zones walks through which parts of a request path need a copy outside the failed zone, and the one on cloud outages and shared dependencies shows how a fault in one shared component can reach unrelated apps.

Last checked November 8, 2026, against the AWS Health Dashboard event log, the AWS Post-Event Summaries page and the AWS Health documentation linked above.