Scheduling Amazon Neptune Cluster
Can ZopNight schedule Amazon Neptune Cluster?
Neptune stops as a cluster, taking writer and up to 15 read replicas together via the management API, and AWS restarts it on its own after 7 days. Storage and backups bill through the stop, and the first morning queries run against an empty buffer pool, so expect slow traversals before the caches refill.
How the stop works
| Field | Value |
|---|---|
| Behaviour | cluster stopped and started via the Neptune management API on schedule. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Writer and replicas move as one
Neptune’s stop is cluster-scoped. The writer and every read replica shut down in the same operation and return in the same operation; there is no leaving one replica up for a skeleton-crew workload. That makes multi-replica development clusters the highest-value candidates: each replica is its own instance-hour meter, and the stop pauses all of them at once.
The one-week ceiling
Like its relational cousins, a stopped Neptune cluster does not stay stopped past 7 days. AWS starts it to apply pending maintenance. Nightly and weekend schedules reset the clock every cycle and never hit the ceiling. The trap is reserved for clusters somebody stopped by hand and walked away from: those return unbidden and bill on.
Storage does not stop with the cluster
Graph storage, automated backups and snapshots continue at full rate during the off window. A cluster with a large property graph keeps paying for every gigabyte at 3am. The schedule’s saving is the instance-hours of the writer plus replicas, and nothing else. Quote it that way.
Cold buffers make slow first traversals
Neptune leans hard on its buffer pool cache, and a freshly started cluster has an empty one. The first multi-hop traversals of the morning read from storage and can run several times slower than the same queries at 5pm the previous day. If a dashboard or batch job runs at open of business, either warm the cache with representative queries after start or set the start early enough that organic traffic does the warming.
Interrupted work does not resume
Bulk loads via the loader endpoint, long-running Gremlin or SPARQL queries, and streams consumers all stop when the cluster does, and none of them pick up where they left off. Close the nightly load before the stop cron, or make the loader job responsible for checking the schedule before it starts.