# AWS status

> Is AWS down? Live status for Amazon Web Services, uptime history, and per-region response times from our own probes every 2 minutes.

Published: 2026-09-01 | Canonical: https://yoping.me/status/aws

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

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/aws. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

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