Posted on

AWS Cloud Troubleshooting Basics

Nothing kills productivity faster than network issues in the cloud. Whether your EC2 instances can’t reach the internet, your microservices are failing to communicate, or DNS isn’t resolving hostnames correctly. AWS connectivity problems can feel overwhelming. Most issues can be isolated and solved quickly if you follow a systematic approach.

AWS commands can be run from Windows powershell with AWS CLI installed. Some commands query AWS resources directly using the AWS CLI, which requires appropriate IAM permissions.

AWS console is an alternate GUI-based tool that is much easier than CLI commands. You do not need to manually click through every page of the AWS console, but you can cross-check results in the console if you prefer a visual view of VPCs, subnets, route tables, and security groups.

Commands such as ping, traceroute, curl, and nslookup can be run via SSH session to an instance when testing connectivity and DNS resolution. This enables testing from within the AWS network since you are testing from the instance. Finally there is Linux bash shell or Windows CMD to run ping for internet latency and path forwarding from a local machine. cURL command will test up to the application layer externally or within the cloud.

*For free hands-on practice without any risk of billing charges, use AWS Educate or AWS Skill Builder sandbox instead of an AWS personal account.

This guide will show step-by-step troubleshooting techniques with symptoms, commands, and console/CLI instructions so you can quickly isolate and fix AWS networking problems.

How to Access the AWS Console for Network Troubleshooting

Step 1: Sign in to AWS

  1. Go to https://aws.amazon.com/console.
  2. Click “Sign in to the Console”.
  3. Enter your credentials.

Root user (email + password) or
IAM user (account ID or alias + IAM username + password)

Tip: For security, use an IAM user with the minimal permissions needed for network troubleshooting (VPC, EC2, CloudWatch).

Step 2: Navigate to the VPC Dashboard

  1. In the top search bar, type “VPC” and click the VPC service.
  2. Here you can see all your VPCs, subnets, route tables, internet gateways, NAT gateways, and security groups.

What to check here:

Confirm your EC2 instances are in the correct VPC and subnet.
Verify public/private subnet configurations.
Look at route tables and check if 0.0.0.0/0 points to an Internet Gateway for public subnets.

Step 3: Check EC2 Instances

  1. In the top search bar, type “EC2” and open the EC2 Dashboard.
  2. Click Instances to see all running EC2 instances.
  3. Click a specific instance to see:

Network interfaces (VPC and subnet ID)
Security groups (inbound/outbound rules)
Public/private IPs

Tip: Security groups are stateful, so check both inbound and outbound rules here.

Step 4: Inspect Security Groups

  1. From the EC2 instance details, click Security Groups.
  2. Check the rules for required ports (e.g., 80, 443, 22).
  3. Verify that the source/destination IPs are correct.

Step 5: Inspect NACLs (Network ACLs)

  1. Back in the VPC dashboard, click Network ACLs in the left menu.
  2. Identify the NACL attached to your subnet.
  3. Confirm that inbound and outbound rules allow the traffic you need.

Step 6: Inspect Route Tables

  1. In the VPC dashboard, click Route Tables.
  2. Find the route table associated with your subnet.
  3. Check the following settings:

Local routes (VPC traffic)
Internet routes (0.0.0.0/0 to IGW)
Routes to NAT Gateway (for private subnets)

Step 7: Use AWS Reachability Analyzer

  1. In the VPC dashboard, click Reachability Analyzer.
  2. Create a new analysis:
    3. Source: your EC2 instance or resource
    Destination: target instance, IP, or service
  3. Run the analysis to visualize network paths and see blocked traffic.

Step 8: Monitor with CloudWatch

  1. Navigate to CloudWatch in the search bar.
  2. Enable VPC Flow Logs for the subnets in question.
  3. Inspect logs for allowed and denied traffic, to help pinpoint security group or NACL issues.
  • You can do most of the troubleshooting directly in the AWS console, without running commands.
  • The console is visual and easier for spotting misconfigurations in VPCs, subnets, route tables, security groups, and NACLs.
  • Combine this with ping, traceroute, and curl commands from local machine to test internet connectivity, or SSH into EC2 instance for internal testing.

Step 1: Cannot access an application externally → Check VPC and Subnet Configuration (AWS CLI)

List network interfaces and subnets 
aws ec2 describe-network-interfaces --query 'NetworkInterfaces[*].{ID:NetworkInterfaceId,Subnet:SubnetId,PrivateIP:PrivateIpAddress}'

[
    {
        "ID": "eni-0a1b2c3d4e5f6g7h",
        "Subnet": "subnet-1234abcd",
        "PrivateIP": "10.0.1.15"
    },
    {
        "ID": "eni-1a2b3c4d5e6f7g8h",
        "Subnet": "subnet-5678efgh",
        "PrivateIP": "10.0.2.20"
    }
]
Check the VPC ID of your EC2 instance 
curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/

0a:1b:2c:3d:4e:5f/

