Amazon Timestream FAQs

Time-series data is a sequence of data points—such as stock prices, temperature, and CPU use of an Amazon EC2 instance—recorded over time. With time-series data, each data point consists of a timestamp, one or more attributes, and the event that changes over time. This data is used to derive insights into the performance and health of an application, detect anomalies, and identify optimization opportunities.

For example, DevOps engineers might want to view data that measures changes in infrastructure performance metrics, manufacturers might want to track IoT sensor data that measures changes in temperature of an equipment across a facility, and online marketers might want to analyze clickstream data that captures how a user navigates a website over time. As time-series data is generated from multiple sources in extremely high volumes, it needs to be cost-effectively stored and analyzed in near real time to derive key business insights.

Amazon Timestream offers fully managed InfluxDB, one of the most popular open source time-series databases in the market, and LiveAnalytics, a serverless time-series database built for scale.

You can get started with Timestream using the AWS Management Console, AWS Command Line Interface (AWS CLI), or SDKs. For more information, including tutorials and other getting started content, see the developer guide.

Amazon Timestream for InfluxDB should be used for use cases that require near real-time time-series queries and when you need InfluxDB features or open source APIs. The existing Timestream engine, Amazon Timestream for LiveAnalytics, should be used when you need to ingest more than tens of gigabytes of time-series data per minute and run SQL queries on terabytes of time-series data in seconds.

Yes. The two engines complement each other for low-latency and large-scale ingestion of time-series data. You can ingest data into Timestream for InfluxDB and use a Telegraf plugin to send data into Timestream for analysis of historical data through SQL queries.

If you decide to migrate your Timestream for InfluxDB data into Timestream for LiveAnalytics, you will incur public billing charges for using that service, including ingestion, storage, and querying. It is optional to use Timestream for LiveAnalytics with Timestream for InfluxDB.

Timestream for InfluxDB can be used separately or with your Timestream for LiveAnalytics workloads. Timestream for InfluxDB is targeted for near real-time applications with single-digit millisecond response times. Timestream for LiveAnalytics addresses use cases that need to ingest gigabytes of data in minutes and query terabytes of data in seconds. You can combine Timestream for InfluxDB and Timestream for LiveAnalytics within your applications or dashboards.

No. Timestream dynamically creates a table’s schema based on a set of dimensional attributes and measures. This offers flexible and incremental schema definition that can be adjusted at any time without affecting availability.

Once your databases have been created and become available, you can retrieve endpoint information from the Timestream console. Alternatively, you can also use the Describe API to retrieve endpoint information (DescribeDatabase when using Timestream for LiveAnalytics and DescribeDBInstances when using Timestream for InfluxDB).

You can visualize your Timestream time-series data and create alerts using Grafana, a multiplatform, open source analytics and interactive visualization tool. To learn more and find sample applications, see the documentation.

You can create AWS Lambda functions that interact with Timestream. For more detailed information, see the documentation.

You can send time-series data collected using open source Telegraf directly into Timestream with the Telegraf connector. For more detailed information, see the documentation.

You can access Timestream from your Amazon Virtual Private Cloud (Amazon VPC) using VPC endpoints. Amazon VPC endpoints are easy to configure and provide reliable connectivity to Timestream APIs without requiring an internet gateway or NAT instance.

AWS CloudFormation simplifies provisioning and management by providing CloudFormation templates for quick and reliable provisioning of the services or applications. CloudFormation provides comprehensive support for Timestream by providing templates to create databases (both for Timestream for LiveAnalytics and Timestream for InfluxDB). The templates are up to date with the latest Timestream for InfluxDB announcement and provide flexibility and ease of use to Timestream customers.

Amazon Timestream for LiveAnalytics is a fast, scalable, and serverless time-series database built for large-scale workloads. It is serverless and automatically scales up or down to adjust capacity and performance, so you don’t need to manage the underlying infrastructure. Its fully decoupled architecture allows you to ingest trillions of data points and run millions of queries per day.

