cloud networking
three clouds, three
firewall models — none of them
are zero trust
security groups, NSGs, and VPC firewall rules look interchangeable on a slide. they aren't. here's where enforcement logic, group references, and hard limits actually diverge.
$ compare --enforcement aws azure gcp
# aws: allow-only, union of SGs, no explicit deny
aws.sg hard_ceiling=1000 rules/ENI ref=sg-id
# azure: ordered priority, explicit deny supported
azure.nsg hard_ceiling=1000 rules/NSG ref=asg
# gcp: global per-VPC, identity-aware via service accounts
gcp.fw soft_ceiling=200–500/project ref=tag|sa
# aws: allow-only, union of SGs, no explicit deny
aws.sg hard_ceiling=1000 rules/ENI ref=sg-id
# azure: ordered priority, explicit deny supported
azure.nsg hard_ceiling=1000 rules/NSG ref=asg
# gcp: global per-VPC, identity-aware via service accounts
gcp.fw soft_ceiling=200–500/project ref=tag|sa
// the comparison
enforcement, references, ceilings
AWS
Security Group
ENI-attached · stateful · allow-only
SGs per ENI
5default · max 16
Rules per SG
60in / out · soft
SGs per VPC
2,500soft
hard ceiling
1,000 rules / ENI
not adjustable — SGs-per-ENI × rules-per-SG must stay under this product
reference
sg-id
Azure
Network Security Group
subnet + NIC · stateful · allow & deny
Attachment points
2subnet + NIC
NSGs per region
5,000soft
Priority range
100–4096ordered eval
hard ceiling
1,000 rules / NSG
not adjustable — inbound + outbound combined, regardless of priority range
reference
application security group
GCP
VPC Firewall Rule
VPC-global · stateful · allow & deny
Attachment point
0policy is global
Rules per project
200soft · to 500
Tags / SAs per rule
30–70/ 10–10
soft ceiling
200–500 / project
hierarchical org/folder policies bypass this limit entirely
reference
tag | service account
union, unordered
multiple SGs on one ENI combine by OR. nothing overrides what another SG permits — there is no explicit deny.
ordered, first-match
priority-ranked rules with explicit deny. a tighter rule can override a broader allow placed earlier.
ordered, first-match
same logic as azure, but applied globally across the VPC rather than at a discrete attachment point.
// reference primitive
topology-bound vs. identity-bound
aws
sg reference
membership in a security group — pure network topology, no workload identity involved.
azure
asg reference
membership in an application security group — same topology binding, separate object.
gcp
service account
bound to workload identity via IAM — closest of the three to identity-native enforcement.
even GCP's service-account model is standing access — granted once, held until revoked. none of the three native models offer time-bound, intent-driven, ephemeral access at the policy-decision level.