Skip to content
Ask AI about this
Help improve this page

Network Firewall firewalls should have subnet change protection enabled

Subnet associations determine which VPC subnets route traffic through a Network Firewall. If an attacker or misconfigured automation removes or changes these associations, traffic bypasses inspection entirely, leaving workloads exposed. Subnet change protection requires a deliberate two-step sequence to modify associations: disable the protection first, then make the change.

This matters most in multi-team environments where several engineers or CI/CD pipelines have write access to firewall resources. A single errant API call to AssociateSubnets or DisassociateSubnets could silently reroute production traffic around your inspection layer.

Implementation

Choose the approach that matches how you manage Terraform.

If you use terraform-aws-modules/network-firewall/aws//modules/firewall, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "network_firewall" {
  source  = "terraform-aws-modules/network-firewall/aws//modules/firewall"
  version = ">=1.0.0"

  firewall_policy_arn = "arn:aws:iam::123456789012:policy/example-policy"
  name                = "abc123"
  subnet_mapping = {
    subnet1 = {
      subnet_id = "subnet-12345678"
    }
  }
  vpc_id = "vpc-12345678"

  subnet_change_protection = true
}

Use AWS provider resources directly. See docs for the resources involved: aws_networkfirewall_firewall.

resource "aws_networkfirewall_firewall" "this" {
  firewall_policy_arn = "arn:aws:network-firewall:us-east-1:123456789012:firewall-policy/example"
  name                = "pofix-abc123"

  subnet_mapping {
    subnet_id = "subnet-12345678"
  }

  vpc_id = "vpc-12345678"

  subnet_change_protection = true
}

What this control checks

The aws_networkfirewall_firewall resource must have subnet_change_protection set to true. When omitted, the argument defaults to false, so the control fails for any firewall that doesn't set it explicitly. No additional resources or nested blocks are required. Adding subnet_change_protection = true to the firewall resource definition is sufficient.

Common pitfalls

  • Default value is false

    The subnet_change_protection argument on aws_networkfirewall_firewall defaults to false. Omitting it entirely causes the control to fail. Every firewall resource must explicitly set subnet_change_protection = true.

  • Confused with delete protection

    delete_protection is a separate argument. Enabling one does not enable the other, and the control checks them independently. If both are required, both must be explicitly configured.

  • Terraform apply blocked if protection is on

    With subnet_change_protection = true, Terraform cannot modify subnet mappings in a single apply. The API enforces the restriction, so lifecycle blocks won't work around it. Plan for a two-step apply in any CI/CD pipeline that manages firewall subnet mappings: disable protection first, then change subnets.

Audit evidence

An auditor expects Config rule evaluation results (from the managed rule or a custom rule checking SubnetChangeProtection) showing all Network Firewall resources as compliant. Console screenshots of each firewall's "Firewall details" page with "Subnet change protection" set to "Enabled" provide direct visual confirmation. CloudTrail logs for UpdateSubnetChangeProtection API calls show that protection was enabled and that any subsequent modifications were intentional and authorized.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: networkfirewall_firewall_subnet_change_protection_enabled

  • AWS Config Managed Rule: NETFW_SUBNET_CHANGE_PROTECTION_ENABLED

  • Powerpipe Control: aws_compliance.control.networkfirewall_firewall_subnet_change_protection_enabled

  • AWS Security Hub Control: NetworkFirewall.10

Last reviewed: 2026-03-09