Study guide

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF

Key Takeaways Explain This Topic AI

Security Groups provide stateful, instance/ENI-level filtering supporting allow rules only, whereas Network ACLs (NACLs) provide stateless, subnet-level filtering with ordered allow/deny rules requiring explicit egress ephemeral port rules (1024–65535).

AWS WAF protects Layer 7 web applications deployed on CloudFront, Application Load Balancers, API Gateway, AppSync, and Cognito, utilizing AWS Managed Rules, rate-based rules, and custom IP/regex match statements.

Automated IP blocking pipelines stream WAF access logs via Kinesis Data Firehose to S3 or Athena, triggering Lambda functions to dynamically append offending client IPs to a WAF IP Set or NACL blocklist within seconds.

AWS Network Firewall delivers stateful and stateless Layer 3–7 VPC inspection using the open-source Suricata engine, deployed via dedicated firewall subnets and VPC Ingress Routing route table associations.

Shield Advanced adds enhanced DDoS detection, cost-protection eligibility, health-based detection, and Shield Response Team (SRT) support. Current Layer 7 designs use an AWS WAF web ACL and the Anti-DDoS managed rule group; Route 53 health checks improve detection and enable proactive SRT engagement.

Last updated: September 2026

Network Security Defense-in-Depth Across the OSI Model

In modern cloud architectures, securing network ingress and egress requires a layered defense-in-depth model that spans multiple layers of the Open Systems Interconnection (OSI) framework. Rather than relying on a single perimeter firewall, AWS distributes network security controls across the edge, the Virtual Private Cloud (VPC) boundary, subnet perimeters, and individual Elastic Network Interfaces (ENIs).

OSI Layer Mapping of AWS Network Security Controls

OSI Layer Inspection Scope AWS Security Controls Key Operational Characteristics

Layer 7 (Application) HTTP/HTTPS headers, URIs, query strings, body payloads, cookies AWS WAF, AWS Shield Advanced Inspects web application transactions, mitigates SQL injection (SQLi), Cross-Site Scripting (XSS), bot traffic, and HTTP flood attacks

Layer 3–7 (Network to Application) Packet payloads, Suricata rules, domain names, TLS Server Name Indication (SNI) AWS Network Firewall Performs deep packet inspection (DPI), stateful protocol validation, outbound domain filtering, and intrusion prevention (IPS) across VPC boundaries

Layer 4 (Transport) TCP/UDP port numbers, protocol states Security Groups Stateful packet filtering operating at the hypervisor level attached to ENIs; automatically tracks connection state

Layer 3/4 (Network / Transport) Source/destination IP CIDRs, protocols, port ranges Network Access Control Lists (NACLs) Stateless packet filtering operating at the subnet boundary; processes numbered rules in sequential order

Layer 3/4 (DDoS Mitigation) SYN floods, UDP reflection attacks, volume floods AWS Shield Standard & Shield Advanced Edge-level DDoS protection at CloudFront, Route 53, and Elastic Load Balancing ingress points

Security Groups vs. Network ACLs: Architectural Comparison

DevOps engineers must master the behavioral differences between Security Groups and Network ACLs to ensure traffic flow reliability while enforcing strict least privilege.

Detailed Technical Comparison

  • Dimension Security Groups Network ACLs (NACLs)
  • Operating Scope Elastic Network Interface (ENI) level Subnet boundary level

Statefulness Stateful : Return traffic is automatically allowed, regardless of inbound or outbound rules Stateless : Return traffic is not tracked; inbound and outbound rules are evaluated independently for every packet

Rule Processing Evaluates all rules before deciding whether to allow traffic; order does not matter Evaluates rules in ascending numerical order (e.g., 100 before 200); terminates on first match

Permitted Actions Allow only (no explicit deny rules) Allow and Deny rules

Default Rule State New SG: Denies all inbound, allows all outbound. Default SG: Allows all inbound from same SG, allows all outbound Default NACL: Allows all inbound and outbound. Custom NACL: Denies all inbound and outbound until configured

Target References IPv4/IPv6 CIDR blocks, Prefix Lists, and Security Group IDs (self-referencing or peer SGs) IPv4/IPv6 CIDR blocks only (cannot reference Security Group IDs or other NACLs)

