Cloud-Native Firewalls in Production: AWS Network Firewall, Azure Firewall Premium, and Google Cloud NGFW Explained

Thirty years ago, a firewall was a physical box bolted in front of your network. You knew exactly what traffic crossed it, you had a single point of control, and you paid the vendor’s support team roughly the GDP of a small nation to keep it running. Then cloud happened.

The engineers who built the first generation of cloud workloads made a pragmatic call: security groups and network access control lists were good enough. Stateful port-and-protocol filtering, combined with carefully designed subnets, kept most threats out. For a while it worked.

Then the attacks got smarter. Threat actors stopped trying to knock down the front door and started using legitimate HTTPS ports to exfiltrate data, command-and-control from inside your network, and hop between VPCs in ways that security groups cannot detect. I watched this play out at a fintech company where a compromised container started beaconing to a command-and-control server over port 443. Their security groups allowed outbound HTTPS to anywhere. From a layer-4 perspective, everything looked normal. The breach ran for weeks before a threat intel correlation finally caught the destination IP. A cloud-native firewall with DNS filtering and TLS inspection would have caught it within minutes of the first connection attempt.

Every major cloud provider now offers a dedicated next-generation firewall service: AWS Network Firewall, Azure Firewall Premium, and Google Cloud NGFW Enterprise. Choosing between them, or knowing when you need them at all, is one of the foundational security architecture decisions that most teams get wrong.

What Security Groups Cannot Do

Before getting into the services, it is worth being precise about the gap. Security groups and network ACLs are stateful L4 controls. They filter on protocol, port, and source or destination IP ranges. They are fast, cheap, and deeply integrated into cloud routing. They do not:

• Inspect DNS queries or block domains. An attacker can beacon to a C2 server on any IP; security groups have no way to detect or block it.
• Perform deep packet inspection on application protocols. They cannot distinguish legitimate HTTP from an HTTP tunnel carrying malicious commands.
• Block outbound HTTPS to unknown destinations. They can restrict outbound to specific CIDRs, but not specific domains or URLs.
• Provide intrusion detection or prevention. No signature matching, no anomaly detection, no threat intelligence correlation.
• Inspect east-west traffic between VPCs or subnets at the application layer.

For a dev environment or an internal tooling layer, this is probably fine. For anything carrying payment card data, protected health information, or that faces a compliance audit, it is not. PCI-DSS v4.0 requirement 1.3.3 mandates packet filtering between the cardholder data environment and all other networks. HIPAA technical safeguards push you toward logging all inter-system communications. FedRAMP Moderate and High include explicit IDS/IPS requirements. If your workloads carry these obligations, a cloud-native firewall is not a nice-to-have.

AWS Network Firewall

AWS Network Firewall has been generally available since November 2020 and has steadily evolved into the most mature cloud-native firewall service on the market. At its core it is a stateful and stateless packet filtering engine built around Suricata-compatible rules.

The rule model has two layers. Stateless rules are evaluated first and are classic 5-tuple matching: source IP, destination IP, protocol, source port, destination port. They process at line rate and pass or drop packets without tracking connection state. Stateful rules come second and get full connection context. They can match on Suricata rule syntax, which means you can drop in Emerging Threats open ruleset signatures, your SOC team’s custom detections, or AWS’s own managed rule groups covering common malware C2 patterns and exploit frameworks.

AWS provides managed rule groups that update continuously without manual maintenance on your part. The managed rule catalog covers known malicious IP sets, malware-associated domains, and domains that appear in malware campaigns but use legitimate-looking names (a class of detection that is genuinely hard to catch any other way). Subscribing to these gives you threat intelligence you would otherwise need a dedicated team to maintain.

Deployment architecture changed in 2025. For years, the standard pattern was an inspection VPC with dedicated firewall subnets, and spoke VPCs routed through Transit Gateway to reach the inspection VPC. This worked but it was operationally complex, and the cost allocation story was painful: Network Firewall charges landed in the inspection VPC’s account rather than the accounts that generated the traffic.

AWS introduced native Transit Gateway attachment for Network Firewall, and as of a July 2025 update to their security best practices guide, this is the recommended approach for new centralized deployments. With native TGW attachment, you specify a Transit Gateway when creating the firewall and AWS creates and manages the internal infrastructure. Flexible cost allocation then meters Network Firewall data processing charges back to the originating accounts, which matters enormously when you are running a multi-account org and finance wants security costs visible per team.

The inspection VPC model is not dead. You still need it when you want to run custom tooling in the inspection path, perform packet capture for forensics, or have a specific compliance requirement for an isolated inspection layer. But for new centralized deployments, the native TGW attachment is simpler.

