Timestream Influxdb

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 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. For V3 encryption choices, customer-managed KMS key policy, migration, or key lifecycle guidance, load encryption guidance.

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.
• 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.
• Key verification: Confirm a specific customer-managed KMS key only by matching the returned ARN to the requested key ARN. Interpret an absent kmsKeyId only when the current GetDbCluster response documentation explicitly defines its semantics; never use absence to identify a specific customer-managed KMS key. Follow "Verify the Key" in encryption guidance.
• Creation completion: After create-db-cluster returns, poll get-db-cluster until it reports AVAILABLE or a terminal failure. Do not report creation complete or ask the user to take over polling while the cluster remains CREATING. For a customer-managed key request, success also requires the returned kmsKeyId ARN to match the requested key ARN; an absent value while the cluster is transitioning is unverified and MUST be checked again at AVAILABLE.
• Retrieve the V3 initial-token secret by ARN: Inspect the GetDbCluster output or API reference for the token-secret ARN field, then pass the returned ARN to AWS Secrets Manager. Never derive the secret identifier from a naming convention. V3 uses Authorization: Bearer <token> (NOT Token). V2 uses Authorization: Token <token>.
• reboot-db-cluster supports --instance-ids for targeting specific nodes. Before using it, verify the current maximum number of IDs and all request constraints in the RebootDbCluster API model and Timestream for InfluxDB documentation. Do NOT say no reboot command exists or assume a fixed node-count limit.
• Before asserting S3 log-delivery availability or configuration paths, verify the create and update API request parameters and the Timestream for InfluxDB log-delivery documentation. Use only the operations, service principal, and bucket-policy requirements those sources document.
• Do NOT invent CloudWatch metric names. Load monitoring operations and metric discovery, then verify availability for the selected engine variant and deployment type. If unsure whether a metric exists, say so explicitly.
• Before asserting backup or restore availability, verify the Timestream for InfluxDB CLI or SDK API model and the customer-managed backup and restore documentation. Confirm support by engine variant and Region for on-demand, scheduled, continuous, point-in-time, and self-service restore capabilities. Use DbBackup terminology for DbBackup resources, never "snapshot," and separately verify the accessibility and recovery path for service-managed snapshots.
• --publicly-accessible is a supported option at instance/cluster creation time. Do NOT say the service is exclusively VPC-only — public access is an opt-in feature.