An AWS issue is a problem with your Amazon Web Services account, infrastructure, or services that prevents them from working as expected

An AWS issue can mean different things depending on your situation. It might be that a service you're using has stopped working, your account has been suspended, you're getting error messages when you try to deploy code, or your resources are performing slower than normal. AWS issues can originate from your own configuration mistakes, from AWS infrastructure problems affecting multiple customers, or from something in between — like a misconfigured security group or an expired credential.

The term "AWS issue" is broad because AWS itself is broad. You might be running virtual servers (EC2), storing files (S3), managing databases (RDS), or using dozens of other services. Each one can fail in different ways. Understanding what kind of issue you're facing — and where to look for answers — saves time when something breaks.

Key Takeaways

  • AWS issues can be caused by your own configuration, by AWS infrastructure problems, or by something in your network or application code.
  • The AWS Service Health Dashboard shows real-time status of AWS services and whether a widespread outage is happening in your region.
  • AWS Support has four tiers: Basic (free, limited help), Developer, Business, and Enterprise, each with different response times and access to support staff.
  • Many AWS issues can be resolved by checking CloudWatch logs, reviewing your security groups and IAM permissions, and verifying your resource configuration.
  • If you think AWS infrastructure is down, check the Service Health Dashboard before opening a support case, since widespread outages affect many customers at once.

How to tell if the problem is on your side or AWS's side

The first step when something stops working is figuring out whether the issue lives in your AWS account or in AWS's infrastructure. If AWS infrastructure is down in your region, thousands of customers are affected at once, and opening a support case won't speed up the fix. If the problem is in your configuration, AWS support might not help you — you may need to fix it yourself or hire a consultant.

Check the AWS Service Health Dashboard first. Go to your AWS console, look for "Service Health Dashboard" in the top navigation, and see whether the services you're using show a green checkmark or a warning. If AWS infrastructure is having problems, it will show there. If the dashboard is green but your service isn't working, the problem is almost certainly in your account.

Next, check your own logs. If you're running EC2 instances, look at CloudWatch Logs. If you're using a database, check the database logs. If you're deploying code, check the deployment logs. Most AWS issues leave a trail — an error message, a failed request, a timeout — that tells you what went wrong. The AWS console also shows recent API calls under "CloudTrail", which can reveal whether a command succeeded or failed.

Common types of AWS issues and where to look

Different AWS services fail in different ways. An EC2 instance might be running but unreachable because of a security group rule. An S3 bucket might be inaccessible because of an IAM policy. A database might be slow because it's running out of storage or because a query is inefficient. RDS might show a "database unavailable" error because the instance type is too small for the workload.

For compute issues (EC2, Lambda), check your security groups first — they act as a firewall and often block traffic you didn't intend to block. Check your IAM roles and policies next — if your instance doesn't have permission to read from S3 or write to CloudWatch, it will fail silently. For storage issues (S3), check bucket policies and object-level permissions. For database issues (RDS, DynamoDB), check storage space, connection limits, and query performance metrics in CloudWatch.

If you're getting an error message, search for that exact message in the AWS documentation or in the service-specific troubleshooting guide. AWS error codes are usually specific enough to point you toward the root cause. "AccessDenied" means a permission is missing. "ThrottlingException" means you've hit a rate limit. "InvalidParameterValue" means you passed something the service doesn't accept.

When to contact AWS Support and what to expect

AWS Support comes in four tiers. Basic Support is free and includes access to documentation, community forums, and the Service Health Dashboard, but not to AWS support staff. Developer Support costs about $29 per month and gives you email access to support engineers with a 12-hour response time for general questions. Business Support costs at least $100 per month and offers phone and chat access with a 1-hour response time for urgent issues. Enterprise Support is custom-priced and includes a dedicated technical account manager.

Before you open a support case, gather information: the exact error message, when the issue started, what you were doing when it happened, the AWS region and service involved, and any recent changes you made to your configuration. Support engineers will ask for this anyway, and having it ready speeds up the process. If you can reproduce the issue, tell them the steps. If you can't, describe the symptoms as precisely as you can.