One mistake I have watched teams make repeatedly: deploying a firewall endpoint in every AZ of every VPC to get high availability, then getting surprised by the bill at end of month. Each firewall endpoint charges per hour regardless of traffic. In a large AWS deployment with dozens of VPCs and three AZs each, distributed deployment means a lot of idle endpoint hours. Run the centralized cost math first.

In February 2026, AWS reduced Network Firewall pricing by eliminating the additional per-GB surcharge for TLS inspection that had applied in most regions. TLS inspection is now included in the standard data processing rate. The cost model is endpoint hours plus data processing per GB; check the official AWS Network Firewall pricing page for current rates, which change.

TLS inspection is where AWS Network Firewall catches the category of threats that bypasses everything else. Outbound TLS inspection means the firewall terminates the TLS connection, decrypts the payload, runs it through your stateful rules, re-encrypts it, and forwards it to the destination. You import a CA certificate the firewall uses for re-signing, and your client systems need to trust that CA. This is operationally non-trivial, especially if you have clients that pin certificates. But for environments where you need to block data exfiltration over HTTPS, TLS inspection is unavoidable.

Tie AWS Network Firewall into your broader zero-trust security posture: outbound TLS inspection combined with SPIFFE/SPIRE workload identity gives you per-connection identity plus per-packet content inspection, which is the combination that zero-trust network access actually requires.

Azure Firewall Premium

Microsoft’s firewall product line has three SKUs: Basic, Standard, and Premium. Basic is for dev and test environments with limited throughput requirements. Standard adds FQDN filtering, real-time threat intelligence that blocks known malicious IPs and domains, and traditional L3-L7 network rules. Premium is the tier you actually want in production when security is a serious requirement.

Azure Firewall Premium adds four headline capabilities. TLS inspection decrypts outbound and east-west HTTPS traffic, inspects it against your rules, and re-encrypts it before forwarding. You configure this with a certificate stored in Azure Key Vault, and clients need to trust the intermediate CA that Azure Firewall uses for re-signing. Microsoft’s documentation states Premium can scale to 100 Gbps, though you should verify current throughput limits in the Azure Firewall Premium documentation since this is a spec Microsoft updates.

IDPS (intrusion detection and prevention) uses Microsoft’s continuously updated signature library. In Alert mode it logs detections without blocking; in Alert and Deny mode it blocks traffic matching intrusion signatures. Coverage includes common exploit frameworks, C2 patterns, and known vulnerability exploitation. Unlike AWS Network Firewall’s Suricata model, you cannot write custom signatures directly into Azure Firewall. You depend on Microsoft’s managed signature updates. For most teams this is a reasonable tradeoff for reduced operational burden, but for a SOC that writes custom detections, this limitation matters.

URL filtering extends beyond FQDN matching to the full URL including path. You can allow github.com but block github.com/specific-repo. This level of control matters for environments where you need to permit broad domain access while still enforcing content policy on specific paths.

Web categories let you define policy based on content classification rather than specific domains. Block gambling sites, allow technology resources, deny known malware categories. This is table stakes in on-premises NGFWs and Azure is one of the few cloud-native firewalls to offer it, which reduces the manual allowlist/denylist maintenance that domain-based filtering requires.

Deployment in Azure almost always means hub-and-spoke, and the recommended approach is Azure Virtual WAN with a secured hub. A secured Virtual WAN hub is a standard hub with Azure Firewall deployed and routing configured so all spoke traffic flows through inspection. Azure Firewall Manager provides policy management across multiple firewalls and regions, which matters once you have more than one deployment.

The management model for Azure Firewall is Firewall Policy, not classic inline rules. Azure Firewall Policy is hierarchical: you define a base policy at the organization level that enforces common rules, then child policies per team or environment inherit the base rules and can add their own. This is the correct architecture for a multi-team organization because it prevents individual teams from accidentally creating gaps in security that affect shared infrastructure.

In May 2026, Azure Virtual Network Manager gained the ability to treat a Virtual WAN hub as the hub in hub-and-spoke network group configurations. Hundreds of spoke VNets can now be connected through network groups and connectivity configurations without manually creating each Virtual WAN connection. If you are managing large-scale Azure deployments with many spoke VNets, this reduces the configuration volume that previously made large Virtual WAN setups painful to operate.

For compliance-driven deployments, pairing Azure Firewall Premium with Azure Sentinel and a security data lake gives you an inspection plane and a detection plane in the same ecosystem with built-in connectors between them. The firewall logs flow directly into Sentinel, and you can write detection rules against the combined stream of firewall events, Azure AD sign-ins, and resource activity without building the plumbing yourself.

