AWS Cost Model: Aurora Service Stack vs StateVec

This note compares a conventional relational-database-centered deployment with a StateVec deployment 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.
• 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: readonly/projection nodes are expected to provide comparable state-query capacity for predefined views and lookup paths, without relying on Aurora readers.
• 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 readonly/projection path is treated as part of the StateVec deployment in this rough model. If separated into dedicated readonly nodes, add those nodes explicitly.

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.
• m7g.large: 2 vCPU / 8 GiB, about $0.0816/hr.
• t4g.micro: 2 vCPU / 1 GiB, about $0.0084/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:

+----------------------+----------+--------------------+----------------+
| Component            | Count    | Modeled size       | Instance       |
+----------------------+----------+--------------------+----------------+
| Aurora DB nodes      | 3        | 32C / 128G         | db.m7g.8xlarge |
| Microservice nodes   | 4        | 4C / 16G           | m7i.xlarge     |
+----------------------+----------+--------------------+----------------+

Monthly instance cost:

Annualized:

$6,492.91 * 12 = $77,914.94 / year

Option B: StateVec HA Queue Shape

Target setup:

• StateVec: 3 nodes.
• Each StateVec node target: 2C / 8G.
• Each StateVec node local SSD target: 200 GB, modeled as c6id.xlarge.
• State query path: readonly/projection views over local StateVec-managed state, intended to cover the same state-query role as the Aurora readers in this model.
• Kafka cluster: 3 brokers.
• Each Kafka broker: 2C / 8G, modeled as m7g.large.
• etcd: 3 nodes.
• Each etcd node target: 1C / 1G, modeled as t4g.micro.

The StateVec runtime target is still 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. State queries are served from readonly/projection views rather than from Aurora readers. This assumes the query workload is made of predefined state views and lookup paths, not arbitrary SQL.

Node count:

+----------------------+----------+-------------------------+--------------+
| Component            | Count    | Modeled size            | Instance     |
+----------------------+----------+-------------------------+--------------+
| StateVec nodes       | 3        | 2C / 8G + 200 GB SSD    | c6id.xlarge  |
| Kafka brokers        | 3        | 2C / 8G                 | m7g.large    |
| etcd nodes           | 3        | 1C / 1G                 | t4g.micro    |
+----------------------+----------+-------------------------+--------------+

Monthly instance cost:

Annualized:

$638.60 * 12 = $7,663.25 / year

Capacity and Cost Comparison

Difference:

Monthly delta = $6,492.91 - $638.60 = $5,854.31
Annual delta  = $77,914.94 - $7,663.25 = $70,251.69
Cost ratio    = $6,492.91 / $638.60 = 10.17x

Under these assumptions, the StateVec setup has about 10.2x lower instance spend than the Aurora-centered service stack.

Why the Shape Changes

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

application services
        |
        v
Aurora writer + 2 Aurora readers
        |
        v
state query / projection / event paths

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 architecture moves the critical mutation path into a smaller deterministic runtime group:

commands
   |
   v
StateVec runtime group
   |
   +--> TxLog / durable history
   +--> readonly projection / state query
   +--> Kafka event delivery
   +--> etcd coordination

Kafka and etcd still exist, but the ordered business execution path is no longer centered on a large Aurora writer plus readers. State queries are served by readonly/projection views designed for the StateVec data path, with the goal of covering the same practical query role in this workload.

Reading This Correctly

This document does not say StateVec always costs $638.60/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.
• The StateVec stack includes readonly/projection query serving in the deployment model, intended to cover comparable state-query capacity for this workload.
• The StateVec stack pays for a smaller replicated execution group plus Kafka and etcd.
• 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.