AWS Console Method:

  • Go to VPC in the AWS console.
  • Verify your EC2 instances are in the correct subnet.
  • Check CIDR ranges and ensure the subnet is public if external access is required.

Step 2: Cannot reach the internet from an EC2 instance → Verify Route Tables and Internet Gateway

List route tables in your VPC (AWS CLI) 
aws ec2 describe-route-tables --query 'RouteTables[*].Routes'

[
    {
        "DestinationCidrBlock": "10.0.0.0/16",
        "GatewayId": "local",
        "State": "active"
    },
    {
        "DestinationCidrBlock": "0.0.0.0/0",
        "GatewayId": "igw-12345678",
        "State": "active"
    }
]
Test internet connectivity, IGW, route table, SG/NACL rules (Linux bash shell) 
ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=13.9 ms
Verify forwarding path to AWS instance (Linux bash shell) 
traceroute 10.0.1.15

traceroute to 10.0.1.15 (10.0.1.15), 30 hops max, 60 byte packets
 1 10.0.1.1 0.123 ms 0.111 ms 0.101 ms
 2 10.0.1.15 0.345 ms 0.332 ms 0.321 ms

AWS Console Method:

  • In VPC → Route Tables, select the route table for your subnet.
  • Confirm there is a `0.0.0.0/0` route to an Internet Gateway (IGW).
  • For private subnets, verify NAT Gateway or NAT instance routes.

Step 3: Internal instances cannot communicate → Ping EC2 Instances Internally

Ping another EC2 instance internally (AWS CLI) 
ping 10.0.1.15

PING 10.0.1.15 (10.0.1.15) 56(84) bytes of data.
64 bytes from 10.0.1.15: icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from 10.0.1.15: icmp_seq=2 ttl=64 time=0.322 ms

AWS Console Method:

  • Check EC2 → Instances.
  • Confirm security groups allow traffic between instances.
  • Verify subnet and routing for internal connectivity.

Step 4: Connections failing despite correct routing → Check Security Groups and NACLs

List security groups attached to an EC2 instance (AWS CLI) 
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].SecurityGroups'

[
 {
 "GroupName": "web-sg",
 "GroupId": "sg-0123abcd"
 },
 {
 "GroupName": "ssh-sg",
 "GroupId": "sg-0456efgh"
 }
]
Check network ACLs for a subnet (AWS CLI) 
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-1234abcd

[
 {
 "NetworkAclId": "acl-1234abcd",
 "Entries": [
   {"RuleNumber": 100, "Protocol": "6", "RuleAction": "allow", "Egress": false, "CidrBlock": "0.0.0.0/0"},
   {"RuleNumber": 100, "Protocol": "6", "RuleAction": "allow", "Egress": true, "CidrBlock": "0.0.0.0/0"}
 ]
 }
]

AWS Console Method:

  • Go to EC2 → Security Groups to inspect inbound/outbound rules.
  • In VPC → Network ACLs, verify that rules allow the required traffic.

Step 5: Application resolves hostname but fails to connect → Fix DNS or Routing Errors

Test DNS resolution (Linux bash shell) 
nslookup example.com

Server: 10.0.0.2
Address: 10.0.0.2#53

Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
Check the routing table inside the instance (AWS CLI) 
ip route

default via 10.0.0.1 dev eth0
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.1.15

AWS Console Method:

  • In VPC → Route Tables, verify proper routes for peered VPCs, VPNs, or Direct Connect.
  • In Route 53, check private hosted zones for misconfigurations.

Step 6: Connectivity restored? → Test Connectivity Again

Test HTTP connectivity (Linux bash shell) 
curl -I http://example.com

HTTP/1.1 200 OK
Date: Tue, 31 Mar 2026 12:00:00 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8
Test port connectivity to another instance (AWS CLI) 
nc -vz 10.0.1.15 22

Connection to 10.0.1.15 22 port [tcp/ssh] succeeded!
Optional: Use AWS Reachability Analyzer 
aws reachability-analyzer start-network-reachability-analysis --source i-1234567890abcdef0 --destination i-0abcdef1234567890

{
 "NetworkInsightsAnalysisId": "nia-0abcd1234efgh5678",
 "Status": "SUCCEEDED",
 "AnalysisState": "complete"
}

Console Method:

  • In VPC → Reachability Analyzer, run an analysis between source and destination resources to visualize network paths and blocked traffic.

Extra Tips

  • Document all changes: Use console notes or internal wiki.
  • Enable CloudWatch logs: Capture VPC Flow Logs to see allowed/denied traffic.
  • Automate connectivity tests: AWS Systems Manager scripts can run periodic checks.
  • Check IAM permissions: Some service-level network failures are due to insufficient permissions, not connectivity.

Conclusion

Network issues in AWS can be frustrating, but most are solvable with a structured approach. Start with VPC and subnet validation, move through routing, firewall, and DNS checks, and always test after making changes.

“Visibility is key in cloud networking. Document, monitor, and analyze your network, and you’ll turn frustrating connectivity problems into quick fixes.”

AWS Solutions Architect Associate Practice Tests