The Timestream for LiveAnalytics adaptive query engine lets you access and analyze recent and historical data together, without having to specify its location. It has built-in time-series analytics functions, helping you identify trends and patterns in your data in near real time.

Timestream for LiveAnalytics is designed to collect, store, and process time-series data. Its serverless architecture supports fully decoupled data ingestion, storage, and query processing services that can scale independently, enabling virtually infinite scale for your application’s needs. Rather than predefining the schema at table creation time, a Timestream table’s schema is dynamically created based on the attributes of the incoming time-series data, allowing for flexible and incremental schema definition.

For data storage, Timestream for LiveAnalytics partitions the data by time and attributes, accelerating data access using a purpose-built index. Attributes of your data such as measure name or the chosen partitioning key play a critical role in effectively partitioning and performantly retrieving your data. In addition, Timestream for LiveAnalytics automates data lifecycle management by offering an in-memory store for recent data and magnetic store for historical data and by supporting configurable rules to automatically move data from the memory store to the magnetic store as it reaches a certain age.

Timestream for LiveAnalytics also simplifies data access through its purpose-built adaptive query engine that can seamlessly access and combine data across storage tiers without having to specify the data location, so you can quickly and easily derive insights from your data using SQL. Lastly, Timestream works seamlessly with your preferred data collection, visualization, analytics, and machine learning (ML) services, making it easy for you to include Timestream in your time-series solutions.

Timestream for LiveAnalytics provides 99.99% availability. For more information, refer to the service level agreement (SLA).

With Timestream for LiveAnalytics, you pay only for what you use. You are billed separately for writes, data stored, and data scanned by queries. Timestream automatically scales your writes, storage, and query capacity based on usage. You can set the data retention policy for each table and choose to store data in an in-memory or magnetic store. For detailed pricing, see the pricing page.

Yes, Timestream for LiveAnalytics offers a 1-month free trial for all new accounts. The free trial usage is capped at 50 GB of ingestion, 100 GB of magnetic storage, 750 GB-hours of memory storage, and 750 GB of data scanned.

You are billed at standard Timestream for LiveAnalytics pricing for the usage beyond what the free trial provides. Additional details are on the pricing page.

For current Region availability, see the pricing page.

Timestream for LiveAnalytics offers near real-time latencies for data ingestion. The Timestream for LiveAnalytics built-in memory store is optimized for rapid point-in-time queries, and the magnetic store is optimized to support fast analytical queries. With Timestream for LiveAnalytics, you can run queries that analyze tens of gigabytes of time-series data from the memory store within milliseconds and analytical queries that analyze terabytes of time-series data from the magnetic store within seconds. Scheduled queries further improve query performance by calculating and storing the aggregates, rollups, and other real-time analytics used to power frequently accessed operational dashboards, business reports, applications, and device monitoring systems.

You can store exabytes of data in a single table. As your data grows over time, Timestream for LiveAnalytics uses its distributed architecture and massive amounts of parallelism to process larger volumes of data while keeping query latencies almost unchanged.

Timestream serverless architecture supports fully decoupled data ingestion, storage, and query processing systems that can scale independently. Timestream for LiveAnalytics continuously monitors your application requirements for ingestion, storage, and query rate to instantly scale without any downtime for the application.

For current limits and quotas, see the documentation.

You can collect time-series data from connected devices, IT systems, and industrial equipment and write it into Timestream for LiveAnalytics. You can send data to Timestream for LiveAnalytics either directly from your application using the AWS SDKs or from data collection services such as AWS IoT Core, Amazon Managed Service for Apache Flink, or Telegraf. For more information, see the documentation.

Late arrival data is data that has a timestamp in the past and is outside the retention boundary of the memory store. Future data is data that has a timestamp in the future. Timestream lets you store and access both kinds.

To store late arrival data, you simply write the data into Timestream for LiveAnalytics, and the service will automatically determine whether it gets written to the memory store or to the magnetic store based on the timestamp of the data and the configured data retention period for the memory and magnetic stores. To store data that is beyond 15 minutes into the future, model your data as a multi-measure record and represent the future timestamp as a measure within the record.

