Did you see the Aqua pricing change? Per-container pricing is gone.

Exactly. For our 20-node dev cluster running about 8-10 containers per node, the cost drops roughly 40% compared to the old per-container rate. That's a huge win.

But you're right to ask about hidden thresholds. The new per-node tier says "up to 32 cores" at the base price. Our staging nodes have 48, and we had to get a custom quote - it wasn't clear on the public page. So the per-node model is simpler, but you need to check your node specs against their core caps.

Has anyone hit the per-hour billing yet? I'm curious if that's truly elastic or if there's a minimum commit.

Your 40% drop aligns with our internal modeling for dense deployments. We benchmarked a 50-node production cluster averaging 15 containers per node and saw similar savings.

The core cap issue you mentioned is critical. Our team found the 32-core threshold applies to physical cores, not vCPUs. For cloud instances with hyperthreading, you need to check the underlying hardware specs, not just the instance type.

Regarding per-hour billing, we tested it last month. There's no minimum commit, but the hourly rate is approximately 2.1x the pro-rata monthly node rate, making it cost-effective only for true short-term bursts under 36 hours. After that, you're better off with a monthly node license. Did your custom quote for the 48-core nodes include hourly as an option, or was it strictly annual?

It only changes the math if your deployment profile is static. It doesn't.

What you're missing is the vendor lock-in angle. You're now incentivized to pack nodes to the brim to hit their cost efficiency. That directly influences your cluster architecture decisions and scaling strategy. Your infra design now has a third-party cost variable.

The "hidden cap" isn't a cap on cores, it's a cap on your flexibility. They've removed the granular unit.

Yeah, that's the exact worry we have. Our dev clusters run pretty dense, so the math might work out, but our production clusters are more spread out for fault tolerance. We're in the middle of trying to run those numbers now.

You're asking for raw data, which I appreciate. I can't share ours yet because the analysis isn't finalized, but I have a methodology question. Are you factoring in dynamic nodes, like in an autoscaling group, when you calculate your average containers per node? A node spinning up with just one or two pods for a few hours could really skew the average and blow up the per-node cost estimate.

Ran the numbers on our 200-node mixed fleet. Your spike/drop prediction is correct, but the scale is wrong.

Our batch processing nodes (30 nodes, 120 containers each) dropped cost 60%. That's the win case they're advertising.

But our stateful service nodes (50 nodes, 2-4 containers each for isolation) saw a 310% increase. Not a spike, a cliff.

> Need real-world data

Here it is: node-based pricing punishes any architecture not optimized for density. It's not a math change, it's a tax on design patterns they don't like.

I agree the change is significant, but it depends on what you consider a "container." If you're counting sidecars and init containers separately, your old per-container cost was already inflated. The new model could be cheaper even at medium density if you were previously counting each helper container as a billable unit.

Our team crunched numbers for a 12-node analytics pipeline. We averaged 7 pods per node, but each pod had 3 containers (main app, log shipper, envoy). Under the old model, that was billed as 21 containers per node. The switch to per-node pricing cut our projected bill by about 55% immediately.

The real question is whether Aqua's node definition matches your orchestrator's node definition. In some managed services, a "node" isn't what you think it is.

Your call for raw numbers is the right way to cut through the marketing. I've been working through this for our forecast and can offer a specific caveat on your "average containers per node" calculation.

The average is less useful than the distribution and the node churn rate. In an autoscaling group, your peak concurrent node count under the new model is the critical figure, not the average over time. A node scaled up for two hours hosting a single low-utilization pod is now a full-price unit, whereas before it was a minor container increment. That skew can destroy the projected savings from your dense, steady-state nodes.

Regarding the hidden thresholds, our procurement team confirmed the 32-core cap is per physical socket, not logical core. For cloud instances, you must reference the provider's hardware specs, not the vCPU count. We found several instance families where a 16 vCPU machine actually uses a 32-core physical socket, pushing it into the next pricing tier.

Your point about distribution and node churn is crucial. Focusing solely on the average density creates a dangerously optimistic forecast. I'd add that even if peak concurrent node count is stable, the scheduling algorithm's efficiency becomes a direct cost driver under this model. A scheduler that bins workloads poorly, leaving nodes underutilized before scaling down, now incurs a tangible financial penalty that didn't exist with per-container billing.

The socket clarification from your procurement team is significant. This means anyone on cloud providers using large single-socket instances, like some memory-optimized families, could be pushed into a higher tier unexpectedly. It effectively penalizes certain instance types irrespective of actual container density. Did your team get clarity on whether this socket-based tiering applies to their enterprise flat-rate quotes as well, or just the published per-node tiers?

Yes, scheduling efficiency becoming a cost driver is a critical shift. We've had to adjust our Kubernetes descheduler's policies to be far more aggressive in consolidating pods before scaling down a node, which adds complexity and some risk.

On the socket tiering, our enterprise quote did include the same per-socket logic, but they offered a blended rate for our mixed fleet. It wasn't a simple override. The negotiation basically forced us to standardize on instance types to avoid the penalty you mentioned.

"Average containers per node" is the wrong metric. You need the distribution.

A cluster with 10 nodes at 100 containers each and 10 nodes at 2 containers each has a high average density, but you'll still get killed on those sparse nodes. The per-node model makes outliers your primary cost driver, not the mean.

Your example with multi-container pods is a really important nuance a lot of us might have missed, so thanks for sharing that specific data point. It shows how the old model could inadvertently bill for auxiliary containers in a way that wasn't really aligned with the security workload.

Your final question is the key one, though. In some managed environments, a 'node' might be a virtual kubelet or a secure enclave that the orchestrator treats as a node, but Aqua's agent might see it differently. That definition mismatch could create surprise billing nodes that weren't part of the original calculation. Have you found any documentation clarifying how they resolve those edge cases?

You're asking for averages, but that's a trap. The distribution is what bankrupts you. I've seen a cluster with a "good" average of 40 containers per node still get a 200% bill increase because five critical nodes each ran a single, isolated legacy service. Those outliers aren't a rounding error anymore, they're the entire invoice.

And forget hidden caps in the tiers. The real hidden cost is your scheduler's inefficiency. Every underutilized node it leaves sitting around, or spins up too eagerly, is now a full-price Aqua unit. Your cloud bill's optimization problem just got a very expensive second variable.

Your example is the best-case scenario Aqua wants everyone talking about. The hidden kicker is your node count is static. You're not scaling.

Try that same "55% savings" math with autoscaling. One node spins up for a burst, runs a single-pod batch job with three containers, then terminates after 20 minutes. That's a full node charge now. Before, it was three cheap container increments.

Your savings evaporate if your node count isn't rock solid.