How Timestream Actually Bills: A Breakdown for Engineers

Timestream can look simple on the bill until you break down the line items. Most teams think in terms of "stored data," but Amazon Timestream for LiveAnalytics is billed across multiple meters that move independently.

If you only watch one number, you can miss where most of the spend actually comes from.

First: Know Which Timestream Product You Are Using

AWS now has two Timestream offerings:

• Amazon Timestream for LiveAnalytics (serverless, billed by writes, query compute, memory store, magnetic store)
• Amazon Timestream for InfluxDB (managed InfluxDB, billed by DB instance-hours and storage)

This post focuses on Timestream for LiveAnalytics, where most billing misunderstandings happen.

The LiveAnalytics Billing Model (What Actually Ticks)

For Timestream for LiveAnalytics, AWS charges separately for:

1. Writes: billed by amount of data written (rounded to nearest KiB), often shown in pricing examples as a per-million 1 KiB write unit.
2. Queries: billed by Timestream Compute Units (TCUs) consumed over time (TCU-hours), not by a flat per-query fee.
3. Memory store: billed by GB-hour.
4. Magnetic store: billed by GB-month (with account/region minimums for magnetic storage usage).

So the statement "Timestream is $0.10/GB-month" is not accurate for LiveAnalytics. That kind of single storage rate framing is incomplete and often wrong.

Why Teams Get Surprised

1) Query charges are compute-time based, not per query count

A dashboard running one heavy query every few seconds can cost more than many lightweight queries. Query cost follows TCU consumption and duration.

2) Memory retention is expensive relative to magnetic retention

Keeping a long retention period in memory store drives GB-hour charges. Moving older data to magnetic store usually lowers storage cost.

3) High write frequency amplifies ingestion cost fast

Small records at high frequency still add up, especially without batching and schema optimization.

4) "Idle table" thinking can be misleading

In LiveAnalytics, empty or unused tables are not the main cost driver. Spend usually comes from write volume, query compute, and retained data in memory/magnetic tiers.

A Better Mental Model for Retention

Retention decisions directly shape spend:

• Short memory retention for hot, low-latency workloads
• Longer magnetic retention for historical analysis
• Keep only what is needed in memory store

If your query patterns are mostly historical and not sub-second operational reads, memory retention is often set too high.

Practical Cost Review Checklist

Run this monthly:

1. Writes: are records batched efficiently? Are you writing unnecessary dimensions/measures?
2. Queries: which workloads consume most TCU time? Any dashboards refreshing too frequently?
3. Memory store: is hot retention longer than real operational need?
4. Magnetic store: is long-term retention aligned with compliance and analytics requirements?
5. Table lifecycle: are stale datasets still retained without business need?

CLI: Inventory Retention Settings Across Tables

Use this to review memory/magnetic retention quickly:

aws timestream-write list-databases --query 'Databases[].DatabaseName' --output text | tr '\t' '\n' | while read db; do
  [ -z "$db" ] && continue
  aws timestream-write list-tables --database-name "$db" --query 'Tables[].TableName' --output text | tr '\t' '\n' | while read tbl; do
    [ -z "$tbl" ] && continue
    aws timestream-write describe-table \
      --database-name "$db" \
      --table-name "$tbl" \
      --query '{Database:Table.DatabaseName,Table:Table.TableName,MemoryHours:Table.RetentionProperties.MemoryStoreRetentionPeriodInHours,MagneticDays:Table.RetentionProperties.MagneticStoreRetentionPeriodInDays}'
  done
done

This does not prove usage by itself, but it gives you the retention map you need before optimizing query and write behavior.

Bottom Line

Timestream for LiveAnalytics billing is multi-dimensional:

• writes
• query compute (TCUs)
• memory store
• magnetic store

If you treat it as a single storage bill, you will miss the biggest optimization levers.

Onsystem helps teams surface these hidden cost patterns and prioritize the fastest savings opportunities across AWS data services.

Onsystem automates AWS cost analysis and waste detection. Try it at onsystem.net.