Is AWS Down? How to Check Amazon Web Services Status in 2026

Amazon Web Services powers an estimated 30% of the internet. When AWS goes down — even partially — the impact cascades across thousands of applications and services that depend on it. If you're seeing errors in your application and suspect an AWS issue, here's how to diagnose it quickly.

The Fastest Way to Check If AWS Is Down

Start with the official AWS status dashboard:

health.aws.amazon.com/health/status

This is AWS's real-time service health page. It shows current status across all AWS services and regions. Look for:

• Orange or red indicators next to service names — these indicate degraded or disrupted service
• Region filters — AWS outages are usually regional. A US-East-1 outage doesn't necessarily affect EU-West-1
• Timestamp on updates — Check when the status was last updated to ensure you're seeing current information

The legacy status page at status.aws.amazon.com is still accessible but AWS now directs users to the Personal Health Dashboard for more detailed service-specific views.

AWS Personal Health Dashboard

If you have an AWS account, the Personal Health Dashboard at console.aws.amazon.com/health/home shows incidents affecting your specific resources, not just global service status. This is more useful than the public status page because:

• It filters to the regions and services you're actually using
• It shows upcoming maintenance that could affect your workloads
• You can configure EventBridge rules to trigger alerts when AWS posts health events for your services

Third-Party AWS Status Sources

AWS's own status page has a history of lagging behind actual incidents — updates sometimes appear 30-60 minutes after engineers are already aware of issues. For faster detection:

• Downdetector — User-reported outages often surface here before the AWS status page updates. Useful for confirming you're not alone.
• Twitter/X — @AWSSupport and #AWSOutage — AWS's support account posts updates, and the engineering community surfaces issues fast on X.
• Hacker News — Major AWS outages consistently generate top-page HN threads within 30 minutes. Search "aws" on news.ycombinator.com.
• ezmon.com — Monitors AWS service endpoints from multiple probe locations to detect regional availability issues. Set up an alert for your specific AWS region.

Diagnosing an AWS Issue: Step-by-Step

Not every error in your AWS-backed application is an AWS outage. Follow this diagnostic flow before assuming AWS is the problem:

Step 1: Check Your Own Infrastructure First

Before looking at AWS status, verify:

• Can you access the AWS console? If yes, AWS's control plane is up.
• Is the issue affecting all users or just some? (Could be a CDN issue, not AWS)
• Did anything deploy in the last hour? (Code changes cause more outages than AWS does)

Step 2: Identify the Specific Service and Region

AWS outages are almost always service-and-region-specific. The most common affected services during incidents:

• EC2 — Compute instance issues (usually in a specific availability zone)
• RDS — Database availability
• S3 — Object storage (globally distributed but can have regional issues)
• Lambda — Serverless execution
• CloudFront — CDN (can affect global content delivery)
• Route 53 — DNS (rare but catastrophic when it fails)
• IAM / STS — Authentication (can block all AWS API calls)

Check the AWS Health Dashboard filtering to your specific region (e.g., us-east-1, eu-west-2, ap-southeast-1).

Step 3: Test Directly

Use AWS CLI to test basic connectivity:

# Test S3 in a specific region
aws s3 ls s3://your-bucket --region us-east-1

# Test EC2 metadata (from within an EC2 instance)
curl http://169.254.169.254/latest/meta-data/

# Test DynamoDB
aws dynamodb list-tables --region us-east-1

Errors like RequestExpired or ServiceUnavailable point to AWS-side issues. NetworkError or ConnectionRefused may be local network issues.

Step 4: Check AWS Support

If you have AWS Business Support or Enterprise Support:

• Open a support case immediately — "infrastructure event" tickets get priority routing
• Include your resource IDs, region, and error messages
• Check the AWS Support Center for any active incident communications for your account

AWS's Most Common Outage Patterns

Understanding how AWS outages typically unfold helps you respond faster:

