AWS Security Groups Step by Step - Inbound and Outbound Rules, Stateful Behaviour, Referencing Security Groups, the Three-Tier ALB-Web-DB Pattern, Quotas, Security Group vs Network ACL, CLI and Terraform (AWS Part-16)

We have been creating security groups since Part-4 without really stopping to look at them - allow SSH from my IP, allow HTTP from anywhere, next. In this Part-16 the security group gets the full treatment, because it is the one piece of AWS networking you will touch every single day, and because a surprising amount of "it does not connect" tickets come down to one of about six misunderstandings about how it works.

By the end of this post you will know exactly where a security group sits, why it never needs a return rule, why referencing another security group is better than typing IP ranges, what the quotas are, and how the classic ALB → web → database chain is wired. Facts and numbers are from the current Amazon EC2 and Amazon VPC documentation.

Table of Content

1. What a security group is and where it sits
2. The six rules of the game
3. Anatomy of a rule
4. The default security group vs a new custom group
5. Stateful - why there is no return rule
6. Step 1 - Create a security group in the console
7. Step 2 - Reference a security group instead of an IP range
8. Step 3 - The three-tier pattern - ALB, web, database
9. Step 4 - Test it with two instances
10. Quotas and how rules are counted
11. Security group vs network ACL
12. The AWS CLI equivalents
13. The same thing in Terraform
14. Troubleshooting - the usual suspects
15. Conclusion

1. What a security group is and where it sits

A security group is a virtual, stateful firewall that controls the traffic allowed to reach and leave the resources it is associated with. Three facts about where it lives explain most of its behaviour -

1. It is attached to a network interface (ENI), not to a subnet and not to "the instance". An EC2 instance gets one by virtue of its primary interface; an RDS instance, a Lambda function in a VPC, an ALB, an interface VPC endpoint, an EFS mount target - all of them have ENIs, and all of them take security groups.
2. It belongs to one VPC. You cannot attach a security group from VPC A to an interface in VPC B (you can reference it across a peering, see section 7).
3. It is Regional like the VPC - a security group id sg-0123... exists in exactly one Region.

2. The six rules of the game

Straight from the security group rules page, with my commentary -

1. Allow rules only. There is no deny. If traffic does not match an allow rule, it is dropped - that is the only "deny" you get. To block a specific IP you need a network ACL or AWS WAF.
2. A new security group has no inbound rules - nothing can reach the resource until you add one.
3. A new security group has one outbound rule - allow everything (0.0.0.0/0, all protocols). Delete it and nothing leaves. Most people never touch it; tightened outbound rules are a compliance requirement in regulated environments.
4. Multiple security groups on one interface are aggregated into a single set of allow rules. Up to 5 by default. There is no ordering and no priority - a packet is allowed if any rule in any attached group allows it.
5. Changes apply immediately to every resource associated with the group. Add a rule to a group used by 200 instances, all 200 open up at once - which is both the super-power and the footgun.
6. Every rule gets a unique id (sgr-...) that you can use in the CLI and API to modify or delete exactly that rule.

And the one limitation the docs call out - a security group cannot block DNS to the Route 53 Resolver (the .2 address of the VPC). Use Route 53 Resolver DNS Firewall for that.

3. Anatomy of a rule

A rule is always evaluated on the five-tuple - source, source port, destination, destination port, protocol - plus connection state (next section).

4. The default security group vs a new custom group

Every VPC comes with a security group literally named default that you cannot delete. Its rules are the source of a classic surprise -

So two instances both left on the default group can talk to each other on every port. That is convenient for a lab and exactly what you do not want in production. My rule - never put anything on default; create purpose-named groups (web-sg, db-sg, bastion-sg) and keep default empty of members.

5. Stateful - why there is no return rule

A security group is stateful: it tracks connections, and the reply to an allowed request is always allowed, regardless of the rules in the other direction. From the connection tracking page -

1. A client at 203.0.113.5:51000 sends a SYN to your instance on TCP 443. Inbound rule TCP 443 from 0.0.0.0/0 matches - the flow is recorded.
2. The instance replies from 443 to 203.0.113.5:51000. Outbound rules are not consulted - the reply belongs to a tracked flow.
3. Equally, if your instance runs apt-get update (outbound 443 allowed), the responses come back without any inbound rule for port 443 or for ephemeral ports.