Google Cloud NGFW

Google’s approach to cloud-native firewalling is architecturally the most distinctive of the three. Where AWS and Azure offer a discrete firewall service you route traffic through, Cloud NGFW is integrated into the VPC networking layer. There is no separate inspection appliance to deploy in most configurations, no firewall endpoint to route through for standard tiers. You attach NGFW features directly to VPC firewall policy rules.

The product has three tiers: Essentials, Standard, and Enterprise.

Essentials is the foundational VPC firewall policy system and carries no additional charge. Standard allow/deny rules based on IP, port, protocol, secure tags, and service accounts are Essentials features. If your existing GCP environment uses VPC firewall rules or Cloud Firewall Policies, you are already using Essentials tier functionality.

Standard adds FQDN filtering and threat intelligence. FQDN filtering means you can write rules that match on domain name rather than IP address, which solves the common problem of allowing traffic to a Google API endpoint without opening broad IP ranges. Threat intelligence filtering uses Google’s continuously updated threat feed to automatically block known malicious IPs and domains. Standard tier billing applies to north-south traffic (internet-to-VM ingress and VM-to-internet egress) that matches Standard rules.

Enterprise adds Layer 7 inspection: inline IPS, TLS decryption, and URL filtering. The IPS is inline, not tap-based. Google manages zonal firewall endpoints that handle the inspection, and the architecture documentation describes them as transparent to the VPC routing fabric. Covers both TLS and plaintext traffic. The Enterprise tier billing model covers both north-south and east-west traffic matched by Enterprise rules, which is the billing boundary that catches teams off guard.

The billing model is the most important thing to understand about Google Cloud NGFW. You do not subscribe to a tier. You enable features in firewall rules, and Google bills at the rate of the highest tier used in any rule that matched a packet. If a single Enterprise-tier rule matches a packet, Google bills that packet at Enterprise rates, covering both north-south and east-west traffic.

I have seen teams accidentally apply Enterprise rules with a broad scope, matching far more traffic than intended, then see firewall costs jump significantly once east-west billing kicked in for traffic they had not expected. Google’s cost optimization advice is to assign Essentials rules higher priority than Standard or Enterprise rules, so that traffic matching simpler rules is processed at the lower tier. This is straightforward in principle but requires discipline in rule management to maintain as your environment grows.

One architectural distinction to understand: Cloud NGFW is separate from Cloud Armor. Cloud Armor is Google’s DDoS protection and WAF product, operating at the Google network edge in front of load balancers. Cloud NGFW operates inside the VPC on VM-to-VM and VPC-to-internet traffic. They are complementary, not competitive. Cloud Armor protects your public-facing load balancer endpoints; Cloud NGFW handles the traffic that Cloud Armor never sees.

For exact current rates on all three tiers, check the Cloud NGFW pricing page directly, as these change.

Deployment Patterns Compared

All three services support centralized and distributed inspection, but the specifics differ enough that your architecture decision should be made per-cloud.

For AWS, the native Transit Gateway attachment is the right starting point for most production deployments. The managed inspection infrastructure reduces operational complexity, and flexible cost allocation means security costs land in the accounts that generate them. Deploy a single firewall per region, route all spoke VPCs through it via Transit Gateway, and manage rule groups from the central security account. Add the distributed model only where you need per-VPC inspection independence, for example where one VPC carries PCI-scoped workloads and the compliance team requires isolated inspection with separate logging.

For Azure, secure Virtual WAN hubs solve the hub-and-spoke problem cleanly because routing policy configuration is built into the hub. If you are on Virtual WAN already, adding Azure Firewall Premium is operationally straightforward. If you are on traditional VNet peering, the hub-and-spoke pattern using a dedicated hub VNet with Azure Firewall is standard. Either way, Azure Firewall Manager is the correct management layer; operating Azure Firewalls without it becomes painful at scale.

For GCP, the distribution is essentially invisible at the infrastructure level because Cloud NGFW policies attach to VPC networks. Your architecture decision is about which rules use which tier and how broadly you scope Enterprise rules to avoid unintended billing. For most organizations, start with Essentials and Standard, add Enterprise only where compliance requirements explicitly mandate inline IPS, and keep Enterprise rules as specific as possible rather than applying them to all traffic.

When You Actually Need a Cloud-Native Firewall

Not every cloud workload needs one. A startup with three services behind an internal load balancer, security groups controlling ingress and egress, and no compliance requirement can function for a significant time without a cloud-native firewall. Adding one for its own sake imposes cost and operational complexity you do not need.