Using batch load, you can ingest CSV files stored in Amazon Simple Storage Service (Amazon S3) into Timestream for LiveAnalytics. You can use batch load for backfilling data that is not immediately required for analysis. You can create batch load tasks by using the AWS Management Console, AWS CLI, and AWS SDKs. For more information, see the documentation.

You can collect data from your IoT devices and store that data in Timestream for LiveAnalytics using AWS IoT Core rule actions. For more detailed information, see the documentation.

You can use Apache Flink to transfer your time-series data from Amazon Kinesis directly into Timestream for LiveAnalytics. For more detailed information, see the documentation.

You can use Apache Flink to send your time-series data from Amazon Managed Streaming for Apache Kafka (Amazon MSK) directly into Timestream for LiveAnalytics. For more detailed information, see the documentation.

Timestream organizes and stores time-series data in partitions. The partitioning of data is determined by the service based on the attributes of the data. Attributes such as timestamp and measure_name or customer-defined partition keys play a key role in deciding the partitions. See Werner Vogels’ blog for more details. If you want to optimize your query performance to better fit your specific needs, we recommend using customer-defined partition keys. Using Timestream, you can automate data lifecycle management by simply configuring data retention policies to automatically move data from the memory store to the magnetic store as it reaches the configured age.

Timestream for LiveAnalytics memory store is a write-optimized store that accepts and deduplicates the incoming time-series data. The memory store is also optimized for latency-sensitive point-in-time queries.

Timestream for LiveAnalytics magnetic store is a read-optimized store built for running fast analytics queries that can scan hundreds of terabytes of data. The magnetic store is also optimized for fast analytical queries that scan hundreds of terabytes of data.

You can set the retention period for both memory store and magnetic store. The defaults are 12 hours and 10 years respectively. As the age of the data, determined by the timestamp in the record, exceeds the configured retention period of memory store, Timestream for LiveAnalytics automatically tiers the data into the magnetic store. Similarly, if the age of the data exceeds the configured magnetic store retention period, the service automatically deletes the data.

Timestream for LiveAnalytics ensures durability of your data by automatically replicating your memory and magnetic store data across different Availability Zones within a single Region. All of your data is written to disk before acknowledging your write request as complete.

You can use SQL to query your time-series data stored in Timestream. You can also use time-series analytics functions for interpolation, regression, and smoothing using SQL. For more information, see the documentation. The Timestream adaptive query engine allows you to access the data across storage tiers using a single SQL statement. It transparently accesses and combines data across storage tiers without requiring you to specify the data location. 

Timestream for LiveAnalytics scheduled queries offer a fully managed, serverless, and scalable solution for calculating and storing aggregates, rollups, and other real-time analytics used to power frequently accessed operational dashboards, business reports, applications, and device monitoring systems.

With scheduled queries, you simply define the real-time analytics queries that calculate aggregates, rollups, and other real-time analytics on your incoming data, and Timestream periodically and automatically runs these queries and reliably writes the query results into a separate table. You can then point your dashboards, reports, applications, and monitoring systems to simply query the destination tables instead of querying the considerably larger source tables containing the incoming time-series data. This leads to performance and cost reductions by an order of magnitude because the destination tables contain much less data than the source tables, thereby offering faster and cheaper data access and storage.

You can use JDBC and ODBC drivers to connect Timestream for LiveAnalytics to your preferred business intelligence tools and other applications. See the JDBC and ODBC documentation for additional details.

You can visualize and analyze time-series data in Timestream for LiveAnalytics using Amazon QuickSight and Grafana. You can also use QuickSight for your ML needs.

You can create rich and interactive dashboards for your time-series data using QuickSight. For more information, see the documentation.

You can use Amazon SageMaker notebooks to integrate your ML models with Timestream for LiveAnalytics. For more information, see the documentation.

Data is always encrypted whether at rest or in transit. Timestream for LiveAnalytics allows you to specify an AWS Key Management Service (AWS KMS) customer managed key for encrypting data in the magnetic store.

