AWS EC2 Linux Troubleshooting: A Practical Guide for Cloud Support
A practical troubleshooting workflow for AWS EC2 Linux instances covering CPU, memory, disk, services, logs, ports, DNS, and AWS networking.
AWS EC2 Linux Troubleshooting: A Practical Guide for Cloud Support
When an application running on an AWS EC2 Linux instance stops responding, restarting the server should not always be the first step.
A better approach is to investigate the problem systematically.
As I continue learning AWS Cloud Support, I have found that combining AWS infrastructure knowledge with Linux and networking troubleshooting makes it much easier to understand what is actually happening.
In this guide, I’ll walk through a simple troubleshooting workflow that can be applied to common EC2 problems.
🔎 1. Understand the Problem First
Before running commands, identify the actual symptom.
For example:
- The website is not loading.
- SSH is failing.
- The application is slow.
- A service has stopped.
- Disk space is running out.
- The server cannot reach another service.
- Users cannot connect to the application.
The symptom tells us where to start investigating.
💻 2. Check Basic System Information
Start with some basic information about the instance:
1
2
3
hostname
uname -a
uptime
What do these commands tell us?
hostname shows the system hostname.uname -a provides kernel and system information.uptime shows how long the system has been running and provides information about system load.This gives us a quick overview before going deeper.
📊 3. Check CPU and Processes
If an application is slow, CPU usage is one of the first things I investigate.
1
top
Another useful command is:
1
ps aux
To search for a specific process:
1
ps aux | grep nginx
The important part is not simply running
top.I want to understand:
- Is CPU usage unusually high?
- Which process is consuming CPU?
- Is that process expected?
- Is the process stuck or behaving abnormally?
This helps move from a symptom toward a possible root cause.
🧠 4. Check Memory
Memory pressure can cause applications to become slow or unstable.
Use:
1
free -h
The
-h option makes the output easier to read.I also use:
1
top
to identify processes that are consuming significant memory.
If an EC2 instance becomes unresponsive, memory usage is one of the areas worth investigating.
💾 5. Check Disk Space
A full filesystem can cause applications to fail because they cannot write files or logs.
Check disk usage:
1
df -h
For example:
1
2
Filesystem Size Used Avail Use%
/dev/root 20G 18G 2G 90%
If disk usage is very high, investigate which directories are consuming the space.
For example:
1
sudo du -sh /var/* 2>/dev/null
Log files are one area worth checking because applications can generate a large amount of log data.
⚙️ 6. Check Services
Linux services are commonly managed using
systemd.For example, if Nginx is expected to be running:
1
systemctl status nginx
To start it:
1
sudo systemctl start nginx
To restart it:
1
sudo systemctl restart nginx
However, restarting a service immediately is not always the best troubleshooting step.
First, I want to understand why the service failed.
📋 7. Check Logs
Logs are one of the most useful sources of information when troubleshooting Linux systems.
For a systemd service:
1
journalctl -u nginx
To view the latest entries:
1
journalctl -u nginx -n 50
To follow logs in real time:
1
journalctl -u nginx -f
I look for:
- Error messages
- Permission problems
- Failed connections
- Configuration errors
- Repeated failures
- Unexpected restarts
The goal is to connect the log message with the problem being investigated.
🌐 8. Check Listening Ports
Suppose an application should be running on port
8080.Check whether anything is listening:
1
ss -tulnp | grep 8080
Or view all listening ports:
1
ss -tulnp
This answers an important question:
Is the application actually listening for connections?
If nothing is listening on the expected port, the problem may be inside the application or service.
🔗 9. Test Network Connectivity
When an EC2 instance cannot communicate with another system, I test connectivity step by step.
Test basic network connectivity:
1
ping 8.8.8.8
Test DNS resolution:
1
nslookup google.com
You can also use:
1
dig google.com
To test a TCP port:
1
nc -zv example.com 443
This helps separate different types of problems:
1
2
3
4
5
6
7
Network connectivity
↓
DNS resolution
↓
TCP connectivity
↓
Application connectivity
☁️ 10. Remember the AWS Layer
Linux troubleshooting is only one part of troubleshooting an EC2 instance.
If the application works locally but users cannot reach it externally, I investigate the AWS networking layer.
A simplified request path can look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
User
↓
Internet
↓
Internet Gateway
↓
Route Table
↓
Subnet
↓
Security Group
↓
EC2
↓
Linux
↓
Application
At the AWS level, I would investigate:
- EC2 instance state
- Instance status checks
- Public/private IP configuration
- Security Groups
- Subnet
- Route Table
- Internet Gateway
- Network ACLs where relevant
This is where understanding both Linux and AWS networking becomes extremely useful.
🧪 11. Example: Website Is Not Loading
Imagine an Nginx web server is running on an EC2 instance, but the website cannot be accessed.
I would investigate in this order.
Step 1 — Is Nginx running?
1
systemctl status nginx
Step 2 — Is it listening?
1
ss -tulnp | grep nginx
Step 3 — Check the logs
1
journalctl -u nginx -n 50
Step 4 — Test locally
1
curl localhost
If
curl localhost works but the website cannot be reached externally, the application may be working correctly.I would then investigate the AWS networking path, including the Security Group, route table, subnet, and Internet Gateway where applicable.
This gives us an important troubleshooting principle:
If the application works locally but not externally, investigate the network path.
🧠 12. My Troubleshooting Checklist
When investigating an EC2 Linux problem, I use this general flow:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. Understand the symptom
↓
2. Check EC2 health
↓
3. Check CPU and memory
↓
4. Check disk space
↓
5. Check services
↓
6. Check logs
↓
7. Check listening ports
↓
8. Check DNS and connectivity
↓
9. Check Security Groups
↓
10. Check VPC networking
The important thing is to troubleshoot from the inside out and outside in, depending on the symptom.
🎯 Key Takeaways
The biggest lesson for me is that cloud troubleshooting is not about memorizing commands.
It is about asking the right questions.
Instead of immediately restarting an instance, I try to determine:
- Is the instance healthy?
- Is the operating system responsive?
- Is CPU or memory under pressure?
- Is the filesystem full?
- Is the service running?
- Is the application listening?
- What do the logs say?
- Can the system resolve DNS?
- Can it reach the destination?
- Is AWS allowing the required traffic?
Each answer reduces the number of possible causes.
🚀 Conclusion
AWS Cloud Support requires more than knowing AWS service names.
Understanding how AWS infrastructure, Linux, networking, and applications work together provides a much stronger foundation for troubleshooting real-world problems.
For me, the combination of:
AWS + Linux + Networking + Troubleshooting
is an important part of my journey toward becoming a Cloud Engineer.
I’ll continue building hands-on AWS labs and documenting the troubleshooting process behind them.
💬 What is your first troubleshooting step?
When an EC2 application suddenly becomes unreachable, what do you check first:
CPU/memory, application status, logs, ports, or AWS networking?
I'd be interested to hear how other AWS Builders approach the problem.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article