Security Groups vs Cloud Firewall Services: when native controls stop being enough

Security groups and their equivalents filter by address, port and protocol, which is enough for most east west segmentation and fails the moment a requirement is phrased as a domain name, a threat signature or an organisation wide rule. Every cloud workload already sits behind a free, stateful, distributed filter: an AWS security group, an Azure network security group (NSG) or a Google Cloud VPC firewall rule. Managed firewall services (AWS Network Firewall, Azure Firewall, Google Cloud NGFW Standard and Enterprise) cost money, add routing and become a shared dependency. This guide is about the triggers that justify adding one: egress filtering, FQDN rules, traffic inspection and central policy, plus how to add it without breaking production. It does not repeat how the native layers evaluate rules; that is in Security Groups vs Network ACLs. Platforms are listed alphabetically (AWS, Azure, Google Cloud); order is never a ranking.

Key takeaways

• Keep security groups as the baseline. They stay the right tool for workload to workload allow lists; a managed firewall is added on top for traffic that crosses a boundary, never as a replacement.
• Four triggers justify a managed firewall. Outbound traffic must be restricted to named destinations, rules must be written as domains, traffic must be inspected for threats or decrypted, or one policy must be enforced across many accounts, subscriptions or projects.
• Domain rules are the most common first trigger. Security groups match IP ranges, so allowing "only our package mirror and payment provider" is not expressible once those services sit on shared, changing addresses.
• A firewall in the path is an availability dependency. Traffic only reaches it through route tables or hub routing, so plan zonal endpoints, symmetric routing, capacity and a tested rollback before enforcing.
• Central policy has native options too. Google hierarchical firewall policies and Azure Virtual Network Manager security admin rules provide organisation level L3/L4 guardrails without a firewall appliance, so central policy alone is not always a reason to buy inspection.

The short answer

Stay with security groups, NSGs and VPC firewall rules when every rule you need can be written as "this workload may talk to that workload, or that CIDR, on this port", and when outbound internet access is either blocked entirely or limited to a few stable address ranges. Add a managed cloud firewall service when at least one of these is true: workloads need internet egress to a list of named domains, a regulator or customer requires intrusion prevention or content inspection on boundary traffic, you need to see and block threats inside allowed connections, or a central team must enforce one rule set on traffic from hundreds of networks owned by other teams. The managed firewall then handles north south and inter network traffic, while security groups keep enforcing micro segmentation at each workload. For the wider design see the Cloud Network Security Guide.

Where native controls stop

Native filters are excellent at what they are built for: they are stateful, free to use, enforced at each network interface, and can reference workload identity (AWS security group references, Azure application security groups, Google Cloud network tags and service accounts). Their ceiling is structural:

• Address based matching only: rules match IP ranges, ports and protocols. They cannot express a domain, a URL path, an application protocol on a non standard port or a file type.
• No payload awareness: an allowed HTTPS connection to an allowed address is allowed, whatever it carries. Command and control over an approved port looks identical to normal traffic.
• Traffic they never see: AWS states that security groups do not filter traffic to or from Amazon DNS, DHCP, EC2 instance metadata, ECS task metadata, Windows licence activation, Amazon Time Sync Service and reserved router addresses. DNS is the important one: DNS tunnelling (ATT&CK T1071.004) passes through the provider resolver, so it needs a DNS layer control, not a port rule.
• Open outbound by default: AWS security groups ship with a default outbound rule that allows all traffic, and Google Cloud VPC networks have an implied allow egress rule. Restricting egress with native rules alone means maintaining IP lists for every external dependency.
• Ownership spread across teams: each application team edits its own groups. That is a strength for agility and a weakness when security needs one rule enforced everywhere, quickly.

What each layer can do

Trigger 1: egress filtering to named destinations

Threat model: a compromised workload, build runner or stolen credential sends data to an attacker controlled host (T1567 Exfiltration Over Web Service, T1048 Exfiltration Over Alternative Protocol) or fetches tooling. The Codecov breach shows the pattern: a modified uploader script in customers' CI jobs posted environment variables, including secrets, to an attacker controlled address. A runner allowed to reach only its required destinations would have blocked or flagged that request.

Why native rules fall short: an egress allow list in security groups works for private destinations and fixed partner ranges, but SaaS APIs, package repositories and cloud service front ends use large, shared and changing address pools. Teams end up allowing 0.0.0.0/0 on 443, which is no control at all.