Two consequences you will meet -

• Tracked vs untracked. If a rule allows all traffic from 0.0.0.0/0 (or ::/0) in both directions, the flow is untracked - it is allowed because the rules allow it, not because of state. Remove or tighten such a rule and existing untracked connections are cut immediately, while tracked connections survive a rule change until they end. This is why removing 0.0.0.0/0 all traffic sometimes drops your SSH session and sometimes does not.
• Idle timeouts. Tracked connections expire (TCP established 5 days, UDP 30 to 60 seconds, ICMP 30 seconds - the exact values are in the page above), so a long-silent connection may need a keepalive.

A network ACL by contrast is stateless - it needs an explicit rule for the reply, including the ephemeral port range (1024-65535). That alone is why most people keep NACLs at allow all and do the real work in security groups.

6. Step 1 - Create a security group in the console

1. EC2 console → Network & Security → Security Groups → Create security group.
2. Security group name - web-sg. Description - required, cannot be changed afterwards, maximum 255 characters, so write something useful like Web servers behind alb-sg. VPC - pick your VPC (the one from Part-5), not the default one.
3. Inbound rules → Add rule - Type SSH, Source My IP (the console fills your current public IPv4 as a /32). Description SSH from my laptop.
4. Add rule - Type Custom TCP, Port 8080, Source - leave this for the next section.
5. Outbound rules - leave the default All traffic to 0.0.0.0/0 for now.
6. Tags - Name = web-sg. Create security group.

The My IP trick deserves a warning - home connections change IP; when SSH stops working tomorrow, the first thing to check is this rule. For anything longer-lived use Session Manager or EC2 Instance Connect Endpoint and delete port 22 entirely.

7. Step 2 - Reference a security group instead of an IP range

Here is the feature that makes security groups better than any IP-based firewall. As the source of a rule you can put another security group's id. The rule then allows traffic from every network interface that is a member of that group, using their private IPs, and it keeps working as instances come and go - perfect for Auto Scaling groups whose IPs you never know in advance.

Important precision from the docs - referencing a group does not import its rules. web-sg: inbound 8080 from alb-sg means "accept 8080 from any interface that wears alb-sg"; it says nothing about what alb-sg itself allows.

Rules for referencing -

1. Inbound - the referenced group may be in the same VPC, in a peered VPC (Part-12), or in a VPC connected through a Transit Gateway (Part-13, with security group referencing enabled on the attachment).
2. Outbound - same VPC or peered VPC only.
3. Traffic must go directly between the interfaces - if you route through a middlebox appliance, reference the IP or subnet CIDR instead, security group references will not match.
4. A referenced group in a peer VPC that gets deleted leaves a stale rule behind; the console flags it and you can delete it.
5. A security group reference counts as one rule regardless of how many members the referenced group has.

So for web-sg the inbound 8080 rule gets Source - Custom - and you type or pick alb-sg (create it first, see the next section). The console shows it as sg-0abc.../alb-sg.

8. Step 3 - The three-tier pattern - ALB, web, database

This is the layout from the diagram and from the official example - three groups, each one trusting only the tier in front of it -

Notice what the design buys you - no IP addresses anywhere except the public edge. Scale the web tier from 2 to 20, replace the database, move subnets - the rules do not change. And the ALB's outbound rule to web-sg is the one most people forget: an ALB does evaluate its outbound rules, so if you tighten them, include the target port.

Create alb-sg and db-sg the same way as web-sg, then go back and set the sources as in the table. Creating groups first and rules second is normal - a rule can only reference a group that already exists.

9. Step 4 - Test it with two instances

Launch two small instances in the VPC (Part-4) - web-1 with web-sg and client-1 with alb-sg (we are using it as a stand-in for the load balancer). On web-1 start a listener -

1# on web-1 - a throwaway HTTP server on 8080
2python3 -m http.server 8080

From client-1 (which wears alb-sg, so the web-sg rule "8080 from alb-sg" applies) -

1# replace with web-1's PRIVATE IP - references match private addresses only
2curl -s -m 5 http://10.0.1.25:8080/ && echo "allowed - alb-sg is referenced by web-sg"
3
4# port 22 is not allowed from alb-sg - this must time out
5nc -zv -w 5 10.0.1.25 22 || echo "blocked - no rule for 22 from alb-sg"
6
7# ping - fails until you add an ICMP rule; security groups do not treat ICMP specially
8ping -c 2 10.0.1.25

