.png)
Key takeaways
1
Amazon Neptune Serverless charges compute based on Neptune Capacity Units (NCUs) instead of fixed database instances.
2
Compute is billed per NCU-second; storage, backup, and data transfer are always separate; I/O is too, unless you're on I/O-Optimized, which folds it in.
3
Serverless is best suited for variable or unpredictable graph workloads, whereas consistently busy production workloads may be more economical on Provisioned Neptune.
4
Optimizing graph queries, monitoring NCU consumption, and configuring appropriate scaling limits can significantly reduce monthly costs.
Amazon Neptune Serverless eliminates manual capacity planning by automatically scaling database compute based on demand. Instead of paying for fixed database instances, you pay for the Neptune Capacity Units (NCUs) your workload consumes.
That flexibility can lower costs for unpredictable workloads, but it isn’t always the most economical choice.
This guide explains how Neptune Serverless pricing works, what NCUs cost, how to estimate monthly bills, and when Serverless is cheaper than Provisioned.
That flexibility can lower costs for unpredictable workloads, but it isn’t always the most economical choice.
This guide explains how Neptune Serverless pricing works, what NCUs cost, how to estimate monthly bills, and when Serverless is cheaper than Provisioned.
The short answer
Amazon Neptune Serverless replaces fixed database instances with an automatically scaling compute model. Instead of choosing an instance size, you configure a minimum and maximum compute range.
Neptune continuously adjusts compute capacity based on the database’s observed resource requirements, including memory usage, CPU utilization, connection activity, and workload characteristics within your configured NCU scaling range.
Compute charges are based on Neptune Capacity Units (NCUs), billed per second, while storage, backup storage, I/O requests, and data transfer are billed separately. You can review the latest regional pricing on the Amazon Neptune pricing page.
This pricing model works well for workloads that experience changing or unpredictable traffic because you only pay for the compute capacity your database actually uses over time.
However, automatic scaling doesn’t always translate to lower costs. Applications that run at consistently high utilization may spend less with a provisioned Neptune deployment.
Understanding your workload patterns and where your application falls on the cost curve is essential before deciding which deployment model is right for you.
What Is Amazon Neptune Serverless?
Amazon Neptune Serverless is the serverless deployment option for Amazon Neptune, AWS’s fully managed graph database service.
Instead of provisioning fixed database instances, you configure a minimum and maximum compute capacity, and Neptune automatically scales resources within that range based on workload demand. This reduces the operational overhead of capacity planning while allowing compute to adjust as application requirements change.
AWS explains this architecture in its Amazon Neptune Serverless documentation.
Neptune Serverless and Provisioned use the same Neptune database engine and support the same graph models, query languages, security features, backups, read replicas, and monitoring capabilities. The primary difference is how compute capacity is allocated, scaled, and billed.
Neptune Serverless also has deployment-specific constraints, including supported Regions, minimum engine version requirements, a maximum capacity of 128 NCUs per Serverless instance, and some feature limitations, such as the lack of Neptune Lookup Cache support.
The right deployment model depends on your workload’s performance, availability, operational, and cost requirements, as well as whether Neptune Serverless meets your application’s technical constraints.
Also read 2026 Guide to AWS Neptune in detail.
Instead of provisioning fixed database instances, you configure a minimum and maximum compute capacity, and Neptune automatically scales resources within that range based on workload demand. This reduces the operational overhead of capacity planning while allowing compute to adjust as application requirements change.
AWS explains this architecture in its Amazon Neptune Serverless documentation.
Neptune Serverless and Provisioned use the same Neptune database engine and support the same graph models, query languages, security features, backups, read replicas, and monitoring capabilities. The primary difference is how compute capacity is allocated, scaled, and billed.
Neptune Serverless also has deployment-specific constraints, including supported Regions, minimum engine version requirements, a maximum capacity of 128 NCUs per Serverless instance, and some feature limitations, such as the lack of Neptune Lookup Cache support.
The right deployment model depends on your workload’s performance, availability, operational, and cost requirements, as well as whether Neptune Serverless meets your application’s technical constraints.
Also read 2026 Guide to AWS Neptune in detail.
What Is a Neptune Capacity Unit (NCU)?
Neptune Serverless doesn’t bill you for fixed database instances. Instead, compute is measured using Neptune Capacity Units (NCUs).
A Neptune Capacity Unit (NCU) is the fundamental compute unit used by Amazon Neptune Serverless. According to AWS, each NCU provides approximately 2 GiB of memory, while CPU and networking resources scale proportionally with the allocated capacity.
AWS does not publish a fixed mapping between NCUs and specific vCPU or network bandwidth, as the underlying resources are managed automatically.
As application demand changes, Neptune automatically adjusts the number of NCUs allocated to your database within the configured scaling range.
Compute charges are based on the number of NCUs allocated over time, billed per NCU-second.
A Neptune Capacity Unit (NCU) is the fundamental compute unit used by Amazon Neptune Serverless. According to AWS, each NCU provides approximately 2 GiB of memory, while CPU and networking resources scale proportionally with the allocated capacity.
AWS does not publish a fixed mapping between NCUs and specific vCPU or network bandwidth, as the underlying resources are managed automatically.
As application demand changes, Neptune automatically adjusts the number of NCUs allocated to your database within the configured scaling range.
Compute charges are based on the number of NCUs allocated over time, billed per NCU-second.
Example: Estimating Neptune Serverless Costs
Suppose your production deployment includes:
In addition to compute, your monthly Neptune bill may include storage, backup storage, data transfer, and read/write I/O charges when using Neptune Standard storage.
Because AWS pricing varies by Region and may change over time, always verify the latest rates on the Amazon Neptune Pricing page before estimating production costs.
- One writer averaging 8 NCUs
- One reader averaging 4 NCUs
- Running continuously for 30 days
- Writer: 8 NCUs × 30 days × 24 hours × 3,600 seconds
- Reader: 4 NCUs × 30 days × 24 hours × 3,600 seconds
In addition to compute, your monthly Neptune bill may include storage, backup storage, data transfer, and read/write I/O charges when using Neptune Standard storage.
Because AWS pricing varies by Region and may change over time, always verify the latest rates on the Amazon Neptune Pricing page before estimating production costs.
How Neptune Serverless Actually Scales
One of the biggest misconceptions about Neptune Serverless is that it instantly scales from zero to whatever capacity your workload requires. That isn’t how the service works.
When you create a Neptune Serverless cluster, you configure a supported minimum and maximum NCU range.
The minimum represents the baseline compute that remains available, while the maximum defines the upper limit the service can allocate during periods of increased demand.
For example, imagine you configure:
This flexibility is what makes Serverless attractive for applications with unpredictable traffic patterns, such as recommendation engines, customer-facing applications, or seasonal workloads.
However, your minimum NCU setting has a direct impact on cost. If your workload rarely falls below 8 NCUs but you’ve configured a minimum of 16 NCUs, you’re paying for capacity your application may not need during quieter periods.
Before lowering it, weigh that savings against scale-up latency during traffic spikes and buffer-cache eviction during quiet periods, both of which can cause extra I/O and slower queries when demand returns. Validate against your burst-response and latency requirements first.
Configuring a higher maximum NCU limit doesn’t incur additional charges by itself, but it allows the database to scale to higher, potentially more expensive compute levels when demand increases.
Production deployments often include one or more read replicas for high availability or read scaling. Each writer and reader instance in Neptune Serverless is billed independently based on its allocated NCUs, and readers in promotion tiers 0 and 1 may scale alongside the writer to remain failover-ready.
When estimating monthly costs or comparing Serverless with Provisioned, include the capacity used by all writer and reader instances, not only the primary writer.
When you create a Neptune Serverless cluster, you configure a supported minimum and maximum NCU range.
The minimum represents the baseline compute that remains available, while the maximum defines the upper limit the service can allocate during periods of increased demand.
For example, imagine you configure:
- Minimum: 2 NCUs
- Maximum: 32 NCUs
This flexibility is what makes Serverless attractive for applications with unpredictable traffic patterns, such as recommendation engines, customer-facing applications, or seasonal workloads.
However, your minimum NCU setting has a direct impact on cost. If your workload rarely falls below 8 NCUs but you’ve configured a minimum of 16 NCUs, you’re paying for capacity your application may not need during quieter periods.
Before lowering it, weigh that savings against scale-up latency during traffic spikes and buffer-cache eviction during quiet periods, both of which can cause extra I/O and slower queries when demand returns. Validate against your burst-response and latency requirements first.
Configuring a higher maximum NCU limit doesn’t incur additional charges by itself, but it allows the database to scale to higher, potentially more expensive compute levels when demand increases.
Production deployments often include one or more read replicas for high availability or read scaling. Each writer and reader instance in Neptune Serverless is billed independently based on its allocated NCUs, and readers in promotion tiers 0 and 1 may scale alongside the writer to remain failover-ready.
When estimating monthly costs or comparing Serverless with Provisioned, include the capacity used by all writer and reader instances, not only the primary writer.
Amazon Neptune Serverless vs. Provisioned: Which Costs Less?
Choosing between Amazon Neptune Serverless and a provisioned Neptune cluster isn’t simply about comparing hourly prices. The right deployment model depends on how your application consumes compute over time.
Both deployment options run the same Amazon Neptune database engine and support the same graph models, APIs, security features, backups, and Multi-AZ capabilities.
The difference lies in how compute resources are allocated, scaled, and billed.
If your application experiences frequent traffic fluctuations, Serverless can reduce the amount of idle capacity you’re paying for.
On the other hand, if your workload remains consistently busy throughout the day, the predictability of a provisioned cluster may result in lower long-term compute costs.
Both deployment options run the same Amazon Neptune database engine and support the same graph models, APIs, security features, backups, and Multi-AZ capabilities.
The difference lies in how compute resources are allocated, scaled, and billed.
If your application experiences frequent traffic fluctuations, Serverless can reduce the amount of idle capacity you’re paying for.
On the other hand, if your workload remains consistently busy throughout the day, the predictability of a provisioned cluster may result in lower long-term compute costs.
Neptune Serverless vs. Provisioned at a Glance
| Feature | Neptune Serverless | Neptune Provisioned |
|---|---|---|
| Compute pricing | Pay only for NCUs consumed | Pay for fixed database instances |
| Scaling | Automatic | Instance sizing is customer-managed |
| Capacity planning | AWS manages scaling | You choose and manage instance sizes |
| Idle capacity costs | Lower, because compute scales down | Fixed instance continues running |
| Cost predictability | Variable | Highly predictable |
| Best suited for | Variable and unpredictable workloads | Stable, continuously busy workloads |
Storage, backup storage, I/O requests, and data transfer are billed separately under both deployment models.
Learn more: AWS Neptune Pricing: The Complete Cost Guide for 2026
When Neptune Serverless Makes More Sense
Serverless is designed for workloads where demand changes throughout the day.
Common examples include:
Traffic spikes during promotional campaigns and weekends, but drops significantly overnight. A provisioned cluster must remain sized for those peak periods even when demand is low.
Neptune Serverless automatically scales within your configured NCU range, allowing compute consumption to better match actual workload demand.
For organizations with long idle periods or highly variable traffic, this flexibility often results in better infrastructure utilization and lower operational overhead.
Common examples include:
- Customer-facing recommendation engines
- E-commerce applications with seasonal traffic
- Fraud detection platforms
- Development and testing environments
- New applications with unpredictable growth
- Internal tools used primarily during business hours
Traffic spikes during promotional campaigns and weekends, but drops significantly overnight. A provisioned cluster must remain sized for those peak periods even when demand is low.
Neptune Serverless automatically scales within your configured NCU range, allowing compute consumption to better match actual workload demand.
For organizations with long idle periods or highly variable traffic, this flexibility often results in better infrastructure utilization and lower operational overhead.
When Provisioned Neptune May Cost Less
Provisioned Neptune becomes increasingly attractive as workloads become more predictable.
Examples include:
Instead of paying for changing NCU consumption throughout the month, a fixed instance may provide a lower and more predictable compute cost.
Provisioned deployments can also make budgeting easier because infrastructure costs remain relatively stable from month to month.
Examples include:
- Enterprise knowledge graphs accessed around the clock
- Internal analytics platforms with continuous query activity
- Manufacturing or logistics systems that process data 24×7
- Production environments with consistently high utilization
Instead of paying for changing NCU consumption throughout the month, a fixed instance may provide a lower and more predictable compute cost.
Provisioned deployments can also make budgeting easier because infrastructure costs remain relatively stable from month to month.
The Biggest Pricing Mistake
Many teams compare deployment models using peak utilization.
That’s the wrong metric.
Suppose two applications both reach 20 NCUs every afternoon.
Application A:
The lesson is simple: The primary compute cost driver for Neptune Serverless is the time-weighted allocated capacity of each Serverless instance, measured in NCU-seconds.
However, your total monthly Neptune cost also depends on storage configuration, reader replicas, I/O charges (for Neptune Standard), backup storage, data transfer, ancillary AWS services, and regional pricing.
When comparing Serverless with Provisioned, evaluate the complete monthly cost and your workload’s performance requirements rather than relying on utilization metrics alone.
That’s the wrong metric.
Suppose two applications both reach 20 NCUs every afternoon.
Application A:
- Peaks for two hours
- Runs at 2–4 NCUs for the rest of the day
- Runs between 16–20 NCUs all day
The lesson is simple: The primary compute cost driver for Neptune Serverless is the time-weighted allocated capacity of each Serverless instance, measured in NCU-seconds.
However, your total monthly Neptune cost also depends on storage configuration, reader replicas, I/O charges (for Neptune Standard), backup storage, data transfer, ancillary AWS services, and regional pricing.
When comparing Serverless with Provisioned, evaluate the complete monthly cost and your workload’s performance requirements rather than relying on utilization metrics alone.
A Practical Break-Even Methodology
There isn’t a universal NCU threshold where Serverless suddenly becomes more expensive than Provisioned.
The break-even point depends on several variables, including:
- Average NCU consumption
- Number of hours your workload runs each month
- AWS Region
- The provisioned instance type you’re comparing against
- Whether your workload spends long periods at minimum capacity or near maximum capacity
Instead of looking for a fixed number, compare the monthly compute cost of both deployment models using the same workload.
Step 1: Estimate Serverless Compute
Rather than relying solely on average utilization, estimate how many NCUs your workload consumes throughout the month.
For production deployments, estimate compute cost across every Serverless instance:
For production deployments, estimate compute cost across every Serverless instance:
Total Serverless Compute Cost = Σ (Allocated NCUs for each writer or reader ×
Time at that capacity × Regional NCU-second price)
Then add:
- Storage
- Backup storage
- I/O charges (Neptune Standard only)
- Data transfer
- Any monitoring or ancillary AWS services
This approach produces a more accurate estimate because each writer and reader instance is billed independently.
Because Neptune bills per NCU-second, workloads that spend long periods at lower NCUs can cost substantially less than workloads that remain near peak capacity, even if their average utilization appears similar.
Use the latest pricing published on the Amazon Neptune pricing page, rather than hardcoding values into your calculations.
Step 2: Estimate Provisioned Compute
Calculate the monthly cost of the provisioned instance that would comfortably support the same workload.
Include:
Include:
- Primary writer instance
- Read replicas (if applicable)
- Multi-AZ architecture
- Any additional compute required for expected growth
Step 3: Compare Total Monthly Compute Costs
Once you have both estimates, compare them alongside your operational requirements.
If your application spends most of the month at low utilization, Serverless often provides better value because you’re paying only for the compute you consume.
If your workload remains consistently busy and rarely scales down, Provisioned may become the lower-cost option over time.
The goal isn’t to prove that one deployment model is universally cheaper. It’s to determine which one aligns with your application’s actual usage patterns.
If your application spends most of the month at low utilization, Serverless often provides better value because you’re paying only for the compute you consume.
If your workload remains consistently busy and rarely scales down, Provisioned may become the lower-cost option over time.
The goal isn’t to prove that one deployment model is universally cheaper. It’s to determine which one aligns with your application’s actual usage patterns.
Where FinOps Teams Gain an Advantage
Manual break-even calculations work well when evaluating a single Neptune cluster. The challenge begins when you’re managing dozens of Neptune clusters alongside Amazon RDS, Amazon EC2, Amazon ElastiCache, and other AWS services, where changing workloads make commitment decisions increasingly difficult.
Usage.ai automates AWS commitment management by continuously analyzing compute usage and optimizing Savings Plans and Reserved Instance commitments as usage evolves.
With its Flex Insured Commitments program, teams can secure the ~57% savings of a 3-year AWS commitment without taking on the long-term commitment risk.
If a commitment costs more than the equivalent on-demand usage, Usage.ai provides cashback protection to cover the difference, helping teams maintain commitment savings while retaining the flexibility to adapt as workloads change.
Usage.ai automates AWS commitment management by continuously analyzing compute usage and optimizing Savings Plans and Reserved Instance commitments as usage evolves.
With its Flex Insured Commitments program, teams can secure the ~57% savings of a 3-year AWS commitment without taking on the long-term commitment risk.
If a commitment costs more than the equivalent on-demand usage, Usage.ai provides cashback protection to cover the difference, helping teams maintain commitment savings while retaining the flexibility to adapt as workloads change.
Best Practices to Optimize Amazon Neptune Serverless Costs
The goal is ensure your database is consuming compute only when it delivers business value. Here are some best practices to follow:
1. Optimize Graph Queries Before Scaling Compute
One of the fastest ways to reduce Neptune costs is by improving query efficiency.
Deep graph traversals, poorly filtered searches, and queries that return unnecessary data consume more compute than well-optimized alternatives. Over time, these inefficient queries increase NCU consumption and drive up monthly costs.
Review your most frequently executed Gremlin, openCypher, or SPARQL queries and look for opportunities to:
Deep graph traversals, poorly filtered searches, and queries that return unnecessary data consume more compute than well-optimized alternatives. Over time, these inefficient queries increase NCU consumption and drive up monthly costs.
Review your most frequently executed Gremlin, openCypher, or SPARQL queries and look for opportunities to:
- Return only the properties your application actually needs.
- Apply filters as early as possible.
- Reduce unnecessary graph traversals.
- Avoid repeatedly executing expensive queries when results can be reused.
- Review execution plans for slow-running queries.
2. Configure Realistic Minimum and Maximum NCUs
Scaling limits should reflect your application’s actual resource requirements, not worst-case assumptions.
A common mistake is configuring a high minimum NCU value “just in case.”
For example, if your workload consistently requires only 2–3 NCUs during off-peak hours but your minimum capacity is configured at 8 NCUs, lowering the minimum may reduce compute costs.
However, validate this change carefully because a lower minimum can increase scale-up time, reduce buffer cache availability, and increase query latency after periods of low activity. Balance potential cost savings against your application’s performance, availability, and responsiveness requirements.
Likewise, configuring an excessively high maximum NCU value does not increase costs by itself, but it allows Neptune Serverless to scale to higher capacity during sustained or unexpected workload spikes.
Ensure your maximum capacity is high enough to accommodate legitimate demand without unnecessarily restricting automatic scaling.
Review your scaling configuration periodically and compare it with actual workload patterns and allocated NCU trends. As your application evolves, revisit your minimum and maximum capacity settings to ensure they continue to balance cost and performance.
A common mistake is configuring a high minimum NCU value “just in case.”
For example, if your workload consistently requires only 2–3 NCUs during off-peak hours but your minimum capacity is configured at 8 NCUs, lowering the minimum may reduce compute costs.
However, validate this change carefully because a lower minimum can increase scale-up time, reduce buffer cache availability, and increase query latency after periods of low activity. Balance potential cost savings against your application’s performance, availability, and responsiveness requirements.
Likewise, configuring an excessively high maximum NCU value does not increase costs by itself, but it allows Neptune Serverless to scale to higher capacity during sustained or unexpected workload spikes.
Ensure your maximum capacity is high enough to accommodate legitimate demand without unnecessarily restricting automatic scaling.
Review your scaling configuration periodically and compare it with actual workload patterns and allocated NCU trends. As your application evolves, revisit your minimum and maximum capacity settings to ensure they continue to balance cost and performance.
3. Monitor NCU Consumption Instead of Monthly Bills
By the time you notice a higher AWS bill, the compute has already been consumed.
Instead, monitor the operational metrics that drive costs. Useful services include:
Understanding why NCU consumption changed is far more valuable than simply knowing that it changed.
Instead, monitor the operational metrics that drive costs. Useful services include:
- Amazon CloudWatch for database performance metrics.
- AWS Cost Explorer for identifying spending trends.
- AWS Cost and Usage Reports (CUR) for detailed billing analysis.
- AWS Budgets for proactive cost alerts.
Understanding why NCU consumption changed is far more valuable than simply knowing that it changed.
4. Schedule Batch Jobs During Off-Peak Hours
Large imports, graph rebuilds, and ETL jobs temporarily increase compute consumption.
Running these operations during periods of low application activity helps avoid stacking heavy background processing on top of peak customer traffic.
Examples include:
Running these operations during periods of low application activity helps avoid stacking heavy background processing on top of peak customer traffic.
Examples include:
- Product catalog imports
- Knowledge graph updates
- Customer relationship synchronization
- Supply chain data ingestion
- Historical data backfills
5. Review Workload Patterns Regularly
Applications rarely behave the same way they did six months ago.
User growth, new features, additional integrations, and changing business requirements all affect database utilization.
Review your Neptune environment periodically and ask:
User growth, new features, additional integrations, and changing business requirements all affect database utilization.
Review your Neptune environment periodically and ask:
- Is Serverless still the right deployment model?
- Has average NCU consumption increased?
- Are there new workload spikes?
- Has baseline utilization changed?
- Would Provisioned now be more economical?
Common Neptune Serverless Pricing Mistakes
Many unexpected cloud bills can be traced back to a handful of avoidable mistakes.
Assuming Serverless Is Always Cheaper
Serverless reduces idle capacity costs, but consistently busy workloads may be more economical on Provisioned Neptune.
Using Peak Utilization for Cost Estimates
Monthly costs are driven by average NCU consumption, not the highest level your database briefly reaches.
Ignoring Minimum NCUs
Your database never scales below the configured minimum. Choosing an unnecessarily high baseline increases compute costs even during quiet periods.
Focusing Only on Storage
For most production workloads, compute is the primary cost driver.
Reducing graph size may have little impact if inefficient queries continue consuming excessive NCUs.
Never Revisiting Deployment Decisions
Applications change over time. The deployment model that made sense a year ago may no longer be the most cost-effective option today.
Neptune Cost Optimization Checklist
Before deploying or reviewing an Amazon Neptune Serverless workload, make sure you’ve completed the following:
Review slow or expensive graph queries.
Configure realistic minimum and maximum NCU limits.
Monitor NCU utilization trends in CloudWatch.
Review spending regularly in AWS Cost Explorer.
Schedule batch imports during lower-traffic periods.
Recalculate your Serverless vs. Provisioned costs periodically.
Evaluate Neptune costs alongside the rest of your AWS environment.
Frequently asked questions
Is Amazon Neptune Serverless cheaper than Provisioned Neptune?
It depends on your workload. Neptune Serverless is generally more cost-effective for variable or unpredictable traffic, while consistently busy workloads may cost less on Provisioned Neptune.
What is a Neptune Capacity Unit (NCU)?
A Neptune Capacity Unit (NCU) is the compute unit used by Amazon Neptune Serverless. Each NCU provides approximately 2 GiB of memory along with proportional CPU and networking resources, scaling automatically based on workload demand.
How is Amazon Neptune Serverless billed?
Neptune Serverless compute is billed per NCU-second. Storage, backup storage, I/O requests, and data transfer are billed separately. See the Amazon Neptune pricing page for the latest regional pricing.
Can Neptune Serverless scale to zero?
No. Neptune Serverless scales only between your configured minimum and maximum NCU values. Your database always maintains at least the minimum capacity.
What affects Neptune Serverless costs the most?
The biggest cost drivers are average NCU utilization, application traffic, query complexity, read/write activity, and minimum NCU configuration. Compute typically has a greater impact on costs than storage.
Share
Facebook
X
LinkedIn
Reddit
