3

When an AWS EC2 instance becomes slow, CPU utilization is often the first metric administrators check. However, low CPU usage does not necessarily mean that the server is healthy or that the CPU is the source of the problem.

An EC2 instance can experience slow application responses, delayed SSH sessions, database timeouts, or sluggish websites while CPU utilization remains relatively low. This usually means another system resource or application component is creating a bottleneck.

The key to troubleshooting this type of problem is to look beyond CPU usage and examine memory, storage, network activity, application processes, and AWS-specific performance metrics.

Why Can an EC2 Instance Be Slow With Low CPU?

Low CPU usage can occur when a process is waiting for another resource. For example, an application may be waiting for disk I/O, a database may be waiting for storage operations, or a service may be blocked by network communication.

Common causes include:

• High disk I/O
• Slow or saturated EBS volumes
• Insufficient memory
• Excessive swap usage
• Network latency
• Database bottlenecks
• Application-level delays
• File-system problems
• CPU credit limitations on burstable instances
• Too many processes waiting for resources

The first step is to determine which resource is actually limiting performance.

1. Check Memory Usage

Start by checking the available memory on the instance:

free -h

Do not focus only on the free value. Linux uses unused memory for filesystem caching, so available memory is generally more useful when assessing memory pressure.

Look for very low available memory and significant swap usage.

You can also identify memory-heavy processes with:

ps aux –sort=-%mem | head

If the system is constantly running short of RAM, applications may become slow even though CPU utilization remains low.

A process waiting for memory or repeatedly accessing swap can make the entire system feel sluggish.

2. Check for Swap Activity

Swap is another important area to investigate.

Run:

swapon –show

and:

free -h

Heavy swap usage can cause noticeable performance degradation because storage is considerably slower than physical RAM.

If the server is actively swapping, identify which applications are consuming memory and determine whether the instance has enough RAM for its workload.

Adding memory may be more effective than attempting to optimize CPU usage.

3. Investigate Disk I/O

A slow EC2 instance with low CPU utilization is often experiencing storage-related delays.

Use:

iostat -xz 1

if the sysstat package is available.

Look at metrics such as utilization, read/write activity, and I/O wait. A high I/O wait percentage indicates that processes are spending time waiting for storage operations.

You can also use:

iotop

to identify processes generating significant disk activity, if the utility is installed.

Typical causes include:

• Large backup operations
• Database activity
• Log processing
• File synchronization
• Heavy application writes
• Storage-intensive scripts

Finding the process responsible can help determine whether the workload can be optimized or rescheduled.

4. Examine Amazon EBS Performance

The storage device itself may be responsible for the slowdown.

For EC2 instances using Amazon EBS, review CloudWatch metrics related to the attached volumes. Depending on the volume type, useful metrics can include read/write operations, throughput, latency, and burst or performance-related metrics.

Check whether the workload is approaching the configured IOPS or throughput limits.

For example, a workload that generates many small random operations may require different storage characteristics from one that performs large sequential transfers.

If the application regularly reaches the storage volume’s performance limits, changing the EBS configuration may improve responsiveness.

5. Check CPU Steal and I/O Wait

Overall CPU utilization can sometimes hide what the CPU is actually doing.

Use:

top

Look at the CPU breakdown, including %wa, which represents I/O wait.

A high I/O wait value means the CPU is not necessarily busy executing instructions; instead, processes are waiting for storage operations to complete.

This explains why a server can show relatively low user CPU usage while still feeling extremely slow.

The distinction between CPU usage and CPU wait time is important when diagnosing performance problems.

6. Check Network Performance

Network-related delays can also make an EC2 instance appear slow.

An application may have plenty of CPU and memory available but still take a long time to respond because it is waiting for another server, database, API, or external service.

Investigate:

• Network throughput
• Packet loss
• Connection errors
• DNS resolution delays
• External API response times
• Database connection latency

AWS CloudWatch network metrics can help establish whether network traffic has changed significantly.

For application-specific problems, review logs and request timings to determine whether delays occur locally or while communicating with another service.

7. Investigate Database Performance

If the EC2 instance hosts a database, database performance should be examined separately.

A database can become slow because of inefficient queries, locking, insufficient indexes, excessive connections, or storage latency.

For MySQL or MariaDB environments, review currently running queries and database logs.

A slow query can make websites and applications appear unresponsive without causing high CPU utilization. The database process may simply be waiting for disk I/O or locks.

If the database is hosted separately, network latency between the application and database servers should also be considered.

8. Look for Disk Space Problems

A nearly full filesystem can create unexpected application problems.

Check disk usage with:

df -h

Also check inode availability:

df -i

A filesystem can have free disk space but still run out of inodes if it contains a very large number of small files.

Pay particular attention to locations such as /var, /tmp, application directories, and database storage paths.

Large logs, temporary files, old backups, and cached data can gradually consume available resources.

9. Check Running Processes and Services

A slow server may have a process that is blocked, repeatedly failing, or generating excessive activity.

Use:

top

and:

ps aux

Review the process list for unexpected services, unusually high memory consumers, or applications that have accumulated many workers.

System logs can provide additional clues:

journalctl -p warning..alert

Look for repeated service failures, storage errors, network problems, or application-related messages.

10. Check Burstable Instance Performance

If you are using a burstable EC2 instance, such as a T-family instance, CPU credit metrics should also be reviewed.

A workload that continuously requires more CPU than the instance’s baseline can behave differently once its available CPU credits are depleted, depending on the instance configuration.

Review CPU credit-related metrics in CloudWatch alongside CPU utilization rather than relying on the CPU percentage alone.

11. Review Application-Level Performance

Infrastructure metrics may appear normal while the application itself is slow.

Review:

• Request response times
• Application logs
• Worker queues
• Connection pools
• Cache performance
• API dependencies
• Database response times
• Background jobs

For web applications, compare slow requests with server metrics. This can help determine whether the bottleneck is inside the EC2 instance or an external dependency.

Build a Complete Performance Picture

Troubleshooting should not rely on a single metric.

A useful performance investigation combines:

CPU + Memory + Disk I/O + EBS + Network + Database + Application metrics

Compare current measurements with a known healthy period. This makes it easier to identify what changed before the slowdown began.

For example, if CPU and memory remain normal while EBS latency increases significantly, storage is a stronger candidate than the processor.

Conclusion

An EC2 instance running slowly with low CPU usage is not unusual. CPU utilization represents only one part of overall system performance.

Start by checking memory and swap usage, then investigate disk I/O, EBS performance, I/O wait, network activity, database operations, filesystem capacity, and application behavior. Also review CloudWatch metrics and instance-specific characteristics such as CPU credits.