An AWS Issue is a problem or error that stops your cloud resources from working the way you expect

An AWS Issue is Amazon's term for any problem with your cloud infrastructure, process, or account that prevents normal operation. It could be a service outage affecting thousands of users, a misconfigured security setting on your account, a failed database connection, or an error in the code you deployed. AWS Issues range from temporary hiccups that resolve in minutes to structural problems that require you to redesign how you built something.

The word "issue" itself is deliberately broad because AWS serves millions of customers running vastly different workloads. A retailer's website going down during a sale is an issue. A developer's API returning the wrong data is an issue. A security group rule that blocks all incoming traffic is an issue. What they have in common is that something is not behaving as intended.

Understanding what counts as an AWS Issue matters because it changes how you troubleshoot, who you contact for help, and whether the problem is on Amazon's side or yours. Most issues people encounter are configuration errors or code bugs in their own account — not failures of AWS infrastructure itself.

Key Takeaways

  • AWS Issues include service outages, account misconfigurations, code errors, and resource failures — anything that stops your cloud setup from working as intended.
  • AWS publishes a status page showing real-time outages affecting their infrastructure; checking it first saves time before you assume the problem is in your account.
  • Most issues people report are caused by their own configuration, permissions, or code rather than by AWS service failures.
  • AWS Support tiers (Basic, Developer, Business, Enterprise) determine how fast you get help and whether you can call a person or only use email and chat.
  • CloudWatch, CloudTrail, and VPC Flow Logs are the main tools AWS provides to diagnose issues in your own account without contacting support.

Service outages versus account-level problems

AWS Issues split into two categories, and knowing which one you have determines your next step. A service outage means AWS infrastructure itself is down — the EC2 service in a specific region is not accepting new instances, or S3 is returning errors for all users. These are rare and affect many customers at once. AWS publishes these on their AWS Service Health Dashboard, which shows real-time status for every service in every region.

An account-level issue affects only your resources or your account. Your database is down because you misconfigured the security group. Your Lambda function is failing because the code has a bug. Your S3 bucket is inaccessible because you accidentally deleted the bucket policy. These are far more common and only you see them — other customers using the same service in the same region are fine.

Before you contact AWS Support, check the Service Health Dashboard. If it shows green across all services in your region, the problem is in your account. If it shows red or yellow, AWS is investigating or has confirmed an outage, and you may need to wait or switch to a different region while they fix it.

Common types of AWS Issues and what causes them

Permission and access issues are the most frequent. You create an IAM user but forget to attach a policy, so they cannot read from S3. You set up a security group that blocks all inbound traffic, so your web server is unreachable. You create a database in a private subnet but try to connect from outside the VPC. These are not AWS failures — they are configuration choices you made that now prevent access.

Resource exhaustion happens when you run out of something you did not know you had a limit on. AWS sets soft limits on how many EC2 instances, RDS databases, or Elastic IPs you can create per account. If you hit the limit, new requests fail. You can request a limit increase, but it takes time. Similarly, if your process uses more CPU, memory, or network bandwidth than your instance type provides, performance degrades or the instance crashes.

Connectivity and networking issues occur when traffic cannot reach your resources. A misconfigured Network Access Control List (NACL) blocks traffic. A route table is missing an entry. Your VPN connection dropped. Your DNS records point to the wrong IP. Your process is trying to reach a database in a different VPC without a peering connection or transit gateway.

process and code errors are issues in the software you deployed, not in AWS itself. Your Lambda function times out because the code is inefficient. Your RDS query fails because the table does not exist. Your API returns a 500 error because the code has a null pointer exception. AWS provides the infrastructure; you provide the code.

How to diagnose an AWS Issue yourself

AWS provides three main tools to investigate issues without contacting support. CloudWatch collects logs and metrics from your resources. If your process is crashing, CloudWatch shows you the error messages and when they started. If your database is slow, CloudWatch shows CPU and memory usage. You can set up alarms to notify you when metrics cross a threshold.

CloudTrail records every API call made in your account — who made it, when, what they changed, and whether it succeeded. If a resource suddenly stopped working, CloudTrail shows you what changed. If someone deleted a security group or modified a policy, CloudTrail has the record. This is especially useful for permission issues, because you can see exactly which API call failed and why.

VPC Flow Logs capture network traffic to and from your instances. If traffic is not reaching your server, Flow Logs show whether the packets are arriving at the network interface. If they are arriving but your process is not responding, the problem is in the process, not the network. If they are not arriving, the problem is in routing, security groups, or NACLs.

