I hadn't done much work with AWS Network Firewall (NFW) until I was tasked with decommissioning one. I knew its general purpose in terms of providing blanket network protection for traffic moving through a VPC but I didn't know much about how it interacted with VPC routing. Before making any changes, I did some reading to understand what I was about to remove and what dependencies I needed to consider.
What is a NFW?
AWS NFW is a managed, stateful network firewall and intrusion detection/prevention service for VPCs. It allows you to inspect and filter network traffic based on rules that you define. It inspects traffic coming in and out of your VPC, traffic between VPCs and traffic from Direct Connect and VPNs, and can inspect traffic at OSI layers three (network) through seven (application). This means rules can range from filtering traffic based on IP addresses, ports and protocols to inspecting application-level characteristics such as domain names.
Components
A NFW has the following components:
Firewall → the actual NFW resource associated with the VPC
Firewall policy → defines how the firewall handles traffic and which rule groups it uses
Rule groups → contain the actual rules used to inspect and allow/drop traffic
Stateless vs Stateful Rules
Stateless rules - inspect each packet independently, the firewall evaluates the packet based on the information available in that individual packet without considering packets that came before it
Stateful rules - understand the wider context of a network connection, the firewall tracks the flow and can make decisions based on the state of the connection rather than treating every packet independently
For the decommission, I didn't need to modify the individual firewall rules but understanding how the firewall was inspecting and controlling traffic helped me work out how I could validate its removal.
Understanding the Network Path
Before removing the NFW, it was important to understand how traffic was currently reaching it and where that traffic would need to go once the NFW was no longer part of the path.
I started by checking the VPC route tables using the Resource Map to see which routes were connected to the NFW.
There were 3 main route tables:
1. Transit Gateway route table
Traffic from other VPCs entered the NFW VPC through the Transit Gateway (TGW).
This route table contained a catch all 0.0.0.0/0 route that directed traffic towards the NFW however, every VPC route table also contains an automatically created local route for the VPC CIDR.
AWS uses longest-prefix matching when selecting routes meaning the more specific local route takes precedence over the generic 0.0.0.0/0 route. Since the NAT Gateway subnets were within the VPC CIDR, traffic destined for those subnets could therefore bypass the NFW. To prevent this, additional routes were needed to explicitly direct traffic through the NFW endpoints before it continued towards the NAT Gateways.
2. NAT/IGW route table
This contained a route to send traffic to the NAT Gateway and another to send traffic to the IGW.
3. Firewall/return path route table
This contained routes back towards the TGW for traffic destined for the connected VPCs as well as routes towards the NAT Gateway for outbound traffic.
This took me a while to wrap my head around because the NFW wasn't sitting between two resources. The route tables were what forced traffic through it and the direction of traffic determined which route table and firewall endpoint was involved and so I used VPC Reachability Analyzer to visualise the network path. It looked something like this:
Spoke VPC → TGW → Network Firewall → NAT Gateway → IGW → Internet
and then for return traffic:
Internet → IGW → NAT Gateway → Network Firewall → TGW → Spoke VPC
Before you make a networking change, you want to know what currently works even if it means traffic being intentionally blocked. One of the firewall rules blocked access to Bing and Yahoo. Before removing the NFW, I connected to an EC2 instance in the development account and tested connectivity to one of those domains and as expected the request failed. I also checked the firewall logs to confirm that traffic was reaching the firewall and that the expected rules were being applied.
Decommissioning the Network Firewall
The NFW was managed through Landing Zone Accelerator with infrastructure changes deployed through CodePipeline.
The first step was to move traffic away from the firewall by updating the relevant route tables. At a high level this involved:
- updating the default routes so outbound traffic was sent directly towards the NAT Gateways rather than the NFW endpoints
- adding routes for internal network ranges so traffic could continue to reach the TGW
- updating the NAT subnet route tables so return traffic for internal destinations was sent back towards the TGW instead of through the NFW
Once the routing changes were in place, the plan was to remove the NFW configuration entirely.
However, the first pipeline deployment failed while applying the route changes. The existing 0.0.0.0/0 route still referenced the NFW endpoint and the infrastructure deployment was unable to replace that route with the new target in a single change.
This meant the decommission needed to be split into an additional step. The existing firewall routes first had to be removed so the new routes could then be applied in the next deployment after which the NFW itself could be removed.
The final sequence became:
- Remove the routes that referenced the NFW endpoints
- Deploy the updated routing configuration without the NFW in the traffic path
- Remove the NFW configuration
Once the NFW had been removed, I repeated the same connectivity test from the EC2 instance. This time the destination was reachable, confirming that traffic was no longer being routed through the NFW and that the updated route was working as expected.
What I Learned
What I initially thought would be a straightforward resource removal ended up being much more about understanding VPC routing and resource dependencies. Decommissioning the NFW safely meant understanding not only what the firewall was doing but how traffic was being routed through it and what needed to replace that path once it was gone.
This work formed part of a wider FinOps activity focused on reducing unnecessary AWS spend. Removing the unused NFW helped eliminate an ongoing cost of around $400 per month while also simplifying the network architecture.
Top comments (0)