Timestream for LiveAnalytics is ISO (9001, 27001, 27017, and 27018), PCI DSS, FedRAMP (Moderate), and Health Information Trust (HITRUST) Alliance Common Security Framework (CSF) compliant. It is also HIPAA eligible and in scope for AWS SOC 1, SOC 2, and SOC 3 reports.

You have two backup options available for your Timestream resources: on-demand backups and scheduled backups. On-demand backups are one-time backups that can be initiated either from the Timestream console or AWS Backup. On-demand backups are useful when you want to create a backup prior to making a change to your table that might require you to revert the changes. Scheduled backups are recurring backups that you can configure, using AWS Backup policies, at desired frequencies (such as 12 hours, 1 day, 1 week, and so on). Scheduled backups are useful when you want to create ongoing backups to meet your data protection goals.

The first backup, either on demand or scheduled, of the table is a full backup and every subsequent backup of the same table is incremental, copying only the data that has changed since the last backup. 

Backup and restores are charged based on the backup storage size of the selected table, measured on a GB-month basis. Charges will be shown under Backup in your AWS bill and include costs for backup storage, data transfers, restores, and early deletes. As the backups are incremental in nature, the storage size of the subsequent backup of the table is the size of the amount of the data changed since the last backup. Refer to AWS Backup pricing for additional details.

To get started, you need to enable AWS Backup to protect your Timestream for LiveAnalytics resources (this is a one-time action). Once enabled, navigate to the AWS Management Console or use the AWS Backup CLI or SDK to create on-demand or scheduled backups of your data, and copy those backups across accounts and Regions. You can configure your backup lifecycle management based on your data protection needs. For more information, refer to the creating a backup documentation. 

You can restore your Timestream for LiveAnalytics tables through the AWS Management Console or using the AWS Backup CLI or SDK. Select the recovery point ID for the resource you want to restore, and provide the required inputs such as destination database name, new table name, and retention properties to start the restore process. Upon successful restore, you can access the data. When you attempt to restore the latest incremental backup of your table, the entire table data is restored. For more information, refer to the documentation.

Amazon Timestream for InfluxDB is a new time-series database engine that makes it easy for application developers and DevOps teams to run InfluxDB databases on AWS for real-time time-series applications using open source APIs. With Timestream for InfluxDB, it is easy to set up, operate, and scale time-series workloads that can answer queries with single-digit millisecond query responses.

Timestream for InfluxDB supports the open source 2.7 version of InfluxDB. 

You should use Timestream for InfluxDB if you are self-managing InfluxDB, want to use open source time-series APIs, or are building real-time time-series applications that require single-digit millisecond query responses. With Timestream for InfluxDB, you get the benefit of open source APIs and a wide set of open source Telegraf agents to collect time-series data. You do not need to manage complex and time-consuming tasks, such as InfluxDB installation, upgrades, storage, replication for high availability, and backups.

Timestream for InfluxDB provides an SLA of 99.9% availability when deployed with a Multi-AZ configuration and 99.5% availability for a Single-AZ configuration.

Timestream for InfluxDB is built for near real-time time-series use cases. Depending on the instance configurations and workloads characteristics, you can expect write to read latency of approximately 1 second with query latency of single-digit milliseconds.

To migrate to Timestream for InfluxDB from a self-managed InfluxDB instance, you can simply restore a backup from an existing InfluxDB database into a Timestream for InfluxDB instance with a few minutes of downtime. You can reconfigure your data collection agents, such as open source Telegraf agents, to target the InfluxDB endpoint managed by Timestream for InfluxDB. Dashboarding technologies, such as InfluxDB UI, self-hosted Grafana, or Amazon Managed Grafana, will continue to work by configuring them to use the Timestream for InfluxDB endpoint without any other code changes.

To migrate from Timestream for LiveAnalytics to Timestream for InfluxDB, you can export your data from Timestream for LiveAnalytics to Amazon S3, make any required modifications to the CSV files exported, and load it into Timestream for InfluxDB.