Availability Zone vs. Regional vs. Global

Most AWS incidents are scoped to a single Availability Zone (AZ) — one datacenter cluster within a region. If you've deployed across multiple AZs (which AWS recommends), an AZ failure may cause degraded performance but not a complete outage.

True regional outages (affecting all AZs in us-east-1, for example) are rarer but more impactful. AWS's largest incidents — the 2021 us-east-1 outage that took down Ring, McDonald's, Delta, and much of the internet — were regional in scope.

Global incidents affecting multiple regions simultaneously are extremely rare in AWS's history.

Control Plane vs. Data Plane

A critical but underappreciated distinction:

• Data plane: Running resources (EC2 instances running, S3 data accessible)
• Control plane: Management APIs (launching new EC2 instances, modifying security groups)

During incidents, AWS often degrades the control plane first while the data plane remains healthy. If you can't launch new EC2 instances but existing instances are running fine, you're seeing a control plane issue. Your existing workload may be unaffected — don't panic-reboot things.

How to Get AWS Outage Alerts Automatically

Waiting to discover AWS issues through user complaints is not a strategy. Set up automated detection:

Option 1: AWS Health EventBridge

AWS can send health events to EventBridge, which can trigger SNS notifications or Lambda functions:

# CloudFormation snippet: EventBridge rule for AWS health events
AWSHealthAlerts:
  Type: AWS::Events::Rule
  Properties:
    EventPattern:
      source: ["aws.health"]
      detail-type: ["AWS Health Event"]
    State: ENABLED
    Targets:
      - Arn: !Ref AlertSNSTopic
        Id: HealthAlertTarget

Option 2: External Uptime Monitoring

External monitoring from outside AWS can detect issues that internal monitoring misses (since your monitoring infrastructure may also be affected). ezmon.com monitors AWS service endpoints and your application endpoints from independent probe nodes in multiple regions.

Configure endpoint checks for your critical AWS-backed URLs. When probes from multiple regions agree your endpoint is unreachable, you get paged before your users start complaining.

Option 3: AWS Chatbot for Slack Integration

AWS Chatbot can pipe Personal Health Dashboard notifications directly to a Slack channel. Set up in the AWS Console under Chatbot — it takes about 10 minutes and ensures your team sees AWS health alerts in the same place they're already communicating during incidents.

What to Do During an AWS Outage

Don't Make It Worse

The instinct to "fix" things during an outage often makes the situation worse:

• Don't restart instances that are running — you may lose your place in a queue for recovery
• Don't redeploy to a degraded region — wait for the incident to clear
• Don't flood the AWS API with retry loops — you'll hit rate limits and delay recovery

Communicate Proactively

While you're waiting for AWS to recover:

• Update your status page immediately — even "we are aware of an issue and investigating" is better than silence
• Post to your company Slack/Teams channel with what you know
• If customers are affected, send an email or notification — don't wait for full resolution

Document the Timeline

Start logging timestamps as soon as you suspect an AWS issue: when you first noticed the problem, when you confirmed AWS status, when services degraded, when they recovered. This becomes the basis for your incident postmortem and customer communication.

Historical Context: AWS's Reliability Record

Despite being the world's largest cloud provider, AWS is not immune to significant outages. Notable incidents from AWS's public history include the December 2021 us-east-1 outage (which affected Amazon.com, Netflix, Disney+, Ring, and thousands of other services), and multiple S3 and EC2 incidents across regions in preceding years.

AWS publishes detailed post-incident analyses for major events through its Post Event Summary program. These are worth reading — they explain root causes, contributing factors, and the engineering changes AWS made in response.

AWS's SLA commitments vary by service — typically 99.9% to 99.99% per service, per region. Those nines add up: 99.9% allows 8.7 hours of downtime per year. For workloads that can't tolerate that risk, multi-region architecture is the only real mitigation — you can't rely on any single cloud provider's uptime guarantees for five-nines reliability.