How to know if AWS is actually down or if the problem is on your end

AWS (Amazon Web Services) goes down rarely, but when it does, the outage usually affects only one region or one service, not the entire platform. Before you assume AWS is down, check three things: whether your internet connection is working, whether you can reach other websites, and whether the specific AWS service you need is actually unavailable or just slow.

The fastest way to confirm an AWS outage is to visit the AWS Service Health Dashboard at status.aws.amazon.com. This page shows the real-time status of every AWS service in every region. If your service shows green, AWS is working on your end — the problem is somewhere else in your setup or network.

If the dashboard shows red or yellow for your region and service, AWS has publicly acknowledged the issue. At that point, you are waiting for Amazon's engineering team to fix it, and refreshing the page every 30 seconds will not speed that up. The dashboard also shows a history of past incidents, so you can see how long similar outages usually take to resolve.

Key Takeaways

  • The AWS Service Health Dashboard at status.aws.amazon.com is the only official source for whether AWS is actually down in your region.
  • Most "AWS is down" problems are actually network issues, misconfigured security groups, or expired credentials on your end, not an AWS outage.
  • AWS outages usually affect one region or one service, not all of AWS, so check which specific region and service you are trying to use.
  • If the dashboard shows green but your process still cannot reach AWS, the problem is your firewall, DNS, or process code, not AWS itself.

Check the AWS Service Health Dashboard first

Open status.aws.amazon.com in your browser. You will see a list of AWS services (EC2, RDS, Lambda, S3, and dozens more) and a list of regions (us-east-1, eu-west-1, ap-southeast-1, and so on). Each combination shows a colored dot: green means operational, yellow means degraded performance, red means service disruption.

Find the service you are trying to use and the region where you launched it. If both show green, AWS is working. If either shows yellow or red, AWS has an active incident. Click on the incident to see when it started, what Amazon is doing about it, and when they expect to resolve it.

The dashboard updates every few minutes during an incident. You do not need to refresh constantly — check once, note the time of the last update, and come back in 15 minutes. The history tab at the bottom shows past incidents going back months, which helps you understand whether this service in this region has a pattern of problems.

Confirm your own network and credentials are working

If the dashboard shows green but you still cannot reach AWS, the outage is not on Amazon's side. Test your internet connection by opening a different website — Gmail, Wikipedia, or your bank. If those load, your internet is fine. If they do not load, your network is down or your ISP is having problems.

Next, check whether you are using the correct AWS credentials. Open the AWS Management Console and sign in. If you can log in and see your resources, your credentials are valid. If you get an authentication error, your access key or password may have expired or been revoked.

Then check your security group rules. If you are trying to connect to an EC2 instance or RDS database, the security group must allow inbound traffic on the port you are using (port 22 for SSH, port 3306 for MySQL, port 5432 for PostgreSQL, and so on). A blocked port looks like a timeout or connection refused error, not an AWS outage. Review your security group in the AWS console under EC2 > Security Groups.

Understand what "AWS is down" actually means

AWS is a collection of independent services spread across multiple regions around the world. When people say "AWS is down," they usually mean one of three things: one service is down in one region, one service is down in multiple regions, or one region is completely unavailable.

A single-service outage in one region (like S3 in us-east-1) affects only applications that use that service in that region. If your process uses EC2 in us-east-1 and S3 in eu-west-1, and S3 in us-east-1 goes down, your process may not notice at all. If your process uses S3 in us-east-1 and has no failover to another region, it will be completely blocked.

A multi-region outage is rarer. It means the same service is down in two or more regions at the same time, usually because of a problem in AWS's shared infrastructure. Even then, other regions are usually unaffected. A complete region outage (where all services in one region stop working) is extremely rare and usually caused by a physical disaster like a power failure or network cut at that data center.

What to do while you wait for AWS to fix an outage

If the dashboard confirms that AWS has an active incident affecting your service and region, you are waiting for Amazon's team to resolve it. There is nothing you can do to speed this up. Do not restart your instances, do not delete and recreate your resources, and do not change your configuration — those actions may make things worse or cause data loss.

Instead, document what you were doing when the outage started, take a screenshot of the dashboard showing the incident, and note the time. If you need to report the outage to your own customers or stakeholders, you can point them to the AWS dashboard as proof that the problem is not on your end.

Use the time to review your disaster recovery plan. If this outage exposed a gap in your setup (for example, you have no failover to another region), now is the time to plan that improvement. Most AWS outages last less than an hour, but some have lasted several hours, so redundancy across regions is worth the cost if your process cannot afford downtime.

Set up alerts so you know about outages before your users do

The AWS Health Dashboard (different from the Service Health Dashboard) sends notifications to your email when an outage affects your account. To set it up, go to the AWS Management Console, search for "Health," and open AWS Health. Click on "Event log" and then "Settings" to configure email notifications for service disruptions in the regions where you run applications.

You can also subscribe to the AWS Service Health Dashboard RSS feed or use a third-party monitoring service like Statuspage or PagerDuty, which aggregates AWS status with your own process monitoring. These tools send alerts to Slack, SMS, or email the moment an outage starts, so you know before your customers call.

For critical applications, consider using AWS's multi-region architecture so that if one region goes down, traffic automatically fails over to another. This requires more setup and cost, but it means your process stays online even during a regional outage.

Frequently Asked Questions

How often does AWS actually go down?

AWS has major outages (affecting multiple services or regions) roughly once or twice per year. Minor outages (affecting one service in one region for under an hour) happen a few times per month. The vast majority of "AWS is down" reports are actually problems with the user's network, credentials, or configuration, not AWS itself.

What should I do if AWS is down and I have paying customers?

Notify your customers when ready that you are experiencing an outage and that the problem is with your cloud provider, not your process. Point them to the AWS Service Health Dashboard so they can see the incident for themselves. Give them a realistic estimate of when service will return based on the dashboard's incident timeline, and update them every 30 minutes until service is restored.

Can I get a refund if AWS is down?

AWS's service level agreement (SLA) provides service credits (discounts on your bill) if uptime falls below a certain threshold in a month. For most services, that threshold is 99.9% uptime, which allows about 43 minutes of downtime per month. Check your service's specific SLA in the AWS documentation, and contact AWS Support if you believe you may have access to for a credit after an outage.

Is there a way to prevent AWS outages from affecting my process?

You cannot prevent AWS outages, but you can design your process to survive them. Run your process across multiple AWS regions so that if one region goes down, traffic fails over to another. Use managed services like RDS Multi-AZ or S3 cross-region replication so your data is automatically backed up. These approaches cost more but eliminate downtime from regional outages.

Why does the AWS dashboard sometimes show an outage that I did not notice?

AWS outages often affect only a small percentage of customers or only certain types of workloads. If you do not use the affected service, or if you use it in a region where you have no resources, you will not notice the outage even though it is real. The dashboard shows all incidents so that every customer can check whether they are affected.