You can think of a DB instance as a database environment in the cloud with the compute and storage resources you specify. You can create and delete DB instances, define and refine infrastructure attributes of your DB instances, and control access and security through the AWS Management Console, Timestream for InfluxDB APIs, and AWS CLI. You can run one or more DB instances and each DB instance can support one or more databases (buckets) or organizations, depending on the workload characteristics and instance configuration.

DB instances are simple to create using either the AWS Management Console, Timestream for InfluxDB APIs, or AWS CLI. To launch a DB instance using the AWS Management Console, choose InfluxDB Databases and then select the Create InfluxDB Database button on the dashboard. From there, you can specify the parameters for your DB instance, including instance type, storage type and amount, primary user credentials, and more.

Alternatively, you can create your DB instance using the CreateDBInstance API or create-db-instance command.

Once your DB instance is available, you can retrieve its endpoint through the DB instance description in the AWS Management Console, GetDBInstance API, or get-db-instance command. Using this endpoint plus your access token, you can use InfluxDB APIs to send writes and read requests as well as manage the engine using your favorite database tool or programming language. You can also access the InfluxDB UI from your browser using that same endpoint. In order to allow network requests to your running DB instance, you will need to authorize access or enable public IP access.

By default, you are allowed to have up to a total of 40 Timestream for InfluxDB instances.

You pay only for what you use and there are no minimum or setup fees. You are billed based on the following:

• DB instance hours: Based on the class (for example, db.influx.large and db.influx.4xlarge) of the DB instance consumed. Partial DB instance hours consumed are billed in 1-second increments with a 10-minute minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class.
• Storage (per GB-month): Storage capacity you have provisioned to your DB instance. If you scale your provisioned storage capacity within the month, your bill will be prorated.
• Data transfer: Internet data transfer in and out of your DB instance.

For Timestream for InfluxDB pricing information, visit the pricing page.

Billing commences for a DB instance as soon as the DB instance is available. Billing continues until the DB instance stops, which would occur upon deletion or in the event of an instance failure.

DB instance hours are billed for each hour your DB instance is running in an available state. If you no longer wish to be charged for your DB instance, you must stop or delete it to avoid being billed for additional instance hours. Partial DB instance hours consumed are billed in 1-second increments with a 10-minute minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class.

While your database instance is stopped, you are charged for provisioned storage but not for DB instance hours.

If you specify that your DB instance should be a Multi-AZ deployment, you will be billed according to the Multi-AZ pricing posted on the Timestream for InfluxDB pricing page. Multi-AZ billing is based on the following:

• Multi-AZ DB instance hours: Based on the class (for example, db.influx.large and db.influx.4xlarge) of the DB instance consumed. As with standard deployments in a single Availability Zone, partial DB instance hours consumed are billed in 1-second increments with a 10-minute minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class. If you convert your DB instance deployment between standard and Multi-AZ within a given hour, you will be charged both applicable rates for that hour.
• Provisioned storage (for Multi-AZ DB instance): If you convert your deployment between standard and Multi-AZ within a given hour, you will be charged the higher of the applicable storage rates for that hour.
• Data transfer: You are not charged for the data transfer incurred in replicating data between your primary and standby. Internet data transfer in and out of your DB instance is charged the same as with a standard deployment.

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and sales tax. For customers with a Japanese billing address, the use of AWS services is subject to Japanese Consumption Tax. 

• Your Timestream for InfluxDB Read Replica cluster bill is calculated per instance within the cluster, according to prices listed on the Timestream for InfluxDB pricing page. The billing structure consists of four main components:
  Cluster node hours are charged based on your selected instance class (such as db.influx.large or db.influx.4xlarge). We bill in 1-second increments with a 10-minute minimum charge following any billable status change, including creation, startup, or instance class modifications. If you convert between cluster types within an hour, you'll be charged for both applicable rates during that period.
