AWS Partner How to Fix AWS EC2 Connection Timed Out

AWS Account / 2026-07-08 12:40:38

What “EC2 connection timed out” really means

When you try to connect to an EC2 instance and the browser/SSH client reports connection timed out, the key point is that your traffic is not reaching the instance (or not getting a response). This is different from errors like “connection refused,” which usually means the instance is reachable but the specific service is not listening.

In practice, “timed out” is most often caused by one of these: security groups blocking the path, network ACLs or routing issues, instance in the wrong subnet/route table, incorrect public IP usage, the instance stopped or in a degraded state, or the OS/firewall not allowing the port.

The fastest way to fix it is to treat the problem as a chain. If any link breaks, the connection fails. The steps below guide you from the outside in, with concrete checks and what each check tells you.

Step 1: Confirm the instance is actually reachable

Verify instance state

Go to the EC2 console and check the instance state. If it’s stopped, it won’t respond. If it’s running, proceed, but also confirm the status checks:

Status checks passed means AWS health checks are OK.
If you see system reachability or instance reachability failures, connection issues can be upstream of security rules.

Confirm the correct IP to connect to

AWS Partner Connection timeouts often come from using the wrong target:

If the instance has a public IPv4 address, ensure you’re using that IP (or the correct Elastic IP if you assigned one).
If you’re connecting from the same VPC, you may need to use the private IP or set up routing/VPN.
Make sure the instance you’re trying to reach is the one you think it is. It’s surprisingly common to rebuild an instance or create a similarly named one and then connect to the old IP.

Choose the right port and protocol

Decide whether you’re trying to connect via:

AWS Partner SSH on port 22 (TCP)
RDP on port 3389 (TCP)
HTTP on port 80 or HTTPS on port 443 (TCP)

Then ensure every layer you check is aligned to that same port and protocol. A rule that allows port 22 won’t help if you accidentally pointed your client to port 2200, for example.

Step 2: Check Security Groups (most common cause)

Security Groups act like a stateful virtual firewall for the instance. If you block the inbound traffic, you’ll get timeouts.

Confirm inbound rules match your source IP

In the EC2 console:

Open the instance → Security → Security groups
Select the relevant security group
Check Inbound rules

For an SSH test, you typically need an inbound rule that allows TCP 22 from your IP (or a range). Example patterns:

Source type: My IP (simplest) or a CIDR like 203.0.113.10/32
Protocol: TCP
Port range: 22

If your rule uses “0.0.0.0/0” for a quick test, it may work, but it’s less secure. For production, restrict it to your office/VPN or specific IP.

Don’t forget multiple security groups

An instance can have more than one security group. All relevant security groups must allow the traffic for it to succeed. If one group blocks by absence of an allow rule, you still may fail because the inbound path depends on the union of allows, not the presence of denies—but the practical effect is that missing the correct allow rule is what matters.

AWS Partner Outbound rules rarely cause timeouts for incoming connections

Security Groups are stateful: if inbound traffic is allowed, replies usually work even if outbound is limited. Still, check outbound if your application initiates connections back out and you see other symptoms.

Step 3: Check Network ACLs and subnet routing

Network ACLs (NACLs) are stateless. Even if Security Groups look correct, NACLs can still drop traffic.

Review NACL rules for the subnet

In the VPC console, locate the subnet that contains your instance. Then check the associated Network ACL:

Ensure inbound rules allow your port (e.g., TCP 22) from your expected source range.
Ensure outbound rules also allow the response traffic, usually the ephemeral port range back to the client.

Stateless behavior means you need both directions to permit the flow.

AWS Partner Confirm route table paths to the internet

If you connect from the public internet, your instance must be in a subnet with a route to an internet gateway:

Check the subnet’s route table
Verify there is a route like 0.0.0.0/0 pointing to an Internet Gateway (for public subnets)

If your instance is in a private subnet without proper NAT/bastion/VPN, direct inbound connections from the internet will time out.

Elastic IP and public IP nuances

If you rely on public access:

A public IP can change after stop/start unless you use an Elastic IP.
A subnet that lacks a public route won’t allow inbound paths even if you have an IP assigned.

These issues frequently look identical to security rule problems: the connection attempt just times out.

Step 4: Confirm there’s an internet gateway (for public access)

For internet-facing connectivity, your VPC typically needs an Internet Gateway attached and properly referenced in the route table.

Internet Gateway attached to the VPC

AWS Partner In the EC2/VPC console, go to Internet Gateways
Verify the gateway is attached to the same VPC as your instance

Public subnet definition in practice

A “public subnet” is not just a label; it’s defined by routing rules. If the route table for that subnet sends 0.0.0.0/0 to an Internet Gateway, inbound traffic can reach the instance (subject to firewall rules).

If the route table points elsewhere (or has no default route), your client will keep timing out.

Step 5: If using a bastion or VPN, validate the network path

If you connect via a jump host (bastion), the problem might be that the bastion can’t reach the target instance.

Security groups for both hops

