Is Amazon Web Services down?

How AWS availability works

Amazon Web Services is a collection of cloud services operating across accounts, regions, and availability zones—not one single application with one universal uptime state. An incident affecting a particular service or region may leave other AWS workloads operating normally.

Start with the official AWS Health status page. Compare any event with the affected service, region, resource, account or environment, and approximate failure time. If there is no matching event, investigate account-specific, workload, configuration, and connectivity causes before treating the problem as a broad AWS outage.

A healthy public status page does not prove that every resource is healthy. Credentials, permissions, DNS, routing, security controls, endpoint selection, deployment changes, and application code can all affect an AWS-backed service.

Troubleshooting AWS failures

1. Check for a service or regional incident

Open the official AWS Health status page and look for an event matching the affected service, region, and approximate start time. A matching event makes a provider-side issue more likely. Avoid repeatedly changing production settings or redeploying resources while an incident is under investigation.

If no matching event appears, the problem may be limited to one account, workload, region, resource, or network path.

2. Identify the failing layer

Define the exact operation that fails: opening the AWS console, deploying code, resolving a hostname, calling an AWS endpoint, reading from storage, or connecting to a database. Check whether unrelated resources or services in the same region still work.

Compare the failure with a recent deployment or configuration change. Review logs for the precise AWS error, request time, region, resource identifier, and operation. An HTTP 5xx response does not by itself show that AWS is down; it may have been generated by the application, proxy, load balancer, or gateway.

3. Check account, permission, and configuration causes

For a failure limited to one account, environment, or resource, verify the selected region, resource state, credentials, permissions, endpoint, quotas, and recent infrastructure changes. Confirm that the application is using the intended account and region. If one identity or deployment fails while a known-good path works, investigate access and configuration before treating the issue as platform-wide.

4. Check browser and console-specific problems

If the AWS console or a hosted application fails in only one browser or on one device, try a private window, another supported browser, or another device. Record the visible error before clearing site data. A console-only problem can be separate from the health of the underlying AWS resources.

5. Check network, DNS, and connectivity

Test from a second network when possible. Compare DNS resolution, TLS negotiation, and connection behavior for the affected hostname. DNS failures, connection refusals, certificate errors, and timeouts can result from local DNS, VPN or proxy settings, firewall rules, routing, security groups, network ACLs, load balancer listeners, or the destination application.

If the request works from another network or region, investigate the path between the client and AWS rather than assuming a global outage.

6. Check SDK, CLI, webhook, and automation failures

Capture the complete error category and operation. Distinguish authentication or authorization errors from throttling, validation, endpoint, timeout, and server-side errors. Confirm the configured region and endpoint, then retry only when the operation is safe to repeat. For production changes, preserve request IDs and timestamps for troubleshooting or support escalation.