• For storage, you'll be billed based on your provisioned capacity. When converting between deployment types (cluster, standard, or Multi-AZ DB) within an hour, we apply the higher of the applicable storage rates for that hour.
• Regarding data transfer, you won't incur charges for data replication between your primary and replica instances. However, internet data transfer in and out of your DB cluster follows the same pricing as standard deployments.
• The Read Replica functionality is provided through a licensed Add-on that is built and sold by InfluxData and will be activated via the AWS Marketplace. This license operates on a pay-as-you-go model, with charges based on your instance hours according the number of vCPUs in your configured instance class.
  

In order to select your initial DB instance class and storage capacity, you will want to assess your application’s compute, memory, and storage needs. For information about the DB instance classes available, refer to the Timestream for InfluxDB User Guide.

Timestream for InfluxDB IOPS Included Storage is an SSD-backed storage option designed to deliver fast, predictable, and consistent I/O performance. With Timestream for InfluxDB IOPS Included Storage, you have three tiers to choose, ranging from small workloads to large-scale, high-performance optimized ones. You only specify the volume size allocated for the tier that better fits your needs. Timestream for InfluxDB IOPS Included Storage is optimized for I/O-intensive, transactional (OLTP) database workloads. For more details, see the Timestream for InfluxDB User Guide.

Choose the storage type that’s most suited for your workload.

• High-performance OLTP workloads: Timestream for InfluxDB IOPS Included Storage.

By default, Timestream for InfluxDB chooses the optimal configuration parameters for your DB instance, taking into account the instance class and storage capacity. However, if you want to change them, you can do so using the AWS Management Console, Timestream for InfluxDB APIs, or AWS CLI. Note that changing configuration parameters from recommended values can have unintended effects, ranging from degraded performance to system crashes, and should only be attempted by advanced users who wish to assume these risks.

At launch, we will provide a limited set of parameters that will be able to be modified by you, and these include: flux-log-enabled, log-level, metrics-disable, no-tasks, query-concurrency, query-queue-size, and tracing-type. This list might grow over time based on customer requirements.

A DB parameter group acts as a container for engine configuration values that can be applied to one or more DB instances. If you create a DB instance without specifying a DB parameter group, a default DB parameter group is used. This default group contains engine defaults and Timestream for InfluxDB system defaults optimized for the DB instance that you’re running.

However, if you want your DB instance to run with your custom-specified engine configuration values, you can simply create a new DB parameter group, modify the desired parameters, and modify the DB instance to use the new DB parameter group. 

When you create or modify your DB instance to run as a Multi-AZ deployment, Timestream for InfluxDB automatically provisions and maintains a synchronous standby replica in a different Availability Zone. Updates to your DB instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure. 

During certain types of planned maintenance, or in the unlikely event of DB instance failure or Availability Zone failure, Timestream for InfluxDB will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB instance remains the same, your application can resume database operation without the need for manual administrative intervention.

With Multi-AZ deployments, replication is transparent. You do not interact directly with the standby, and it cannot be used to serve read traffic.

Availability Zones are distinct locations within a Region that are engineered to be isolated from failures in other Availability Zones. Each Availability Zone runs on its own physically distinct, independent infrastructure and is engineered to be highly reliable. Common points of failures such as generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados, or flooding would only affect a single Availability Zone. Availability Zones within the same Region benefit from low-latency network connectivity.

When you run a DB instance as a Multi-AZ deployment, the primary serves database writes and reads. In addition, Timestream for InfluxDB provisions and maintains a standby behind the scenes, which is an up-to-date replica of the primary. The standby is promoted in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (for example, for read operations) at any point prior to promotion.

The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone.

For example, if a storage volume on your primary fails, Timestream for InfluxDB automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single Availability Zone where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last 5 minutes) would not be available.

You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. The availability benefits of Multi-AZ also extend to planned maintenance. Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. 

You might observe elevated latencies relative to a standard DB instance deployment in a Single Availability Zone as a result of the synchronous data replication performed on your behalf.

No, a Multi-AZ standby cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Our implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations.

