The Dev World – Sergio Lema

We’ve all been there: You’ve just spun up a new EC2 instance, you’ve got your key pair ready, and you’re feeling good. Then you try to connect, and all you get is a “Connection timed out” error. My first instinct, and likely yours, is to look at the security group. Nine times out of ten, that’s where the problem is hiding.

In this article, I’ll walk you through the most common security group pitfalls that lead to EC2 connectivity issues. This isn’t a comprehensive guide to every possible AWS problem, but a practical checklist focused on what a mid-level developer needs to check first.

Your Security Group Inbound Rules

The most frequent offender is a misconfigured inbound rule. Think of your security group as the front door to your EC2 instance. The inbound rules are the bouncer, deciding who gets to come in. If the bouncer doesn’t have your name on the list, you’re not getting in.

Here’s what to look for:

• Wrong Protocol or Port: For SSH connections, you need a rule for TCP on port 22. For Windows instances and RDP, you need TCP on port 3389. A simple slip-up here will block all traffic.
• The Source IP: This is a classic. You set a rule to allow your specific IP address, but then you move to a coffee shop with a different IP. Or your home ISP changes your public IP address. The solution is simple: Update the source to your current public IP address. In the AWS console, you can often select “My IP” to automatically populate the correct value. For more flexibility, you might use a broader CIDR range if you understand the risks.
• No Inbound Rule: It might sound obvious, but it’s worth a check. Did you even create an inbound rule for your desired connection type? The default security group in a VPC, for instance, often comes with no inbound rules at all.

Common Security Group Headaches

Even if your rules look perfect, there can still be issues. The AWS ecosystem has a few quirks that can trip you up.

• Region Mismatch: This is a subtle one. Security groups are region-specific. If you’re using the AWS CLI or trying to reference a security group from another service, ensure you’re in the correct region. I’ve wasted hours on this exact issue—it’s a simple fix, but a frustrating one.
• The “Phantom” Security Group: This is a rare but confusing scenario. On older EC2-Classic instances, a security group can sometimes appear to be lost or unassociated. In these cases, the AWS console might give you an error like “The security group ‘sg-xxxxxx’ does not exist.” When this happens, your best bet is to use the aws ec2 describe-instances CLI command to see the full details, then contact AWS support if needed.
• Referencing Other Security Groups: A powerful feature is allowing traffic from another security group. This is great for an application and database layer. Just remember that this only works for private IPs within the same VPC. Public and Elastic IPs don’t carry this security group information, so your rule won’t apply.

Instance-Side Firewall and Services

After a thorough review of your security groups, if you’re still unable to connect, it’s time to look at the instance itself.

• Internal Firewall (iptables): Your EC2 instance might have its own firewall rules that are blocking traffic. For Linux instances, a quick sudo iptables -L will show you the current rules. If you see a rule that’s dropping traffic on your desired port, you’ll need to adjust it.
• Is the Service Running?: If you’re trying to connect to a web server (HTTP on port 80), but the service like Apache (httpd) isn’t running, you’ll get a connection refusal. The security group might be letting traffic in, but there’s nothing on the other end to listen. Check your application logs and use commands like sudo systemctl status httpd to ensure everything is operational.

A Final Sanity Check

Before you dive into a deep rabbit hole, try this quick test:

1. Temporarily create a new security group.
2. Add an inbound rule for all TCP traffic (0-65535) from your IP address (My IP).
3. Associate this new security group with your instance.
4. Try to connect.

If it works, you know for a fact the problem is with your original security group rules. If it still fails, it’s time to look at your VPC, routing, or the instance’s own configuration. In my experience, this simple test can save you from an hour of pointless head-scratching.