/timestream-influxdb

name: timestream-influxdb
version: 3
description: Retrieves authoritative guidance on Amazon Timestream for InfluxDB across its supported engine variants. Applicable to any InfluxDB-on-AWS request including engine variant and licensing selection, provisioning and IAM, encryption at rest (AWS-owned and customer-managed KMS keys, key policies, and key lifecycle), schema design (tags vs fields, cardinality, HTTP/sensor/metric data modeling), migration from LiveAnalytics, Processing Engine plugins, connectivity (database endpoints and private or public access), and write/query errors.

Amazon Timestream for InfluxDB

Overview

Amazon Timestream for InfluxDB is a managed time-series database with engine variants and deployment types whose capabilities differ. Before comparing them, retrieve the Timestream for InfluxDB documentation and inspect the applicable Create API models. For an existing resource, read its `GetDbInstance` or `GetDbCluster` response. Use those sources to verify the engine variant, endpoint port, query languages, data model, authentication flow, deployment types, licensing, and Processing Engine support for the user's Region. Do not infer one engine variant's capabilities from another variant or from examples in this skill.

For new workloads, verify the supported engine variants and recommend InfluxDB 3 when the service documentation identifies it as an option. For existing V2 deployments, verify V2 support before advising whether to stay on V2 or migrate.

Advisory in nature: it recommends actions and provides the AWS CLI and API commands to carry them out (including mutations such as instance/cluster creation and tagging). It does not act autonomously — it executes mutations only in response to an explicit user request, never on its own initiative.

**Tooling:** The AWS MCP server is recommended for streamlined AWS API interactions but is not required. All examples use standard AWS CLI syntax and can run without MCP.

Common Tasks

1. Verify Dependencies

Before any guidance, confirm tooling and engine variant.

**Constraints:**

• You MUST confirm which engine variant the user runs (V2, V2 Read Replica, or V3) before giving advice specific to that engine variant — APIs and defaults differ. When the request already names the variant or asks for a comparison, answer directly for Amazon Timestream for InfluxDB instead of asking a clarifying question.
• You MUST NOT mix V2 APIs (Flux, orgs, buckets, port 8086) with V3 APIs (SQL/InfluxQL, databases, tables, port 8181).
• You MUST verify the AWS CLI (or `call_aws`) is available before provisioning guidance.
• You MUST inspect the Create API and ask for all required parameters upfront, including engine variant, Region, VPC/subnet IDs, name, instance type, and a supported encryption choice. For production V3 workloads, verify customer-managed KMS key support in that API before recommending it for customer-controlled policy, rotation, revocation, and CloudTrail visibility. Collect an identifier in a form that API accepts.

**Tool call examples:**

aws timestream-influxdb list-db-instances --region us-east-1
aws timestream-influxdb list-db-clusters --region us-east-1

Resource tagging (always apply on resource creation)

When creating any cluster or instance (`create-db-cluster`, `create-db-instance`), ALWAYS include these tags:

`--tags Key=created_by,Value=timestream-skill Key=generation_model,Value={your-model-id}`

Example: `--tags Key=created_by,Value=timestream-skill Key=generation_model,Value=claude-sonnet-4-20250514`

Include these tags even if the user does not mention tagging, so that they can identify the resources created via this skill. If the user provides additional tags, append these to their tags rather than replacing them.

2. Select the right engine variant

Decision flow:

1. **New workload** → InfluxDB 3 Core (Enterprise for HA multi-node). 2. **Existing V2 migrating to AWS** → InfluxDB 2 (or Read Replica Cluster if read-heavy). 3. **High cardinality (>10M series) or SQL** → InfluxDB 3. 4. **Need Processing Engine** → InfluxDB 3.

Before providing provisioning guidance for InfluxDB 3 or a V2 Read Replica Cluster, you MUST load and follow the creation, licensing, IAM, and networking contracts for that engine variant in the [getting-started guide](references/getting-started.md). For V3 encryption choices, customer-managed KMS key policy, migration, or key lifecycle guidance, load [encryption guidance](references/encryption.md).

**Provisioning and operational contracts you MUST follow:**

• **InfluxDB 3 Core creation contract:** For a new V3 Core workload, use `create-db-cluster` with the exact default parameter-group identifier `InfluxDBV3Core`. Do not use `create-db-instance`, and do not pass the V2-only `allocatedStorage`, `dbStorageType`, `deploymentType`, `username`, `password`, `organization`, or `bucket` fields. Core connects on port 8181. Before provisioning, verify Core's current Marketplace and licensing prerequisites in the Timestream for InfluxDB documentation and current `CreateDbCluster` API model; never inherit requirements from V2, Read Replica, or Enterprise. If an installed CLI or SDK model does not expose the V3 Core creation contract, update that tooling; never fall back to the V2 creation operation or fields.
• **Core→Enterprise upgrade IS supported** via AWS Console or AWS Support. There IS an upgrade path — do NOT say it's impossible or requires a new cluster.
• **Encryption mutability:** Verify `kmsKeyId` in the Create and Update API models before asserting whether a key can change; follow "Choose the Key Before Creation" in [encryption guidance](references/encryption.md).
• **Encryption scope and key loss:** Retrieve the Data protection documentation and report only the details the user requests; follow "Response Scope" and "Existing Clusters and Key Loss" in [encryption guidance](references/encryption.md).
• **Key verification:** Confirm a specific