For a bastion setup:

The bastion security group must allow outbound traffic to the target port (often this is allowed by stateful logic, but you still want matching rules).
The target instance security group must allow inbound traffic from the bastion’s security group or its private IP range.

Best practice is to allow by security group reference rather than opening to the whole world.

Routing between VPCs or via Direct Connect

If you’re on a different network (another VPC, on-prem, or connected via Direct Connect), routing must exist for the return path too. Missing routes can manifest as timeouts.

Step 6: Check the instance’s OS and host firewall

Once AWS-level networking allows traffic, the instance must also accept it at the OS level. For timeouts, the OS firewall can drop packets (or the service may be misconfigured).

Check whether the service is listening

On the instance (use EC2 serial console, SSM, or another method to access it), run checks:

For SSH: confirm the SSH daemon is running and listening on the expected interface/port.
For web servers: confirm the web server is bound to 0.0.0.0 and the correct port.

If the service is not listening, you often see “connection refused,” but misconfigurations or firewall rules can still produce timeouts.

AWS Partner Check OS firewall rules (common culprits)

On Linux, common firewalls include ufw, firewalld, or raw iptables rules. Ensure inbound rules allow the port you’re connecting to.

AWS Partner Also confirm you didn’t restrict the SSH daemon to only localhost, or configure it to use a different port than your client expects.

Cloud-init and reboot effects

If you recently changed network settings or user-data scripts, verify the instance still applied the configuration. Rebuilds and updates can revert firewall settings.

Step 7: Use AWS tools to reduce guesswork

If you want to pinpoint where traffic gets stuck, you can leverage AWS features.

EC2 Instance Connect Endpoint and SSM (when available)

If you have System Manager (SSM) enabled, you can connect to the instance and validate OS firewall and service status without relying on inbound network access.

SSM won’t fix firewall/network issues by itself, but it helps you quickly confirm what’s happening on the host.

VPC Reachability Analyzer

When available, Reachability Analyzer can simulate the connection flow given a source and destination, showing which security group, NACL, route, or other component blocks it. This can save time compared with manual checking.

Step 8: A practical “most likely” checklist (quick order)

If you need a fast triage sequence, use this order:

Confirm instance is running and status checks passed.
Confirm you’re using the right public/private IP and correct port.
Security group inbound allows the port from your IP (or the bastion/VPN network).
Subnet route table allows traffic to reach an Internet Gateway (for public access).
Network ACLs allow inbound and outbound for that port/traffic.
OS firewall allows inbound and the service is listening.

Stop as soon as you find the broken link and fix it—don’t check every layer if the first three already clearly explain the issue.

Common scenarios and what to change

Scenario A: You can’t SSH, but the instance is running

Check Security Group inbound for TCP 22 and your actual source IP.
Confirm the instance is in a subnet with a public route (if you’re connecting from the internet).
Verify the host firewall allows SSH and the SSH daemon is running.

Scenario B: You created the instance in a private subnet

Direct internet SSH/RDP will time out.
Use a bastion host, VPN, or SSM for access, and ensure the target security group allows inbound from the bastion/VPN.
Alternatively, place it in a public subnet only if your security posture allows it.

Scenario C: Security group looks open, but it still times out

Check NACLs (stateless) and route tables.
Confirm internet gateway attachment and correct route table association.
Validate your OS firewall; a host firewall can still drop the traffic.

Scenario D: You recently changed IPs and now time out

If you used a public IP that changed after stop/start, update the client to the new IP or re-assign an Elastic IP.
Re-check “source IP” in the security group—if your home/office IP changed, the old CIDR no longer matches.

How to prevent connection timeouts in the future

Once you solve the immediate issue, a few habits reduce the chance of repeating it:

Use security group references (e.g., allow from the bastion security group) instead of overly broad CIDRs.
Document the intended access path: public internet → instance, or bastion/VPN → private instance.
Automate config checks with configuration management (so firewall rules don’t drift).
AWS Partner Keep SSM enabled when possible so you can troubleshoot even if inbound connectivity is broken.

When to escalate: signs the problem is outside your control

If you’ve checked security groups, NACLs, routes, and instance health, but still see consistent timeouts, consider:

Instance status checks failing (AWS-side reachability or hardware issues).
Misconfigured VPC components you didn’t touch (route table associations, shared NACL policies, organizational network controls).
Transient network issues—rare, but worth re-testing after a short interval.

At that point, using AWS reachability tools and checking console status panels can help determine whether you’re blocked by a specific component.

Final thought

“Connection timed out” is frustrating because it doesn’t name the cause. But the problem is usually consistent: something in the network path or host firewall is preventing traffic from being delivered or answered. If you follow the chain from IP/port → security groups → NACLs/routes → OS firewall/service, you’ll find the failing link quickly.

If you share what you’re connecting to (SSH/HTTP/RDP), the subnet type (public/private), and whether you use a bastion or VPN, the troubleshooting can be narrowed to the most likely rules to inspect first.