Now from your laptop curl the public IP of web-1 on 8080 - it must fail, because the only 8080 rule has alb-sg as source and your laptop is not a member. Change the rule source to 0.0.0.0/0, retry without restarting anything - it works instantly. That is rule 5 from section 2 in action.

VPC Reachability Analyzer (VPC console → Reachability Analyzer) tells you in one run whether a path from client-1 to web-1 on a port is reachable and names the exact security group rule or route that blocks it - worth using before you start adding 0.0.0.0/0 rules in frustration. VPC Flow Logs show the same thing after the fact as REJECT records.

10. Quotas and how rules are counted

From the Amazon VPC quotas page -

How a rule is counted - a CIDR counts as 1, a security group reference counts as 1, a customer-managed prefix list counts as its maximum entries (a prefix list sized 20 costs 20 rules), and an AWS-managed prefix list (CloudFront origin-facing, S3, DynamoDB...) counts as its published weight. Managed prefix lists are still the right tool for "our 12 office IPs" - one list, referenced by thirty groups, updated in one place.

If you hit the 60-rule wall the fix is almost always design, not a quota ticket - split by tier, reference groups instead of listing IPs, use prefix lists.

11. Security group vs network ACL

My approach - security groups do the work, the NACL stays at allow-all unless I need to deny a specific attacker's range or a compliance rule asks for subnet-level control. Two stateless rule sets to debug is a cost you only pay if there is a reason.

12. The AWS CLI equivalents

 1VPC_ID=vpc-0123456789abcdef0
 2
 3# create the three groups - the description is mandatory and immutable
 4ALB_SG=$(aws ec2 create-security-group --group-name alb-sg --description "ALB - public edge" \
 5  --vpc-id $VPC_ID --query GroupId --output text)
 6WEB_SG=$(aws ec2 create-security-group --group-name web-sg --description "Web servers behind alb-sg" \
 7  --vpc-id $VPC_ID --query GroupId --output text)
 8DB_SG=$(aws ec2 create-security-group --group-name db-sg --description "RDS - only from web-sg" \
 9  --vpc-id $VPC_ID --query GroupId --output text)
10
11# alb-sg inbound 80 and 443 from the internet, with descriptions
12aws ec2 authorize-security-group-ingress --group-id $ALB_SG --ip-permissions \
13  'IpProtocol=tcp,FromPort=80,ToPort=80,IpRanges=[{CidrIp=0.0.0.0/0,Description="HTTP from internet"}]' \
14  'IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges=[{CidrIp=0.0.0.0/0,Description="HTTPS from internet"}]'
15
16# web-sg inbound 8080 from alb-sg - a security group reference
17aws ec2 authorize-security-group-ingress --group-id $WEB_SG --ip-permissions \
18  "IpProtocol=tcp,FromPort=8080,ToPort=8080,UserIdGroupPairs=[{GroupId=$ALB_SG,Description=\"from ALB\"}]"
19
20# db-sg inbound 3306 from web-sg
21aws ec2 authorize-security-group-ingress --group-id $DB_SG --ip-permissions \
22  "IpProtocol=tcp,FromPort=3306,ToPort=3306,UserIdGroupPairs=[{GroupId=$WEB_SG,Description=\"MySQL from web tier\"}]"
23
24# tighten alb-sg outbound - remove allow-all, allow only 8080 to web-sg
25aws ec2 revoke-security-group-egress --group-id $ALB_SG --ip-permissions \
26  'IpProtocol=-1,IpRanges=[{CidrIp=0.0.0.0/0}]'
27aws ec2 authorize-security-group-egress --group-id $ALB_SG --ip-permissions \
28  "IpProtocol=tcp,FromPort=8080,ToPort=8080,UserIdGroupPairs=[{GroupId=$WEB_SG}]"
29
30# list rules with their ids, then delete one rule by id
31aws ec2 describe-security-group-rules --filters Name=group-id,Values=$WEB_SG \
32  --query "SecurityGroupRules[].{id:SecurityGroupRuleId,in:IsEgress,proto:IpProtocol,from:FromPort,to:ToPort,cidr:CidrIpv4,sg:ReferencedGroupInfo.GroupId}" --output table
33aws ec2 revoke-security-group-ingress --group-id $WEB_SG --security-group-rule-ids sgr-0123456789abcdef0
34
35# attach groups to a running instance (replaces the whole list)
36aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --groups $WEB_SG

