An AWS eu-south-2 outage on Sunday, October 4, 2026 left one Availability Zone of Amazon Web Services’ Spain region with elevated packet loss from 15:48 to 18:28 UTC. According to the event summary on the AWS Health Dashboard, the problem sat in the zone with the ID eus2-az1 and “resulted in elevated API latencies and error rates for multiple workflows and AWS Services.” AWS traced it to a networking configuration change and reverted it.

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.

AWS has not published a longer post-event summary for this incident. The dashboard note does not say how many customers or requests were affected.

Timeline from the AWS Health Dashboard

AWS posted its updates in Pacific Daylight Time. Converted to UTC:

  • 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:38: the root cause, a networking configuration change, is identified and reverted.
  • 18:28: full mitigation.
  • 18:56: the event is marked resolved.

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. 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.

Which zone is eus2-az1?

AWS names zones in two ways. 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.” The zone ID is the same for everyone. AWS’s documentation on Availability Zone IDs says an AZ ID “represents the same physical location in every AWS account.” Teams that run in eu-south-2 can check which of their zone names maps to eus2-az1 in the VPC console or with the aws ec2 describe-availability-zones command, and then match the incident window against their own logs.

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.

Dated provider reports, with causes and durations, are collected in our cloud outage tracker. For why a fault in one shared component can reach unrelated apps, see our explainer on cloud outages and shared dependencies.