2.3.1.4. Network Security Design (Security Groups, Network ACLs, Network Firewall, WAF, Shield)

2.3.1.4. Network Security Design (Security Groups, Network ACLs, Network Firewall, WAF, Shield)

💡 First Principle: A multi-layered, defense-in-depth approach to network security, applied at the instance, subnet, and edge, is essential for protecting resources from unauthorized network access and malicious attacks.

Scenario: You are designing a new multi-tier web application. The web servers will be publicly accessible, but the application servers and database servers must be strictly protected from direct internet access. You need to implement layered security to protect against common web exploits and network-level attacks.

Robust network security is paramount in cloud environments. AWS provides a suite of services for layered defense.

• "Security Groups (SGs)": Instance-level, "stateful" virtual firewalls.
  • Practical Relevance: Control inbound/outbound traffic to individual "EC2 instances" or "ENIs". Allow rules automatically imply return traffic. Best practice is to use "SGs" as the primary instance firewall.
• "Network Access Control Lists (Network ACLs / NACLs)": Subnet-level, "stateless" firewalls.
  • Practical Relevance: Control traffic to and from one or more subnets. Rules are evaluated in order (lowest number first). Must explicitly allow inbound and outbound return traffic. Useful for broad subnet-level blocking or allowing.
• "AWS Network Firewall": A managed service that makes it easier to deploy network protections for all your "Amazon VPCs".
  • Practical Relevance: Provides deep packet inspection, intrusion prevention and detection, web filtering, and granular traffic control at the "VPC border". Integrates with "AWS Firewall Manager".
• "AWS WAF (Web Application Firewall)": Protects web applications or APIs from common web exploits and bots.
  • Practical Relevance: Filters HTTP/S requests based on rules (e.g., "SQL injection", "XSS", IP reputation, geo-blocking). Integrates with "CloudFront", "ALB", "API Gateway".
• "AWS Shield": Managed Distributed Denial of Service ("DDoS") protection service.
  • Practical Relevance: "Shield Standard" (free) provides automatic protection against common network and transport layer DDoS attacks. "Shield Advanced" (paid) provides enhanced protection, cost protection for scaling, and access to the "DDoS Response Team".

Visual: Network Security Layers (Defense in Depth)

⚠️ Common Pitfall: Relying solely on "Security Groups" for all network security. While "SGs" are the primary instance-level firewall, "Network ACLs" provide a crucial additional layer of defense at the subnet level, useful for blocking known malicious IP addresses before traffic even reaches the instances.

Key Trade-Offs:

• Granularity ("Security Groups") vs. Broad Control ("Network ACLs"): "Security Groups" provide fine-grained, stateful control for specific instances. "Network ACLs" provide broad, stateless allow/deny rules for entire subnets.

Design Rules the Exam Tests:

• Network ACL rule order: Rules are evaluated from the lowest rule number upward and the first match wins. A "deny" for a malicious range only works if its rule number is lower than the broad "allow" it must override; a deny numbered after the allow is never reached. The final * rule is an implicit deny.
• Tier-to-tier least privilege: Reference a security group ID as the source (database SG allows the DB port only from the application tier's SG) instead of CIDR ranges or instance IPs. The rule then follows instances as they scale, and nothing else can reach the tier. Never open a data tier to "0.0.0.0/0".
• Layer 7 vs. Layer 3/4: "AWS WAF" is the layer 7 control (SQL injection, XSS, managed rule groups such as the Core rule set and SQL database rules, plus custom rate-based rules). It attaches to "CloudFront", "ALB", "API Gateway", "AppSync" and "Cognito user pools", but not to an "NLB"; an "NLB" passes TCP and inspects nothing at layer 7. "Shield Standard" covers layer 3/4 floods only and does not stop SQL injection or XSS. "Amazon GuardDuty" and "Amazon Inspector" detect threats and vulnerabilities; they do not sit in the traffic path blocking requests. For a public web app, DDoS plus web exploits means "Shield" + "WAF" in front of the "ALB"/"CloudFront".
• Absorbing volumetric attacks at the edge: Putting "CloudFront" in front of the origin means layer 3/4 floods hit the edge network, not the "ALB". "Shield Advanced" adds the Shield Response Team, cost protection and advanced detection for protected resources. WAF rate-based rules throttle HTTP floods (layer 7) but cannot stop volumetric network floods.
• API protection: "API Gateway" + "AWS WAF" blocks common web exploits. Callers are authenticated by a Cognito user pool authorizer (API Gateway validates the user pool token with no code; the token carries the user's group membership for method-level checks) or a Lambda authorizer (custom logic). Resource policies, API keys and usage plans control who may call / how much, not exploit filtering.
• Centralized inspection (hub-and-spoke): Attach spoke VPCs to a "Transit Gateway" and route east-west and internet-bound traffic to a central inspection VPC containing "AWS Network Firewall" endpoints (managed, highly available, stateful and intrusion-prevention rules), with "NAT Gateways" in the inspection (or a central egress) VPC for outbound. Enable appliance mode on the inspection VPC attachment so both directions of a flow use the same AZ appliance. "VPC Peering" is non-transitive and cannot centralize inspection.
• Third-party appliances behind a "Gateway Load Balancer" (GWLB): To inspect inter-VPC and internet-bound traffic with a fleet of third-party firewall or IDS appliances (Palo Alto, Fortinet, etc.), put the appliances behind a GWLB in the central inspection VPC. Workload VPCs send traffic to it through GWLB endpoints (route-table targets), with "Transit Gateway" as the hub for spoke-to-spoke flows. GWLB operates at layer 3 and encapsulates traffic with GENEVE, so each appliance receives the packet with its original source and destination IP and returns it the same way: transparent insertion, with no source NAT. It keeps flows symmetric, scales the appliance fleet horizontally and fails over on health checks. "ALB"/"NLB" are not transparent bump-in-the-wire inserters, "Transit Gateway" only routes, and security groups and NACLs filter by IP/port and cannot do appliance-grade inspection.
• Blocking malicious domains: "Route 53 Resolver DNS Firewall": Filters outbound DNS queries from VPCs against domain lists, including AWS-managed lists of malicious domains. Security groups and NACLs work on IP addresses and cannot follow a domain, and "GuardDuty" only detects DNS-based threats.
• "AWS Firewall Manager" policies: Firewall Manager (which needs "AWS Organizations", an administrator account and "AWS Config") places a WAF policy's central rule groups first or last in every in-scope web ACL, including those of new accounts and resources, while account owners add their own rules in between and Firewall Manager keeps the central rule groups in place; compliance is visible centrally and in "Security Hub". It rolls out "Route 53 Resolver DNS Firewall" rule groups to VPCs the same way. A "WebACL" belongs to one account and Region and cannot be shared through "AWS RAM"; SCPs restrict API calls but do not deploy or enforce rules. Its other policy types (Shield Advanced, "AWS Network Firewall", security groups) likewise apply across the Organization and cover new accounts and resources automatically. Security group policies come in three kinds: common (replicates a primary security group into in-scope accounts and associates it with resources), content audit (checks rules against what you allow or deny) and usage audit (finds unused or redundant groups). Security groups hold only allow rules, so an explicit deny (such as blocking a malicious IP range everywhere) needs a construct that supports deny or drop rules, such as a network ACL or an AWS Network Firewall rule group.

Reflection Question: How would you combine "VPC subnets", "Security Groups", "Network ACLs", "AWS WAF", and "AWS Shield" to create a robust, multi-layered network security design for a multi-tier web application, ensuring public access only to web servers while strictly protecting application and database servers from direct internet exposure?