Cargando...
Cargando...
Serverless, auto-scaling time-series database built for IoT, DevOps, and analytics workloads at any scale
Amazon Timestream is a fully managed, serverless time-series database service designed to store and analyze trillions of time-stamped events per day. It automatically scales ingestion, storage, and query capacity, and features built-in tiered storage that seamlessly moves data from an in-memory store (for recent, hot data) to a cost-optimized magnetic store (for historical, cold data). Timestream includes purpose-built time-series analytics functions, making it far more efficient than repurposing relational or NoSQL databases for time-series workloads.
To provide a purpose-built, serverless time-series database that eliminates the operational overhead of managing infrastructure while delivering high-performance ingestion and querying for time-stamped data such as IoT sensor readings, application metrics, and operational telemetry.
Use When
Avoid When
Serverless auto-scaling
No servers, clusters, or capacity planning required; Timestream scales ingestion and query capacity automatically
Tiered storage (Memory + Magnetic)
Automatic, policy-driven data movement from fast in-memory store to cost-optimized magnetic store; no manual ETL or migration needed
Scheduled Queries
Pre-compute and materialize aggregated results on a schedule into a derived table; dramatically reduces query cost and latency for repeated aggregations
Built-in time-series analytics functions
Native SQL functions for interpolation, smoothing, time-series approximation, bin(), date_trunc(), and window functions
Multi-measure records
Store multiple measure values in a single row; reduces storage overhead and improves query efficiency for dense schemas
Magnetic store writes (late data ingestion)
Allows ingestion of data with timestamps older than memory store retention directly into the magnetic store
AWS PrivateLink support
Query and write endpoints accessible via VPC endpoints for private network access without traversing the public internet
Encryption at rest
Data encrypted using AWS KMS-managed keys; supports customer-managed keys (CMK)
Encryption in transit
All data transmitted using TLS
IAM-based access control
Fine-grained resource-level permissions via IAM policies for databases, tables, and operations
Grafana integration (Amazon Managed Grafana)
Native Timestream data source plugin available in Grafana; used for real-time operational dashboards
Amazon SageMaker integration
Query Timestream data directly from SageMaker for ML model training on time-series datasets
AWS IoT Core integration
IoT Core rules can route MQTT messages directly to Timestream tables without custom Lambda code
Amazon Kinesis Data Streams integration
Kinesis Data Streams can feed into Timestream via Lambda or Kinesis Data Firehose for streaming ingestion pipelines
Cross-account access
Supported via IAM roles and resource-based policies
CloudWatch metrics for monitoring
Timestream publishes operational metrics (ingestion errors, query metrics) to CloudWatch
ACID transactions
Timestream is append-optimized and does not support multi-row ACID transactions; not suitable for transactional workloads
SQL JOINs across Timestream tables
Timestream supports JOINs within a single database; cross-database JOINs require external orchestration
Deletion of individual records
Individual record deletion is not supported; data is managed via retention policies at the table level
IoT Rules Engine → Timestream Direct Ingestion
high freqAWS IoT Core Rules Engine uses the Timestream action to route MQTT device messages directly to a Timestream table without requiring a Lambda function as an intermediary. This is the lowest-latency, lowest-cost pattern for IoT telemetry ingestion and is the recommended architecture for IoT → Timestream pipelines.
Streaming Ingestion via Kinesis + Lambda
high freqKinesis Data Streams captures high-volume event streams; Lambda functions triggered by Kinesis batch and transform records before writing to Timestream using the WriteRecords API. Used when custom transformation, enrichment, or fan-out logic is needed before storage.
Scheduled Query Materialization → S3 Export
high freqScheduled Queries materialize aggregated Timestream data into a derived summary table. For long-term archival or cross-service analytics, results can be exported to S3 via custom Lambda or Kinesis Data Firehose. However, for most use cases, Timestream's magnetic store eliminates the need for S3 archival.
Federated Query for Cross-Service Analytics
high freqAmazon Athena can query Timestream data using Athena Federated Query with the Timestream connector. This pattern is used when analysts need to JOIN Timestream time-series data with S3-based dimensional data (e.g., device metadata in a data lake) in a single SQL query.
Real-Time Operational Dashboards
medium freqAmazon Managed Grafana has a native Timestream data source plugin. Teams use this pattern for live DevOps dashboards, IoT monitoring panels, and industrial telemetry visualization without building custom front-ends.
Time-Series ML Feature Engineering
medium freqSageMaker notebooks and training jobs can query Timestream directly to extract time-series features for anomaly detection, forecasting, and classification models. Timestream's built-in interpolation and smoothing functions reduce pre-processing code in the ML pipeline.
Operational Monitoring of Timestream Itself
low freqTimestream publishes ingestion and query metrics to CloudWatch, enabling alarms on write errors, rejected records, or high query scan volumes. This is the standard observability pattern for Timestream deployments.
Timestream's tiered storage (memory store → magnetic store) is AUTOMATIC and policy-driven — you never need to write ETL jobs or Lambda functions to move old data to S3 for cost savings. If an exam scenario describes 'moving historical time-series data to S3 to reduce costs,' the correct answer is to configure Timestream's magnetic store retention policy instead.
Scheduled Queries are the primary cost and performance optimization tool for Timestream. If an exam scenario describes expensive repeated aggregation queries (e.g., hourly averages computed by thousands of dashboard users), the correct answer is to use Scheduled Queries to pre-compute and materialize results — not to add more read replicas (which don't exist in Timestream) or partition data across databases.
Timestream does NOT have read replicas or Multi-AZ configurations like RDS — it is fully managed and serverless. AWS handles all availability and durability internally. Never select 'create a read replica' or 'enable Multi-AZ' as answers for Timestream scalability or HA questions.
Timestream is SERVERLESS — no read replicas, no Multi-AZ, no cluster management. AWS handles HA and scaling internally. Never choose 'create read replica' for Timestream scalability questions.
Use SCHEDULED QUERIES to pre-aggregate repeated query workloads — this is the primary cost and performance optimization lever in Timestream, not database partitioning or caching layers.
Tiered storage (memory → magnetic) is AUTOMATIC via retention policies. Never architect a manual ETL pipeline to move Timestream data to S3 for cost savings — configure magnetic store retention instead.
For IoT ingestion architectures, prefer the AWS IoT Core Rules Engine → Timestream direct action over Lambda-based intermediaries when no transformation is needed. This reduces latency, cost, and operational complexity — and is the pattern AWS explicitly recommends and tests.
Magnetic store writes allow late-arriving data (with timestamps older than the memory store retention window) to be written directly to the magnetic store. For IoT scenarios where devices reconnect after being offline and send backlogged data, this is the correct Timestream feature — not a separate S3 cold-path or DynamoDB buffer.
Timestream uses a purpose-built SQL dialect with time-series specific functions (bin(), date_trunc(), interpolate(), CREATE_TIME_SERIES). When exam questions mention 'time-series specific SQL functions' or 'built-in interpolation,' Timestream is the correct answer over RDS, Aurora, or Redshift.
For the DEA-C01 exam (Data Security and Governance domain): Timestream supports encryption at rest with AWS KMS (including CMKs) and encryption in transit with TLS. Access is controlled via IAM. There is no native row-level security — access control is at the database and table level.
Partitioning data across multiple Timestream databases does NOT improve query performance. Timestream's query engine is optimized internally and scales automatically. Splitting data across databases increases management complexity and can actually hurt cross-table query performance. Use a single well-designed table with proper dimensions instead.
Multi-measure records are the recommended data model for new Timestream tables. They store multiple measure values (e.g., temperature, humidity, pressure) in a single record, reducing write costs and improving query efficiency compared to single-measure records where each attribute requires a separate row.
For SAP-C02 migration scenarios: When modernizing a self-managed InfluxDB, TimescaleDB, or OpenTSDB deployment to AWS, Timestream is the target service. Key migration benefits include: no infrastructure management, automatic tiered storage, and native AWS service integrations (IoT Core, Kinesis, SageMaker).
Common Mistake
Timestream requires read replicas or Multi-AZ configuration for high availability and read scalability, similar to Amazon RDS.
Correct
Timestream is fully serverless and managed — AWS handles all replication, availability, and durability internally. There are no read replicas, no Multi-AZ toggles, and no cluster nodes to configure. Scalability and HA are built into the service architecture.
This is the #1 trap for candidates who over-apply RDS mental models to Timestream. On the exam, if you see 'how do you scale reads in Timestream,' the answer is never 'create a read replica' — it's 'use Scheduled Queries to reduce query load' or 'the service scales automatically.'
Common Mistake
To reduce storage costs for old time-series data, you should build a Lambda function or Glue job to periodically export historical Timestream data to S3, then query it with Athena.
Correct
Timestream's magnetic store is a built-in, cost-optimized storage tier for historical data. Simply configure the magnetic store retention policy (up to 200 years) and data automatically moves from the expensive memory store to the cheap magnetic store. No ETL, no Lambda, no S3 migration needed for the vast majority of use cases.
This misconception leads candidates to design unnecessarily complex architectures. The exam tests whether you know that Timestream's tiered storage eliminates the need for manual archival pipelines. The S3+Athena pattern is only appropriate if you need to JOIN Timestream data with other S3 datasets in a federated query.
Common Mistake
Splitting time-series data across multiple Timestream databases (e.g., one database per region or device type) improves query performance through parallelism.
Correct
Timestream's query engine is internally optimized and scales automatically. Partitioning data across multiple databases does NOT improve performance and actually increases operational complexity. The correct optimization levers are: (1) use Scheduled Queries to pre-aggregate frequently queried data, (2) use multi-measure records to reduce row count, and (3) ensure queries filter on time ranges to leverage Timestream's internal time-based partitioning.
This trap catches candidates who apply traditional database sharding/partitioning logic to Timestream. The exam rewards knowing that Timestream handles internal partitioning automatically and that Scheduled Queries are the primary performance optimization tool.
Common Mistake
Scheduled Queries in Timestream are just a convenience feature for automation — they don't meaningfully affect cost or performance.
Correct
Scheduled Queries are a critical cost and performance optimization feature. They pre-compute aggregations on a schedule and materialize results into a derived table. Dashboard queries against the derived table scan dramatically less data than running the full aggregation query repeatedly, reducing both query latency and data-scanned costs.
Candidates who overlook Scheduled Queries will choose expensive architectures (e.g., caching layers, Lambda pre-aggregation, DynamoDB result stores) when the exam scenario describes repeated aggregation workloads. Scheduled Queries is the purpose-built, correct answer.
Common Mistake
Timestream is just a specialized version of DynamoDB or RDS optimized for timestamps — you can use it for any workload that involves dates and times.
Correct
Timestream is purpose-built for time-series data: append-mostly, high-cardinality, time-ordered events where the timestamp IS the primary access pattern. It does not support individual record deletion, complex multi-table relational JOINs, or ACID transactions. Using it for transactional or general-purpose workloads is an anti-pattern.
Understanding the specific use case boundary of Timestream prevents incorrect service selection on architecture questions. The exam will present scenarios where Timestream seems applicable (because there are timestamps) but the correct answer is RDS or DynamoDB because the workload requires transactions, updates, or complex relational queries.
TIMESTREAM = 'Time In Memory Eventually Streams To Reduced-cost Elastic Archival Magnetically' — Memory store (hot, fast, expensive) → Magnetic store (cold, slower, cheap) — automatic tiering, no manual work
The 3 S's of Timestream optimization: Scheduled Queries (pre-aggregate), Single-table design (avoid multi-DB splits), and Storage tiering (let magnetic store handle history)
IoT → Timestream: 'Rules Direct' — AWS IoT Core Rules Engine writes DIRECTLY to Timestream. No Lambda needed for simple ingestion.
Timestream is NOT RDS: No Replicas, No Multi-AZ, No Transactions, No Deletes — it's a serverless append-only time-series store
CertAI Tutor · SAP-C02, DEA-C01 · 2026-02-21
In the Same Category
Comparisons