Architecture in words: private subnets send internet bound traffic through a firewall endpoint before the NAT gateway, usually in a shared egress network reached through a transit gateway, virtual hub or network connectivity hub. Security groups still restrict which workloads may originate egress at all. The Cloud Egress Filtering guide covers the domain matching details, proxies and Kubernetes egress, so they are not repeated here.

Failure modes: asymmetric routing that sends replies around the firewall; workloads with public IPs that bypass the egress path; allow lists built from guesses instead of flow logs.

Trigger 2: rules that must be written as domains

Threat model: the business requirement is phrased in names ("only api.payments.example and our artifact registry"), and IP based approximations either over allow or break when the provider changes addresses.

What the services offer: AWS Network Firewall stateful domain list rule groups limit the domains applications can reach. Azure Firewall application rules filter FQDNs using SNI for HTTP/S and SQL on all SKUs, and network rule FQDN filtering for any port and protocol on Standard and Premium, which requires DNS proxy. Google Cloud NGFW Standard adds FQDN objects to firewall policy rules on top of Essentials.

Failure modes: SNI and Host headers are supplied by the client, so domain rules should be paired with DNS layer controls and a deny on direct IP connections; wildcard domains on shared platforms can admit attacker owned tenants on the same service.

Trigger 3: inspection inside allowed traffic

Threat model: exploits, malware downloads and command and control that use permitted ports and destinations. A port rule cannot tell them apart from legitimate sessions.

What the services offer: AWS Network Firewall uses the open source Suricata engine for stateful inspection, supports Suricata compatible rules and performs stateful protocol detection regardless of port. Azure Firewall Premium adds signature based IDPS (Microsoft cites over 67,000 signatures in more than 50 categories), TLS inspection for outbound and east west traffic, URL filtering on the full path and full URL web categories; HTTPS URL filtering applies only when TLS inspection is enabled. Cloud NGFW Enterprise sends matched traffic to Google managed zonal firewall endpoints for Layer 7 inspection using security profile groups referenced by the apply_security_profile_group rule action, and can decrypt selected traffic with TLS inspection; Google states these capabilities are available only through firewall policies, not VPC firewall rules.

Failure modes: IDPS left in alert mode indefinitely; TLS inspection that breaks certificate pinned clients and mutual TLS; inspection exclusions that grow until most traffic is bypassed; gaps such as Google's documented limitation that firewall endpoints do not inspect egress from serverless workloads. The TLS Inspection Guide covers decryption trade-offs.

Trigger 4: central policy across many networks

Threat model: one team opens a database port to the internet, or a new account starts without any egress controls, and security cannot enforce a rule fast enough across hundreds of accounts, subscriptions or projects.

Native options first: Google hierarchical firewall policies attach to the organisation or folders and are evaluated before VPC firewall rules; Azure Virtual Network Manager security admin rules are evaluated before NSGs, so a central Deny holds even when an application team allows the port. For pure L3/L4 guardrails these may be enough.

Managed firewall options: AWS Firewall Manager centrally configures Network Firewall across accounts in AWS Organizations from a single account. Azure Firewall Manager applies firewall policies across firewalls in multiple subscriptions, in virtual networks and Virtual WAN secured hubs. On Google Cloud, Layer 7 inspection rules can live in hierarchical firewall policies as well as global network policies.

Failure modes: central rules that nobody owns after the project ends; local exceptions granted at the workload layer that silently defeat the central intent; policy managers whose administrators become a high value target. See the Firewall Management Guide.

Provider availability notes

Deeper per provider hardening lives in the AWS Network Firewall guide and the Google Cloud VPC and Cloud NGFW Security Guide.

Decision guidance

Small estates with a few networks can often meet egress needs with a DNS firewall, strict security groups and one shared egress firewall at the lowest tier that supports FQDN rules. Large estates usually centralise egress and inter network inspection in a hub, keep application teams in charge of security groups, and give a central team the managed firewall policy. If users rather than workloads need web filtering, compare the Secure Web Gateway vs NGFW options.

Worked scenario: a SaaS company hits the egress trigger

A SaaS company runs 60 AWS accounts and a smaller Azure footprint. Security groups segment every service well. An assessment finds that build runners and application tiers allow outbound TCP 443 to any address, and a customer contract now requires egress restrictions and intrusion prevention on internet traffic.

