AWS status

How we check AWS

We watch s3.amazonaws.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

AWS is dozens of independent services, not one, so no single URL proves "AWS is up" the way an API root proves a smaller vendor is. We watch S3 instead of the marketing site, because object storage is the single most broadly relied-upon primitive underneath the rest of AWS, and an anonymous request to its root reliably returns the same response when the service is healthy.

What is AWS?

AWS is not one service. It is a catalogue of dozens of independently operated products, from compute and storage to databases, queues, and machine learning infrastructure, sold under one brand and one console. That structure is the first thing worth understanding before treating any single reading of "AWS" as meaningful, because the platform mostly does not fail as a single unit.

Object storage is the closest thing AWS has to a common foundation, which is why this page watches S3 rather than the marketing site or the console. A huge share of what runs on AWS touches S3 somewhere in its path, directly or as a dependency of something else, which makes it a more honest proxy for "is AWS's infrastructure broadly reachable" than any page that merely describes the company. It is still only one service among many, and it says nothing definitive about EC2, Lambda, RDS, or any of the others running independently.

Regional isolation is the second property that shapes how an AWS incident actually reads. Most applications run in one or two regions, not all of them, and a region having a bad day leaves the rest of the platform untouched. This is precisely why two engineers can compare notes during an announced AWS incident and describe completely different experiences without either being wrong: the region and the specific service in use decide whether an incident is relevant at all.

Throttling is the most common cause of AWS-adjacent errors that get mistaken for outages. Nearly every AWS API enforces limits on how many requests an account can make, and hitting one produces an error from a service that is otherwise entirely healthy. Traffic that spikes, a retry loop that makes things worse instead of better, or simply operating at a larger scale than the default limits assume will all trigger this. It is a configuration and capacity-planning question, not a platform problem, and it will never appear on any status page because nothing is actually down.

The practical response to running on AWS is to treat availability as per-service and per-region rather than as one number. AWS's own Health Dashboard reports incidents at that granularity, scoped to the account and resources actually in use, which is a more useful signal during an incident than any outside reading, including this one. What an external probe against one service can offer is an independent, always-on baseline that does not depend on AWS having published anything yet.

Frequently asked questions

Is AWS down right now?

Check the board above; it reflects our own probes against S3 from all five of our regions, refreshed every couple of minutes. That tells you whether one foundational AWS service is reachable, not whether every AWS service is, since AWS runs dozens of them independently.

My application uses AWS but this page shows AWS up. What should I check?

Check AWS's own Health Dashboard for your specific services and region, because an outage almost never hits all of AWS at once. A single service having a bad day in one region, a rate limit on your account, or a permissions change during unrelated work will all produce failures while the platform broadly reports healthy.

Does an AWS region outage affect every AWS customer?

No. AWS regions are largely independent, and most applications run in one or two of them rather than all. An incident in a region you do not use is invisible to you, and reports during a regional event will disagree with each other for exactly that reason, not because anyone is wrong.

Is the AWS Health Dashboard the same as this page?

No, and they answer different questions. Their dashboard reports what AWS has confirmed internally, broken down by service and region, which is far more granular than any outside probe could be. This page reports what our own probes measured against one service from outside AWS's infrastructure, on a fixed schedule, independent of what AWS has published.

I am getting throttled or rate-limited by an AWS API. Is that an outage?

No, a throttling response means the service answered and is enforcing a limit, which is a normal and expected part of using AWS at scale. Retrying with backoff, requesting a limit increase, or spreading load across more resources addresses it; none of it is a platform incident.