Amazon Timestream Database
Does ZopNight manage Amazon Timestream Database?
Amazon Timestream meters four things independently: writes by volume ingested, memory-store storage per GB-hour, magnetic-store storage per GB-month, and queries by data scanned. Retention settings decide how the storage meters grow. ZopNight discovers databases on the 6-hour cycle and flags them when the account's Timestream ingest and query metering has stayed near zero for 30 days (RC-194).
Rules that fire on Amazon Timestream Database
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
Amazon Timestream is a serverless time-series database billed on writes, storage tiers, and query volume. Cost grows silently with retention settings and unbounded ingest, so visibility into per-database spend matters.
Four independent meters
Timestream has no instances to size; it bills along four axes. Writes meter by volume ingested. The memory store, the hot tier serving recent data fast, bills per GB-hour, at rates suited to hours or days of retention. The magnetic store bills per GB-month for the long tail. Queries bill by data scanned. Because each meter is independent, a Timestream bill can be dominated by any of them, and the retention configuration per table is what routes data between the expensive hot tier and the cheap cold one. Memory-store retention set generously “to be safe” is the single most common cost error.
Idle databases flagged, retention checked by hand
ZopNight discovers Timestream databases automatically on the 6-hour cycle, with per-resource cost from Cost Explorer or CUR 2.0 and one recommendation, RC-194, which flags databases once the account’s ingest and query metering has stayed near zero for 30 days. AWS reports that activity per account rather than per database, so a database still taking writes that nobody reads, such as an IoT pipeline still writing device telemetry that no longer has a reader, is not flagged and is worth checking by hand. Two retention questions remain manual checks too: whether memory-store retention exceeds what dashboards and alerts actually query, and whether magnetic retention is unbounded on tables whose consumers only ever look back 90 days.
Time-series spend patterns
Ingest is set-and-forget by design, which is the hazard: fleets grow, sampling intervals tighten, and the write meter scales with both while nobody revisits the decision. Query-side waste comes from dashboards refreshing broad time windows on a timer, scanning the same gigabytes every 30 seconds. And dual-retention mistakes (the same data held long in both tiers) pay hot-tier rates for data the cold tier already covers.
Checking tables and retention in the console
The Timestream console lists databases and tables with their memory-store and magnetic-store retention settings side by side; that pair of numbers per table, against what consumers actually query, is most of the audit. CloudWatch’s Timestream metrics cover ingest and scan volumes for the trend view.