AWS Certified Cloud Practitioner / EC2 - Elastic Compute Cloud

Security Groups & Classic Ports Overview

❓What is a security group?

A virtual firewall attached to your instance. It controls two directions of traffic:

  • 📥 Inbound — what's allowed to reach the instance

  • 📤 Outbound — what's allowed to leave it

Key thing to know: security groups only have ALLOW rules. There's no "deny" — anything not explicitly allowed is blocked by default.

🤝 What a rule can match against

  • 🌍 IP addresses — e.g. your laptop's public IP

  • 🔗 Other security groups — rules can reference another security group instead of an IP, letting resources trust each other directly

🏃‍♂️ How it plays out

Picture yourself on your laptop, out on the public internet, trying to reach your EC2 instance:

  1. That instance sits behind a security group

  2. The security group holds a set of rules

  3. Those rules decide, traffic by traffic: does this get to come in? Does this get to go out?

If there's no rule allowing it, the traffic simply doesn't get through.

🔥 Security Groups — Deeper Dive

Security groups act as a firewall on EC2 instances. They regulate:

  • Access to specific ports

  • Authorized IP ranges (IPv4 and IPv6)

  • Inbound traffic — who can reach the instance

  • Outbound traffic — where the instance can reach out to

Remember it as: Inbound = who can enter · Outbound = where EC2 can go.

Control who's allowed to connect to your instance.

  • ✅ Matching IP + port → connection succeeds

  • ❌ IP not covered by any rule → connection is blocked (times out, doesn't get an error back)

Control where the instance is allowed to connect out to.

  • ✅ By default, all outbound traffic is allowed — nothing to configure unless you want to lock it down

Example rule set

Type

Protocol

Port Range

Source

Description

HTTP

TCP

80

0.0.0.0/0

test http page

SSH

TCP

22

122.149.196.85/32

—

Custom TCP Rule

TCP

4567

0.0.0.0/0

java app

Each rule really just says: this port, this protocol, allowed from this source.

Worth noting:

  • 0.0.0.0/0 means "anywhere on the internet" — wide open

  • The SSH rule is scoped to one exact IP (/32) — much tighter, and the pattern worth following for anything admin-related

  • HTTP and the custom app port here are both open to the world, which makes sense for a public web service but would be a mistake for something like SSH

🔥 Security Groups — Good to Know

  • Reusable across instances. One security group isn't tied to a single EC2 instance — you can attach the same one to several instances that should share the same access rules.

  • Scoped to a region + VPC (Virtual Private Cloud). A security group only exists within the region and VPC it was created in — you can't attach it to an instance somewhere else.

  • It lives outside the instance, not inside it. The filtering happens before traffic ever touches the EC2 instance. If a security group blocks something, the instance itself never sees the attempt — there's nothing to log or debug on the instance side, because it never arrived.

💡 Best practice: give SSH its own dedicated security group. Instead of bundling SSH access into the same group as your app's HTTP/HTTPS rules, keep it separate. That way you can tighten or loosen admin access without touching the rules your application actually depends on.

  • A "timed out" connection almost always means a security group problem. The request just sits there with no response — because the security group silently dropped it before it ever reached your app.

  • A "connection refused" error usually means an application problem, not a firewall one. The traffic did get through the security group — it reached the instance — but nothing was listening on that port, either because the app crashed or was never started.

  • Inbound traffic is blocked by default. A brand-new security group lets nothing in until you explicitly add a rule allowing it.

  • Outbound traffic is allowed by default. Unlike inbound, a new security group lets your instance freely reach out anywhere, unless you deliberately restrict it.

The mental shortcut: timeout → check the security group. Connection refused → check the application.

🔗 Referencing Other Security Groups

A small advanced feature — genuinely useful once load balancers come into play — that lets you authorize traffic by security group instead of by IP address.

🤖 The setup

Our Primary Instance has Security Group 1 attached. Its inbound rule says: allow traffic from anything wearing Security Group 1 or Security Group 2 (External Groups)

🤝 What that means for the other instances

  • External Instance A wears Security Group 2 — it's on the trusted list, so it's allowed to connect in

  • External Instance B wears Security Group 1 — same group as the primary instance's own, also trusted, allowed to connect in

  • External Instance C wears Security Group 3 — not on the trusted list, so its connection attempt gets denied

Each of these is an external instance trying to reach our primary instance — the badge they're wearing determines whether that connection is let through.

🧠 Why this is worth knowing

None of this cares about IP addresses. Access is decided entirely by which security group an instance is wearing — so as long as an instance carries an authorized group, it gets through, no matter what its actual IP happens to be.

That's the real payoff: you stop babysitting IPs. Instances get relaunched, replaced, scaled up and down constantly in AWS — and this pattern doesn't break when that happens. It's exactly why this shows up so often with load balancers, whose IPs were never fixed to begin with.

The one-picture summary: Security Group 1's inbound rule lists which other security groups it trusts. Wear one of those, and you're in. Wear anything else, and you're not — regardless of IP.

🌐 Important Ports (Exam + Real World)

Port

Protocol

Use Case

22

SSH

Linux access

21

FTP

File transfer (insecure)

22

SFTP

Secure file transfer

80

HTTP

Unsecured web

443

HTTPS

Secured web

3389

RDP

Windows access