In order to create a Multi-AZ DB instance deployment, simply choose the Create a Standby Instance option for Multi-AZ Deployment when launching a DB instance with the AWS Management Console. Alternatively, if you are using the Timestream for InfluxDB APIs, you would call the CreateDBInstance API and set the Multi-AZ parameter to the True value.
You can also modify one of your existing instances and set the Deployment type to Multi-AZ.

Timestream for InfluxDB detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible without administrative intervention. Timestream for InfluxDB automatically performs a failover in the event of any of the following:

• Loss of availability in primary Availability Zone
• Loss of network connectivity to primary
• Compute unit failure on primary
• Storage failure on primary

Note: Timestream for InfluxDB Multi-AZ deployments do not fail over automatically in response to database operations, such as long running queries, deadlocks, or database corruption errors.

Failover is automatically handled by Timestream for InfluxDB so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Timestream for InfluxDB simply flips the canonical name (CNAME) record for your DB instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer.

Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within a couple of minutes. Failover time can also be affected by whether large, uncommitted transactions must be recovered, the size of the index, and other factors. The use of adequately large instance types is recommended with Multi-AZ for best results. AWS also recommends the use of Timestream for InfluxDB IOPS Included Storage with Multi-AZ instances for fast, predictable, and consistent throughput performance.

Timestream for InfluxDB will automatically failover without user intervention under a variety of failure conditions. At this time, you cannot manually initiate a forced failover of your Timestream for InfluxDB DB instance.

With Multi-AZ deployments, you simply set the Multi-AZ parameter to True. The creation of the standby, synchronous replication, and failover are all handled automatically. This means you cannot select the Availability Zone your standby is deployed in or alter the number of standbys available (Timestream for InfluxDB provisions one dedicated standby per DB instance primary). The standby also cannot be configured to accept database read activity.

Yes, your standby is automatically provisioned in a different Availability Zone of the same Region as your DB instance primary.

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or GetDBInstance API.

Availability Zones are engineered to provide low-latency network connectivity to other Availability Zones in the same Region. In addition, you might want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure. Multi-AZ deployments address this need for the database tier without administration on your part.

A Timestream for InfluxDB Read Replica cluster provides enhanced availability and read scalability for your database. When you create a cluster, Timestream for InfluxDB automatically provisions and maintains at least one asynchronous readable replica in a different Availability Zone. Your primary node's updates are asynchronously replicated to these Read Replicas, allowing you to distribute your query workload across multiple nodes.

The cluster supports automatic failover during planned maintenance or in the unlikely event of a node or Availability Zone failure. When failover occurs, your applications can continue operating without manual intervention since the writer and reader endpoints maintain the same name records. However, it's important to note that during the recovery period, while we restore the failed node and reinstate it as a Read Replica, applications using the replica node endpoints for reading will temporarily be unavailable.

In a Read Replica cluster, the primary node handles all database writes, reads, and manages engine-specific configurations and administrative functions. Alongside this, Timestream for InfluxDB automatically provisions and maintains a Read Replica that stays up-to-date with the primary node. The Read Replica serves two key purposes: it extends your read capacity by accepting additional read requests, and it can be promoted to primary during failover scenarios. During a failover event, when the Read Replica is promoted to primary, it takes over all database operations. Once the previously failed node becomes operational again, it rejoins the cluster as a Read Replica, maintaining the cluster's resilience.

Read Replica clusters offer three key advantages: enhanced scalability, improved availability, and workload optimization. The increased scalability comes from your ability to distribute read workloads across multiple cluster nodes, making it particularly valuable for applications where read requirements significantly outweigh write operations.

When configured with failover enabled, Read Replica clusters provide higher availability through faster failover capabilities. Since all nodes in the cluster remain active, you can promote a replica to primary without waiting for node startup, minimizing downtime during failover scenarios.

Additionally, Read Replica clusters enable efficient workload management. You can dedicate your primary node to handle simple, fast queries typically used for real-time dashboards, alarms, and notifications, while directing more complex analytical queries to your Read Replicas. This separation ensures optimal performance for different types of workloads.

