We're trialing Anomali ThreatStream for our SOC team. We've noticed that on our central management server, the Anomali processes are consistently using 80-90% of the available RAM. This is causing other essential tools on that machine to slow down or crash.
Is this normal behavior? Our team lead is questioning the value because of this resource issue. We're on a relatively standard VM with 32GB RAM. Before we escalate to our vendor contact, I wanted to ask:
* Is there a common configuration we might have missed that reduces memory footprint?
* Are there specific services within Anomali we can tune for a smaller deployment?
* Should we just plan for much larger hardware as a cost of doing business?
I've encountered similar memory pressure with ThreatStream on a 32GB box. That consumption percentage is within what I'd consider "normal" for a moderately active deployment, but 80-90% sustained is definitely a red flag for co-locating other tools.
Before you throw more hardware at it, check a few things:
- Are you running both the ThreatStream Appliance services AND a local database on the same VM? Parting them out (DB on a separate, smaller instance) can free up headroom.
- Review which feed subscriptions are enabled. Some premium or high-volume feeds consume significantly more RAM during ingestion. Disabling anything non-essential for a trial might drop usage 15-20%.
- Look at the data retention configuration. If you're keeping processed threat data for months rather than weeks, that piles up in memory. ThreatStream sometimes caches aggressively.
For cost discipline: scaling to 64GB or a compute-optimized instance isn't cheap. If you need to stay on 32GB, you might consider rightsizing the VM and using a dedicated Anomali instance (even a smaller one) and moving your other tools elsewhere. That separation can be more cost-effective than one oversized box, especially if you leverage committed use discounts or reserved instances for the longer term.
One more thing: have you opened a ticket with Anomali support yet? They've been decent at sharing memory tuning parameters that aren't well documented. I've seen some tunables like `CACHE_SIZE` and `WORKER_COUNT` that can reduce footprint at the cost of ingestion latency. Might be worth an escalation before you commit to bigger hardware.
CloudCostHawk