Renaming Network Firewall Name Causes Routes ‘AlreadyExists’ Errors on Route Creation

[prabhukiran9999]

Describe the bug
When attempting to update the Network Firewall configuration by changing the firewall name in the configuration file and re-running the Landing Zone Accelerator pipeline, the deployment fails due to existing firewall-related routes in the associated route tables. Specifically, CloudFormation attempts to create new routes for the renamed firewall, but routes with identical CIDR destinations and types that are related to the previous firewall already exist. This leads to “The route identified by X.X.X.X/XX already exists.” errors and causes the pipeline to fail. The issue seems to be caused by the solution not properly handling dependencies or cleaning up existing firewall routes before re-creating them under the new firewall name.

To Reproduce

1. Deploy the Landing Zone Accelerator with a given Network Firewall configuration (including firewall name and associated routes).
2. Change the name of the existing firewall in the network configuration YAML file.
3. Re-run the pipeline to apply the updated configuration.
4. Observe the pipeline failing with Routes “AlreadyExists” errors for routes that CloudFormation attempts to create again.

Expected behavior
When updating a firewall’s name, the existing firewall routes should either be updated or replaced seamlessly. The solution should handle the rename operation gracefully by removing or reassigning affected routes before creating new ones, ensuring the pipeline can be run successfully.

Please complete the following information about the solution:

• Version: [ 1.9.2(CCCS Medium)]
• Region: [ca-central-1]
• Was the solution modified from the version published on this repository? No.
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the services this solution uses? Yes
• Were there any errors in the CloudWatch Logs? Yes, Route “AlreadyExists” errors were found in the pipeline logs.

Screenshots

Additional context
The problem seems closely tied to how route creation dependencies are managed. Adjusting the firewall name should not require manually removing or altering routes. A more clean dependency management or a cleanup mechanism when firewall resources are updated would help prevent these deployment failures.

To temporarily work around this issue, I first renamed the firewall and commented out the Perimeter VPC routes in the YAML file. After running the pipeline and having the firewall recreated with the new name, I then uncommented the Perimeter VPC routes and ran the pipeline again, resulting in a successful deployment.

[bo1984]

Hi @prabhukiran9999 ! Thank you for reaching out and utilizing the Landing Zone Accelerator on AWS (LZA) solution. With the networking features of the LZA solution, end-users have to be mindful of the downstream dependencies and how to manage them in their configuration as we have documented. For this particular use case, CloudFormation will attempt to create resources first before tearing them down. Since the Amazon Network Firewall was renamed, CloudFormation created a new Amazon Network Firewall, which CloudFormation attempted to create routes pointing to the new firewall endpoints, hence the duplicate resources that you're seeing. To bypass this behavior, you'll want to account for some downtime with inspection in your environment, and take the following steps:

1. Add in new Amazon Network Firewall resource
2. In the applicable VPCs and their respective subnet route tables, comment out the routes to the Network Firewall endpoints
3. Perform the pipeline run
4. Add in the firewall endpoint routes in the previously commented out subnet route tables.
5. Perform another pipeline run.

Once this is done, you should be able to see the routes pointing to the new Amazon Network Firewall endpoints. I will keep this issue open to verify that this approach worked for you.

[prabhukiran9999]

Hey @bo1984 , The Suggested approach works. Thanks.
One other thing that we noticed is that Changing the firewall Policy to something other than the one created in the config file and running the pipeline does not revert the policy. Is this intended?