AWS Issues are how Amazon Web Services reports problems affecting your cloud resources

An AWS Issue is Amazon's term for a problem or outage that affects one or more AWS services in a specific region. When AWS infrastructure fails — whether a data center loses power, a network component malfunctions, or a service experiences a software bug — AWS publishes details about what broke, which regions it affects, and when they expect to fix it. You see these reported on the AWS Service Health Dashboard, which is the official place AWS tells customers what is happening right now.

Issues are different from maintenance windows. Maintenance is planned downtime that AWS schedules in advance and announces weeks ahead. An issue is unplanned — something went wrong, and AWS is working to restore service. Some issues last minutes. Others can last hours. AWS tracks each one with a status that moves from "Investigating" to "Identified" to "Resolved."

Key Takeaways

  • AWS Issues are unplanned outages or service degradation that affect specific AWS services in specific regions, not your entire account.
  • The AWS Service Health Dashboard is the official source for issue information and updates, and you can set up email alerts for services you use.
  • An issue affecting one region does not necessarily affect another region, so your workload may still run in an unaffected area.
  • AWS publishes a post-event report after major issues that explains what failed, why it failed, and what they changed to prevent it.

How AWS Issues differ from your own service problems

A critical distinction: an AWS Issue is a problem with AWS infrastructure itself. If your application crashes, your database runs out of storage, or your code has a bug, that is not an AWS Issue — that is a problem with your own resources running on AWS. AWS will not report it on the Service Health Dashboard because AWS systems are working correctly.

You can tell the difference by checking the dashboard first. If the service you are using shows no reported issues, then the problem is on your side. If the dashboard shows an active issue for, say, EC2 in us-east-1, and your EC2 instances in us-east-1 are unreachable, then AWS infrastructure is the cause. If your instances in us-west-2 are running fine, that confirms the issue is regional.

Where to find AWS Issue information

The AWS Service Health Dashboard is the official page where AWS publishes all current and recent issues. You reach it by logging into your AWS account and navigating to the Health Dashboard, or by visiting the public AWS status page. The dashboard shows every AWS service, lists which regions are affected, and displays the current status of each issue.

Each issue on the dashboard includes a timeline. You see when AWS first detected the problem, when they identified the root cause, and when they resolved it. AWS also publishes updates as the situation changes — if an issue was supposed to be fixed in 30 minutes but takes longer, they post a new update with a revised estimate.

You can set up email notifications so you do not have to check the dashboard constantly. In your AWS account settings, you can choose which services matter to you and receive alerts whenever an issue is reported for those services in your regions. This is especially useful if you run production workloads and need to know immediately when something breaks.

What happens during an AWS Issue

When an issue starts, AWS moves through a predictable sequence. First, their automated monitoring detects abnormal behavior — higher error rates, slower response times, or failed health checks. An engineer is paged. AWS updates the dashboard to "Investigating" and begins gathering data about what is wrong.

Once they understand the root cause, the status changes to "Identified." AWS posts details: "Database cluster in us-east-1a is unavailable due to a network switch failure." They give an estimate for when service will return. During this phase, AWS engineers are working to restore the affected infrastructure — rerouting traffic, failing over to backup systems, or restarting failed components.

When the issue is fixed, the status changes to "Resolved." Service is restored, but AWS does not close the issue immediately. They leave it on the dashboard for a period so customers can see what happened and when. After a few hours or days, the issue moves to the "Closed" section of the dashboard.

How AWS Issues affect your workload

The impact depends on how you built your application. If you run everything in a single AWS region and an issue hits that region, your application goes down. If you spread your workload across multiple regions, an issue in one region does not affect the others — your traffic automatically routes to the healthy region.

Similarly, if you use multiple availability zones within a single region, you have some protection. An issue affecting one availability zone may not affect the others, so your application keeps running on the healthy zones. AWS designs their infrastructure so that most issues affect only one zone or one region, not the entire global network.

The duration of an issue also matters. A 5-minute outage might cause a brief spike in errors that your monitoring catches and logs. A 2-hour outage will cause real customer impact — failed transactions, timeouts, or complete unavailability depending on how your application handles errors. This is why teams running production systems monitor the AWS dashboard and have runbooks for what to do if a specific service goes down.

AWS post-event reports explain what went wrong

After a significant issue, AWS publishes a detailed post-event report called a Root Cause Analysis or RCA. This document explains what failed, why it failed, and what AWS changed to prevent it from happening again. RCAs are public and available on the AWS status page.

For example, an RCA might explain: "A misconfiguration in our load balancer deployment script caused new instances to be created without proper security group rules. This prevented traffic from reaching the instances, causing a service outage in us-east-1 for 47 minutes. We have updated the deployment script, added a validation step, and improved our testing process." These reports are useful for understanding AWS infrastructure and for learning how large systems fail and recover.

What you can do to prepare for AWS Issues

You cannot prevent AWS Issues — they are outside your control. But you can reduce their impact on your business. The most effective approach is multi-region redundancy: run your application in at least two AWS regions so that if one region has an issue, the other keeps serving traffic. This requires more infrastructure and more cost, but it means an AWS Issue in one region does not cause downtime.

A simpler approach for less critical workloads is multi-availability-zone deployment within a single region. This protects you against issues affecting a single zone but not the whole region. Most AWS services support this natively — you specify multiple zones when you create the resource, and AWS spreads it across them automatically.

You should also set up monitoring and alerting on the AWS Service Health Dashboard. Subscribe to notifications for the services you use. When an issue is reported, you will know immediately instead of learning about it from customer complaints. This gives you time to communicate with your users, check your application logs, and decide whether to fail over to another region or wait for AWS to fix the problem.

Frequently Asked Questions

Does an AWS Issue mean my data is lost?

No. AWS Issues affect availability — whether you can reach your service — not durability. Your data is stored on multiple redundant systems. Even if one component fails, your data remains safe. Once AWS fixes the issue, your data is still there and unchanged. You may lose in-flight transactions or see errors during the outage, but your stored data is not at risk.

Can I get a refund if an AWS Issue causes downtime?

AWS offers service credits under their Service Level Agreement if an issue causes extended unavailability. The credit depends on how long the outage lasted and which service was affected. You do not request the credit — AWS automatically applies it to your account after investigating the issue. Check your AWS billing page for credits after a major outage.

How do I know if an issue is affecting me specifically?

Check the AWS Service Health Dashboard and look for issues in the regions where you run resources. If an issue is reported for EC2 in us-east-1 and you only use EC2 in us-west-2, the issue does not affect you. If you use the affected service in the affected region, the issue may affect you — check your application logs and monitoring to see if you are experiencing errors.

What is the difference between an AWS Issue and a service limit?

An AWS Issue is a temporary outage or degradation of AWS infrastructure. A service limit is a permanent boundary on how much of a resource you can use — for example, you can create only 20 EC2 instances by default in a region. Service limits are not issues; they are design constraints. You can request a limit increase from AWS, but that is a different process than reporting an issue.

Should I switch cloud providers if AWS has frequent issues?

All cloud providers have issues occasionally — it is the nature of running massive distributed systems. AWS publishes their issues transparently on the Service Health Dashboard, which is actually a strength. The question is not whether issues happen, but whether you have designed your application to survive them. Multi-region deployment, health checks, and automated failover are the real solutions, regardless of which cloud provider you use.