Cloud Egress Filtering: The 'Everything is HTTPS' Problem

Cloud Security

AWS Network Firewall, Azure Firewall, and GCP Cloud NGFW all promise FQDN-based egress filtering. The reality is messier when half your traffic is HTTPS to AWS service endpoints.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 25, 2024 · 7 min read

Egress filtering used to mean a Palo Alto or Check Point at the corporate perimeter doing SSL decryption and URL categorization. In the cloud, the perimeter is the VPC and the tools are AWS Network Firewall, Azure Firewall Premium, GCP Cloud NGFW, or third-party network virtual appliances (Palo Alto VM-Series, Fortinet FortiGate-VM, etc). All of them advertise FQDN-based egress filtering. None of them solve the problem cleanly because most cloud traffic is HTTPS to AWS service endpoints that share certificates across products.

AWS Network Firewall in practice

AWS Network Firewall (ANFW) is a managed service that runs Suricata rules at the VPC level. It supports stateful inspection, FQDN-based filtering via SNI inspection for TLS, and basic IPS rules via the managed rule groups from AWS.

What works well:

• Allow-list FQDNs for known third-party APIs (GitHub, PyPI, Docker Hub).
• Deny outbound to TOR exit nodes and known malicious IPs (AWS managed threat intelligence rule group).
• Block specific TLS versions, suspicious JA3 fingerprints (with Suricata rules).

What does not work well: per-AWS-service filtering. AWS service endpoints (s3.amazonaws.com, ec2.amazonaws.com, sts.amazonaws.com) all share an *.amazonaws.com certificate. SNI-based filtering can see the specific subdomain (e.g., my-bucket.s3.ap-south-1.amazonaws.com), but writing rules to allow only specific buckets through SNI is fragile because of path-style vs virtual-hosted-style addressing. AWS recommends VPC endpoints with endpoint policies for this case, not Network Firewall.

Azure Firewall Premium

Azure Firewall Premium adds TLS inspection (with a certificate the firewall presents to clients, requires CA trust on the client side), URL filtering with categories, and IDPS. The TLS inspection actually decrypts traffic, which lets it filter on full URL paths rather than just SNI.

The catch: TLS inspection requires a certificate signed by a CA that all internal clients trust. Distributing that CA cert to every workload (containers, serverless functions, EC2 instances) is operationally heavy and breaks anything that pins certificates. Half the SDKs we use pin AWS or third-party certificates and break the moment you man-in-the-middle them.

GCP Cloud NGFW

Cloud NGFW (GA mid-2023) is GCP's answer, with Cloud NGFW Enterprise tier offering FQDN-based filtering, threat prevention, and TLS inspection. Same trade-offs as Azure: TLS inspection requires cert distribution and breaks pinning workloads.

GCP's pattern of recommending VPC Service Controls in addition to NGFW is the right one. VPC Service Controls is identity-based egress filtering at the API level, which sidesteps the network-layer SNI problem entirely. Combined with private Google access endpoints, it gives the strongest egress posture in the major clouds.

The 'allow-list amazonaws.com' anti-pattern

We see this every audit: AWS Network Firewall configured with an allow rule for *.amazonaws.com and a default deny for everything else. The intent is reasonable (only allow AWS-bound traffic). The reality is that *.amazonaws.com is a massive surface that includes S3 globally, every Lambda function in every account, every public ECR repository, and a lot more.

A compromised workload allow-listed to *.amazonaws.com can exfiltrate data to any S3 bucket in any account, including attacker-controlled accounts. The FQDN allow-list does not actually constrain anything useful.

Better pattern: use VPC endpoints with endpoint policies that scope to your AWS Organization (aws:PrincipalOrgID condition). Network Firewall handles non-AWS egress only.

What egress filtering actually catches

Despite the gaps, egress filtering catches real attacks:

1. Cryptominer C2 to known mining pools. We have seen this on freshly compromised EKS workers running misconfigured Pod images. ANFW with the AWS managed crypto rule group catches it.
2. Credential exfil to pastebin / Discord webhooks / attacker-controlled domains. Most attackers do not bother registering AWS-blessed domains for exfil channels.
3. DNS-over-HTTPS to non-allowlisted resolvers, when DNS filtering is part of the policy.

Realistic recommendation

For most AWS estates we configure:

• VPC endpoints with endpoint policies scoped to the Organization for all AWS service traffic.
• AWS Network Firewall with the managed threat intelligence rule group and an FQDN allow-list for known third-party APIs (GitHub, PyPI, npm, Docker Hub, a small list of vendors).
• Route 53 Resolver DNS Firewall blocking newly registered domains, DGA-likely domains, and known malicious domains.
• VPC Flow Logs to S3 for forensics, with Athena queries for unexpected destinations.

We do not enable TLS inspection in 99% of cloud environments. The cert distribution complexity and the breakage of pinning SDKs outweigh the marginal value. Identity-based controls (IAM, VPC endpoint policies, Service Controls) are stronger and cheaper.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.