How can I troubleshoot AWS connectivity problems?

One of the simplest and quickest tools to test AWS connectivity -- or the connection between any two nodes on a TCP/IP network -- is the ping utility. Ping works by sending an Internet Control Message Protocol packet from a source system to a specific network name or IP address -- an AWS node, in this case.

Ping is native to Windows and can be used through a command-line interface:

C:\WINDOWS\system32>ping www.amazon.com

Ping also works though Linux operating systems and command lines:

ubuntu@ip-10-1-1-250:~$ sudo ping -c 1 www.amazon.com

Always refer to ping documentation for a specific operating system to select and understand the specific command-line switches and options. IT teams can make basic determinations about AWS connectivity and resource connections, such as an EC2 instance, by examining the ping response.

To check AWS connectivity, ping the IP address associated with AWS or a particular AWS resource. This will help guarantee that the destination is responding before troubleshooting. The first step to do this is to determine if the name resolves to an IP address.

Ping will attempt to resolve the name to a specific IP address and make several attempts to send a data packet. If the ping fails with an "unknown host" response and the company's network seems fine otherwise, check that you entered the correct target name. If the problem persists, the AWS target may be offline or inaccessible -- a blocked port is a potential cause for this problem. Developers can investigate AWS availability further through the AWS network status page.

If ping responds with an IP address, then the target server name is correct and the target should be accessible. For example, the Web server used in the ping command www.amazon.com should accept browser requests through port 80.

It is also possible to check the address-to-name resolution of your target destination using the "–a" switch with the ping utility under Windows, such as:

C:\WINDOWS\system32>ping -a 127.0.0.233

Or use the nslookup command with Linux:

ubuntu@ip-10-1-1-250:~$ nslookup 127.0.0.233

This approach attempts to resolve the target host name from the IP address. Look for the returned name and verify that it is correct for the expected target, such as an AWS load balanced node or other service. If an error occurs or the returned name is not associated with the correct node or service, there may be DNS failures or configuration problems.

Once the target name resolves, take another look at the percentage of successful ping responses and response times. It's not uncommon for public cloud providers such as AWS to apply low priority to ICMP packets; this can lead to a high percentage of packet loss. Admins should look for successful ping replies with low loss and response times below 250 milliseconds. A persistently high percentage of lost packets and excess response times may lead to application performance problems.

Tools such as Windows tracert or Linux traceroute can be used to trace the path and check delays between the data center source and AWS destination nodes. A trace utility can reveal additional details about each router hop and quickly help pinpoint possible performance bottlenecks across the public Internet. Remember: Timeouts in a tracert or traceroute report are not necessarily a problem because ICMP packets are often handled with low priority, but watch for hops with persistently high packet loss or packet loss that accumulates over several hops. It may be necessary to work with your internet service provider to determine and correct the underlying cause of the AWS connectivity problem.