AWS EC2 Linux Troubleshooting: A Practical Beginner’s Guide
Learn a practical, step-by-step approach to troubleshooting Linux workloads on Amazon EC2 using system, resource, service, log, and network checks.
AWS EC2 Linux Troubleshooting: A Practical Beginner’s Guide
When an application running on an Amazon EC2 Linux instance stops responding, restarting the server should not always be the first action.
A better approach is to investigate the problem systematically.
In this guide, I’ll walk through a simple troubleshooting workflow covering system health, CPU, memory, disk usage, services, logs, ports, DNS, and network connectivity.
The goal is not just to memorize Linux commands. It is to understand which command to use when a particular problem occurs.
1. Start by Understanding the Problem
Before running commands, identify what the user or application is actually experiencing.
For example:
- The website is not loading.
- SSH connection is failing.
- The application is very slow.
- A service stopped running.
- The server is running out of disk space.
- The instance is unreachable.
- An application cannot connect to another service.
This helps narrow down the troubleshooting path.
2. Check Basic System Information
Start with some basic information about the instance:
1
2
3
hostname
uname -a
uptime
What these commands tell us
hostname shows the server name.uname -a provides kernel and system information.uptime shows how long the system has been running and provides the system load average.For example:
1
uptime
If the load is unusually high, the next step is to investigate CPU, memory, processes, or I/O.
3. Check CPU Usage and Processes
If an application is slow, CPU usage is one of the first things to investigate.
1
top
Another useful command is:
1
ps aux
To search for a specific process:
1
ps aux | grep nginx
Instead of immediately restarting the instance, ask:
- Is CPU usage high?
- Which process is consuming CPU?
- Is that process expected?
- Is the process stuck or behaving abnormally?
This can help identify the actual cause of the problem.
4. Check Memory Usage
Memory exhaustion can cause applications and services to become unstable.
Use:
1
free -h
The
-h option displays memory values in a human-readable format.You can also use:
1
top
to identify processes consuming large amounts of memory.
If the instance is unresponsive, memory pressure is one of the areas worth investigating.
5. Check Disk Space
A full filesystem can cause applications to fail because they cannot create files, write logs, or store temporary data.
Check filesystem usage:
1
df -h
Example:
1
2
Filesystem Size Used Avail Use%
/dev/root 20G 18G 2G 90%
If a filesystem is close to 100%, investigate what is consuming the space.
For example:
1
sudo du -sh /var/* 2>/dev/null
Log files are one area worth checking because applications can generate large amounts of data over time.
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, blindly restarting a service can hide the underlying problem.
A better approach is:
1
systemctl status nginx
followed by checking the service logs.
7. Investigate Logs
Logs are one of the most valuable sources of information during troubleshooting.
For a
systemd service:1
journalctl -u nginx
To display the latest entries:
1
journalctl -u nginx -n 50
To follow new entries in real time:
1
journalctl -u nginx -f
Look for:
- Error messages
- Failed connections
- Permission problems
- Configuration errors
- Repeated failures
- Unexpected restarts
The goal is to connect the error message with the behavior you are investigating.
8. Check Listening Ports
Suppose an application should be running on port
8080.Check whether anything is listening on that port:
1
ss -tulnp | grep 8080
You can also view all listening sockets:
1
ss -tulnp
This helps answer an important question:
Is the application actually listening for connections?
If nothing is listening on the expected port, investigate the application or service before looking at external networking.
9. Test Network Connectivity
When an EC2 application cannot communicate with another system, test connectivity step by step.
Test basic connectivity:
1
ping 8.8.8.8
Test DNS resolution:
1
nslookup google.com
You can also use:
1
dig google.com
To test TCP connectivity to a specific port:
1
nc -zv example.com 443
This helps separate different problems:
1
2
3
4
5
6
7
Network connectivity
↓
DNS resolution
↓
TCP port connectivity
↓
Application connectivity
10. AWS Networking Must Also Be Checked
Linux troubleshooting is only one part of troubleshooting an EC2 instance.
If the application is running correctly but users still cannot reach it, investigate the AWS networking layer.
For example:
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
For SSH connectivity, AWS documentation specifically recommends checking whether the Security Group allows inbound traffic to port
22 from the appropriate source and whether the instance has a reachable public IPv4 address when required.For a web application, you would normally investigate the appropriate application port and the surrounding AWS networking configuration.
11. A Simple Troubleshooting Workflow
When an EC2 Linux application has a problem, I use this general workflow:
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 status
↓
3. Check CPU and memory
↓
4. Check disk space
↓
5. Check the application/service
↓
6. Check service logs
↓
7. Check listening ports
↓
8. Check DNS and connectivity
↓
9. Check Security Groups
↓
10. Check VPC networking
This prevents random troubleshooting and helps narrow down the root cause.
12. Example: Website Not Loading
Imagine an Nginx web server running on EC2 is not accessible.
I would investigate it like this:
Step 1 — Is Nginx running?
1
systemctl status nginx
Step 2 — Is Nginx 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 is not accessible externally, the application itself may be working.At this point, investigate the AWS networking configuration, including the Security Group, subnet, route table, and Internet Gateway where applicable.
This is an important troubleshooting principle:
If the application works locally but not externally, investigate the network path.
13. What I Learned
One of the biggest lessons from working with AWS and Linux is that troubleshooting should be methodical rather than random.
Instead of immediately restarting an EC2 instance, I try to answer smaller questions:
- 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 on the expected port?
- What do the logs say?
- Can the instance resolve DNS?
- Can it reach the destination?
- Is AWS networking allowing the traffic?
Each answer helps narrow down the possible cause.
Conclusion
AWS Cloud Support is not only about knowing AWS services.
A strong troubleshooting foundation requires understanding how AWS infrastructure, Linux, networking, and applications work together.
The combination of:
AWS + Linux + Networking + Troubleshooting
provides a strong foundation for working with cloud infrastructure.
I am continuing to build hands-on AWS labs and document the troubleshooting process behind them as I work toward a career in cloud engineering.
Useful AWS Documentation
For deeper investigation, AWS provides official EC2 troubleshooting documentation covering instance connectivity, status checks, Linux issues, and diagnostic procedures.
- Amazon EC2 troubleshooting
- Troubleshooting Linux EC2 status check failures
- Troubleshooting connections to Linux EC2 instances
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article