describe-security-group-rules is the command to remember - it shows the rule ids, and the --security-group-rule-ids form of revoke is the only precise way to delete one rule when several share a port.

13. The same thing in Terraform

The current AWS provider recommends the standalone rule resources aws_vpc_security_group_ingress_rule and aws_vpc_security_group_egress_rule instead of inline ingress {} blocks - one resource per rule, with descriptions and rule ids in state, and no fights between inline and standalone rules -

 1resource "aws_security_group" "alb" {
 2  name        = "alb-sg"
 3  description = "ALB - public edge"
 4  vpc_id      = aws_vpc.main.id
 5  tags        = { Name = "alb-sg" }
 6}
 7
 8resource "aws_security_group" "web" {
 9  name        = "web-sg"
10  description = "Web servers behind alb-sg"
11  vpc_id      = aws_vpc.main.id
12  tags        = { Name = "web-sg" }
13}
14
15resource "aws_security_group" "db" {
16  name        = "db-sg"
17  description = "RDS - only from web-sg"
18  vpc_id      = aws_vpc.main.id
19  tags        = { Name = "db-sg" }
20}
21
22# alb-sg - 80 and 443 from the internet
23resource "aws_vpc_security_group_ingress_rule" "alb_http" {
24  security_group_id = aws_security_group.alb.id
25  description       = "HTTP from internet"
26  ip_protocol       = "tcp"
27  from_port         = 80
28  to_port           = 80
29  cidr_ipv4         = "0.0.0.0/0"
30}
31
32resource "aws_vpc_security_group_ingress_rule" "alb_https" {
33  security_group_id = aws_security_group.alb.id
34  description       = "HTTPS from internet"
35  ip_protocol       = "tcp"
36  from_port         = 443
37  to_port           = 443
38  cidr_ipv4         = "0.0.0.0/0"
39}
40
41resource "aws_vpc_security_group_egress_rule" "alb_to_web" {
42  security_group_id            = aws_security_group.alb.id
43  description                  = "to web tier"
44  ip_protocol                  = "tcp"
45  from_port                    = 8080
46  to_port                      = 8080
47  referenced_security_group_id = aws_security_group.web.id
48}
49
50# web-sg - 8080 from the ALB only
51resource "aws_vpc_security_group_ingress_rule" "web_from_alb" {
52  security_group_id            = aws_security_group.web.id
53  description                  = "from ALB"
54  ip_protocol                  = "tcp"
55  from_port                    = 8080
56  to_port                      = 8080
57  referenced_security_group_id = aws_security_group.alb.id
58}
59
60resource "aws_vpc_security_group_egress_rule" "web_all" {
61  security_group_id = aws_security_group.web.id
62  ip_protocol       = "-1"          # all traffic
63  cidr_ipv4         = "0.0.0.0/0"
64}
65
66# db-sg - 3306 from the web tier only
67resource "aws_vpc_security_group_ingress_rule" "db_from_web" {
68  security_group_id            = aws_security_group.db.id
69  description                  = "MySQL from web tier"
70  ip_protocol                  = "tcp"
71  from_port                    = 3306
72  to_port                      = 3306
73  referenced_security_group_id = aws_security_group.web.id
74}

Note that aws_security_group without inline rules still creates the group with the default allow-all egress - Terraform removes it only if you declare egress {} inline or manage egress with the standalone resource (which is what web_all above does explicitly). The full EC2 build with these groups is in my Terraform EC2 post and the ALB wiring in Terraform ALB and SSL.

14. Troubleshooting - the usual suspects

