AWS Cost Model: Aurora Service Stack vs StateVec Cluster

This note compares a conventional relational-database-centered deployment with a three-node StateVec cluster for a 10k TPS business engine.

It is an EC2 and Aurora instance cost model, not a full production bill. It does not include Aurora storage, Aurora I/O charges, backups, snapshots, cross-AZ traffic, data transfer, load balancers, monitoring, NAT, support plans, reserved instances, savings plans, or managed-service markups.

Assumptions

Region and billing:

• AWS region: us-east-1.
• Pricing model: Linux On-Demand EC2 and Aurora/RDS On-Demand instances.
• Price snapshot: May 2026. Costs and savings are calculated from hourly rates before rounding to cents.
• Month length: 730 hours.
• Target write load: 10k TPS.
• Query load assumption for the database-centered setup: the 2 Aurora readers provide about 20k QPS state query capacity.
• Query load assumption for the StateVec setup: read-side views target comparable state-query capacity for predefined views and lookup paths, using committed transactions from the cluster.
• Local SSD is modeled through instance-store EC2 families. There is no separate per-GB local SSD line item; the storage requirement changes the instance type.

Sizing notes:

• The requested Aurora setup is 32C / 64G, with 1 writer and 2 readers.
• A common Aurora/RDS general-purpose class that preserves the 32 vCPU target is db.m7g.8xlarge, but it has 128 GiB memory rather than 64 GiB.
• The requested StateVec node setup is 2C / 8G with 200 GB instance SSD. The closest local-NVMe EC2 setup used here is c6id.xlarge, which provides 4 vCPU / 8 GiB / 237 GB local NVMe.
• The StateVec instance total covers the three voting nodes of the transaction core. Dedicated learners, projection services and query stores are added separately when required.

Instance mapping:

Price references:

• db.m7g.8xlarge: 32 vCPU / 128 GiB, about $2.696/hr.
• m7i.xlarge: 4 vCPU / 16 GiB, about $0.2016/hr.
• c6id.xlarge: 4 vCPU / 8 GiB / 237 GB local NVMe, about $0.2016/hr.

Option A: Aurora-Centered Service Stack

Target setup:

• Aurora: 1 writer and 2 readers.
• Each Aurora node target: 32C / 64G, modeled as db.m7g.8xlarge.
• Reader capacity target: about 20k QPS state queries from the 2 readers.
• Application layer: 4 microservice nodes.
• Each microservice node: 4C / 16G, modeled as m7i.xlarge.

This setup represents a conventional architecture where the relational database is the main transactional coordination point. The writer handles the mutation path, while readers serve state queries. Application services perform validation, orchestration, cache updates, and event publication around the database.

Node count:

Monthly instance cost:

Annualized:

(3 * $2.696 + 4 * $0.2016) * 730 * 12 = $77,914.94 / year

Option B: StateVec Cluster

The StateVec cluster runs deterministic business plugins over application-defined records. Each command updates related records as one ACID transaction. Raft provides leader election, ordered replication and quorum commitment across the cluster.

All voting nodes run the same business plugin. Full Consistency (Verify mode) adds follower verification of execution results before commit; Extreme Performance (Performance mode) executes business logic after commit. Both modes recover from a selected checkpoint and the committed Raft WAL. See execution modes for the complete flow.

Target setup:

• StateVec cluster: 3 voting nodes, with 1 leader and 2 followers.
• Each StateVec node target: 2C / 8G.
• Each StateVec node local SSD target: 200 GB, modeled as c6id.xlarge.
• Each node keeps its local Raft WAL and recovery checkpoints.
• Read-side services build query views, notifications and integrations from committed transactions, outside the voting quorum.

The per-node target is 2C / 8G; c6id.xlarge is used here because local instance SSD capacity is tied to the EC2 instance type. It provides 237 GB local NVMe, which satisfies the 200 GB local SSD assumption. The query workload consists of predefined state views and lookup paths. Optional non-voting learners can feed read-side extensions; this integration is in development.

Node count:

Monthly instance cost:

Annualized:

3 * $0.2016 * 730 * 12 = $5,298.05 / year

Capacity and Cost Comparison

Difference:

Monthly savings = $6,051.41
Annual savings  = $72,616.90
Cost ratio      = 14.71x

Under these assumptions, the modeled Aurora service stack costs about 14.7x as much as the three-node StateVec cluster. Dedicated read-side infrastructure is added to the StateVec total when required.

Why the Shape Changes

The conventional architecture places the durable mutation path and query-serving responsibility behind a large relational database cluster:

That is a familiar and productive architecture, but at 10k TPS writes plus 20k QPS state queries, the database tier becomes the expensive part of the system. The application layer is not the main cost driver; the database writer/readers are.

The StateVec cluster brings business execution, replicated history and recovery into the same three-node transaction core:

The business plugin defines models and rules; the StateVec cluster supplies transaction execution, consistency and recovery. Read-side extensions consume committed history and may lag behind the core. Any change they propose returns through a business command, so the transaction core remains the authority for business state.

Reading This Correctly

This document does not say a StateVec cluster always costs $441.50/month, or that an Aurora-based system always costs $6,492.91/month.

It says that for the specific 10k TPS setups above:

• The Aurora-centered stack pays for 3 large DB nodes plus application services.
• The Aurora readers are included because they are expected to serve about 20k QPS state queries.
• StateVec read-side views target the same practical query role; dedicated learners, projection services and query stores are sized separately.
• The StateVec instance total pays for the three voting nodes that execute plugins, replicate commands and retain local recovery data.
• The model excludes Aurora storage and I/O charges, which can be material for write-heavy workloads.
• Exact procurement numbers should be checked with the AWS calculator before purchase.

Use this as a starting point for a workload-specific AWS estimate, not as a universal price quote.