Full Diagnostic Tree & Step-by-Step Overview
What primary network protocol or service path is failing when connecting to your AWS EC2 instance?
- SSH (Port 22) or RDP (Port 3389) connection times out continuously
- HTTP (Port 80) or HTTPS (Port 443) web traffic timed out or unreachable
- AWS Systems Manager (SSM) Session Manager or EC2 Instance Connect fails
- Security Groups are open, but traffic is still dropped by subnet or host OS
Where is the target EC2 instance deployed within your Virtual Private Cloud (VPC)?
- Public Subnet with an assigned IPv4 Public IP or Elastic IP
- Private Subnet without a Public IP (Internal RFC 1918 address only)
Fix Missing Inbound Security Group Rules & IGW Routing for Public Subnet EC2
Solution:
Root Cause: Missing Inbound Security Group Rule or Absent Internet Gateway Route
The EC2 Security Group is blocking incoming packets on port 22 (SSH) or 3389 (RDP), or the VPC public subnet route table lacks an active default route (0.0.0.0/0) targeting an attached Internet Gateway (IGW).
# Step-by-Step Fix:
Update Inbound Security Group Rules:Open AWS Management Console -> EC2 -> Security Groups.Select the Security Group attached to your instance and click Edit inbound rules.Add Rule: Type SSH (Port 22) or RDP (Port 3389), Source My IP (or client CIDR x.x.x.x/32).Save rules and test connection via CLI: nc -zvw 5 YOUR_EC2_PUBLIC_IP 22.Verify VPC Subnet Route Table:Go to VPC Console -> Subnets -> Select your instance's subnet.Click the Route table tab.Ensure a route exists for 0.0.0.0/0 with Target set to igw-xxxxxxxx (Internet Gateway). Status must be Active.Verify Public IP & Auto-assign Settings:Confirm the instance has an active IPv4 Public IP attached in the EC2 instance summary details panel.
Configure Bastion Host, Client VPN, or SSM Tunneling for Private Subnet EC2
Solution:
Root Cause: Direct Public Inbound Access Attempted on Private Subnet Instance
EC2 instances residing in private subnets do not possess public IPv4 addresses and cannot accept direct inbound TCP connections over the public Internet.
# Step-by-Step Fix:
Connect via AWS Client VPN or Site-to-Site VPN:Establish a session to your AWS Client VPN endpoint authorized to route to the private VPC CIDR block.Use SSH Bastion Host (Jump Box):SSH into a public subnet Bastion instance: ssh -i key.pem ec2-user@BASTION_PUBLIC_IP.SSH from Bastion to private instance: ssh ec2-user@PRIVATE_IP.Use SSH Agent Forwarding locally: ssh -A -i key.pem ec2-user@BASTION_PUBLIC_IP.Configure AWS SSM Port Forwarding Tunnel:Tunnel SSH over SSM without public IPs: aws ssm start-session --target INSTANCE_ID --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["22"],"localPortNumber":["2222"]}'.Connect locally: ssh -p 2222 ec2-user@localhost.
How is incoming web traffic (HTTP/HTTPS) routed to the EC2 target instance?
- Traffic connects directly to the EC2 Public IP or Elastic IP
- Traffic passes through an AWS Application Load Balancer (ALB) / Target Group
Fix Web Traffic Inbound Security Group Rules and Web Server Process
Solution:
Root Cause: Security Group Blocking Ports 80/443 or Web Server Daemon Stopped
The EC2 Security Group inbound rules filter out HTTP (port 80) or HTTPS (port 443) packets, or the web server process (Nginx, Apache, Node.js) inside the OS has crashed.
# Step-by-Step Fix:
Add Web Ports to Inbound Security Group:Navigate to EC2 Console -> Security Groups -> Select attached Security Group.Click Edit inbound rules.Add Rule: Type HTTP (Port 80), Source 0.0.0.0/0 (and ::/0 for IPv6).Add Rule: Type HTTPS (Port 443), Source 0.0.0.0/0 (and ::/0 for IPv6).Verify Web Server Daemon Status:Connect via SSM or Console Serial and inspect process: systemctl status nginx or systemctl status httpd.Restart service if down: sudo systemctl restart nginx.Verify Local Port Binding:Test local binding: curl -I http://localhost:80 or netstat -tulpn | grep 80.
Align ALB Security Group and Target Group Security Group Inbound Rules
Solution:
Root Cause: Security Group Mismatch Between Application Load Balancer and EC2 Targets
The EC2 instance Security Group is blocking inbound traffic originating from the Application Load Balancer (ALB) Security Group, causing target group health check failures (Unhealthy state).
# Step-by-Step Fix:
Identify ALB Security Group ID:EC2 Console -> Load Balancers -> Select your ALB -> Copy the Security Group ID (e.g., sg-alb12345).Allow ALB Security Group in EC2 Instance Security Group:EC2 Console -> Security Groups -> Select your EC2 Instance Security Group -> Edit inbound rules.Add Rule: Type Custom TCP, Port Range 8080 (or target app port), Source Custom -> Select ALB Security Group ID (sg-alb12345).Verify Target Group Health Status:EC2 Console -> Target Groups -> Select Target Group -> Targets tab.Verify target status transitions from Unhealthy (Request timed out) to Healthy.
Which AWS native management tool is failing to connect?
- AWS Systems Manager (SSM) Session Manager reports 'TargetNotConnected'
- EC2 Instance Connect times out when attempting connection from AWS Console
Fix SSM Agent IAM Role, Outbound Security Group, and VPC Endpoints
Solution:
Root Cause: Missing IAM Instance Profile, Blocked Outbound HTTPS, or Missing SSM VPC Endpoints
The SSM Agent installed on the EC2 instance cannot establish an outbound encrypted WebSocket connection to AWS Systems Manager control plane endpoints.
# Step-by-Step Fix:
Attach AmazonSSMManagedInstanceCore IAM Role:EC2 Console -> Select Instance -> Actions -> Security -> Modify IAM role.Attach an IAM role containing AWS managed policy AmazonSSMManagedInstanceCore.Verify Outbound Security Group Traffic:Open Instance Security Group -> Edit outbound rules.Ensure Outbound rule allows HTTPS (Port 443) to 0.0.0.0/0 (or to SSM VPC Endpoint Security Group).Configure Interface VPC Endpoints (For Private Subnets without NAT Gateway):In VPC Console, create 3 Interface Endpoints with SG allowing Inbound 443 from EC2:com.amazonaws.[region].ssmcom.amazonaws.[region].ssmmessagescom.amazonaws.[region].ec2messagesRestart SSM Daemon inside OS:Linux: sudo systemctl restart amazon-ssm-agent | Windows: Restart-Service AmazonSSMAgent.
Authorize AWS EC2 Instance Connect Service IP Block in Security Group
Solution:
Root Cause: EC2 Instance Connect Regional Service IP Range Blocked by Security Group
EC2 Instance Connect pushes temporary SSH keys to instance metadata via API, but the browser SSH connection originates from AWS EC2 Instance Connect service IP blocks for that specific region.
# Step-by-Step Fix:
Fetch Regional EC2 Instance Connect IP Block:Query official AWS IP ranges JSON via CLI: curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.service=="EC2_INSTANCE_CONNECT") | select(.region=="YOUR_REGION") | .ip_prefix'.
Add Service IP Block to Inbound Security Group:Edit EC2 Security Group Inbound Rules.Add Rule: Type SSH (Port 22), Source Custom -> Insert the retrieved CIDR block (e.g., 18.206.107.24/29 for us-east-1).Verify EC2 Instance Connect Endpoint (EICE):If utilizing an EC2 Instance Connect Endpoint in a private VPC, grant Inbound SSH (22) in the EC2 SG explicitly from the EICE Security Group ID.
At which secondary network filtering boundary is incoming traffic being dropped?
- Subnet Network Access Control List (NACL) is dropping packets
- Host OS internal firewall (ufw, firewalld, or iptables) is dropping packets
Fix Network ACL (NACL) Inbound and Ephemeral Outbound Rules
Solution:
Root Cause: Subnet Network ACL (NACL) Blocking Stateless Traffic or Return Ephemeral Ports
Unlike stateful Security Groups, Network ACLs are stateless. If an Inbound NACL rule permits port 22/80 traffic, but the Outbound NACL rule blocks ephemeral response ports (1024-65535), return packets are dropped.
# Step-by-Step Fix:
Inspect Subnet Network ACL:VPC Console -> Subnets -> Select Instance Subnet -> Network ACL tab.Configure Inbound NACL Rules:Rule #100: Type SSH (22) (or HTTP/HTTPS), Protocol TCP, Action ALLOW, Source 0.0.0.0/0.Configure Ephemeral Outbound NACL Rules (Required for Stateless Return Traffic):Rule #100: Type Custom TCP, Port Range 1024-65535, Action ALLOW, Destination 0.0.0.0/0.*Note:* Ephemeral outbound ports are mandatory for client TCP handshakes to resolve.
Reset OS-Level Internal Firewall (UFW / Firewalld / iptables)
Solution:
Root Cause: OS-Level Local Firewall Blocking Inbound Port Traffic
Although the AWS cloud infrastructure (Security Groups and NACLs) permits incoming packets, local firewall software (ufw, firewalld, iptables) inside the instance OS rejects or drops connections.
# Step-by-Step Fix:
Access Instance via EC2 Serial Console or SSM Session Manager:EC2 Console -> Select Instance -> Connect -> EC2 Serial Console.Check and Update UFW (Ubuntu/Debian):Inspect status: sudo ufw status verbose.Allow SSH/HTTP: sudo ufw allow 22/tcp && sudo ufw allow 80/tcp.Or disable UFW temporarily for diagnostic validation: sudo ufw disable.Check and Update Firewalld (RHEL/CentOS/Rocky Linux):Inspect status: sudo firewall-cmd --state.Grant service: sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload.Audit IPtables Chains:Inspect rules: sudo iptables -L -n -v.Flush blocking chains if necessary: sudo iptables -F.