AWS Troubleshooting Practice: 7 Problems Every Cloud Support Beginner Should Learn
A practical guide to seven common AWS and Linux troubleshooting problems, with a systematic approach to finding root causes and building hands-on cloud support skills.
Cloud support is not only about knowing AWS services. A big part of the job is understanding what went wrong, finding the root cause, and fixing the issue without making things worse.
As a student preparing for entry-level cloud support roles, I have found that troubleshooting becomes much easier when you practice realistic problems instead of only reading service documentation.
This article covers seven common AWS and Linux troubleshooting scenarios that beginners can practice.
1. EC2 Instance Is Not Reachable
One of the first problems to practice is an EC2 instance that cannot be accessed through SSH.
Instead of immediately restarting the instance, check the problem layer by layer:
- Is the instance running?
- Does it have the expected public or private IP?
- Does the subnet have the correct route?
- Is the Internet Gateway configured when internet access is required?
- Does the Security Group allow SSH on port 22?
- Are Network ACL rules blocking the traffic?
- Is the SSH service running on the operating system?
This is a good example of why cloud troubleshooting requires both AWS networking knowledge and Linux knowledge.
2. S3 Access Denied
Another common issue is receiving an
AccessDenied error while accessing an S3 bucket or object.The first step should be identifying who is making the request and what permission is actually required.
Check:
- IAM identity policies
- S3 bucket policies
- IAM roles
- Block Public Access settings
- Object ownership and permissions
- Whether the requested resource is actually the expected bucket/object
Avoid immediately adding broad permissions such as
AdministratorAccess.The goal of troubleshooting should be to find the missing permission and provide only the access that is actually required.
3. IAM Permission Problems
IAM issues can sometimes be confusing because several policies may affect the final result.
When troubleshooting an IAM problem, I would start with:
- Identify the IAM user or role.
- Identify the AWS API action being attempted.
- Identify the resource being accessed.
- Check identity-based policies.
- Check resource-based policies where applicable.
- Look for explicit denies.
- Test again after making the smallest required change.
This approach is much better than continuously adding permissions until the error disappears.
4. Linux Service Is Not Running
Cloud support often involves troubleshooting the operating system inside an EC2 instance.
For example, if Nginx is not responding, I would start with:
1
systemctl status nginxIf the service has failed, check the logs:
1
journalctl -u nginx -n 50You can also verify whether the process is listening on the expected port:
1
ss -tulpnThe important lesson is to use evidence from the system instead of guessing.
5. Application Returns HTTP 504
A
504 Gateway Timeout usually means that a gateway or proxy did not receive a timely response from the upstream service.For troubleshooting, check the request path:
1
2
3
4
5
6
7
Client
↓
Load Balancer / Proxy
↓
Application
↓
Database / DependencyThen investigate each layer.
For example:
- Is the target healthy?
- Is the application process running?
- Is the application listening on the expected port?
- Can the application reach its dependency?
- Are Security Groups allowing the required traffic?
- Are there application or system logs showing delays?
Thinking about the complete request path helps narrow down the failure.
6. DNS Is Not Resolving
If an application works through an IP address but not through its domain name, DNS should be one of the first things to investigate.
Useful checks include:
1
nslookup example.comor:
1
dig example.comCheck whether the DNS record exists and whether it points to the expected destination.
Also remember that DNS problems can sometimes look like application or networking problems, so testing name resolution separately is important.
7. CloudWatch Shows a Problem
Monitoring data is useful only when you know how to interpret it.
Suppose an EC2 instance suddenly shows high CPU utilization.
Instead of immediately increasing the instance size, investigate:
- When did the increase begin?
- Which process is consuming CPU?
- Did a deployment happen around the same time?
- Are there related memory, disk, or network changes?
- Do application logs show an error?
- Is the problem temporary or continuous?
Useful Linux commands include:
1
topand:
1
ps aux --sort=-%cpu | headCloudWatch can tell you that something changed. System and application investigation helps determine why.
A Simple Troubleshooting Framework
When facing an unfamiliar cloud issue, I try to follow a simple process:
1. Understand the symptom
What exactly is failing?
For example:
"The website is not loading."
This is only a symptom, not the root cause.
2. Reproduce the problem
Try to confirm the issue yourself.
Check whether it happens consistently or only under certain conditions.
3. Break the system into layers
Think about:
1
2
3
4
5
6
7
8
9
10
11
12
13
User
↓
DNS
↓
Network
↓
Load Balancer
↓
Application
↓
Database / Dependency
↓
Operating System4. Collect evidence
Use:
- AWS console
- CloudWatch
- AWS CLI
- Linux commands
- Service logs
- Application logs
- Network tests
5. Identify the root cause
Do not stop at the first error you find.
Ask:
Why did this happen?
6. Apply the smallest safe fix
Avoid making large changes without understanding their impact.
7. Verify the fix
Test the original problem again and confirm that the system is working normally.
8. Document what happened
A good support engineer should be able to explain:
- What happened
- Why it happened
- How it was fixed
- How it can be prevented
Practice Is More Valuable Than Memorizing Commands
For beginners, troubleshooting can initially feel difficult because there can be many possible causes for the same symptom.
The solution is not to memorize hundreds of commands.
Instead, practice the troubleshooting process repeatedly.
For example, create small labs where you intentionally:
- Remove an EC2 Security Group rule.
- Break a route configuration.
- Stop an important Linux service.
- Change an IAM permission.
- Create an incorrect DNS record.
- Introduce an application configuration problem.
- Monitor the resulting failure.
Then try to find the problem without looking at the solution first.
This turns AWS knowledge into practical troubleshooting experience.
What I Am Practicing
My current learning focus is AWS Cloud Support, Linux, and networking.
I am particularly interested in practicing problems around:
- EC2
- VPC
- IAM
- S3
- Security Groups
- DNS
- Linux services
- CloudWatch
- AWS CLI
- Root cause analysis
I believe these fundamentals are important for anyone preparing for an entry-level cloud support or cloud engineering role.
Final Thoughts
Learning AWS services is important, but knowing how those services fail is equally important.
A real support situation rarely says:
"The problem is your Security Group."
Instead, you may hear:
"The application was working yesterday, but users cannot access it today."
The real skill is taking that symptom, investigating systematically, finding the root cause, applying a safe fix, and explaining what happened.
That is the kind of hands-on troubleshooting experience I am working toward as I continue my cloud journey.
What AWS troubleshooting problem was the hardest for you when you were learning?
Share your experience in the comments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article