Chapter 45: Terraform 3-Tier Architecture in a Single Availability Zone

45.2 Security groups for web, app and database tiers

By Ravindra Bagale · Last updated: 25 October 2026

Story. Suppose we are reviewing that same HR portal with the client's security team. Their first question is always: who can talk to the database? The answer must be "only the app servers" and the code should prove it. Chaining security groups gives exactly that: the internet reaches web, web reaches app, app reaches the database, and nothing skips a layer.

Steps

1. Add security.tf.
2. Run terraform validate.
3. Read the plan and check that no rule other than web_http uses 0.0.0.0/0 for ingress.

# ---- security.tf ----
resource "aws_security_group" "web" {
  name   = "${var.project}-web"
  vpc_id = aws_vpc.main.id
}

resource "aws_security_group" "app" {
  name   = "${var.project}-app"
  vpc_id = aws_vpc.main.id
}

resource "aws_security_group" "db" {
  name   = "${var.project}-db"
  vpc_id = aws_vpc.main.id
}

resource "aws_vpc_security_group_ingress_rule" "web_http" {
  security_group_id = aws_security_group.web.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "tcp"
  from_port         = 80
  to_port           = 80
}

resource "aws_vpc_security_group_ingress_rule" "app_from_web" {
  security_group_id            = aws_security_group.app.id
  referenced_security_group_id = aws_security_group.web.id
  ip_protocol                  = "tcp"
  from_port                    = 8080
  to_port                      = 8080
}

resource "aws_vpc_security_group_ingress_rule" "db_from_app" {
  security_group_id            = aws_security_group.db.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 3306
  to_port                      = 3306
}

