Skip to content
Notifications
Clear all

Best NGFW for a hybrid AWS/on-prem shop under 300 users - real deployment stories

34 Posts
33 Users
0 Reactions
3 Views
(@ethanb8)
Estimable Member
Joined: 3 weeks ago
Posts: 179
 

That packet buffer contention you saw is the hidden cost of the unified model. The latency number they quote for AWS assumes a clean traffic profile, not sustained database replication. Once your flows hit that 1.2 Gbps wall, the exemptions start.

Your logging workaround mirrors what a lot of teams end up doing. It's frustrating that the proposed "solution" is always another paid service, not an acknowledgement of the architectural limit. Did you find the S3/Athena pipeline gave you acceptable query times for incident response, or was it purely for compliance retention?


Keep it civil, keep it real


   
ReplyQuote
(@henryb)
Trusted Member
Joined: 2 weeks ago
Posts: 58
 

> Consistent App-ID, User-ID, and Threat-ID enforcement regardless of traffic origin.

This was the biggest promise that fell apart for us too, but for a simpler reason. We're a smaller shop, maybe 100 users, and couldn't even get the PAN agents to install reliably on all our on-prem machines. So our "User-ID" consistency was broken before traffic even hit the firewall.

Our reporting got messy fast because some logs had usernames and some didn't. How did you handle that gap between the promise and the actual endpoint coverage?



   
ReplyQuote
(@ava23)
Reputable Member
Joined: 3 weeks ago
Posts: 184
 

That 85ms p99 latency is the real number they don't print on the datasheet. Synthetic tests are useless, they exist to match the vendor's checkbox.

We hit the same wall with replication traffic. You end up with a flowchart of exemptions that looks nothing like the "unified policy" slide from the sales deck. The whole model collapses once you admit that some of your packets are more equal than others.


Trust but verify.


   
ReplyQuote
(@danielp)
Estimable Member
Joined: 3 weeks ago
Posts: 92
 

Oh yeah, the Cloud NGFW is interesting. We tested it briefly in a dev account. The policy push *feels* faster because you're just clicking in a portal, but the actual rule propagation time to the AWS backend still had a noticeable lag - maybe 1-2 minutes instead of 3-5. Not exactly real-time.

The real trade-off is cost predictability. It cuts GWLB complexity, sure, but now you're on a per-GB inspected model. For that real-time data pipeline you mentioned, it could get wildly expensive fast. Kind of feels like you're just swapping one type of bill shock for another.



   
ReplyQuote
Page 3 / 3