Amazon Timestream FAQs

What is time-series data?

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.

Which engines does Amazon Timestream support?

Amazon Timestream offers fully managed InfluxDB, one of the most popular open source time-series databases in the market

How do I get started with Timestream?

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

Do I need to define a schema before sending data to Timestream?

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.

How do I access my Timestream databases?

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).

How do I use Timestream with Grafana?

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.

How can I send data to Timestream using Amazon Lambda?

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

How can I send data to Timestream using open source Telegraf?

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.

Can I use Timestream in an Amazon VPC?

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.

Can I use Timestream through Amazon CloudFormation?

Amazon 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.

What is Amazon Timestream for InfluxDB?

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 Amazon Web Services Cloud 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.

What versions of InfluxDB are supported?

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

Why should I use Timestream for 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.

What kind of SLAs can I expect from Timestream for InfluxDB?

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.

What performance can I expect from Timestream for InfluxDB?

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.

How do I migrate workloads to Timestream for InfluxDB?

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.

What is a database (DB) instance?

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 Amazon Web Services Management Console, Timestream for InfluxDB APIs, and Amazon 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.

How do I create a DB instance?

DB instances are simple to create using either the Amazon Web Services Management Console, Timestream for InfluxDB APIs, or Amazon CLI. To launch a DB instance using the Amazon Web Services 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.

How do I access my running DB instance?

Once your DB instance is available, you can retrieve its endpoint through the DB instance description in the Amazon Web Services 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.

How many DB instances can I run with Timestream for InfluxDB?

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

How will I be charged and billed for my use of Timestream for InfluxDB?

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.

When does billing of my Timestream for InfluxDB DB instances begin and end?

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.

What defines billable Timestream for InfluxDB instance hours?

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.

How will I be billed for a stopped DB instance?

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

How will I be billed for Multi-AZ DB instance deployments?

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.

Do your prices include taxes?

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 Amazon Web Services services is subject to Japanese Consumption Tax. 

How do I determine which initial DB instance class and storage capacity are appropriate for my needs?

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.

What is Timestream for InfluxDB IOPS Included Storage?

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.

How do I choose among the Timestream for InfluxDB storage types?

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

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

How do I choose the right configuration parameters for my DB instances?

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 Amazon Web Services Management Console, Timestream for InfluxDB APIs, or Amazon 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.

What are DB parameter groups? How are they helpful?

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. 

What does it mean to run a DB instance as a Multi-AZ deployment?

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.

What is an Availability Zone?

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.

What do “primary” and “standby” mean in the context of a Multi-AZ deployment?

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.

What are the benefits of a Multi-AZ deployment?

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. 

Are there any performance implications of running my DB instance as a Multi-AZ deployment?

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.

When running my DB instance as a Multi-AZ deployment, can I use the standby for read or write operations?

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.

How do I set up a Multi-AZ DB instance deployment?

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 Amazon Web Services 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.

At this time, you will not be able to convert an existing Single-AZ Timestream for InfluxDB DB instance to Multi-AZ. The only way to achieve this would be to create a new Multi-AZ DB instance and migrate your workload to it.

What events would cause Timestream for InfluxDB to initiate a failover to the standby replica?

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.

What happens during Multi-AZ failover and how long does it take?

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 ideal results. We also recommend the use of Timestream for InfluxDB IOPS Included Storage with Multi-AZ instances for fast, predictable, and consistent throughput performance.

Can I initiate a forced failover for my Multi-AZ DB instance deployment?

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.

How do I control and configure Multi-AZ synchronous replication?

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.

Will my standby be in the same Region as my primary?

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

Can I see which Availability Zone my primary is currently located in?

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

After failover, my primary is now located in a different Availability Zone than my other Amazon Web Services resources (such as EC2 instances). Should I be concerned about latency?

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 Amazon Web Services 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.