Stateful = the firewall keeps a connection-tracking table. Once it allows one direction of a connection, the return traffic is allowed automatically — you never write a rule for the reply.

Stateless = every packet is judged on its own, no memory of the connection. You must explicitly allow both directions (request and reply).

Example — a client hitting a web server on 443

A client at 10.0.0.5:54321 (a random ephemeral source port) connects to a web server at 10.0.1.9:443.

The classic stateless footgun: you open inbound 443, it "half works," and you're left debugging why responses vanish — because you never opened the outbound ephemeral port range for the replies.

Takeaway: GCP firewall rules are stateful, so you almost never think about return traffic. The only stateless model among the big clouds is the AWS NACL — which is exactly why NACLs feel fiddly.

In GCP, an instance runs as a service account (an IAM identity bound to the VM). A firewall rule can then match on that identity via source_service_accounts / target_service_accounts instead of IPs or tags. The rule applies to whichever instances run as that SA — no IP bookkeeping.

Scenario — app tier may reach the DB, nothing else may

• App VMs run as app-sa@proj.iam.gserviceaccount.com
• DB VMs run as db-sa@proj.iam.gserviceaccount.com
• Goal: only app-tier VMs can reach Postgres (5432) on the DB tier.

# The instances declare their identity:
resource "google_compute_instance" "app" {
  # ...
  service_account { email = google_service_account.app.email }
}
resource "google_compute_instance" "db" {
  # ...
  service_account { email = google_service_account.db.email }
}

# The rule matches on identity, not IP or tag:
resource "google_compute_firewall" "db_from_app" {
  name      = "allow-app-to-db"
  network   = google_compute_network.vpc.id
  direction = "INGRESS"

  allow {
    protocol = "tcp"
    ports    = ["5432"]
  }

  target_service_accounts = [google_service_account.db.email]  # applies to DB VMs
  source_service_accounts = [google_service_account.app.email] # allowed callers
}

Why it's nice: an autoscaler can spin up 50 new app VMs with brand-new IPs — they're allowed the instant they boot, because they run as app-sa. No IP lists, no tag to spoof. Changing a VM's SA requires **stopping it + iam.serviceAccountUser

• compute permissions**, so access is gated by IAM, not by a mutable label.

⚠️ Restriction: you can't mix service accounts and tags in the same rule (no source_service_accounts together with source_tags/target_tags). Pick one model per rule.

AWS equivalent — Security Group referencing another Security Group

AWS has no IAM-identity firewalling, but the same pattern is expressed with one SG referencing another as its source. Membership in the app SG grants access, much like membership-by-service-account in GCP.

resource "aws_security_group" "app" { name = "app-sg" vpc_id = aws_vpc.main.id }
resource "aws_security_group" "db"  { name = "db-sg"  vpc_id = aws_vpc.main.id }

# DB SG allows 5432 only from instances in the app SG:
resource "aws_security_group_rule" "db_from_app" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.db.id   # attached to DB instances
  source_security_group_id = aws_security_group.app.id  # membership = access
}

Difference that matters: GCP binds to a real IAM identity (spoofing- resistant, auditable in IAM); AWS/Azure bind to network-group membership on the interface. Same "membership grants access" idea, different trust anchor.