The use cases where L7 inspection is genuinely necessary:

Compliance requirements with explicit controls. PCI-DSS v4.0, HIPAA technical safeguards, FedRAMP Moderate and High all impose requirements that security groups cannot satisfy. If your workloads carry these obligations, a cloud-native firewall is not optional.

East-west inspection between VPCs with different security postures. Once you have workloads in multiple VPCs serving different trust levels, you need a way to verify that traffic crossing the boundary carries legitimate content. Security groups restrict which ports are open between VPCs, but they cannot detect a compromised workload in one VPC exfiltrating data to another VPC through an allowed port.

Outbound internet egress filtering from sensitive workloads. Most cloud breaches involve attacker tooling that calls home. With outbound filtering at the firewall layer, including TLS inspection for encrypted traffic, you can catch this before significant damage occurs. Security groups with broad outbound HTTPS allowed cannot.

Detecting lateral movement inside your cloud environment. A compromised container that starts scanning internal networks, or an insider threat that begins accessing resources outside their normal pattern, shows up in IPS signature matches and anomaly detection. Security groups do not provide this visibility.

If none of these apply to your workloads, your resources are better spent on hardening container images and tightening your CNAPP scanning and attack path analysis. Those controls catch more realistic threats for most organizations than a network firewall they are not actively tuning.

Third-Party NGFWs on Cloud

A discussion of cloud-native firewalls is incomplete without noting that Palo Alto Networks, Fortinet, and Check Point all offer managed NGFW services in cloud marketplaces. Palo Alto’s Cloud NGFW for AWS and Azure deploys Palo Alto hardware as a managed service without you operating the VMs directly.

The argument for third-party NGFWs is usually one of three things: your existing SOC runs on Palo Alto Panorama and adding another management plane creates unacceptable operational friction; you have multi-cloud deployments and want policy consistency across AWS, Azure, and GCP from a single tool; or you need features like custom protocol decoders and advanced application identification that native services do not provide.

The argument against is cost. Palo Alto Cloud NGFW charges per deployment hour plus per GB, and the rates are substantially higher than native services. You are paying for the feature set and the Panorama integration. If your team does not have the operational expertise to benefit from those features, you are paying for capabilities you will not use. For organizations without a dedicated network security team with NGFW expertise, the native cloud services are the right call.

For teams managing their network security as code, the native services also integrate more cleanly with infrastructure as code workflows and GitOps pipelines. Third-party NGFWs sometimes require the vendor’s proprietary management plane for policy changes, which creates a break in your IaC-managed infrastructure.

A Practical Decision Framework

After twenty years designing security infrastructure across on-premises and cloud environments, my approach to this choice has simplified.

Ask three questions:

Do you have a compliance requirement that mandates L7 inspection or IPS? If yes, you need a cloud-native firewall. Pick the native service for your primary cloud, or a third-party NGFW if your security operations team already runs one in production.

Do you have untrusted east-west traffic between different security boundaries in your architecture? Security groups are insufficient for this because they cannot inspect content, only ports and protocols. If yes, centralized inspection is the answer.

Do you have outbound internet access from workloads that process sensitive data? Outbound egress filtering with TLS inspection is not optional for these workloads.

If you answered no to all three, optimize other layers first. If you answer yes to any of them, pick your cloud’s native service, start with centralized inspection through Transit Gateway or Virtual WAN, and enable IPS in alert-only mode before switching to blocking. Alert mode builds your traffic baseline and prevents you from disrupting legitimate traffic during rollout. Once you understand your traffic patterns, move to blocking on high-confidence signature sets while reviewing medium-confidence ones in parallel.

For AWS deployments, ensure the centralized model uses native Transit Gateway attachment rather than the older inspection VPC pattern; the operational and cost allocation improvements are substantial. For Azure, use Firewall Policy and Azure Firewall Manager from day one, not classic rules. For GCP, treat the billing model as a first-class design constraint: scope Enterprise tier rules precisely, and test billing behavior in a staging environment before enabling broad Enterprise rules in production.

The cloud-native firewall market has matured to the point where there is no reason to run a production workload with compliance requirements on security groups alone. The services exist, they work, and the operational overhead is a fraction of what it was when these products launched. The question is no longer whether you need one. It is which deployment model fits your architecture and how carefully you scope your rules to avoid surprises on the bill.

For the broader network security context these firewalls sit within, see our guides on CNAPP and cloud-native application protection, AWS VPC connectivity and hub-and-spoke design, and cloud data sovereignty and residency requirements that often drive the compliance requirements pushing teams toward L7 inspection.