Skill detail
timestream-influxdb
Guides Amazon Timestream for InfluxDB engine selection, provisioning, schema design, and migration for time-series workloads. Relevant storage-layer skill for data engineers handling time-series data.
Needs (stated): MCP server
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
---
name: timestream-influxdb
version: 2
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.
- 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 Read the full source on GitHub (opens external page)