Start with CloudWatch logs for your process. Look for error messages with timestamps. Then check CloudTrail to see what changed around that time. If the issue is network-related, enable VPC Flow Logs on the affected instance and try to reproduce the problem. These three tools answer most questions before you need to contact AWS.

When to contact AWS Support and what to expect

Contact AWS Support if you have checked the Service Health Dashboard, reviewed CloudWatch and CloudTrail, and still cannot find the cause. AWS Support is not free — it depends on your support plan. Basic Support is free but only includes access to documentation and community forums. Developer Support costs about $29 per month and gives you email support with a response time of 12 to 24 hours. Business Support costs more and includes phone support with faster response times. Enterprise Support is the highest tier and includes a dedicated technical account manager.

When you contact support, have the following ready: the exact error message, the timestamp when the issue started, the AWS region and service affected, the steps you took to diagnose it, and the output from CloudWatch, CloudTrail, or VPC Flow Logs. The more specific you are, the faster support can help. "My process is broken" takes longer to resolve than "My Lambda function returns a 504 timeout error starting at 2:15 PM UTC, and CloudWatch shows the function exceeded its 15-minute timeout limit."

AWS Support cannot fix code bugs or design flaws in your architecture — those are your responsibility. They can help you understand AWS behavior, confirm whether a service is working as documented, and escalate if there is an actual AWS infrastructure problem.

AWS Issues related to billing and account security

Some AWS Issues affect your account rather than your resources. If your account is compromised, someone may launch instances, create databases, or store data without your permission, resulting in unexpected charges. AWS will not reverse charges for unauthorized use, but they can help you find the account and prevent future access.

Billing issues — such as being charged for resources you thought you deleted, or seeing charges for services you did not use — are also common. Reserved Instances, data transfer costs, and storage charges are often misunderstood. If your bill is higher than expected, check the AWS Billing Dashboard to see which services are costing the most, then review the pricing page for that service to understand the charges.

Account lockouts happen when AWS detects suspicious activity and temporarily restricts your access. This is a security measure. Contact AWS Support to verify your identity and regain access. Enable multi-factor authentication (MFA) on your root account and use IAM users with limited permissions for day-to-day work to reduce the risk of compromise.

Preventing AWS Issues before they happen

Many AWS Issues are preventable with planning. Use Infrastructure as Code tools like CloudFormation or Terraform to define your resources in version-controlled files. This makes it straightforward to see what changed and roll back if something breaks. Manually clicking through the AWS console is error-prone and hard to audit.

Set up CloudWatch alarms for metrics that matter to your process — CPU usage, network throughput, error rates, database connections. Alarms can trigger notifications or automatically scale your resources. Catching a problem at 80% CPU is better than discovering it when users report the site is down.

Use AWS Config to monitor whether your resources comply with your own rules. For example, you can set a rule that all S3 buckets must have encryption enabled, or all security groups must not allow unrestricted SSH access. Config alerts you when something violates the rule, so you catch misconfigurations early.

Test your disaster recovery plan regularly. If a resource fails, can you recover it? How long does it take? Do you have backups? Do you have a failover region? Testing before disaster strikes means you know what to do when an issue actually occurs.

Frequently Asked Questions

What is the difference between an AWS Issue and an outage?

An outage is a specific type of AWS Issue — it means AWS infrastructure is down and affects many customers. An AWS Issue is any problem, including ones only you experience. Check the AWS Service Health Dashboard to see if there is an outage. If it shows green, the issue is in your account.

How do I know if an AWS service is down?

Go to the AWS Service Health Dashboard at status.aws.amazon.com. It shows real-time status for every AWS service in every region. Green means normal. Yellow means degraded performance. Red means the service is down. You can also subscribe to notifications so AWS emails you when status changes.

Can I get a refund if an AWS outage caused me to lose money?

AWS Service Level Agreements (SLAs) offer service credits if uptime falls below a threshold, but they do not cover lost revenue or business impact. Credits are typically 10 to 100% of your monthly bill for that service, depending on the SLA. You must request the credit within 30 days of the outage.

What should I do if I cannot figure out what is wrong with my AWS setup?

Start with CloudWatch logs and CloudTrail to see what your resources are doing and what changed. Check the AWS documentation for the service you are using. Search AWS forums and Stack Overflow — your issue is likely common and someone has solved it. If you still cannot find the answer, contact AWS Support through your support plan.

Do I have to pay for AWS Support to get help?

Basic Support is free and includes access to documentation, whitepapers, and community forums. Paid support plans (Developer, Business, Enterprise) give you direct contact with AWS engineers via email, chat, or phone. The cost depends on your plan and how fast you need a response.