Skip to content
Calcrivo

Sandbox Resource Calculator

Size a malware analysis sandbox farm: concurrent VMs, CPU, RAM, storage and daily sample throughput per node.

Inputs

samples/day
minutes
minutes
vCPU
GB
MB
days
×
%

Concurrent VMs Required

26VMs

Runs per VM per Day

155.1runs/day

Physical Cores Needed

18cores

RAM Needed

120GB

Artefact Storage

41.20TB

Hosts at 64 Cores and 512 GB

1hosts

Capacity Note

Balanced — keep 20% spare concurrency for incident-driven submission spikes

Step by step

  1. Values used

    Samples to detonate per day = 4,000 samples/day; Detonation runtime per sample = 5 minutes; Snapshot revert and setup per run = 1.50 minutes; vCPU per analysis VM = 2 vCPU; RAM per analysis VM = 4 GB; Artefacts retained per sample = 120 MB; Artefact retention = 90 days; vCPU overcommit ratio = 3 ×; Target farm utilisation = 70 %

  2. Sandbox Resource

    concurrentVMs = samplesPerDay ÷ (1440 ÷ (runtime + resetTime) × utilisation); physicalCores = concurrentVMs × vCPU ÷ overcommitRatio.

  3. Artefact storage

    artefactStorage = samplesPerDay × artefactSize × retentionDays, covering PCAP, memory strings, dropped files and screenshots.

  4. Concurrent VMs Required

    = 26 VMs

  5. Runs per VM per Day

    = 155.1 runs/day

  6. Physical Cores Needed

    = 18 cores

  7. RAM Needed

    = 120 GB

  8. Artefact Storage

    = 41.20 TB

  9. Hosts at 64 Cores and 512 GB

    = 1 hosts

How it works

Each VM completes 1440 minutes of day divided by its cycle time, where the cycle is the detonation window plus the snapshot revert — reverting is not free and on a five-minute runtime it is a fifth of the cost. Divide the daily sample volume by realistic per-VM throughput to get concurrency, then convert to hardware using your vCPU overcommit ratio. Memory does not overcommit safely for malware analysis, so RAM usually sets the host count. Sandbox farms are sized on peak submission, not average: an incident that dumps ten thousand samples into the queue is exactly when analysts cannot wait six hours for a verdict.

Formulas

Sandbox Resource

concurrentVMs = samplesPerDay ÷ (1440 ÷ (runtime + resetTime) × utilisation); physicalCores = concurrentVMs × vCPU ÷ overcommitRatio.

runtime
Detonation window per sample
resetTime
Snapshot revert, boot and instrumentation setup
utilisation
Realistic duty cycle allowing for queue gaps and failures
overcommitRatio
vCPU packed per physical core

Artefact storage

artefactStorage = samplesPerDay × artefactSize × retentionDays, covering PCAP, memory strings, dropped files and screenshots.

artefactSize
Retained output per detonation
retentionDays
How long analysis output is kept for correlation

Frequently Asked Questions

How is Sandbox Resource calculated?

concurrentVMs = samplesPerDay ÷ (1440 ÷ (runtime + resetTime) × utilisation); physicalCores = concurrentVMs × vCPU ÷ overcommitRatio. Each VM completes 1440 minutes of day divided by its cycle time, where the cycle is the detonation window plus the snapshot revert — reverting is not free and on a five-minute runtime it is a fifth of the cost. Divide the daily sample volume by realistic per-VM throughput to get concurrency, then convert to hardware using your vCPU overcommit ratio. Memory does not overcommit safely for malware analysis, so RAM usually sets the host count.

Why does Sandbox Resource matter?

Sandbox farms are sized on peak submission, not average: an incident that dumps ten thousand samples into the queue is exactly when analysts cannot wait six hours for a verdict.

What values do I need to enter?

This calculator takes 9 inputs: Samples to detonate per day, Detonation runtime per sample, Snapshot revert and setup per run, vCPU per analysis VM, RAM per analysis VM, Artefacts retained per sample, Artefact retention, vCPU overcommit ratio, Target farm utilisation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why not overcommit memory as well as CPU?

Because ballooning and swapping change timing, and timing changes malware behaviour — some samples explicitly check for it. Overcommitted memory also risks a detonation being paged out mid-run, which produces a useless report.

Is a longer runtime always better?

No. Most commodity malware reveals its behaviour in the first two to three minutes, and doubling the runtime halves farm throughput. Reserve long runs for samples that show sleep or trigger-based evasion in the short run.

You might also need