Support response times vary by tier and severity. A "general guidance" question under Developer Support might take 12 hours. An "urgent" issue under Business Support (something affecting production) gets a response within 1 hour. An "emergency" issue under Enterprise Support (something affecting many users) gets a response within 15 minutes. If you don't have a paid support plan and the issue is blocking production, upgrading to Business Support is usually faster than waiting for a free-tier response.

Using AWS documentation and community resources

Before paying for support, check the AWS documentation. Every service has a troubleshooting section. The EC2 troubleshooting guide covers connectivity, performance, and instance state issues. The RDS troubleshooting guide covers connection problems, performance, and storage issues. The S3 troubleshooting guide covers access denied errors, slow uploads, and replication issues. These guides are written by the people who built the services and usually contain the answer.

The AWS forums and Stack Overflow also have thousands of answered questions. Search for your error message or symptom — chances are someone else has hit it and posted a solution. AWS community members and AWS employees monitor these spaces, so you might get a response even without a paid support plan. Reddit's r/aws and the AWS subreddit are also active, though responses are less may provide.

If you're studying for an AWS certification, understanding common issues and how to troubleshoot them is part of the exam. The certification guides include sections on monitoring, logging, and troubleshooting. Learning how to read CloudWatch metrics, interpret error messages, and check configuration is as important as knowing how to create resources in the first place.

How to prevent AWS issues before they happen

Many AWS issues are preventable. Set up CloudWatch alarms before something breaks so you know about it immediately. Use AWS Config to track changes to your resources — if someone modifies a security group or IAM policy, you'll see it. Enable VPC Flow Logs to see network traffic and spot connectivity issues. Use AWS Trusted Advisor to scan your account for common misconfigurations like open security groups or unused resources.

Document your infrastructure. Write down which security groups are attached to which instances, which IAM roles are used by which services, and which resources depend on which other resources. When something breaks, you'll know where to look. Use infrastructure-as-code tools like CloudFormation or Terraform so your setup is reproducible and version-controlled.

Test your disaster recovery plan. If a resource fails, do you know how to recover it? If a region goes down, can you fail over to another region? If your database gets corrupted, do you have a backup? Many AWS issues become crises because people don't know how to recover. Testing recovery procedures before you need them is the best prevention.

Frequently Asked Questions

What does it mean if AWS shows a service is degraded but I can still use it?

A degraded service means AWS is experiencing problems but hasn't completely shut it down. You might see slower performance, occasional errors, or intermittent unavailability. AWS is working on the fix. If your application is critical, consider failing over to another region or service while the degradation continues. Check the Service Health Dashboard for updates on when the service will return to normal.

Can I get a refund if AWS infrastructure goes down and I lose money?

AWS's service level agreement (SLA) offers service credits if uptime falls below a threshold — usually 99.9% or 99.99% depending on the service. The credits are applied to your AWS bill, not paid as cash. The credit amount is typically 10% to 100% of your monthly bill for that service, depending on how far uptime fell. You have to request the credit; AWS doesn't apply it automatically.

What's the difference between an AWS issue and a problem with my application code?

An AWS issue is a problem with the infrastructure, service, or account itself — something AWS provides. An application code problem is a bug in the software you wrote. If your code is throwing errors, that's your problem. If your code can't reach AWS because a security group is blocking it, that's an AWS configuration issue. If AWS infrastructure is down, no code can reach it. AWS support helps with AWS issues; you fix code issues yourself or hire a developer.

How long does it usually take AWS to fix an infrastructure outage?

Most AWS outages last minutes to hours, not days. AWS publishes post-incident reports after major outages that explain what happened and how long it took to fix. Small, localized issues might be resolved in 15 minutes. Larger issues affecting multiple services or regions might take several hours. During an outage, the Service Health Dashboard updates every few minutes with status and estimated time to resolution.

Do I need AWS Support to fix most issues, or can I do it myself?

Most AWS issues can be fixed without paid support if you know where to look. Configuration mistakes, permission problems, and performance issues are usually solvable by reading logs, checking the AWS console, and reviewing documentation. You need paid support when you're stuck, when you need faster response times, or when the issue is genuinely with AWS infrastructure rather than your account. Many people start with Basic Support and upgrade only when they hit a problem they can't solve alone.