I Broke AWS on Purpose: 10 Troubleshooting Scenarios Every Beginner Should Try
Learning AWS is easy when everything works. The real learning begins when something breaks. This article covers 10 realistic AWS troubleshooting scenarios for beginners, including EC2, IAM, Lambda, S3, CloudWatch, networking, and configuration issues. Instead of simply following solutions, you’ll learn how to investigate problems, identify root causes, and build a practical troubleshooting mindset for real-world AWS and DevOps environments.
I Broke AWS on Purpose: 10 Troubleshooting Scenarios Every Beginner Should Try
Learning AWS is easy when everything works.
You create a resource, follow the documentation, run a few commands, and everything looks perfect.
But real cloud environments are different.
At some point, an application will stop responding. A deployment will fail. A Lambda function will suddenly return an error. An EC2 instance will be running but unreachable. A user will have the correct-looking IAM policy but still receive
AccessDenied.This is where troubleshooting becomes one of the most important skills for a cloud or DevOps engineer.
Instead of learning AWS only by creating resources, try creating problems and solving them.
Below are 10 beginner-friendly scenarios that can help develop that troubleshooting mindset.
1. EC2 Instance Is Running but You Cannot Connect
Scenario
You launch an EC2 instance and AWS shows:
Instance state: Running
But you cannot connect to it.
What could be wrong?
Don't immediately terminate the instance and create another one.
Start investigating:
- Is the instance in the correct subnet?
- Does the subnet have a route to an Internet Gateway?
- Does the Security Group allow SSH?
- Is the correct port open?
- Is the Network ACL blocking traffic?
- Are you using the correct key pair?
- Does the instance have a public IPv4 address?
- Is the operating system itself running correctly?
Troubleshooting mindset
Start from the outside and move inward:
Internet → Route → Security Group → Instance → Operating System
The goal isn't just to fix the connection.
The goal is to understand where the connection is failing.
2. EC2 Is Reachable but the Website Does Not Open
Scenario
You can connect to your EC2 instance through SSH, but visiting:
http://your-public-ipdoesn't work.
Investigate
Check whether your application is actually running.
For example:
1
systemctl status nginxThen check whether the server is listening on port 80:
1
sudo ss -tulpnThen check:
- Is Nginx installed?
- Is Nginx running?
- Is port 80 allowed in the Security Group?
- Is the operating system firewall blocking port 80?
- Is the application listening on the expected interface and port?
This teaches an important lesson:
Being able to reach a server does not mean the application running on that server is healthy.
3. IAM User Gets AccessDenied
Scenario
A developer tries to access an S3 bucket and receives:
1
AccessDeniedThe developer says:
"But I already have an S3 policy!"
Don't assume the policy is the problem.
Investigate:
- Which IAM identity is actually making the request?
- What permissions does the identity have?
- Is there an explicit Deny?
- Is the bucket policy restricting access?
- Is a permissions boundary involved?
- Is an SCP affecting the account?
- Is the request going to the correct AWS account and Region?
Key lesson
AWS permissions aren't simply:
Allow = access
A Deny from another policy layer can change the final result.
Learning to identify the effective permission is much more valuable than memorizing IAM policies.
4. Lambda Function Works Locally but Fails in AWS
Scenario
Your Lambda function works perfectly during development.
After deploying it, it starts failing.
Investigate
Look at CloudWatch Logs first.
Don't guess.
Check:
- Runtime errors
- Environment variables
- IAM execution role
- Timeout
- Memory configuration
- VPC configuration
- Network connectivity
- Dependency/package issues
For example, if Lambda needs to access an AWS service, ask:
Does the Lambda execution role actually have permission to perform that operation?
If Lambda is attached to a VPC, also ask:
Does it still have the network connectivity required by the application?
5. S3 Bucket Works for One User but Not Another
Scenario
User A can access an S3 object.
User B receives:
1
AccessDeniedBoth users appear to have similar IAM permissions.
Investigate
Look beyond the IAM user.
Check:
- IAM policies
- Bucket policy
- Object ownership
- Block Public Access settings
- Encryption configuration
- KMS permissions
- Account-level restrictions
This is a good example of why cloud troubleshooting requires looking at multiple layers at the same time.
6. CloudWatch Alarm Is Not Triggering
Scenario
You created a CloudWatch alarm expecting it to notify you when CPU utilization becomes high.
The CPU goes above your threshold.
But nothing happens.
Investigate
Check:
- Is the alarm monitoring the correct metric?
- Is it monitoring the correct instance?
- Is the threshold correct?
- Is the evaluation period correct?
- Is the alarm actually entering
ALARMstate? - Is the SNS notification configured?
- Is the SNS subscription confirmed?
Don't assume:
"No notification = CloudWatch isn't working."
The failure could be anywhere between the metric and the notification.
7. Application Returns HTTP 500
Scenario
Your website loads, but one endpoint returns:
1
500 Internal Server ErrorThis is a perfect opportunity to practice structured troubleshooting.
Start with the application logs.
Then determine:
Is the problem in the application, database, configuration, authentication, or infrastructure?
Check:
- Application logs
- Environment variables
- Database connectivity
- Credentials
- Recent deployments
- Dependency changes
- CPU and memory usage
Avoid randomly changing configuration.
First identify the layer where the failure occurs.
8. Load Balancer Shows Unhealthy Targets
Scenario
An Application Load Balancer is running, but its target group shows:
Unhealthy
The EC2 instances themselves appear healthy.
What do you check?
Look at the health check configuration:
- Protocol
- Port
- Health check path
- Expected response code
- Security Group rules
- Application listener
- Application process
For example, if the load balancer checks:
1
/healthbut your application only responds successfully to:
1
/the instance may be perfectly healthy while the target remains unhealthy.
Key lesson
Infrastructure health and application health are not always the same thing.
9. Deployment Suddenly Fails After a Small Change
Scenario
A deployment worked yesterday.
Today, someone changed a small configuration value and the deployment fails.
Instead of rebuilding everything, investigate what changed.
Compare:
- Git changes
- Environment variables
- Infrastructure changes
- Dependency versions
- IAM permissions
- Deployment logs
- Recent AWS configuration changes
A useful troubleshooting question is:
What changed between the last known good state and the first failing state?
This single question can save a huge amount of time.
10. Everything Looks Healthy but the Application Is Slow
Scenario
There are no obvious errors.
EC2 is running.
The load balancer is healthy.
CloudWatch shows no major alarms.
But users complain that the application is slow.
This is where troubleshooting becomes more interesting.
Look at:
- CPU utilization
- Memory usage
- Network metrics
- Disk performance
- Application response times
- Database performance
- Request patterns
- Logs
- Traffic increases
Don't immediately assume that the EC2 instance is the problem.
The bottleneck could be somewhere else.
A Simple Troubleshooting Framework
When something breaks in AWS, beginners often jump directly to changing things.
Instead, try this process:
1. Reproduce
Can you consistently reproduce the problem?
2. Define
What exactly is failing?
For example:
"The website is down"
is less useful than:
"The EC2 instance is reachable through SSH, but HTTP requests to port 80 time out."
3. Identify the Layer
Ask where the failure is happening:
User → DNS → Load Balancer → Network → EC2 → Application → Database
4. Collect Evidence
Use:
- CloudWatch
- CloudTrail
- Application logs
- EC2 system logs
- AWS Console
- AWS CLI
- Network information
- Metrics
5. Change One Thing
Avoid changing five settings at once.
If you change everything simultaneously, you may fix the problem without knowing why it was broken.
6. Verify
After making the change, reproduce the original problem.
Did it actually disappear?
7. Find the Root Cause
Don't stop at:
"It works now."
Ask:
"Why did it fail in the first place?"
The Most Important Skill: Asking Better Questions
Good troubleshooting isn't about knowing every AWS service.
It's about asking the right questions.
Instead of:
Why isn't my application working?
Ask:
Is the request reaching the load balancer?
Then:
Is the load balancer reaching the target?
Then:
Is the target accepting the request?
Then:
Is the application processing the request?
Then:
Is the application able to reach its dependencies?
Breaking a large problem into smaller questions makes complicated incidents much easier to solve.
Try Breaking Your Own AWS Environment
If you're a beginner, don't be afraid to experiment in a safe AWS environment.
Create a small lab.
Then intentionally introduce one problem.
For example:
- Remove an IAM permission.
- Block a port in a Security Group.
- Change an application's health-check path.
- Stop a service.
- Change an environment variable.
- Remove a required route.
- Change a CloudWatch alarm threshold.
Then try to diagnose the problem without immediately looking at the solution.
Once you find the root cause, restore the configuration and document what happened.
This turns AWS learning from:
"I followed a tutorial."
into:
"I found and fixed a production-like problem."
Final Takeaway
AWS troubleshooting is a skill that improves through repetition.
You don't need to know every AWS service before you start.
Start with small failures.
Break something.
Observe what changes.
Collect evidence.
Test your hypothesis.
Fix the problem.
Then ask yourself one final question:
"What could I have checked first to solve this faster?"
That question is how troubleshooting experience is built.
The next time your AWS environment breaks, don't see it only as an error.
See it as a lab.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article