{"id":4651,"date":"2025-10-06T18:52:54","date_gmt":"2025-10-06T18:52:54","guid":{"rendered":"https:\/\/geekmungus.co.uk\/?p=4651"},"modified":"2025-10-06T18:52:54","modified_gmt":"2025-10-06T18:52:54","slug":"aws-web-application-firewall-waf-reconciling-aws-firewall-manager-applied-webacl-to-cloudfront-distribution","status":"publish","type":"post","link":"https:\/\/geekmungus.co.uk\/?p=4651","title":{"rendered":"AWS Web Application Firewall (WAF) – Reconciling AWS Firewall Manager Applied WebACL to CloudFront Distribution"},"content":{"rendered":"\n

We use IaC (Infrastructure as Code) for the deployment and management of all cloud (AWS) workloads to ensure we can manage and update infrastructure and applications that are deployed in the cloud rapidily and on an ongoing basis, while maintaining flexibility, security and availability. However issues may occur when changes are made using automated processes, such as the AWS Firewall Manager to “retrofit” or “enforce” particular configurations on infrastructure\/applications that are managed via IaC through Terraform (for example). The issue that can occour is that the Terraform dictates “what we want the world to look like”, if something changes the configration (within scope of the Terraform template) out-of-band of this, it is considered “drift”, and needs to be either expicitly excluded (ignored), imported into Terraform, or instead acknowledged.<\/p>\n\n\n\n

Issue<\/h1>\n\n\n\n

The example we are considering is a workload which uses the AWS CloudFront distribution to publish a web application. An AWS Firewall Manager Policy has been centrally managed and deployed to all CloudFront Distributions within the AWS Organisation. The problem is with this is that this has changed a resource that is within scope of an existing IaC (Terraform) template’s configuration. The implication of this is that because this configuration is missing from the template it is considered a “drift” from the desired configuration as denoted in the Terraform template.<\/p>\n\n\n\n

We don’t want to import the FMS-managed Web ACL into the member account\u2019s Terraform. We want to let Firewall Manager (FMS) keep ownership, but in the member account (workload account), just \u201cadopt\u201d the association on the CloudFront resource so Terraform stops trying to remove it; because it thinks it is drift. An example of this if\/when it occurs can be found below. As you can see Terraform wants to remove this because its not declared in the template.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Resolution (Recommended)<\/h1>\n\n\n\n

To resolve the issue we are going to “Adopt” the assocation into our IaC (Terraform).<\/p>\n\n\n\n

Step 1 – Determine Name<\/h2>\n\n\n\n

First determine the “Name” of the WebACL that is being applied to your CloudFront Distribution. You can do this by running this command:<\/p>\n\n\n\n

aws wafv2 list-web-acls --scope CLOUDFRONT --region us-east-1<\/code><\/pre>\n\n\n\n
We then get the output like this, and it is the “Name” attribute we are interested in.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
In our example it is: FMManagedWebACLV2-fms-cf-waf-policy-1758643214119<\/strong>, names start with FMManagedWebACLV2-<policy-name>-<timestamp>; because it is CloudFront the scope is global, i.e. us-east-1<\/strong>.<\/p>\n\n\n\n
Step 2 – Adopt the WebACL to CloudFront Distribution<\/h2>\n\n\n\n
In the workload account\u2019s Terraform, read that ACL via a data source and wire it into your aws_cloudfront_distribution.web_acl_id (which expects the ARN, not the ID). The “data” will require you to enter the policy name (not ARN), i.e. FMManagedWebACLV2-<policy-name>-<timestamp>, but then it uses this to discover the ARN, which in this used within the CloudFront.<\/p>\n\n\n\n
We obtained this value in the previous step, so we’ll then add to the relevant Terraform template containing our AWS CloudFront definition the following:<\/p>\n\n\n\n
...\n\n\/\/ AWS CloudFront Distribution - AWS Firewall Manager Deployed WAF (WebACL) ---------------------------------------------------------------------------------\n# The CloudFront distribution is subject to AWS Firewall Manager policy (or policies), therefore these need to be discovered and \"adopted\" to the configuration to avoid\n# being seen as \"drift\".\n\ndata \"aws_wafv2_web_acl\" \"fms_acl\" {\n  provider = aws.useast1\n  name  = \"FMManagedWebACLV2-fms-cf-waf-policy-1758643214119\"\n  scope = \"CLOUDFRONT\"\n}\n\n\/\/ AWS CloudFront Distribution ------------------------------------------------------------------------------------------------------------------------------\n\n# Create an AWS CloudFront distribution\nresource \"aws_cloudfront_distribution\" \"simple-cf\" {\n  ... your existing distribution config ...\n\n  # Adopt the association so Terraform doesn't try to remove it\n  web_acl_id = data.aws_wafv2_web_acl.fms_acl.arn\n\n  # Optional: if FMS might rotate the ACL (new ARN), avoid drift\n  #lifecycle {\n  #  ignore_changes = [web_acl_id]\n  #}\n\n  ... your existing distribution config ...\n}\n\n...<\/code><\/pre>\n\n\n\n
Regions and their Impact<\/h3>\n\n\n\n
You’ll notice that on the data resource above aws_wafv2_web_acl<\/strong>, that we’ve added a provider = aws.useast1<\/strong>, this is because without this the Terraform will default to whatever your current region is. If it is not us-east-1 then it will be attempting to find a resource in the wrong region, therefore the following is required in your providers.tf<\/strong> file (alongside your existing “provider” definition – if not us-east-1):<\/p>\n\n\n\n
...\nprovider \"aws\" {\n  alias   = \"useast1\"\n  region  = \"us-east-1\"\n  profile = \"ids-imt-sandbox\"\n}\n...<\/code><\/pre>\n\n\n\n
If you fail to deal with this you’ll see an error like:\u00a0Error: list WAFv2 WebACLs: operation error WAFV2: ListWebACLs, https response error StatusCode: 400, RequestID: 9c3cfaeb-dd9e-455f-a2a0-c1469cb7d689, WAFInvalidParameterException: Error reason: The scope is not valid., field: SCOPE_VALUE, parameter: CLOUDFRONT<\/strong><\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Step 3 – Verify WebACL is Adopted<\/h2>\n\n\n\n
Verifying if the WebACL is as simple as running a “terraform plan”, assuming you have no outstanding changes, you should see the “No changes. Your infrastructure matches the configuration” output, which shows that the WebACL has been successfully adopted.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Resolution (Another Way)<\/h1>\n\n\n\n
If you prefer not to reference the ACL at all:<\/p>\n\n\n\n
resource \"aws_cloudfront_distribution\" \"this\" {\n  # ... your existing distribution config ...\n\n  lifecycle {\n    # Leave association entirely to FMS\n    ignore_changes = [web_acl_id]\n  }\n}<\/code><\/pre>\n\n\n\n
This stops Terraform from trying to disassociate the FMS-applied ACL during plan\/apply (useful when FMS might replace ACLs). There\u2019s even an open provider issue discussing drift with FMS-managed associations.<\/p>\n\n\n\n
Additional Information<\/h2>\n\n\n\n