Ephemeral Ports Handled transparently by connection tracking state table Must explicitly open outbound ephemeral port ranges (TCP 1024–65535) for return traffic Incoming Request (Client -> Web Server :443)

  • │
  • ▼
  • [ Subnet Boundary: Network ACL ] ──> Evaluates Inbound Rules (Rule 100: Allow TCP 443)
  • │ (Stateless: must allow inbound port 443)
  • ▼
  • [ Instance ENI: Security Group ] ──> Evaluates Allow Rules (Allow TCP 443 from 0.0.0.0/0)
  • │ (Stateful: opens connection tracking entry)
  • ▼
  • [ Web Server Application ]
  • │
  • ▼ Response Sent (Web Server -> Client Ephemeral Port :49152)
  • [ Instance ENI: Security Group ] ──> Auto-Permitted by Connection Tracking (Bypasses Outbound Rules)
  • │
  • ▼
  • [ Subnet Boundary: Network ACL ] ──> Evaluates Outbound Rules (Rule 100: Allow TCP 1024-65535)
  • (Stateless: MUST have outbound ephemeral rule or packet drops!)

Important

DOP-C02 Ephemeral Port Pitfall : When troubleshooting private subnet instances accessing external services (such as downloading patches via a NAT Gateway), the outbound connection initiates to port 80/443, but the return packets arrive on an ephemeral port. For Amazon Linux and NAT Gateways, the ephemeral range is 1024–65535 . For Windows Server, it is 49152–65535 . If the subnet NACL does not permit outbound ephemeral traffic, the response is dropped, resulting in client timeouts.

AWS WAF: Architecture, Rule Groups & Associations

AWS WAF is a Layer 7 web application firewall that inspects HTTP and HTTPS traffic targeting web endpoints. It operates using Web Access Control Lists (Web ACLs) , which contain an ordered collection of rules evaluated by priority.

Supported Association Targets

Amazon CloudFront : Distributed globally at edge locations. Web ACLs must be created in the us-east-1 (N. Virginia) region.

Application Load Balancers (ALBs) : Regional inspection before traffic hits backend EC2 targets or ECS containers.

Amazon API Gateway : Regional inspection for REST and HTTP APIs.

AWS AppSync : GraphQL API protection against oversized queries and nested introspection attacks.

Amazon Cognito User Pools : Protection against credential stuffing and brute-force authentication attacks.

Rule Types and Evaluation Mechanics

AWS Managed Rules (AMR) : Pre-configured, AWS-maintained rule sets:

Core Rule Set (CRS) : Covers OWASP Top 10 vulnerabilities (XSS, path traversal, command injection).

Known Bad Inputs : Blocks malformed request patterns and known exploits.

SQL Database Rule Set : Detects SQL injection (SQLi) vectors.

Amazon IP Reputation List : Blocks IPs associated with bots, TOR nodes, and compromised hosts.

Bot Control : Classifies scrapers, search engines, and malicious automated tools.

Account Takeover Prevention (ATP) : Protects login pages against credential stuffing.

Rate-Based Rules : Track request volume per originating IP address over a sliding evaluation window of 60, 120, 300 (default), or 600 seconds (1, 2, 5, or 10 minutes). If requests exceed the configured threshold (e.g., 300 requests per minute), WAF immediately applies the configured action (Block, Count, CAPTCHA, or Challenge) until the rate subsides.

Custom Rule Statements : Inspect headers, cookies, query arguments, HTTP methods, and body payloads using regex patterns, string matching, size constraints, and geo-matching (blocking or allowing by ISO country code). {

  • "Name": "RateLimitLoginEndpoint",
  • "Priority": 10,
  • "Action": {
  • "Block": {}
  • },
  • "VisibilityConfig": {
  • "SampledRequestsEnabled": true,
  • "CloudWatchMetricsEnabled": true,
  • "MetricName": "RateLimitLoginEndpoint"
  • },
  • "Statement": {
  • "RateBasedStatement": {
  • "Limit": 300,
  • "EvaluationWindowSec": 60,
  • "AggregateKeyType": "IP",
  • "ScopeDownStatement": {
  • "ByteMatchStatement": {
  • "SearchString": "/api/v1/auth/login",
  • "FieldToMatch": {
  • "UriPath": {}
  • },
  • "TextTransformations": [
  • {
  • "Priority": 0,
  • "Type": "LOWERCASE"
  • }
  • ],
  • "PositionalConstraint": "EXACTLY"
  • }
  • }
  • }
  • }
  • }
  • Automated IP Blocking Pipelines

When standard rate limits or managed rules detect persistent malicious actors, organizations deploy automated pipelines to extract offending IP addresses and enforce dynamic blocklists across the infrastructure.

Sub-Minute Automated Remediation Workflow

Telemetry Streaming : AWS WAF full access logging is directed to an Amazon Kinesis Data Firehose delivery stream with a buffer interval set to 60 seconds (or directly to Amazon CloudWatch Logs / Amazon S3).

Log Parsing & Detection : Amazon Kinesis Data Firehose buffers incoming JSON log records and invokes an inline AWS Lambda transformation function or delivers logs to an S3 staging bucket where Amazon Athena or Lambda processes suspicious patterns (e.g., error codes 401/403 exceeding 50 per minute per IP).

