AWS Network Firewall – New Managed Firewall Service in VPC (opens in new tab)

For folks that are deploying ec2-based firewalls already, the hourly cost is flat.

Usage price seems high at first but honestly you're paying a premium for any commercial firewall product. Palo Altos, for example, are $1.38/hr if you license them through the marketplace (above the instance costs). That breaks even at 21GB/hr, so you're likely to pay a lot more for the AWS product for anything in production (possibly by an order of magnitude).

For large enough enterprises, $1k a month is a rounding error.

Also, depending on how you're provisioning accounts and laying out your networking, you may not want to be sticking one of these in every VPC. There's no one-size-fits-all, but in many cases a transit VPC that handles the egress centrally would make more sense.

Amazon often makes it a little too convenient to segment things more than you really need, which adds extra cost, like additional NAT gateways, or in this case, Managed Firewalls.

But you can use Shared VPCs that spans many accounts and drastically reduce the need for things like attachments to virtual gateways, nat gateways, service endpoints, and so on.

Looks like it is built on the new Gateway Load-Balancer, which the Enterprise firewalls are a part of and auto-scale out. Meaning, third-parties have the same scaling capabilities now. So I see this as "Oh I don't need the big fancy palo alto crowd, just the basics". I've known a lot of people who spent a lot of time trying to get snort running proper in AWS, this seems to be geared at that. The Palo Altos of the world certainly aren't scared of competing with Snort.

GCP's built-in firewalling capabilities are quite basic and on par with AWS' Security Groups and NACLs. This new offering is Suricata backed which offers much more sophisticated packet inspection, and is probably built off their recently launched Gateway Load Balancer tech [1].

A key difference is that third-party appliances, and now with Suricata, hostname based (rather than IP addresses) filtering can be applied at the VPC level. This isn't possible in GCP's native offerings.

Disclaimer: I should add that I work for a third-party firewall appliance company myself so have been looking at these developments with a lot of interest.

Although a deep-dive analysis is pending on my side, on the face of it this would seem a security-lite offering as another hacker on this thread has put it. If one were to consider what protocols are supported for hostname based filtering, what depth of checks are run, how ECH/ESNI is handled, and at what level of granularity policies can be attached to individual applications, the offering is a bit underwhelming to say the least. Compare that to our product [2] (on AWS and GCP), and ours is more straightforward to deploy, incorporates the best protocol level decisions already, and has a closer association with individual applications. (You basically stick in the protocol and hostname (even for SSH) in the description field of each Security Group or Firewall Rule.)

[1] https://aws.amazon.com/blogs/aws/introducing-aws-gateway-loa... [2] https://chasersystems.com/

This is exactly what I came here to say.

Thank you for raising this! I work for a firewall vendor myself and its drives us mad when competition uses the word URL when they can only look at SNI in a TLS handshake. By competition I mean most others are doing it too.

I guess one of the reasons they choose to say URL over FQDN or hostname is that the latter two are less likely what typical developers might venture out looking for - but I could be wrong. At least the requirements when they emerge would want URLs to be whitelisted and that is what the intercepting proxy world had been delivering.

It was a key dependency for this and they also broke it out into a separate product.

I feel exactly the same. I can't wait to try it out. Now, I just need Terraform to add support...