We've been running Sysdig Secure for two years across three GCP Kubernetes clusters (~200 nodes). Initial POC was smooth, but scaling up revealed two major pricing pain points that weren't clear during sales discussions.
**1. Image Scanning Cost Creep**
The per-image scan quote looked manageable. Reality: every layer in your pipeline triggers a scan, and each counts as a "scan event." Our Jenkins pipeline does a scan on build, another on registry push, and a final one on deployment. Multi-arch images? Double it. The billable "events" exploded beyond our projected monthly count by 300%. No easy way to deduplicate without breaking security gates.
**2. Agent Resource Overhead & Scaling**
The `sysdig-agent` DaemonSet is hungry. Per node, we see:
- Consistent 0.5 vCPU request, often spiking to 0.8
- 600Mi memory baseline
This adds up fast. For 200 nodes, that's ~100 reserved vCPUs and 120Gi of memory just for monitoring/security. That's infrastructure cost on top of the license fee. Scaling the cluster? Your Sysdig cost scales linearly, even if you're just adding nodes for batch jobs.
Our current agent config snippet (showing resource requests we had to set to avoid evictions):
```yaml
resources:
requests:
cpu: 500m
memory: 600Mi
limits:
cpu: 1000m
memory: 1200Mi
```
**Bottom line:** The per-host license is just the entry ticket. The real cost is in the compounded scanning events and the infrastructure burden of running their agent at scale. We're now evaluating whether to move scanning to a pre-merge tool like Trivy and use Sysdig only for runtime.
Anyone else hit this? How did you adjust your deployment or negotiate with their sales?
-shift
shift left or go home
The per-image scan event counting is a common trap. Did your sales rep clarify whether scans of the same image SHA at different pipeline stages are considered distinct events? I've seen some vendors only charge for unique scans against the registry, not per-pipeline invocation.
You're right to flag the resource overhead. That 0.5 vCPU request is a placeholder, but the actual consumption can spike during event bursts, like a container startup storm. I've seen nodes throttle under load because the agent's cpu limit wasn't set high enough to cover those bursts, leading to dropped metrics or security events.
It creates a double penalty: you're paying for the reserved capacity in your cluster *and* the per-node licensing fee. When you scale for a short-lived batch job, you're effectively paying Sysdig twice for that temporary node - once for the infrastructure to run their agent, and once for the license seat.
Have you looked at adjusting the agent's sampling rate or disabling certain collectors? It can trim the footprint, but you start trading off data fidelity for cost, which defeats the purpose.
Always have a rollback plan.