AWS Network Firewall – New Managed Firewall Service in VPC | Hacker News Reader

AWS Network Firewall – New Managed Firewall Service in VPC

aws.amazon.com

78 pointsdduarte28 comments

Almost $.40/hour, you need one per AZ, and it’s $.06/GB for network traffic. I’m happy to see the capability (mainly outbound URL filtering), but this looks like it’s going to be a hard sell to my managers.

You’re probably looking at a grand per month per account. On the plus side, they don’t double charge for NAT gateway traffic.

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.

It’s really not a rounding error. What happens is we have hundreds of these little rounding errors and some poor dude exists solely to work out where all the money is leaking out of the budget.

Then you find it’s some weird inter VPC peering transit cost through a firewall because something was designed by an external consultancy who didn’t do a cost analysis or didn’t understand which one of the myriad of complex charging rules were invoked. The end game being you’re architecturally tied into paying $1000 a month 100 times over.

Corporate clouds are complicated and with complexity comes extreme expense. Even small ones can escalate quickly.

For large enough enterprises, $1M a month is similarly irrelevant.

Should security pricing only be accessible to businesses over a certain size?

A monthly price floor on services like this is trash. It’s pay-what-you-use, so it should scale evenly down to $0, just like lambda or network transfer usage costs.

To be fair, you are ALWAYS using a security device even if your instance should not be doing anything. You want to know when something malicious is incoming from the internet, or when suddenly that malware calls out to a C2 server. You may think your instances are being quiet, but, that is why you have security tools for the abnormal behaviors and those can happen at anytime.

Similarly, the instance is ALWAYS connected to the internet, but I only have to pay for what I transfer. Same with Lambda and S3 and everything else AWS sells (except a few weird exceptions like this).

Every place I've worked the AWS bill has always gone into a sort of a cost center blackhole. Finance would do their best in the beginning of the year to negotiate discounts & teams would do their best to keep costs low w/ reserved instances, etc.

Even though $1k is indeed a rounding error where I work vs. what we pay each month, it's becoming annoying how granular the billing for new setups is becoming. When I'm asked to compare TCO of an on-prem solution vs. a hosted one that includes all-of-the-above, I feel like I'm playing actuary and not cloud engineer.

When asked to compare I always immediately get instructed by subordinates to apply the existing lies they were telling. That's how you manage cloud costs!

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).

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.

This can hook into Transit Gateway too if you're routing all of your VPC traffic through there I think.

Looking at the firewall vendors that are listed as official partners here, this looks like another pretty security-lite, native product for companies that are just looking to check a compliance box and not a real enterprise offering.

Similar to the AWS WAF, this seems geared for a smaller team that can't afford the time to deploy and manage virtual security appliances.

It looks like they're following the same formula as the WAF on this one by letting partners provide rulesets.

I'm waiting for AWS to really flesh these products out and eat all these "partners" lunches.

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.

This reminds me of Google clouds built in network firewall[1], which is just called "Google Cloud Firewalls". One difference is that Googles firewall capabilities are built in and part of the platform, no extra service or fees. Just thought it could be an interesting reference for people not so used to GCP.

[1] https://cloud.google.com/firewalls

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/

Oh man, if I had this a few years ago, I could have used it instead of a nightmarish solution involving proxying all AWS traffic through a datacentre that had Palo Alto devices.

It kinda amazes me how they can deploy this major topology change with no network issues.

This is exactly what I came here to say.

Hmm transparent proxy, can do 5 tuple and domain filtering, can’t do URL filtering bc doesn’t terminate tls I assume? They Should update the product page and take out “URL filtering” before it confuses other people..

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.

Ergonomics of SNI / domain rules suck, you think it’s ok until you have to choose whether or not to whitelist all of SQS or something and you end up having giant holes in your firewall because you can’t be specific enough and few services cater to those behind proxies..

I wonder if they had to build the new Gateway Load Balancer in their implementation of this, so they decided to turn it into a product as well.

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

This was also something AWS was a couple years behind Azure on.

Azure internal load balancers have some hang ups, but load balancing egress or east-west traffic across security appliances in AWS has always been diabolical in comparison.

I've never used the Geneve protocol, so I can't really tell if this is going to affect which vendors can use the GWLB.

Azure had more specific routing capabilities, yes. But they can't do what this does and maintain the flow stickiness and sessions and scale out.

Makes total sense. I haven't tried it yet but it would have really made life easier for me a couple of years ago. :)

We've been waiting for this one for about a year so we can get rid of some of our home grown solutions. Can't wait to implement and see what it can do. Curious to see what other customers think.

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

Reply on news.ycombinator.com