resource "aws_vpc_security_group_egress_rule" "web_all" {
  security_group_id = aws_security_group.web.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

resource "aws_vpc_security_group_egress_rule" "app_all" {
  security_group_id = aws_security_group.app.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

What each line does

• aws_security_group "web" / "app" / "db" — One firewall per tier, all in the 3-tier VPC.
• web_http cidr_ipv4 = "0.0.0.0/0" — Only the web tier is open to the internet, on port 80.
• app_from_web referenced_security_group_id = web — The app port 8080 accepts only the web servers.
• db_from_app referenced_security_group_id = app — MySQL 3306 accepts only the app servers.
• web_all / app_all egress — Web and app can reach out; the DB group has no outbound rule because RDS does not need it.

When it is green.

$ terraform validate
Success! The configuration is valid.

When it is red.

Error: Reference to undeclared resource
  on security.tf line 26: referenced_security_group_id = aws_security_group.wb.id

Fix. A typo in a resource name. Terraform tells you the file and line; fix the name to aws_security_group.web.

What: every term in plain English

• security group — A stateful firewall attached to a network interface. Return traffic is allowed automatically.
• ingress rule — A rule that allows traffic coming in.
• egress rule — A rule that allows traffic going out.
• referenced security group — A rule source that is another security group instead of a CIDR, so only members of that group may connect.
• security group chain — Web allows the internet, app allows only web, DB allows only app.
• aws_vpc_security_group_ingress_rule — The newer resource for one ingress rule each. It avoids the conflicts of inline rules.
• stateful — If a request is allowed in, the reply is allowed out without an extra rule.
• least privilege — Open only the ports and sources a tier truly needs.

Example 1: Write the chain with referenced groups

At HDFC Bank style audits, a database port open to a CIDR is a finding. Referencing the app security group means only app servers reach MySQL, even if IPs change.

1. Create three empty groups.
2. Add one ingress rule per hop.
3. Reference the previous group as the source.

resource "aws_vpc_security_group_ingress_rule" "app_from_web" {
  security_group_id            = aws_security_group.app.id
  referenced_security_group_id = aws_security_group.web.id
  ip_protocol                  = "tcp"
  from_port                    = 8080
  to_port                      = 8080
}

resource "aws_vpc_security_group_ingress_rule" "db_from_app" {
  security_group_id            = aws_security_group.db.id
  referenced_security_group_id = aws_security_group.app.id
  ip_protocol                  = "tcp"
  from_port                    = 3306
  to_port                      = 3306
}

Output

aws_vpc_security_group_ingress_rule.app_from_web: Creation complete after 1s [id=sgr-0a11b22c33d44e55f]
aws_vpc_security_group_ingress_rule.db_from_app: Creation complete after 1s [id=sgr-0f66e77d88c99b00a]

What it shows: No CIDR on the app or DB rules. The source is a group, so the chain stays correct after servers are replaced.

Example 2: Restrict web to HTTP and HTTPS only

Flipkart style public sites expose only 80 and 443. SSH on 22 to the internet is the first thing scanners flag.

1. Allow 80 from 0.0.0.0/0.
2. Allow 443 from 0.0.0.0/0.
3. Do not add 22; use Session Manager.

resource "aws_vpc_security_group_ingress_rule" "web_http" {
  security_group_id = aws_security_group.web.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "tcp"
  from_port         = 80
  to_port           = 80
}

resource "aws_vpc_security_group_ingress_rule" "web_https" {
  security_group_id = aws_security_group.web.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "tcp"
  from_port         = 443
  to_port           = 443
}

Output

Plan: 2 to add, 0 to change, 0 to destroy.

What it shows: Even if nginx serves only HTTP today, open 443 now so adding a certificate later needs no firewall change.

Example 3: Read the chain from the CLI

During an incident at a Paytm-sized team, nobody opens the console. One CLI query shows who may reach the database.

1. Get the DB group id from outputs or state.
2. Query its ingress rules.
3. Confirm the source is the app group.

DB_SG=$(terraform state show aws_security_group.db | awk '/^ *id /{print $3}' | tr -d '"')
aws ec2 describe-security-group-rules --filters Name=group-id,Values=$DB_SG \
  --query "SecurityGroupRules[?IsEgress==\`false\`].[FromPort,ReferencedGroupInfo.GroupId,CidrIpv4]" --output table

Output

----------------------------------------------
|         DescribeSecurityGroupRules         |
+------+------------------------+-----------+
|  3306|  sg-0app1234567890abc  |  None     |
+------+------------------------+-----------+

What it shows: Exactly one ingress rule, port 3306, source the app group, no CIDR. That is the audit evidence.

Example 4: Why the DB group has no egress rule

Security groups are stateful, so MySQL replies flow back without an egress rule. Leaving egress empty on the DB group stops the database from calling out if it were ever compromised.

1. Give web and app an egress-all rule.
2. Give the DB group none.
3. Test that the app still gets query results.

resource "aws_security_group" "db" {
  name        = "${var.project}-db"
  description = "MySQL from app tier only"
  vpc_id      = aws_vpc.main.id
  # no egress rule on purpose: replies are allowed because SGs are stateful
}

Output

mysql> SELECT 1;
+---+
| 1 |
+---+

What it shows: The query result returned even with no egress rule. That proves stateful behaviour.

Example 5: Scan the groups before apply

Teams at Zomato run a scanner in CI so an open port never reaches review. Checkov reads the rules without touching AWS.

1. Run Checkov on the folder.
2. Look only at security group checks.
3. Fix anything that opens 22 or 3306 to the world.

checkov -d . --framework terraform --compact --quiet | grep -A2 "security group"

Output

Check: CKV_AWS_23: "Ensure every security group and rule has a description"
    FAILED for resource: aws_vpc_security_group_ingress_rule.web_http

What it shows: Add description = "HTTP from internet" to each rule. Small fix, cleaner audits.

Command cheat sheet

Verify: did it work?

1. Three groups exist

   terraform state list | grep -c "aws_security_group\."
   

   Output

   3
   

2. DB rule uses a group source

   aws ec2 describe-security-group-rules --filters Name=group-id,Values=$DB_SG --query "length(SecurityGroupRules[?ReferencedGroupInfo])"
   

   Output

   1
   

3. No port 22 anywhere

   grep -c "from_port *= 22" security.tf
   

   Output

   0
   

When it is red 1

Error: InvalidPermission.Duplicate: the specified rule "peer: 0.0.0.0/0, TCP, from port: 80" already exists

Cause. An inline ingress block and a separate rule resource define the same rule.

Fix, step by step

1. Use only aws_vpc_security_group_ingress_rule resources.
2. Remove inline ingress blocks from aws_security_group.

When it is red 2

curl: (28) Failed to connect to 10.30.11.25 port 8080 after 5001 ms: Timeout was reached

Cause. The app group does not allow 8080 from the web group.

Fix, step by step

1. Check app_from_web exists.
2. Check the referenced group is web, not app.

When it is red 3

ERROR 2003 (HY000): Can't connect to MySQL server on 'hrportal-mysql...' (110)

Cause. The DB group does not allow 3306 from the app group.

Fix, step by step

1. Check db_from_app.
2. Confirm the app server has the app group attached.

Cleanup

terraform destroy -auto-approve

Practice tasks

Homework: try at home

Recap

• Each tier allows only the tier in front of it.
• Use referenced groups instead of CIDRs between tiers.
• Security groups are stateful.
• Never open 22 or 3306 to 0.0.0.0/0.
• Use one rule resource per rule.

FAQ

Why not one group for all tiers?

Then every server can reach the database; one hacked web server exposes everything.

Can a group reference itself?

Yes, useful for clusters where members talk to each other.

Do I need NACLs too?

Not for this lab. Security groups are enough for most apps; NACLs add a subnet-level layer.

Why the new rule resources?

Inline rules and separate rules fight each other. One rule per resource is clear and safe.

Interview questions

1. How do you allow only the app tier to reach RDS?

   An ingress rule on the DB group for 3306 with the app security group as the source.

2. What does stateful mean for a security group?

   Replies to allowed traffic are allowed automatically.

3. Security group versus NACL?

   SG is stateful and per interface; NACL is stateless and per subnet.

4. How do you avoid SSH on servers?

   Use Systems Manager Session Manager with an instance role.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards