AWS Security Group: What It Is and When to Use It

Definition

A Security Group (SG) is a virtual firewall that controls inbound and outbound traffic for AWS resources at the Elastic Network Interface (ENI) level. Security Groups are stateful (return traffic is automatically allowed), allow-only (no deny rules), and operate at Layer 3/4 by matching on protocol, port, and source/destination (CIDR, SG ID, or prefix list). They are the primary instance-level access-control mechanism in a VPC and sit at the foundation of AWS's defense-in-depth networking model.

Almost every AWS resource with an ENI — EC2, RDS, Lambda-in-VPC, ECS tasks, ELB, EKS nodes — is governed by one or more Security Groups. Default behavior: all inbound traffic is denied; all outbound is allowed.

How It Works

Every SG has two rule lists: inbound and outbound. A rule specifies:

• Type / Protocol — TCP, UDP, ICMP, or All.
• Port range — a single port or a range (e.g., 443, 8080–8090).
• Source (inbound) or Destination (outbound) — a CIDR (0.0.0.0/0, 10.0.0.0/16), another Security Group ID, or an AWS-managed prefix list (e.g., S3, CloudFront).
• Description — free-text for documentation.

When a packet arrives at an ENI, AWS evaluates all SGs attached to that ENI. If any rule in any SG matches and allows the traffic, it is permitted. Because SGs are stateful, the reply packet is automatically allowed regardless of the outbound rules — no need to open ephemeral ports manually.

A powerful feature: SG-to-SG references. Instead of hardcoding IPs, you can source rules from another SG ID — e.g., "allow 5432/tcp from sg-app-layer". Membership in the referenced SG dynamically resolves to the private IPs of all ENIs tagged with it, eliminating drift when instances scale in and out.

Key Features and Limits

• Stateful — return traffic is implicit.
• Allow-only — no deny rules (use NACLs or AWS Network Firewall for deny).
• Default SG — every VPC has one; allows all traffic within the SG and all outbound.
• Default outbound rule on custom SGs: allow all outbound (0.0.0.0/0, all protocols).
• Default inbound rule on custom SGs: deny all (no inbound rules).
• Limits (soft, raisable):
  • 60 inbound + 60 outbound rules per SG (120 total; each IPv4 and IPv6 rule counts separately).
  • 5 Security Groups per ENI (raisable to 16).
  • 2,500 SGs per VPC.
• Rule counts against the per-ENI rule limit: 5 SGs x 60 inbound rules each = 300 rules per ENI (soft max 1,000).
• References — SG IDs, prefix lists (AWS-managed or customer-managed), CIDR blocks. No hostnames, no DNS names.
• Applies to ENIs — not instances, subnets, or VPCs directly. An instance with multiple ENIs can have different SGs on each.
• Changes take effect immediately — no restart required.
• Tags & descriptions — key for documenting who owns and uses each SG.

Common Use Cases

1. Web-tier SG — allow 443 from 0.0.0.0/0, reference from the ALB's SG as source for the app tier.
2. App-to-DB segmentation — DB SG allows 5432/tcp only from the app-tier SG ID. When app tier scales, DB access follows automatically.
3. Bastion host — SG allows 22/tcp from your corporate CIDR (or better, from AWS Systems Manager Session Manager via prefix lists).
4. Cross-account shared VPC — SG-to-SG references work across accounts within the same VPC or via sharing (same Region).
5. AWS service access via prefix list — allow outbound 443 to the managed S3 or DynamoDB prefix list for compliance-friendly egress rules.
6. Lambda-in-VPC — attach an SG to the function so it can reach RDS/ElastiCache, mirroring the EC2 model.
7. Zero-trust microservices — each service has its own SG, with rules limited to the specific callers' SGs — no IP-based rules at all.

Pricing Model

Security Groups are free. There are no rule charges, no evaluation fees, no attachment fees. You pay only for the underlying resources (EC2, ELB, RDS, NAT Gateway, VPC Endpoints, etc.) and their data transfer. Because SGs are free and evaluation is in-line, they are the default and cheapest way to enforce network access control on AWS.

Pros and Cons

Pros

• Stateful — no need to open ephemeral return ports explicitly.
• SG-to-SG references make scaling and drift trivial.
• Free with no rule-count cost.
• Apply directly to ENIs — fine-grained per-instance control.
• Changes apply instantly across all attached ENIs.
• Integrated with IAM Access Analyzer, Config rules, GuardDuty findings.

Cons

• No deny rules — to block a specific IP you must use NACLs, AWS Network Firewall, or AWS WAF.
• No matching by hostname — DNS-based rules require prefix lists or third-party automation.
• 60-rule limit per direction can bite rule-heavy environments (workaround: consolidate via CIDRs or customer-managed prefix lists).
• Debugging which SG allowed a flow requires VPC Flow Logs plus SG rule audit.
• Rule sprawl across many SGs is hard to reason about without tagging discipline.

Comparison with Alternatives

| Feature | Security Group | Network ACL (NACL) | AWS Network Firewall | AWS WAF | | --- | --- | --- | --- | --- | | Scope | ENI (instance) | Subnet | VPC (via firewall endpoints) | ALB/CloudFront/API Gateway | | State | Stateful | Stateless | Stateful (Suricata) | Stateful | | Rule types | Allow only | Allow + Deny | Allow, Deny, Alert, stateful rules | Allow, Block, Count, CAPTCHA | | References | SG IDs, prefix lists, CIDRs | CIDRs only | Rule groups, Suricata rules | IP sets, rate limits, managed rules | | Best for | Fine-grained per-instance | Subnet-level deny layer | Deep packet inspection, IDS/IPS | HTTP-layer protection |

Rule of thumb: Security Groups are your primary allowlist. NACLs provide an optional subnet-level deny. Network Firewall gives deep inspection. WAF handles Layer 7 attacks. Most architectures use SG + NACL as the baseline defense-in-depth pattern.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — heavy topic: SG vs NACL, SG-to-SG references, default SG behavior, multi-SG instances.
• Developer Associate (DVA-C02) — placing Lambda in a VPC with proper SGs, reading VPC Flow Logs, allowing RDS access.
• SysOps Administrator (SOA-C02) — troubleshooting connectivity, effective rules, SG rule limits.
• Security Specialty (SCS-C02) — deep: defense-in-depth patterns, IAM Access Analyzer for unused SGs, GuardDuty findings related to SG misconfigurations, Config rules for SG compliance.
• Advanced Networking Specialty (ANS-C01) — cross-account/VPC SG references, ENI-level SG effects, NLB SG (2023+) behavior.

Classic exam traps: SGs are stateful — you do not need to allow the return port. SGs do not have deny rules — for blocking, use NACL or a network firewall. SGs apply to ENIs, not subnets. The default SG in a VPC allows all intra-SG traffic; custom SGs deny all inbound by default. Rules can reference other SG IDs but not DNS hostnames.

Frequently Asked Questions

Q: What does it mean that Security Groups are stateful?

A: When an SG allows an outbound packet, the response packet is automatically allowed back regardless of inbound rules — and vice versa. You only write rules for the initiating direction. This differs from a stateless firewall (like a NACL), where you must explicitly allow both the request and the reply, including the high-numbered ephemeral ports for return TCP traffic. Statefulness makes SGs simpler and safer for day-to-day access control.

Q: Can I use a Security Group to block a specific IP address?

A: No. Security Groups are allow-only — they cannot deny. To block a specific IP or CIDR, use a Network ACL (which supports deny rules at the subnet level), AWS Network Firewall (deep packet inspection at VPC scale), or AWS WAF (for HTTP/HTTPS at an ALB, API Gateway, or CloudFront). The layered SG + NACL model is the typical defense-in-depth pattern: SGs grant the default allows, NACLs block known-bad traffic.

Q: How does referencing another Security Group as a source work?

A: When you create a rule that uses another SG ID as the source (e.g., sg-app-tier), AWS dynamically resolves that reference to the private IPs of all ENIs currently tagged with that SG — across any number of instances, containers, or Lambda functions. If the app tier scales from 2 to 200 instances, the DB SG automatically accepts traffic from all 200 without any rule change. This is the cleanest way to express "trust all members of tier X" and is preferred over CIDR-based rules for internal services.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Security Group documentation before making production decisions.