Dynamic Rule Enforcement : Lambda calls the wafv2:UpdateIPSet API to insert the offending IP into an AWS WAF IP Set referenced by a high-priority block rule. Simultaneously, Lambda can invoke ec2:CreateNetworkAclEntry to block traffic at the subnet boundary before it consumes ALB compute resources.

Expiration Management : An Amazon DynamoDB table tracks the blocked IP address along with a Time to Live (TTL) attribute set to 1 hour. A DynamoDB Streams event or scheduled EventBridge rule triggers a cleanup Lambda function to remove expired IPs from the WAF IP Set.

AWS Network Firewall: Architecture & VPC Ingress Routing

While AWS WAF inspects Layer 7 HTTP/S applications, enterprise networks require deep packet inspection (DPI) for non-HTTP traffic, egress filtering to prevent data exfiltration, and stateful intrusion prevention (IPS).

Architectural Ingress Routing Pattern

AWS Network Firewall is deployed into a dedicated firewall subnet within each Availability Zone. Traffic routing is controlled using VPC Ingress Routing (edge route table associations attached to the Internet Gateway):

Edge Route Table : Associated with the Internet Gateway (IGW). Contains a route targeting the public workload subnet CIDR ( 10.0.1.0/24 ) with the target set to the Network Firewall VPC Endpoint ( vpce-xxx ).

Firewall Subnet Route Table : Contains a default route ( 0.0.0.0/0 ) pointing to the Internet Gateway ( igw-xxx ).

Workload Subnet Route Table : Contains a default route ( 0.0.0.0/0 ) pointing to the Network Firewall VPC Endpoint ( vpce-xxx ). Internet

  • │ (Ingress Traffic)
  • ▼
  • [ Internet Gateway (IGW) ] ──> Edge Route Table: 10.0.1.0/24 -> vpce-firewall
  • │
  • ▼ (Redirected to Firewall)
  • [ Firewall Subnet: AWS Network Firewall Endpoint ] ──> Evaluates Suricata Rules & Domain Lists
  • │ (Allows legitimate traffic)
  • ▼
  • [ Workload Subnet: Application Load Balancer / EC2 ]
  • Rule Group Engines

Stateless Rule Groups : Evaluated first. Inspects 5-tuple packet attributes (source IP, source port, destination IP, destination port, protocol). Actions include Pass , Drop , or Forward to stateful rule groups .

Stateful Rule Groups : Evaluates bidirectional connection state using Suricata-compatible syntax. Supports:

5-tuple inspection with state tracking.

Domain list filtering : Allows or denies outbound HTTP Host and TLS SNI requests (e.g., preventing C2 exfiltration by allowing only *.corp.amazon.com ).

Suricata IPS rules : Detects protocol anomalies, buffer overflows, and known malware signatures.

AWS Shield Standard vs. AWS Shield Advanced

Distributed Denial of Service (DDoS) attacks threaten service availability at Layers 3, 4, and 7. AWS provides two tiers of protection.

DDoS Protection Tier Comparison

  • Feature AWS Shield Standard AWS Shield Advanced
  • Cost Included automatically at no extra cost $3,000/month base fee + data transfer usage fees

Protection Scope Common Layer 3 and Layer 4 attacks (SYN floods, UDP reflection, ICMP floods) Comprehensive Layer 3, 4, and 7 protection

Protected Resources All AWS public endpoints globally CloudFront distributions, Route 53 hosted zones, ALBs, NLBs, AWS Global Accelerator, and Elastic IPs

Shield Response Team (SRT) Not available 24/7 SRT support ; with prior authorization, the SRT can inspect and update WAF protections during an attack

Financial Cost Protection None (standard auto-scaling infrastructure charges apply) Cost spike protection : Credits provided for scaling spikes caused by DDoS attacks on protected resources

Health Check Integration None Route 53 health checks improve detection and are required for proactive SRT engagement

Application-Layer Protection Customer-managed WAF rules and fees Shield Advanced includes eligible WAF protection; as of March 26, 2026, the AWS WAF Anti-DDoS managed rule group is the default HTTP-flood protection, superseding legacy Layer 7 Auto Mitigation

For CloudFront and ALB resources, associate an AWS WAF v2 web ACL and use the current AWSManagedRulesAntiDDoSRuleSet for automated HTTP-flood detection and mitigation. Existing Shield Advanced customers may continue using the legacy Shield-managed Layer 7 Auto Mitigation feature, but AWS recommends the Anti-DDoS managed rule group. Health checks are a separate signal that improves detection and enables proactive SRT engagement; they do not by themselves turn on automatic Layer 7 mitigation.

Loading diagram... Network Defense-in-Depth & Automated IP Blocking Architecture