.png)
Key takeaways
1
Amazon Neptune supports Database Savings Plans for eligible provisioned instance usage, Neptune Serverless, and Neptune Analytics. The important FinOps step is separating eligible compute or capacity spend from the rest of the Neptune bill before sizing a commitment.
2
AWS advertises up to 35% savings across Database Savings Plans overall, while the current Amazon Neptune FAQ states up to 30% for Neptune specifically. The Neptune percentage is a ceiling, not the savings every workload should expect to realize.
3
A safe commitment starts with a durable post-optimization hourly floor, not peak demand or a monthly average. Purchase Analyzer can help test different commitments, but its analysis is historical rather than a forecast of future Neptune usage.
Amazon Neptune Database Savings Plans can reduce eligible Neptune costs without tying the commitment to one supported instance size or Region. The tradeoff is that the dollar-per-hour commitment lasts for one year, so getting the baseline right matters as much as getting the discounted rate.
Eligible provisioned Neptune instance usage, Neptune Serverless, and Neptune Analytics can receive Database Savings Plans rates.
AWS describes Database Savings Plans as a one-year, no-upfront model that automatically applies to eligible provisioned and serverless database usage across supported configurations and Regions. For Neptune, validate that the charge is an eligible instance, Serverless, or Analytics usage type before including it in the commitment model.
The AWS Database Savings Plans pricing page is the best place to verify current coverage before purchasing.
For the broader mechanics, see our AWS Database Savings Plans guide.
The savings percentage also needs context. AWS advertises up to 35% across the broader program, while the Amazon Neptune FAQ currently states up to 30% for Neptune specifically. Use the Neptune-specific figure when modeling potential savings and verify the actual rate for your eligible usage before purchase.
Neptune Analytics became eligible on March 5, 2026, and AWS says that expansion is available in all AWS Regions except China Regions.
For FinOps teams, the main task is separating eligible compute or capacity from Neptune cost components that sit outside the Database Savings Plans baseline.
Short answer
AWS Neptune Database Savings Plans exchange a consistent dollar-per-hour commitment for discounted rates on eligible Neptune usage over one year with no upfront payment. AWS advertises up to 35% savings across Database Savings Plans overall, while the Amazon Neptune FAQ currently states up to 30% for Neptune specifically.Eligible provisioned Neptune instance usage, Neptune Serverless, and Neptune Analytics can receive Database Savings Plans rates.
How Neptune Database Savings Plans work
Database Savings Plans are spend-based commitments. You commit to a fixed dollar amount per hour, and AWS automatically applies Savings Plans rates to eligible database usage until that hourly commitment is consumed. Eligible usage above the commitment is billed at On-Demand rates.AWS describes Database Savings Plans as a one-year, no-upfront model that automatically applies to eligible provisioned and serverless database usage across supported configurations and Regions. For Neptune, validate that the charge is an eligible instance, Serverless, or Analytics usage type before including it in the commitment model.
The AWS Database Savings Plans pricing page is the best place to verify current coverage before purchasing.
For the broader mechanics, see our AWS Database Savings Plans guide.
The savings percentage also needs context. AWS advertises up to 35% across the broader program, while the Amazon Neptune FAQ currently states up to 30% for Neptune specifically. Use the Neptune-specific figure when modeling potential savings and verify the actual rate for your eligible usage before purchase.
What Neptune usage is eligible
AWS currently lists Neptune Instances, Neptune Serverless, and Neptune Analytics under Database Savings Plans. Eligible provisioned and serverless usage can receive Savings Plans rates across supported configurations.Neptune Analytics became eligible on March 5, 2026, and AWS says that expansion is available in all AWS Regions except China Regions.
For FinOps teams, the main task is separating eligible compute or capacity from Neptune cost components that sit outside the Database Savings Plans baseline.
| Cost component | Sizing treatment |
|---|---|
| Provisioned Neptune instance usage | Include eligible provisioned usage after validating the exact billed usage type |
| Existing provisioned instance usage | Validate the billed usage type; do not exclude it solely because the generation is older |
| Neptune Serverless NCUs | Include eligible Serverless usage |
| Neptune Analytics | Include eligible Analytics usage |
| Storage | Exclude from the Database Savings Plans baseline |
| I/O and backup | Exclude from the Database Savings Plans baseline |
| Data transfer | Exclude from the Database Savings Plans baseline |
This prevents a common sizing mistake: treating the entire Neptune bill as commitment-eligible spend.
Use the live AWS Database Savings Plans pricing page as the final eligibility reference. For NCU-specific behavior, see our Neptune Serverless pricing guide.
Use the live AWS Database Savings Plans pricing page as the final eligibility reference. For NCU-specific behavior, see our Neptune Serverless pricing guide.
Choose On-Demand or a Savings Plan
A Database Savings Plan is most useful when optimized eligible hourly spend has a durable floor. If the workload is new, undergoing migration, or still changing materially, staying On-Demand longer can give you a more representative commitment baseline.| Workload pattern | Better starting point | Why |
|---|---|---|
| New or changing workload | On-Demand | Build representative history first |
| Stable provisioned baseline | Database Savings Plan | Predictable eligible spend supports commitment modeling |
| Variable Serverless workload | Measure, then model | Autoscaling creates a floor plus peaks |
| Scheduled Analytics jobs | Model active and paused periods | Size from recurring spend, not maximum capacity |
| Planned family, size, or Region change | Database Savings Plan | Eligible usage can retain Savings Plans rates across supported configurations and Regions |
The durable hourly floor matters more than the monthly average. A high monthly average can hide nights, weekends, or other low-demand periods when eligible spend falls sharply.
Those low points are what determine whether the fixed hourly commitment remains well utilized.
Use this sequence:
Those low points are what determine whether the fixed hourly commitment remains well utilized.
Size the commitment safely
AWS provides Savings Plans Recommendations and Purchase Analyzer to test recommended and custom commitment scenarios before purchase.Use this sequence:
1
Optimize Neptune first. Right-size provisioned resources, tune Serverless bounds, and account for Analytics pause periods.
2
Separate eligible spend. Remove storage, I/O, backup, data-transfer, and other charges AWS does not identify as Database Savings Plans eligible.
3
Choose a representative historical period after major optimization or architecture changes.
4
Find the durable hourly floor across nights, weekends, and low-demand periods.
5
Test multiple hourly commitment levels and compare savings, utilization, and coverage together.
6
Remove spend you reasonably expect to disappear during the one-year term.
7
Purchase only after the downside of lower-than-expected usage is clear.
Purchase Analyzer has an important limitation. AWS says its analysis is based on historical usage from the selected lookback period. It does not forecast future usage and does not account for queued or scheduled purchases.
If Neptune was recently resized, migrated, or optimized, use a post-change period that better represents the environment you expect to keep. Otherwise, the recommendation may be based on a workload pattern that no longer exists.
See the AWS Purchase Analyzer calculation guidance for the current calculation behavior.
Instead, test several custom commitments below the recurring floor, such as $0.50 and $0.60 per hour, in Purchase Analyzer. Then compare estimated savings with utilization and coverage at each level.
These figures are illustrative, not a recommendation. The correct commitment depends on actual eligible hourly usage, current rates, expected architecture changes, and how much underutilization risk your organization is prepared to accept.
If Neptune was recently resized, migrated, or optimized, use a post-change period that better represents the environment you expect to keep. Otherwise, the recommendation may be based on a workload pattern that no longer exists.
See the AWS Purchase Analyzer calculation guidance for the current calculation behavior.
Illustrative sizing example
Suppose eligible Neptune spend reaches $1.00 per hour during busy periods but repeatedly falls to $0.65. A commitment close to the $1.00 peak would be exposed during quieter hours.Instead, test several custom commitments below the recurring floor, such as $0.50 and $0.60 per hour, in Purchase Analyzer. Then compare estimated savings with utilization and coverage at each level.
These figures are illustrative, not a recommendation. The correct commitment depends on actual eligible hourly usage, current rates, expected architecture changes, and how much underutilization risk your organization is prepared to accept.
Practical callout:
A commitment should still make sense during quiet periods. If the economics work only at peak traffic, the baseline is not stable enough.
Know the return guardrail
AWS provides a limited return mechanism for qualifying Savings Plans purchase mistakes.Under the current Savings Plans return restrictions, a plan with an hourly commitment of $100 or less may be returnable if it was purchased within seven days and in the same calendar month, subject to AWS limits and eligibility requirements.
This is not a sizing strategy.
Model the purchase as if you will hold the commitment for its full term. Treat the return mechanism as a correction path for a qualifying mistake, not permission to purchase an aggressive commitment and reconsider later.
For broader commitment planning, see our business case for AWS Savings Plans.
Optimize Neptune before committing
A discounted rate should follow workload optimization. Otherwise, you can lock a lower rate onto spend that should have been removed first.For provisioned Neptune, evaluate newer instance generations before establishing the commitment baseline. A migration can change the workload’s cost structure and the level of eligible hourly usage, so model the post-migration environment rather than relying on the legacy baseline.
Storage architecture matters too. Neptune Standard and Neptune I/O-Optimized use different I/O pricing approaches, so compare the complete database bill on the Amazon Neptune pricing page before deciding that commitment purchasing is the next optimization step.
For Serverless, review NCU bounds against actual demand. A high minimum NCU setting can raise the baseline before commitment analysis even begins.
For Neptune Analytics, model active and paused periods rather than continuous peak capacity. Scheduled graph workloads can create very different hourly spending patterns from an always-on production database.
The order is simple: optimize, measure, validate eligible usage, model, then commit.
Neptune background for the decision
Amazon Neptune is AWS’s managed graph database for connected-data workloads. Common use cases include fraud detection, recommendation engines, knowledge graphs, identity graphs, network dependency analysis, and life sciences.For this cost decision, deployment model matters most.
The provisioned Neptune Database uses an instance-based compute. Neptune Serverless scales through Neptune Capacity Units. Neptune Analytics is designed for analytical graph workloads and uses memory-optimized capacity.
You do not need every graph model or query-language detail to make the savings decision. The commitment question comes down to four practical inputs:
- Which Neptune deployment generates the spend?
- Which billed usage is eligible?
- What is the stable post-optimization hourly floor?
- What is likely to change during the one-year term?
How we approach AWS commitments
We analyze eligible AWS commitment opportunities and evaluate coverage only after the eligible baseline is clear.That sequence matters because commitment purchasing should not compensate for an inefficient workload. Rightsizing, migrations, architecture changes, Serverless configuration, and changing demand can all alter how much spend is genuinely safe to commit.
An AWS Neptune Database Savings Plan is a one-year database commitment. Our broader Flex Commitment Program applies to eligible AWS commitment opportunities under its own eligibility and program terms.
With Flex Insured Commitments, teams can get up to 35% savings on a 1-year Neptune Database Savings Plan with none of the commitment risk. If an eligible Flex Commitment becomes more expensive than equivalent On-Demand usage, cashback is calculated after the applicable accrual and reconciliation process. See how cashback works and our Flex Commitment eligibility requirements.
The distinction matters. First determine what Neptune spends is eligible and what hourly commitment is safe. Then evaluate broader commitment management separately.
Conclusion
Neptune Database Savings Plans can reduce eligible costs when usage is stable and the commitment is sized from a realistic post-optimization baseline. Validate eligible spend, use representative historical data, and commit conservatively to avoid underutilization risk.For broader AWS commitment needs, our Flex Commitments can help eligible teams pursue deeper savings with reduced long-term commitment exposure and conditional cashback protection.
Frequently asked questions
Does Amazon Neptune support Database Savings Plans?
Yes. AWS lists Neptune Instances, Neptune Serverless, and Neptune Analytics under Database Savings Plans. For provisioned usage, validate the exact billed usage type before including it in the commitment model. Do not exclude it solely because of its instance generation.
How much can Database Savings Plans save on Neptune?
AWS advertises up to 35% across Database Savings Plans overall, while the current Amazon Neptune FAQ states up to 30% for Neptune specifically. Actual savings depend on the eligible usage type, Savings Plans rate, and utilization. Treat the published percentage as a maximum rather than an expected realized saving.
Does a Neptune Savings Plan cover storage and I/O?
No. Storage and I/O are separately billed Neptune cost components and should be excluded from the Database Savings Plans baseline. Apply the same conservative treatment to backup and data-transfer charges when calculating eligible hourly spend.
Does Purchase Analyzer forecast future Neptune usage?
No. AWS says Purchase Analyzer uses historical usage from the selected lookback period. It does not forecast future demand or account for queued or scheduled purchases, so use a historical period that resembles the Neptune environment you expect to keep.
When did Neptune Analytics become eligible?
AWS added Neptune Analytics to Database Savings Plans on March 5, 2026. AWS stated that the expanded coverage was available in all AWS Regions except China Regions.
Share
Facebook
X
LinkedIn
Reddit
