From the VAST Data edition of November 1, 2026
VAST models VAST on Cloud Event Broker at $238,387 a month versus $1.1 million for Confluent Cloud Enterprise at 4 GB/s, and concedes long retention can cost more
VAST Data · AI data infrastructure vendor (cloud event streaming); applicable to state/local agency telemetry and higher-ed data platforms · Global (AWS and Microsoft Azure deployments described); no SLED customer named
- Publisher
- VAST Data blog (Jason Gaudreau, Senior Product Marketing Manager)
- Original publication
- 2026-10-30 (page metadata 19:20 UTC; modified 2026-10-31 02:04 UTC; on-page byline shows Nov 3, 2026)
- Source retrieved
- 2026-11-02
What happened
VAST's own TCO model prices a Kafka-compatible VAST Event Broker running on VAST on Cloud virtual EBoxes against Confluent Cloud Enterprise list pricing (October 2026) for a 4 GB/s, 2:1 fanout, five-day-retention workload: $238,387 versus $1,106,530 per month ($23.78 versus $110.38 per TB ingested). The gap is attributed to Confluent's per-GB ingress/egress and post-replication storage fees versus erasure coding with 2.7% to 20% parity overhead. VAST concedes long retention on flash EBoxes can cost more than archive-tier cloud offerings and says value is greatest for 1 to 14 days. Full-AZ recovery takes 3 to 15 minutes, with data lazy-loaded from object storage.
Why it matters
Limited and indirect. No government or education customer is named. State and local agencies and universities that stream high-volume telemetry (traffic and transit sensors, public-safety video metadata, security logs, research instruments) could use the model as a template for their own comparisons. Most SLED streaming workloads are far below 4 GB/s, where the modeled gap is smaller and fixed provisioned costs matter more.
Evidence and measured results
Vendor-authored cost model, not a measured deployment. It uses one workload profile and list pricing (low end of the regional range); the Confluent figure is described as a floor because three Enterprise clusters are pooled. No performance, latency or reliability measurements are reported, and no customer bill is shown. A Hanging Context summary published 2026-11-01 00:58 UTC repeats the figures and labels them self-reported.
Limitations and uncertainty
Vendor claim. Single modeled scenario; no independent reproduction; publication date ambiguous (metadata Oct 30, byline Nov 3). Event Broker performance claims have previously been criticized for missing methodology (see StorageMath item). Treat savings as a hypothesis to test, not an expected outcome.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-02; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Usage-based streaming fees grow with throughput, retention and the number of consumers reading the same telemetry stream.
- Stakeholders
- Agency or university data platform owner
- State or campus CIO/CTO finance staff
- Security operations teams consuming log streams
- Procurement and cooperative-contract officers
- Discovery questions
- What sustained ingest rate, retention and consumer fanout do current streams have?
- Is FedRAMP, StateRAMP or a government cloud region required?
- What do you pay today under negotiated, not list, pricing?
- Which analytics tools read the streams after landing?
- Value hypothesis
- For high-throughput, multi-consumer, short-retention streams, provisioned capacity without per-GB read fees may lower cost; this is VAST's modeled hypothesis, unverified for any SLED workload.
- Potential engagement
- A bounded TCO workshop comparing the customer's own streaming bills and workload profile against a VAST on Cloud estimate, with no savings commitment.
- Unsupported claims
- Guaranteed 4-5x savings
- Any SLED or government deployment of VAST Event Broker
- Performance or reliability parity with Kafka
- Government-cloud authorization of VAST on Cloud
Pre-sales engineering
Role takeaway
- Fit
- Relevant only to high-volume, multi-consumer event streams with short retention that also need SQL access to landed events.
- Architecture and integration
- Kafka-protocol producers and consumers connect to VAST Event Broker VIPs on virtual EBoxes; topics land as VAST DataBase tables queried by Trino, Presto or Spark; Cloud-HA persists to block and object storage on AWS or Azure.
- Prerequisites
- Measured workload profile (ingest, fanout, retention, message size)
- Confirmation of supported cloud regions, including any government regions
- Inventory of Kafka features, connectors and schema registry in use
- Constraints
- VAST KB states VAST on Cloud clusters do not support expansion or OS upgrade
- Long retention on flash can exceed archive-tier cloud costs
- No government-cloud authorization evidence found
- Comparator priced at commercial list rates, not government offerings
- Security
- Security controls for the broker endpoint, identity integration and encryption are not described in the blog; agencies must verify them and any required authorization before handling sensitive or CJIS-type data.
- Proof of value
- Run the agency's own throughput and fanout profile and record p99 latency
- Test AZ-loss recovery time against the 3-15 minute claim
- Confirm cluster expansion and upgrade path on the virtual-EBox model
- Rebuild TCO with negotiated pricing for both options
Delivery
Role takeaway
- Work
- Stand up a VAST on Cloud pilot cluster, mirror one production topic, and compare cost, latency and recovery against the incumbent broker.
- Dependencies
- Cloud account and region approvals
- Kafka client and connector compatibility
- Security review and authorization decision
- Analytics engine connectors (Trino/Spark)
- Ownership
- Agency or campus data platform team, with cloud operations owning VAST cluster lifecycle.
- Skills and adoption
- Staff need VAST cluster operations and VAST DataBase skills alongside existing Kafka knowledge; plan training before cutover.
- Governance checkpoints
- Security and authorization review before production data
- Cost review against negotiated baseline after pilot
- Retention policy approval (keep within modeled window)
- Acceptance criteria
- Proposed: pilot monthly cost per TB ingested below incumbent at measured workload
- Proposed: p99 end-to-end latency within agreed SLO
- Proposed: zero message loss and preserved ordering in failover test
- Risks
- Savings disappear at low throughput or long retention
- Expansion/upgrade limits on cloud clusters
- Lock-in to a single storage vendor's broker implementation
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Replaces broker log replication with VAST DataBase tables protected by erasure coding and Cloud-HA (block and object persistence) on AWS and Azure; topics become queryable through Trino, Presto and Spark without ETL. VAST's 5.4 knowledge-base page states VAST on Cloud clusters do not support expansion or OS upgrade, which sits uneasily with the blog's 'add more EBox VMs' scaling claim and needs confirmation for the virtual-EBox model.
Governance
Who approves, reviews and stays accountable for outcomes?
Agencies comparing streaming platforms should build their own TCO with their actual throughput, retention, fanout and contract pricing rather than adopt a vendor's single scenario. The comparison uses commercial list prices, not negotiated public-sector or cooperative-contract pricing.
Security and privacy
What data, permissions and controls need testing?
The blog does not address government-cloud authorization. Confluent's government offering is FedRAMP 20x Moderate on AWS GovCloud only and supports Dedicated clusters, so the commercial Enterprise-tier baseline may not be the comparator a state agency with FedRAMP or StateRAMP-type requirements would actually buy. No VAST on Cloud government-region or authorization evidence surfaced.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Shifts skills from managed-service consumption to operating VAST clusters; smaller agencies may lack staff to run them.
Procurement
What should contracts, pricing and exit terms secure?
Commercial list pricing in the model is not public-sector pricing; buyers should request vendor quotes under existing cooperative or state contracts and compare total cost including staff time.
Operating model
Which teams own the service once it runs?
Moves from a fully managed streaming service to a provisioned, customer-operated platform; fixed capacity must be sized and paid for regardless of actual load.
Publication history
- 2026-11-01VAST Data · Issue 042 resources
Stable resource ID: vast-on-cloud-event-broker-tco-vs-confluent-20261030