Neptune Cluster Calculator
Size an Amazon Neptune cluster from graph size and query rate, then price instances, cluster storage and graph I/O.
Inputs
Multi-hop traversals read many pages, so this is the main cost driver.
db.r5.large is around $0.348/hour in us-east-1.
Estimated Monthly Cost
$2,911.92
Instances in the Cluster
4instances
Graph Storage
35.8GB
Graph Storage
36 GiB
Cluster Storage
$3.60
Graph I/O
$1,892.16
Step by step
Values used
Vertices in the graph = 50,000,000 vertices; Edges in the graph = 200,000,000 edges; Average bytes per vertex = 256 bytes; Average bytes per edge = 128 bytes; Peak query rate = 1,200 queries/s; Query capacity of one instance = 400 queries/s; Storage I/O per query = 3 requests; Instance price = 0.3480 $/hour; Billed hours per month = 730 hours; Storage price = 0.1000 $/GB-month; I/O price = 0.2000 $/million
Neptune Cluster
graph bytes = vertices × bytes per vertex + edges × bytes per edge; instances = 1 writer + ceil(QPS ÷ per-instance QPS), capped at 16; I/O millions = QPS × I/O per query × 2,628,000 ÷ 1,000,000.
Estimated Monthly Cost
= 2,911.92
Instances in the Cluster
= 4 instances
Graph Storage
= 35.8 GB
Graph Storage
= 38,400,000,000
Cluster Storage
= 3.60
Graph I/O
= 1,892.16
How it works
Neptune storage is estimated from element counts because a graph's footprint is dominated by adjacency lists and property values rather than by rows, and it is billed in the same shared-volume model as Aurora with a 10 GB minimum. Reads scale out across up to 15 replicas, but a graph traversal touches many pages per query, so the per-million I/O charge often outgrows instance-hours on deep multi-hop workloads. Every rate here is an editable input with a realistic us-east-1 default, so confirm current Neptune prices with AWS for your region. Traversal depth, not data volume, is what makes a graph workload expensive — modelling I/O per query is how you discover that a three-hop query pattern costs more in I/O than the whole reader fleet costs in compute.
Formula
Neptune Cluster
graph bytes = vertices × bytes per vertex + edges × bytes per edge; instances = 1 writer + ceil(QPS ÷ per-instance QPS), capped at 16; I/O millions = QPS × I/O per query × 2,628,000 ÷ 1,000,000.
- 16
- One writer plus the 15-replica maximum for a Neptune cluster
- graph bytes
- Adjacency and property storage estimated from element counts
- writer
- Single primary instance — Neptune accepts writes on one node only
- I/O per query
- Pages the storage layer touches for one traversal
Frequently Asked Questions
How is Neptune Cluster calculated?
graph bytes = vertices × bytes per vertex + edges × bytes per edge; instances = 1 writer + ceil(QPS ÷ per-instance QPS), capped at 16; I/O millions = QPS × I/O per query × 2,628,000 ÷ 1,000,000. Neptune storage is estimated from element counts because a graph's footprint is dominated by adjacency lists and property values rather than by rows, and it is billed in the same shared-volume model as Aurora with a 10 GB minimum. Reads scale out across up to 15 replicas, but a graph traversal touches many pages per query, so the per-million I/O charge often outgrows instance-hours on deep multi-hop workloads. Every rate here is an editable input with a realistic us-east-1 default, so confirm current Neptune prices with AWS for your region.
Why does Neptune Cluster matter?
Traversal depth, not data volume, is what makes a graph workload expensive — modelling I/O per query is how you discover that a three-hop query pattern costs more in I/O than the whole reader fleet costs in compute.
What values do I need to enter?
This calculator takes 11 inputs: Vertices in the graph, Edges in the graph, Average bytes per vertex, Average bytes per edge, Peak query rate, Query capacity of one instance, Storage I/O per query, Instance price, Billed hours per month, Storage price, I/O price. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why cap instances at 16?
A Neptune cluster supports one writer and up to 15 read replicas. Beyond that you need to partition the graph across clusters or move to a Neptune Analytics graph for heavy analytical traversals.