Amazon Timestream for IoT Data

What Amazon Timestream is today, and who this is for

Amazon Timestream is AWS's family of managed time-series databases. The name now covers two separate engines with different architectures, APIs and pricing:

• Amazon Timestream for LiveAnalytics: the original serverless service, with a memory store for recent data, a magnetic store for history, its own SQL dialect and per-write, per-query and per-GB pricing.
• Amazon Timestream for InfluxDB: managed instances or clusters running open source InfluxDB, either the 2.x branch or InfluxDB 3 (Core or Enterprise). You use the InfluxDB APIs, client libraries and Telegraf.

This page is for engineers who run building-management (BMS), energy or plant telemetry on AWS and are deciding whether Timestream should hold their sensor readings. If you are new to the category, read the time-series database overview first; for InfluxDB itself (line protocol, tags and fields, Flux, the 3.x engine) see InfluxDB Explained, which this page does not repeat.

Current status: LiveAnalytics is closed to new customers

The Timestream Developer Guide states that AWS decided "to close new customer access to Amazon Timestream for LiveAnalytics, effective 6/20/25" (20 June 2025). AWS also states that the change does not affect workloads already running, that existing customers with an active payer account can continue to add new users and linked accounts, and that AWS continues to invest in security, availability and performance for the service. New customers are told to evaluate Timestream for InfluxDB instead.

The Timestream FAQ, checked on 27 October 2026, goes further: it says Timestream for InfluxDB "should be used for all time series workloads", that LiveAnalytics "is no longer accepting new customers", and describes LiveAnalytics as in maintenance mode for existing customers. Our editorial view: for a new IoT project in 2026 that wants Timestream, that leaves Timestream for InfluxDB, and the rest of this page concentrates on it.

How IoT data reaches Timestream on AWS

Keep three roles apart when you design the pipeline:

• Messaging and streaming moves readings from devices and gateways and buffers them: AWS IoT Core (an MQTT broker with a rules engine), Amazon Kinesis Data Streams or Amazon MSK (managed Kafka). These are not databases; see Kafka vs MQTT for the difference.
• The time-series database stores readings and answers recent, operational queries: Timestream.
• Analytics across years and across the whole estate happens in a warehouse or lakehouse fed from S3 or the stream, for example BigQuery or Databricks if you run them, or Amazon's own analytics services.

For LiveAnalytics, AWS documents a direct AWS IoT Core rule action that writes message fields into a Timestream table, plus Apache Flink connectors from Kinesis and MSK. Timestream for InfluxDB is written to with InfluxDB line protocol over HTTPS. The InfluxDB 3 migration guide tells existing users to update "Telegraf outputs, application code, or IoT Rules to write via Line Protocol to the cluster endpoint", and recommends batches of 5,000 to 10,000 points sorted by tag key.

The AWS IoT Core Developer Guide, checked on 27 October 2026, also lists an InfluxDB rule action that "Writes time-series data from an IoT device into InfluxDB": AWS IoT Core converts each JSON message to line protocol and writes it to the database and table you specify, through an InfluxDB action destination (endpoint, version and credentials in AWS Secrets Manager). Its prerequisites mention Timestream for InfluxDB V3 clusters and InfluxDB V2 tokens, and each payload object must carry an integer Unix epoch timestamp key. We have not run this action, and Region availability and limits should be checked in the IoT Core documentation for your account. The alternative is a small ingestion service (a Lambda function, a container consuming Kinesis or MSK, or Telegraf on the gateway) that batches readings and posts them to the InfluxDB endpoint, which gives you a place to map BMS point names and drop bad values first.

InfluxDB 3 is schema-on-write: the database, tables and columns are created by the first writes, and later writes are validated against that schema. Plan tag names (site, asset, point) before the first device connects, because they become the table structure.

Choosing an engine: InfluxDB 2, InfluxDB 3 Core or Enterprise

Timestream for InfluxDB offers three engines, and AWS describes each one's role clearly:

• InfluxDB 2 uses Flux and InfluxQL, runs as a single instance, a Multi-AZ pair or a read replica cluster, and is, in the FAQ's words, "the right choice when you are lifting an existing InfluxDB 2 database". Instances can have up to 16 TiB of storage.
• InfluxDB 3 Core is single-node and has no compaction. AWS says it is designed for near real-time workloads on recent data (typically a few days) and is not recommended for long-term storage and analysis, because performance degrades over time without compaction.
• InfluxDB 3 Enterprise supports multi-node clusters (the migration guide says up to 15 nodes) with compaction, which AWS describes as enabling horizontal scaling for reads and writes; AWS positions it for high-cardinality data and long-term analytics. AWS states that "For InfluxDB 3 Enterprise deployments, there is an additional InfluxData license cost charged on a per vCPU per hour basis", billed through AWS Marketplace.

InfluxDB 3 is built on Apache Arrow, Apache DataFusion and Parquet files in Amazon S3, and is queried with SQL or InfluxQL over HTTP or Flight (gRPC). For a new BMS project that wants SQL and more than a few days of history, Enterprise is the engine AWS recommends; Core suits a short-retention "live" store or development. AWS also documents a ceiling: a single InfluxDB 3 Enterprise cluster cannot currently support more than 1 million records per second, beyond which you shard across clusters.

