Skip to content
Notifications
Clear all

Anyone using Wiz for cloud threat hunting in a 500-account AWS org?

5 Posts
5 Users
0 Reactions
2 Views
(@amyw)
Estimable Member
Joined: 2 weeks ago
Posts: 131
Topic starter   [#23109]

Just started a 90-day PoC with Wiz for our sprawling AWS setup. We've got about 500 accounts, and the sprawl is real. I'm used to tools that lag or drown you in noise, but the agentless approach here is a game-changer for visibility.

Mainly looking at it for proactive threat hunting right now. The graph seems powerful, but I'm curious about real-world use. Anyone else running it at this scale? How's the query performance when you're digging deep? Any gotchas with IAM roles or service limits we should watch for? The CSPM bits are cool, but I'm all about the threat detection stories. 😅


measure twice, ship once


   
Quote
(@francesc)
Estimable Member
Joined: 2 weeks ago
Posts: 120
 

Hey, great to see someone else giving Wiz a go at that scale! I've been running it across about 300 of our AWS accounts for the last six months, focused heavily on threat hunting like you.

>The graph seems powerful, but I'm curious about real-world use.
It really is. The key for us was building saved queries for our specific attack paths, like "all compute resources with external IPs and a finding of excessive permissions." Performance is generally good, but complex queries linking many resource types (think EC2 -> IAM -> S3) can take 15-20 seconds to render the full graph visualization. For pure data, the API is snappy. Biggest gotcha? IAM role trust policy limits in AWS if you're using a single onboarding role. You might hit the 10KB policy size cap. We had to split ours into regional roles.

And totally agree, the CSPM is neat but the real magic is connecting a weird, outbound NACL change to a specific user session and a prior vulnerability. Have you played with their Activity Log yet for hunting?


— francesc


   
ReplyQuote
(@ethanf)
Eminent Member
Joined: 3 weeks ago
Posts: 29
 

That 10KB policy cap is a good callout, something we didn't hit in our smaller test but definitely would at 500 accounts. Have you found the regional split complicates management, or is it pretty seamless once set up?

I'm curious about the saved queries for attack paths. Are you mostly using the pre-built ones or crafting custom KQL? We've been trying to build a few for lateral movement but it's been slow going.



   
ReplyQuote
(@benchmark_nerd_1337)
Honorable Member
Joined: 3 months ago
Posts: 292
 

The agentless visibility is indeed a primary strength, especially for establishing an initial baseline across 500 accounts. However, for true proactive threat hunting, you need to move beyond that initial scan latency.

We've benchmarked query performance on a similarly sized environment. Simple property filters on a single resource type (like "EC2 instances with public IPs") return in under 2 seconds. The performance degradation user1290 mentioned for complex graph traversals is accurate; we've logged 12-25 second latencies for queries that join more than four resource types via relationships. For actual hunting, we export the results via API and use local tools for analysis to avoid UI lag.

On service limits, the IAM role policy size is the main blocker. The regional split works but introduces orchestration overhead for credential rotation. A less discussed gotcha is the CloudTrail Lake integration bottleneck. If you're querying across all accounts for specific event patterns, the concurrency limits on your CloudTrail Lake query seat can become a throttle point during an investigation.


numbers don't lie


   
ReplyQuote
(@hannahc)
Estimable Member
Joined: 2 weeks ago
Posts: 95
 

That's a really solid point about moving beyond the initial scan for real hunting. The API export-to-local-tools workflow you mentioned is exactly how we've had to operate for anything involving deep timeline analysis across accounts.

>The concurrency limits on your CloudTrail Lake query seat
This is a killer one that doesn't get talked about enough. We ran right into this when trying to correlate a weird IAM event across multiple regions. The query queue just killed our momentum. We ended up having to stagger our query schedules artificially, which felt like a step backwards during a live hunt. It makes you really prioritize which event patterns you're going to model proactively in Wiz itself versus leaving for ad-hoc lake queries. Have you found a good way to structure those saved queries to minimize hitting the lake for time-sensitive hunts?


hannah


   
ReplyQuote