The team builds an allow list from 30 days of VPC flow logs and DNS query logs, then deploys AWS Network Firewall in a central egress VPC behind the transit gateway, with domain list rules in alert mode, and Azure Firewall Standard in the Azure hub with application rules for the same domains. Security groups are tightened so only tiers with a documented need may originate internet traffic. After two weeks of alerts and owner sign off, CI runner networks switch to enforce first, because they hold the most secrets, followed by production one account group at a time. Each change keeps the previous route table so traffic can be returned to the NAT path within minutes if the firewall misbehaves. IDPS is enabled in alert mode, tuned, then moved to drop for high confidence signatures.

Implementation and rollback

1. Write down the trigger. Record which of the four triggers applies, because it decides the tier you need and avoids buying inspection you will not use.
2. Collect evidence. Use flow logs and DNS logs to list real destinations per workload group before writing rules.
3. Design routing. Choose distributed firewalls per network or a central hub; confirm symmetric paths and one endpoint per zone to avoid cross zone traffic and single zone failure.
4. Deploy in alert mode. Start with alert or log only actions, a default allow, and full logging to your SIEM.
5. Enforce in rings. Move the highest risk networks (CI, internet facing) to default deny first, then the rest by account or subscription group.
6. Keep a rollback path. Retain the previous route tables and firewall policy version; document who can revert and how fast.
7. Harden the firewall's own identities. Restrict who can edit firewall policies and route tables through least privilege roles; changes to either can switch the control off (ATT&CK T1686 Disable or Modify System Firewall covers host firewalls; treat cloud firewall policy changes with the same suspicion).

Where identity fits

A managed firewall limits where a stolen workload credential can be used from and where secrets can be sent, which is why CI runners and AI agents deserve the strictest egress lists. The firewall itself is also governed by identity: the roles that can change firewall policy, route tables or Firewall Manager policy are privileged and belong in your access reviews. See the Agent Egress Control and Network Isolation Guide.

Detection and measurement

• Egress coverage: percentage of internet bound flows that traverse a managed firewall, from flow logs.
• Open egress rules: count of security groups, NSGs and firewall rules allowing 0.0.0.0/0 outbound on any port, trended down.
• Bypass paths: workloads with public IPs or routes to an internet gateway that skip the firewall.
• Denied egress by workload: blocked connections to non allow listed domains, reviewed weekly for both false positives and real findings.
• IDPS mode ratio: share of signatures in drop versus alert, and time to tune new alerts.
• Policy change audit: every change to firewall policy, rule groups and route tables, matched to a change ticket.

Common failure patterns

• Buying inspection for a central policy problem: organisation wide L3/L4 denies were available natively, and the expensive tier sits in alert mode.
• Firewall without route changes: the service is deployed but some subnets still route straight to NAT or an internet gateway.
• Retiring security groups after the firewall arrives: east west segmentation disappears and one compromised workload can reach everything behind the same firewall.
• Domain allow lists without DNS controls: clients can present an approved name while connecting elsewhere, and DNS tunnelling is never inspected.
• Single zone endpoints: a zonal issue or a route mistake takes down egress for the whole estate.
• Exclusions that never expire: TLS inspection and IDPS bypass lists grow until the control covers little traffic.

Framework mapping

Practitioner checklist

• Keep security groups, NSGs and VPC firewall rules as the workload level allow list in every design.
• Record which trigger (egress, FQDN, inspection, central policy) justifies a managed firewall and pick the lowest tier that meets it.
• Check native central guardrails (hierarchical policies, security admin rules) before buying for central policy alone.
• Build egress allow lists from flow and DNS logs, not from guesses.
• Pair domain rules with DNS layer filtering and a deny on direct IP egress.
• Deploy zonal endpoints with symmetric routing and keep a tested route table rollback.
• Enforce in rings, CI and internet facing networks first.
• Treat firewall policy and route table permissions as privileged and review them.

Standards and references

• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• AWS: Control traffic to your AWS resources using security groups
• AWS: What is AWS Network Firewall?
• Microsoft Learn: What is Azure Firewall?
• Microsoft Learn: Azure Firewall features by SKU
• Google Cloud: Cloud NGFW overview
• Google Cloud: Intrusion prevention service overview

Related NHI Mgmt Group resources: Security Groups vs Network ACLs · AWS Network Firewall · Google Cloud VPC and Cloud NGFW Security Guide · Cloud Egress Filtering · Firewall Buyer's Guide