AWS recently launched a preview of the AWS Network Firewall proxy, a managed service for proxy management and deployment. According to the company, this service allows customers to focus more on the security policies governing outbound access from their VPCs.
The Network Firewall proxy is integrated with the NAT Gateway service, which operates within the VPC and handles IP address translation for outgoing traffic. Users’ applications can connect to the proxy from both local and remote VPCs via a proxy-specific VPC interface endpoint powered by AWS PrivateLink.
(Source: AWS Network & Connectivity Blog)
Unlike traditional transparent firewalls, the proxy inspects network traffic by handling HTTP CONNECT requests and establishing connections on behalf of applications. It evaluates traffic in a sequential three-phase model:
- PreDNS: Evaluated before the proxy resolves the destination domain.
- PreRequest: Evaluated before the proxy sends the request to the destination.
- PostResponse: Evaluated after the proxy receives the response from the server.
Access rules are applied at each stage; if traffic is blocked in an earlier phase, subsequent phases do not trigger, optimizing processing efficiency.
Users can configure the Network Firewall’s proxy to either intercept TLS or allow TLS to pass through untouched. In case TLS interception is enabled, the proxy generates a certificate for the real destination, allowing it to inspect HTTP-layer content and apply policies. However, the workload must trust the proxy’s certificate authority. In contrast, when interception is disabled, an end-to-end encrypted tunnel is established directly between the workload and the destination, preventing the proxy from decrypting the payload and limiting policy enforcement to unencrypted metadata such as DNS, IP addresses, or SNI.
Architecturally, the service supports both distributed (per-VPC) and centralized models. In centralized setups, engineers can leverage Transit Gateway or Cloud WAN to route egress traffic from multiple VPCs to a single proxy endpoint, significantly reducing the administrative “tax” of patching and scaling traditional self-hosted Squid fleets. However, a key limitation remains, as Ivo Pinto points out in a LinkedIn post: the proxy is strictly for HTTP/HTTPS traffic, making it a specialized tool rather than a general-purpose network firewall.
The authors of the blog post on Network Firewall Proxy write:
Network Firewall proxy can be used to protect traffic from the local VPC, remote VPC, or even on-premises sources. As long as your workload has connectivity to the proxy endpoint, it can use the proxy service. Note that traffic can only reach the proxy through an endpoint. If you simply route traffic to the NAT Gateway, it will not apply proxy policies on it.
Currently, the service is available in the East Ohio AWS region and in preview. Kayesee commented in a Reddit thread:
Best to try it out. It is free in the Public Preview phase. It’s essentially a managed explicit forward proxy. You can configure rules for traffic from specific locations (e.g., VPC, account, or CIDR) to be whitelisted/blacklisted for specific websites. The workloads have to be proxy-aware (explicit).
Lastly, more details are available on the documentation pages.
