Having recently completed a security posture management tool evaluation for a client migrating a modest AWS and Kubernetes footprint (approximately 150 EC2 instances and 12 EKS clusters), I can offer a detailed comparative analysis between Orca Security and Wiz, specifically through the lens of cost for smaller engineering teams.
The prevailing notion that Orca is inherently cheaper is an oversimplification. The pricing models differ fundamentally, making direct comparison highly dependent on your asset profile and scanning requirements.
**Orca's Pricing Model:**
Orca operates on a per-asset, per-month model. An "asset" is broadly defined—a cloud account, a container image, a VM, an S3 bucket with public exposure, etc. For a small, well-defined environment, this can be predictable. However, in dynamic environments, this can lead to unexpected cost creep. Their recent shift towards more bundled "workload" pricing aims to address this but adds complexity to forecasting.
**Wiz's Pricing Model:**
Wiz is priced per-hour of runtime (e.g., EC2, ECS, EKS nodes) scanned. This aligns more directly with your cloud compute bill. If you have a high proportion of managed services (RDS, Lambda, S3) or paused assets, they do not contribute to the core runtime cost in the same way. This can be advantageous for teams leveraging significant serverless or PaaS components.
**Critical Considerations for Small Teams:**
* **Entry Threshold:** Both vendors have minimum annual commitments. For very small teams (e.g., under 50 assets or $10k cloud spend), you may find both solutions economically challenging, and might be better served by CSP-native tools (AWS Security Hub, Azure Defender) augmented with open-source.
* **Scope of Scanning:** Orca's side-scanning (agentless) architecture has a broader out-of-the-box scope, including VM vulnerability assessment without installation. Wiz requires a lightweight agent for deep OS-level visibility on VMs. The operational overhead of the agent is minimal, but it's a deployment consideration.
* **Cost Drivers:**
* Your bill will be lower with **Orca** if you have a large number of low-cost, static assets (e.g., many small S3 buckets, container registries with many static images).
* Your bill will be lower with **Wiz** if you have a smaller number of frequently changing, high-cost compute instances (e.g., auto-scaled `m5.4xlarge` instances, transient Kubernetes pods).
**A Simplified Cost Illustration:**
Assume an environment with 50 running EC2 instances (avg. $0.20/hr) and 500 S3 buckets.
* **Wiz Cost Driver:** `50 instances * 730 hrs/month * $0.20/hr = $7,300` of runtime. Pricing is a percentage of this.
* **Orca Cost Driver:** `50 instances + 500 buckets = 550+ assets`. Pricing is per asset.
The S3 buckets, which cost almost nothing in runtime, are a significant cost factor for Orca but negligible for Wiz in this model.
Ultimately, the "cheaper" tool is the one whose pricing model best aligns with your asset inventory's growth pattern. I strongly advise you to:
1. Conduct a precise asset inventory (cloud accounts, VMs, containers, buckets, serverless functions).
2. Obtain formal quotes from both vendors based on that inventory.
3. Model the cost under 20% and 50% growth scenarios for both assets and runtime.
For our specific client, Wiz proved 18% more cost-effective annually due to their heavy use of auto-scaled, ephemeral compute and extensive serverless architecture. A different team with a legacy VM-heavy footprint found Orca's flat per-asset fee easier to budget for.
Good breakdown on the pricing models. Your point about Orca's "asset" definition is key. For teams with heavy container use, a single host running dozens of pods can explode the asset count quickly, making the per-hour model from Wiz look much simpler.
Wiz's model mirrors the cloud bill, but watch out for non-compute resources. If you're heavy on S3, RDS, or serverless, you need to clarify if those are included or an extra charge. That's where per-asset can sometimes feel more complete, even if it's less predictable.
Your analysis of the dynamic environment cost creep with Orca's per-asset model is spot on. The container example is perfect, but I'd add that serverless functions are the real wildcard. With Lambda, a single function with multiple deployed versions or aliases can be counted as separate assets. If your team does frequent deployments, you're essentially paying for temporary, historical artifacts.
You're right that Wiz's cloud-bill alignment simplifies forecasting for compute, but that complexity just shifts. The negotiation isn't about asset definition anymore, it's about which resource types are included in that "per-hour" scan. I've seen teams get surprised when they're told their extensive CloudFront distributions or active Message Queues require a separate add-on. The predictability of Wiz's model assumes your cloud provider's billing is your primary source of truth for what constitutes a 'workload'.
Measure twice, cut once.
Exactly. That hidden complexity in Wiz's model is why you need the final contract, not just the sales deck. The "per-hour" metric ties directly to their scanning engine's capacity consumption, not your actual cloud bill line items.
You can get burned on ephemeral workloads too. A CI/CD agent that spins up for two hours a day costs the same as a production instance, but provides minimal security value. The predictability is a mirage if you don't map their "workload" definition to your specific resource lifecycle.
Ask them for the exact list of resource types covered under the core hourly rate. Anything else is an add-on, and that's where the real cost lands.
The cloud bill comparison is a clever sales angle, but it's a surface-level mirror. My cloud bill is about resource consumption, not security risk. Wiz's model charges me for scanning a development container spun up for five minutes as if it were a critical production database. That's not alignment, that's a tax on my CI/CD pipeline.
Orca's asset sprawl is a real pain, but at least the cost is tied to the number of things I need to secure. If a pod is alive long enough to be an asset, it was alive long enough to potentially be a problem. The unpredictability is a budgeting headache, not a logic flaw.
You're right to flag the non-compute gotchas with Wiz. In my last procurement, "serverless" meant Lambda. API Gateway stages, DynamoDB tables, and Step Functions were all separate line items. So much for simple forecasting.
You're right that the simplicity of Wiz's per-hour model is appealing, especially for teams with high container churn. But that simplicity hinges completely on how they define a "workload hour" for non-VM resources. For those container pods, is it based on the underlying node's uptime, or does each pod's lifetime get counted? That's a key question that can turn a simple model into a complex one very quickly.
That's a useful distinction between the models, thanks. When you say Orca's newer "workload" pricing aims to address cost creep, how does that actually compare to the classic per-asset model for a setup like your client's? Is it a true simplification, or does it just shift the complexity to defining a "workload" instead of an "asset"?
For a smaller team with those 150 EC2 instances and 12 EKS clusters, which model ended up providing more predictable billing in practice?
Great question. I'm actually in a similar boat, trying to figure this out for my team's smaller AWS setup.
From what I've gathered talking to their sales folks, the workload model is basically their attempt to compete directly with Wiz's simplicity. But you're right, it feels like they just swapped one confusing term for another. An "asset" was vague, now a "workload" is vague.
For your specific example, which one gave more predictable numbers in the end? I'd worry that with 12 EKS clusters, the definition of a "workload" could still balloon if they count each pod separately.
Yep, the "per-hour" scan definition is everything. I had the same surprise with their API Gateway coverage, it was treated as a separate "advanced resource" module. So much for simple cloud bill alignment.
The predictability really does hinge on your exact resource mix, not just your compute hours. It forces you to audit your cloud footprint before you even start the security audit, which is a bit ironic.
—b
You're absolutely right about Lambda versions and aliases. That's a major gotcha that sales demos always gloss over. We hit the same thing with container image tags in a private registry. Every nightly build pushed a new tag, and Orca counted each unique image as a separate asset, even if they were identical layers and only one was actually running. Our bill was tracking our CI/CD activity, not our production risk surface.
The shift from negotiating asset definitions to negotiating included resource types is exactly the pivot. It turns a technical question into a procurement one, which can be even messier.
pipeline all the things
That's the core of it, isn't it? Swapping terms doesn't fix the problem. I've seen the same issue with how they define a "serverless workload". Is it per function, per active alias? Without that, the new model is just as unpredictable.
For your smaller setup, did they give you concrete examples of what counts as one EKS workload? I'm curious if they've really simplified it or just repackaged the complexity.