A building-management example

A facilities team runs a BMS across several buildings. Gateways read AHU supply-air temperature, zone CO2 and chiller kW every 1 to 60 seconds and publish them to AWS IoT Core over MQTT. In this illustrative design a rule forwards messages to an ingestion function (the IoT Core InfluxDB rule action described above is the alternative when no mapping step is needed), which maps each BMS point to a stable site, asset and measure name from the asset register, batches the readings and writes line protocol to an InfluxDB 3 Enterprise cluster. Dashboards in Grafana query the last few days; CMMS work orders stay in the relational database that owns them.

In line protocol the site and asset become tags and each measure becomes a field, so one line can carry all readings for an asset at one timestamp. If historical readings live in PostgreSQL today, you can produce line protocol from them with plain SQL for a backfill. The query below joins readings to the point register and emits one line per asset and timestamp, escaping the space in the site name as line protocol requires.

CREATE TABLE bms_point (
    point_id   integer PRIMARY KEY,
    site       text    NOT NULL,
    asset      text    NOT NULL,
    measure    text    NOT NULL
);
CREATE TABLE bms_reading (
    point_id  integer          NOT NULL REFERENCES bms_point,
    ts        timestamptz      NOT NULL,
    value     double precision NOT NULL,
    PRIMARY KEY (point_id, ts)
);
INSERT INTO bms_point VALUES
    (101, 'London HQ', 'AHU-01',  'supply_air_temp'),
    (102, 'London HQ', 'AHU-01',  'zone_co2'),
    (201, 'London HQ', 'CH-01',   'chiller_kw');
INSERT INTO bms_reading VALUES
    (101, '2026-10-27 09:00:00+00', 13.2),
    (102, '2026-10-27 09:00:00+00', 612),
    (201, '2026-10-27 09:00:00+00', 148.5),
    (101, '2026-10-27 09:01:00+00', 13.4);

-- One line protocol line per asset and timestamp: table,tags fields unix_seconds
SELECT 'bms,site=' || replace(p.site, ' ', '\ ') || ',asset=' || p.asset || ' '
       || string_agg(p.measure || '=' || r.value::text, ',' ORDER BY p.measure) || ' '
       || extract(epoch FROM r.ts)::bigint AS line
FROM bms_reading r
JOIN bms_point p USING (point_id)
GROUP BY p.site, p.asset, r.ts
ORDER BY r.ts, p.asset;

bms,site=London\ HQ,asset=AHU-01 supply_air_temp=13.2,zone_co2=612 1793091600
bms,site=London\ HQ,asset=CH-01 chiller_kw=148.5 1793091600
bms,site=London\ HQ,asset=AHU-01 supply_air_temp=13.4 1793091660

# Write: native v3 endpoint, second precision
curl "https://your-cluster-endpoint:8086/api/v3/write_lp?db=bms&precision=s" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --data-binary @readings.lp

# Query: hourly average supply-air temperature per asset for the last day (SQL)
curl --get "https://your-cluster-endpoint:8086/api/v3/query_sql" \
  --header "Authorization: Bearer YOUR_TOKEN" \
  --data-urlencode "db=bms" \
  --data-urlencode "q=SELECT asset, date_bin(INTERVAL '1 hour', time) AS hour, avg(supply_air_temp) AS avg_sat FROM bms WHERE time >= now() - INTERVAL '1 day' GROUP BY asset, hour ORDER BY asset, hour"

If you already run Timestream for LiveAnalytics

Existing workloads continue, so there is no forced cut-over date in the documentation. LiveAnalytics keeps recent data in a memory store and moves it to a magnetic store by retention policies you configure, queries both tiers transparently, and offers scheduled queries for roll-ups. AWS IoT Core can still write to it through the Timestream rule action.

For a move, AWS recommends Timestream for InfluxDB 3 Enterprise for most LiveAnalytics migrations, and InfluxDB 2 for low-latency operational monitoring with lower series cardinality. The cardinality threshold is not consistent within the same AWS page as checked on 27 October 2026: InfluxDB 3 Enterprise "is the recommended target for workloads with more than 1 million series", and the InfluxDB 2 option is headed "Low-latency operational monitoring (less than 1 million series)", but the text under that heading says "We recommend Amazon Timestream for InfluxDB 2, if your Timestream for LiveAnalytics table has less than 10 million cardinality (series keys)". We report both figures as published; between 1 and 10 million series, confirm the right engine with AWS before migrating. Points the migration guide makes that affect an IoT team:

• The SQL dialect "does not match LiveAnalytics 1:1": queries such as ago() and the measure_value::double pattern need rewriting and checking on a development cluster.
• The write path changes from the AWS SDK WriteRecords API to line protocol over HTTPS, and authentication changes from IAM to InfluxDB tokens; IAM-based data-plane authentication for InfluxDB 3 is not yet available.
• History is exported with UNLOAD to S3 and written back as line protocol; bulk import from Parquet is listed as a future release.
• Scheduled queries become processing-engine plugins (Python) in InfluxDB 3, or tasks in InfluxDB 2.