1. "Connection timed out" on SSH - your public IP changed and the /32 rule is stale; or you are using the public IP of an instance in a private subnet. Timeout = security group or route; connection refused = the port is open but nothing is listening.
2. Referenced the wrong direction - web-sg must have an inbound rule from alb-sg; adding an outbound rule on alb-sg alone does nothing for the inbound side.
3. Referenced a group but connecting to the public IP - references match private IPs only. Use the private IP, or go through the load balancer.
4. IPv6 clients cannot connect - 0.0.0.0/0 is IPv4; add ::/0.
5. The instance is on the default group plus yours - the aggregated rules allow more than you think. Check Networking → Security groups on the instance, there are usually two.
6. Health checks failing on the ALB targets - the target group's health check port must be allowed from alb-sg, which is often a different port from the app port.
7. Ping does not work - ICMP needs its own rule; TCP rules never allow ICMP.
8. Rule change had no effect on an existing connection - tracked connections survive rule changes; new connections pick the new rules. Untracked (allow-all) flows are cut immediately.
9. "RulesPerSecurityGroupLimitExceeded" - you hit 60; prefix lists or an extra group, not a bigger quota, is usually the answer.
10. Cannot delete the group - something still references it - another group's rule, an ENI, a launch template. describe-network-interfaces --filters Name=group-id,Values=sg-... finds the interface.

15. Conclusion

A security group is a stateful, allow-only firewall on the network interface. Memorise the six rules - allow only, empty inbound, open outbound, aggregated, immediate, rule ids - and the stateful behaviour, and you will stop needing return rules and stop opening ports in frustration. Build tiers by referencing security groups rather than IPs, keep the network ACL at allow-all unless you need a deny, and reach for prefix lists before you reach for a quota increase.

Next in the series is Part-17 on launch templates, where web-sg becomes part of the template every Auto Scaling instance is born with. If you want to see the rejected packets a security group drops, that is VPC Flow Logs, and the Azure equivalent - network security groups, which can deny - is in my Azure virtual network post.

AWS step by step series -

1. Part-1 : AWS IAM user - create a user, group, policy, access keys and MFA
2. Part-2 : AWS Organizations - multi-account setup, OUs and SCPs
3. Part-3 : AWS assume IAM role - trust policy, switch role in console and CLI
4. Part-4 : How to launch an EC2 instance - key pair, security group, SSH
5. Part-5 : AWS VPC - public and private subnets, Internet Gateway, NAT Gateway, route tables
6. Part-8 : EC2 launch template - versions, default version, source template, SSM parameter AMI
7. Part-10 : EC2 Auto Scaling - launch template, Auto Scaling group, target tracking, ALB
8. Part-11 : AWS WAF - web ACL, managed rules, rate limiting, geo blocking
9. Part-12 : AWS VPC Peering - connect two VPCs, routes, security groups, DNS
10. Part-13 : AWS Transit Gateway - hub-and-spoke for many VPCs and on-premises
11. Part-14 : AWS NAT Gateway deep dive - public vs private, limits, cost, troubleshooting
12. Part-15 : Amazon Route 53 - hosted zones, records, alias, routing policies, health checks
13. Part-16 : AWS security groups - inbound and outbound rules, stateful, referencing, quotas
14. Part-16 : AWS Certificate Manager - free TLS certificates for ALB, CloudFront and API Gateway
15. Part-17 : AWS Lambda - function URLs, environment variables and layers
16. Part-18 : Network Load Balancer - setup, and ALB vs NLB
17. Part-19 : VPC endpoints - gateway and interface endpoints (PrivateLink) instead of NAT
18. Part-20 : AWS PrivateLink - publish your own service with an endpoint service and NLB
19. Part-20 : Amazon EBS volumes - types, attach, mount, resize, snapshots, encryption
20. Part-21 : VPC Flow Logs - CloudWatch Logs, S3, record format, Logs Insights, Athena
21. Part-21 : EC2 Spot Instances - pricing, interruptions, mixed instances groups
22. Part-24 : AWS Control Tower - landing zone, controls, Account Factory, Identity Center

Networking fundamentals -

1. What is a VPC and a subnet? AWS networking in five minutes
2. What is CIDR? Calculate IP ranges for VPCs and subnets
3. What is NAT? Static NAT, dynamic NAT and PAT explained

More AWS guides -

1. What is AWS CloudFormation? Templates, stacks, change sets, drift, StackSets
2. Learn AWS S3 - the complete course
3. AWS API Gateway - REST API with Lambda, authorizers, Terraform
4. AWS Advanced Networking Specialty (ANS-C01) - course companion
5. AWS ECS and Fargate - how to deploy a Docker container
6. AWS S3 - how to host a static website
7. Terraform create EC2 instance on AWS
8. Terraform AWS IAM - users, roles and policies
9. Terraform and AWS multi-account setup
10. Terraform - setting up an ALB and SSL