The replicator process has demonstrated negligible performance impact, with minimal effect on CPU or memory consumption. However, it's important to note that replication lag—the time between when a record is accepted on the primary and when it becomes available in the Read Replicas—may vary depending on the load level of your replica nodes.

Timestream for InfluxDB publishes a CloudWatch metric called "ReplicaLag" that helps you monitor the synchronization state of your Read Replicas. This metric, measured in milliseconds, tracks how far behind the replicas are from the primary node. Replication latency can be affected by your database load levels, so we recommend customers actively monitor this metric to ensure their Read Replicas maintain acceptable synchronization levels for their use case.

To set up a Read Replica cluster in Timestream for InfluxDB, start by signing into the AWS Management Console and navigating to the Amazon Timestream console. Choose "Create InfluxDB database" from the InfluxDB Databases section. When configuring Deployment Settings, select "DB Cluster with Read Replicas." You'll need to activate a subscription through the AWS Marketplace, which requires either AWSMarketplaceManageSubscriptions or AWSMarketplaceFullAccess permissions. After confirming your subscription, provide basic configuration details, and select appropriate node and storage classes that will apply to all nodes in your cluster.

No, in a Read Replica cluster, there can only be one primary node that handles write operations at any given time. The primary node serves all write requests while also managing database reads, engine-specific configurations, and administrative functions. Read Replicas are kept up-to-date with this primary node and can only accept read requests. While you can promote a Read Replica to become the primary during failover scenarios, the cluster architecture maintains a single-writer model to ensure data consistency.

For Read Replica clusters, you can enable or disable the failover feature during cluster creation or modification. When enabled, the management of replicas, replication, and failover processes are handled automatically by Timestream for InfluxDB. You cannot select specific Availability Zones for your replicas, and Timestream for InfluxDB maintains at least one Read Replica per cluster. Read Replicas actively accept read requests to help distribute your workload.

Timestream for InfluxDB detects and automatically recovers from common failure scenarios in Read Replica cluster deployments, allowing you to resume database operations quickly without administrative intervention. The system automatically performs a failover to a Read Replica in the event of any of the following:

• Loss of availability in the primary node's Availability Zone
• Loss of network connectivity to the primary node
• Compute unit failure on the primary node
• Storage failure on the primary node

Note: Timestream for InfluxDB Read Replica clusters do not fail over automatically in response to database operations, such as long running queries, deadlocks, or database corruption errors. Remember that automatic failover will only occur if you have specifically enabled this feature for your Read Replica cluster during setup or through cluster modification.

Failover in a Read Replica cluster is automatically handled by Timestream for InfluxDB when the feature is enabled, allowing database operations to resume quickly without administrative intervention. During failover, Timestream for InfluxDB updates the canonical name (CNAME) record of your database to point to the Read Replica, which is then promoted to become the new primary. We recommend implementing database connection retry logic in your application layer as a best practice.

Due to the fact that nodes in a Read Replica cluster are active, failover time will be stable regardless of the workload characteristics. Typically, failovers complete within a few minutes, measured from the detection of primary failure to the resumption of transactions on the promoted replica. For optimal performance, we recommend using adequately sized node types and Timestream for InfluxDB IOPS Included Storage.

When failover is enabled, Timestream for InfluxDB will automatically handle failover under various failure conditions. Currently, manual initiation of forced failover is not supported for Timestream for InfluxDB Read Replica clusters.

Yes, your Read Replica is automatically provisioned in a different Availability Zone of the same Region as your primary node.

Yes, you can view the location of both your primary and Read Replica nodes through the AWS Management Console or by using the GetDBInstance API.

Availability Zones are engineered to provide low-latency network connectivity to other Availability Zones in the same Region, so latency impact should be minimal. However, we recommend architecting your application and other AWS resources with redundancy across multiple Availability Zones for maximum resilience. Read Replica clusters support this architecture naturally, as you can distribute your read workloads across nodes in different Availability Zones, and when failover is enabled, your application can continue operating even if an Availability Zone becomes unavailable.