Sizing and retention

InfluxDB 2 instances. You choose a db.influx instance class and an Influx IOPS Included storage tier. AWS publishes a sizing table for a reference workload (Telegraf agents, 5,000 lines per write request, moderately complex queries); for example it lists db.influx.large for fewer than 100,000 series at about 50,000 lines per second. Treat those rows as AWS's starting guidance for that workload, not as a measured result for yours. Series cardinality (sites x assets x measures) is the figure to estimate first.

InfluxDB 3 clusters. Data lives in S3 as Parquet, so storage grows independently of compute. Size nodes for write throughput and query concurrency; with Core, keep retention short because there is no compaction.

Retention. One approach (a design choice, not an AWS recommendation) is to keep raw one-second or one-minute readings in Timestream only as long as operators look at them directly, write roll-ups for longer periods, and export history to S3 for the warehouse or lakehouse. The period depends on how far back operators and fault-finding need raw data, reporting needs, the engine (Core has no compaction) and storage cost. The IoT sensor data storage guide walks through the arithmetic for estimating rows and bytes.

Security and operational considerations

• Network. Timestream for InfluxDB runs in your VPC and has no direct host access; you reach it through the InfluxDB API, CLI and UI. Keep BMS networks segmented and let only the ingestion service reach the write endpoint.
• Authentication. InfluxDB tokens, not IAM, control data access. Give the ingestion service a write-only token for one database, store tokens in a secrets manager and rotate them.
• Encryption. Data is encrypted at rest and in transit by default; you can supply a customer managed AWS KMS key when you create the instance or cluster, and it cannot be changed afterwards.
• Availability. The FAQ lists a 99.9% monthly uptime commitment for Multi-AZ deployments and 99.5% for single instances under the Timestream SLA. Multi-AZ standbys do not serve reads; read replica clusters (InfluxDB 2) need an InfluxData add-on.
• Backups and maintenance. Automated backups can run hourly to monthly with 1 to 365 days of retention, and you set a weekly maintenance window.

Limitations and when not to use Timestream

• You wanted serverless. The serverless engine is closed to new customers. Timestream for InfluxDB is provisioned capacity you size and pay for by the hour, whether or not readings arrive.
• Readings need joins with relational data. If most queries join readings to assets, spaces and CMMS work orders, PostgreSQL or TimescaleDB keeps them in one database.
• Multi-cloud or on-premises sites. Timestream is AWS-only. Self-managed InfluxDB or QuestDB can be run on premises or on other clouds.
• Long-term portfolio analytics. Years of history across hundreds of buildings, joined with energy tariffs and asset data, is warehouse or lakehouse work.
• IAM-only security policies. InfluxDB 3 data access uses tokens; if your organisation requires IAM for every data-plane call, check the current documentation first.

For a wider comparison of engines, see the guide to choosing a time-series database.

Pricing

Prices from the provider's official pricing pages, checked 27 October 2026, region any (pricing model only; rates vary by Region), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.

The Timestream pricing page shows rates per Region and instance class, so we describe the model rather than reproduce figures. Timestream for InfluxDB charges for instance-hours (on demand, no long-term commitment) and for provisioned storage in GB-months; Multi-AZ and read replica deployments are billed per instance. While an instance is stopped you pay for storage but not instance-hours. InfluxDB 3 Enterprise and InfluxDB 2 read replicas add an InfluxData licence charged through AWS Marketplace. The FAQ says Timestream usage is eligible for Database Savings Plans.

The licence terms here are commercial charges as AWS describes them; the InfluxData licence itself is sold through AWS Marketplace, where its terms are published with the listing. This is not legal advice: read the licence terms that apply to your purchase and take advice for your situation.

Timestream for LiveAnalytics (existing customers) charges separately for writes, memory store, magnetic store and query compute measured in Timestream Compute Units. Check the pricing page for your Region before estimating either service.

Frequently asked questions

Sources

• AWS docs: Timestream for LiveAnalytics availability change
• AWS docs: What is Amazon Timestream for LiveAnalytics?
• Amazon Timestream FAQs
• AWS docs: What is Timestream for InfluxDB?
• AWS docs: Amazon Timestream for InfluxDB 3
• AWS docs: LiveAnalytics alternatives evaluation
• AWS docs: Migrating to Timestream for InfluxDB 3
• AWS docs: Writing data to your InfluxDB 3 cluster
• AWS docs: Querying data from InfluxDB 3
• AWS docs: AWS IoT Core and Timestream
• Amazon Timestream pricing
• AWS IoT Core docs: AWS IoT rule actions
• AWS IoT Core docs: InfluxDB rule action

Checked 27 October 2026.

How we research these articles: our editorial method. Research-based from official documentation; SQL examples are run on a local database where the page says so. CodeWithSQL earns nothing from the vendors mentioned.