Timestream for InfluxDB customer managed keys shipped 20 August 2026 with no API or CLI reference

Summary. AWS announced customer managed key support for Amazon Timestream for InfluxDB on 20 August 2026 at 20:00 GMT. The choice is permanent: "Customers specify the key during resource creation. The key cannot be changed after the resource is created." There is no extra Timestream charge, only standard AWS KMS pricing of $1 per key per month, plus $1 per month for each of the first two key rotations and $0.03 per 10,000 requests beyond a 20,000-request monthly free tier. Two problems sit underneath that announcement. The kmsKeyId parameter it tells you to use appears in none of the six AWS API and CLI reference pages we checked. And the announcement covers InfluxDB 3 clusters while the developer guide explains the feature purely as Amazon EBS volume encryption, even though InfluxDB 3 keeps its data in Amazon S3.

What AWS actually announced

The What's New entry, carried verbatim in the AWS What's New feed with a pubDate of Thu, 20 Aug 2026, says the feature covers "InfluxDB 2 database instances, InfluxDB 2 Read Replicas, and InfluxDB 3 clusters." It requires a symmetric KMS key in the same account and Region as the database. It is available "in all AWS Regions where Timestream for InfluxDB is available," which the AWS service endpoints page enumerates as 20 commercial endpoints including ap-south-1, and with no AWS GovCloud endpoint for InfluxDB at all.

Encryption itself was never optional. The existing encryption-at-rest page states that "Encryption is turned on by default on your Timestream for InfluxDB DB instance, and cannot be turned off. The industry standard AES-256 encryption algorithm is the default encryption algorithm used." What changed on 20 August is custody of the key, which is the only part a compliance team cares about.

The parameter that exists in the guide and nowhere else

The developer guide is explicit: "To create a DB instance with a customer managed key, specify the --kms-key-id parameter with the ARN of your AWS KMS key." It then tells you the read path: "The response includes the kmsKeyId field if a customer managed key was specified during creation."

Neither string appears in the reference documentation.

The complete CreateDbInstance request syntax lists 17 members: allocatedStorage, bucket, dbInstanceType, dbParameterGroupIdentifier, dbStorageType, deploymentType, logDeliveryConfiguration, name, networkType, organization, password, port, publiclyAccessible, tags, username, vpcSecurityGroupIds and vpcSubnetIds. The API reference is still stamped API Version 2023-01-27.

The obvious defence is that these pages are simply stale snapshots. They are not. The same CLI create-db-instance page carries --maintenance-schedule, and get-db-instance returns maintenanceSchedule, lastMaintenanceTime and nextMaintenanceTime from the April 2026 customer-defined maintenance window release. The reference is current enough for an April launch and silent on an August one. If you build infrastructure from the API contract rather than from a prose guide, and most teams with a Terraform or CDK pipeline do, the feature is undiscoverable.

Getting the key wrong once is a migration, not a setting change

The guide states the constraint twice. "You can only specify a customer managed key during resource creation. You cannot change the encryption key after an instance or cluster has been created," and in its limitations list, "Customer managed keys can only be specified during resource creation, not updated afterward."

There is no documented path back to an AWS owned key. The only remedy AWS publishes is a full data move: create a new instance with --kms-key-id, "Migrate data from the existing database to the new database using the influx backup and influx restore CLI commands," repoint your application, then delete the old database. For a time-series estate that is measured in terabytes, that is a planned outage, not an afternoon.

The blast radius of losing key access is equally blunt. "If you disable or delete a customer managed key, or revoke the grants, Amazon Timestream for InfluxDB loses access to the encrypted data," after which "The database instance or cluster becomes unavailable. Read and write operations fail. The database remains in a degraded state until key access is restored." Re-enabling the key recovers the instance automatically. Scheduling the key for deletion does not: "If you permanently delete a customer managed key (after the AWS KMS waiting period), the encrypted data is permanently unrecoverable."

Backups inherit the same fate. "Service-managed backups (Amazon EBS snapshots) are encrypted with the same customer managed key. If the key is deleted, backups cannot be restored." Your restore path is only as durable as your key policy, which is a different team's IAM change away from breaking.

One carve-out is worth reading twice before you write it into a control narrative: "Root volumes (operating system) are not encrypted with the customer managed key, they continue to use service-managed encryption."

The InfluxDB 3 gap

Every mechanism sentence in the CMK guide describes EBS. "Amazon Timestream for InfluxDB uses your key to encrypt the Amazon EBS volumes that store your database data." The CloudTrail table repeats it three more times, attributing CreateGrant, GenerateDataKeyWithoutPlaintext and Decrypt to Amazon EBS operations. The page slug is influxdb2-cmk-encryption. Both CLI examples are labelled InfluxDB 2. The migration procedure prescribes influx backup and influx restore, InfluxDB 2 era commands.

InfluxDB 3 does not store data on EBS. The InfluxDB 3 documentation says "InfluxDB 3 clusters use a single storage class called InfluxDB Object Storage, which is built on Amazon S3," and "Unlike traditional database architectures where storage is directly attached to compute nodes, InfluxDB 3's object storage is shared across all nodes in the cluster." It sells that design against EBS directly, claiming "up to 75% cost savings compared to traditional EBS-based solutions" above 16TB. The Timestream pricing page repeats it: "InfluxDB 3 uses S3-based object storage that is shared across all nodes in your cluster."

So the announcement promises InfluxDB 3 cluster coverage and the guide explains a mechanism InfluxDB 3 does not use. What the key encrypts on an InfluxDB 3 cluster, the S3 objects, the Parquet files, any node-local cache, is documented nowhere we could find. For a buyer who is purchasing CMK specifically to answer a key-custody question in an audit, that undocumented boundary is the entire product.

A third seam runs alongside it. CreateDbCluster accepts exactly one deploymentType, "Valid Values: MULTI_NODE_READ_REPLICAS," which is the InfluxDB 2 read-replica topology, and its instance-class list stops at db.influx.24xlarge. Yet the same page documents port as "Default: 8086 for InfluxDB v2, 8181 for InfluxDB v3." The API is half aware of InfluxDB 3.

What this costs

AWS is straightforward that the feature itself is free: "There is no additional Amazon Timestream for InfluxDB charge for using customer managed keys. Standard AWS KMS pricing applies for your key and the API calls made by the service." The Timestream pricing page, updated the same day at 2026-08-20T11:27:38 Pacific, does not mention KMS at all, even though both the announcement and the guide link to it for pricing detail.

The AWS KMS pricing page renders its request rate table in JavaScript, so the $0.03 per 10,000 figure is quoted here as it appears inside AWS's own worked arithmetic ("1,990,000 requests ... x $0.03 / 10,000 requests"), not as a rate-card line. Because the guide attributes Decrypt calls to EBS volume reads rather than per-query operations, the realistic monthly cost of a Timestream CMK is close to the $1 key charge, rising to $2 once you have rotated twice. AWS publishes no Timestream-specific KMS call volume, so treat any number beyond the key charge as unmodelled.

Two more contradictions worth logging

Multi-Region keys are listed as "Supported (the primary or replica key must be in the same Region as the database)" in the key requirements, then the limitations section two hundred words later says flatly "The AWS KMS key must be in the same AWS Region and account as the database." The What's New post takes the restrictive reading and never mentions multi-Region key support, which is the property a cross-Region DR design depends on.

Separately, the backup and restore launch dated 7 August 2026 already promised CMK behaviour thirteen days before CMK was announced: "If the source resource uses a Customer Managed key (KMS), its backups use the same key." Neither page says whether restoring that backup into a new resource lets you select a different key. Given that the CMK guide's own migration procedure routes you through influx backup and influx restore instead of the native backup system, the reasonable reading is that native restore cannot re-key. AWS does not say so.

What to do this week

Do not enable CMK on anything you cannot afford to rebuild. Decide the key before the instance exists, because the instance is the only place the decision can be made.

If your provisioning runs through Terraform, CloudFormation or the CDK, check whether your provider version exposes a KMS argument for aws_timestreaminfluxdb_db_instance before you plan the work. The absence of kmsKeyId from the API reference and the CLI synopsis means the parameter may be live on the wire while the tooling that reads AWS's own model files has not caught up.

Write the key policy before the key. The grant conditions the guide specifies are narrow: kms:CreateGrant scoped with "kms:ViaService": "timestream-influxdb.region.amazonaws.com" and "kms:GrantIsForAWSResource": "true", plus a kms:DescribeKey statement. Put the key in a separate account's deletion-protection regime if your organisation allows it, and make the key's deletion alarm route to the same on-call rotation as the database.

If you run InfluxDB 3, ask your AWS account team in writing what the key covers in object storage, and keep the answer. The public documentation does not contain it.

This is the same failure pattern we documented in the CloudFront OAC and S3 Multi-Region Access Point signing conflict and in the AWS Cost Anomaly Detection coverage of third-party Bedrock models: a launch post and a developer guide ship on time, and the reference material that automation actually reads lags behind. Teams running a formal cloud FinOps and cost governance practice tend to catch it, because the KMS key charge appears on the bill whether or not the parameter appears in the docs.

India-specific considerations

Timestream for InfluxDB is available at the ap-south-1 endpoint, so an Indian deployment can hold both the key and the data in Mumbai. That matters for organisations building a case under the Digital Personal Data Protection Act 2023, where the ability to name the custodian of the encryption key is part of the reasonable security safeguards story. Two caveats apply. The key must sit in the same Region as the database, so a Mumbai instance cannot be backed by a key held elsewhere for central control. And because root volumes stay on service-managed encryption, any control narrative that claims customer-held keys cover the whole instance would be inaccurate.

FAQ

How eCorpIT can help

eCorpIT is an ISO 27001:2022 certified and CMMI Level 5 assessed engineering organisation in Gurugram, and our senior engineering teams design AWS data platforms where key custody, backup restorability and cost are decided together rather than discovered on an invoice. We can review your Timestream, RDS and S3 encryption posture against what AWS actually documents, and build the provisioning path so an immutable choice like this one is made deliberately. Talk to us via /contact-us/.

References

1. AWS What's New feed, "Amazon Timestream for InfluxDB now supports customer managed keys", pubDate Thu, 20 Aug 2026

1. Amazon Timestream Developer Guide, customer managed key encryption for InfluxDB

1. Amazon Timestream Developer Guide, encryption at rest for Timestream for InfluxDB

1. Amazon Timestream Developer Guide, InfluxDB 3 clusters and object storage

1. Timestream for InfluxDB API Reference, CreateDbInstance

1. Timestream for InfluxDB API Reference, CreateDbCluster

1. Timestream for InfluxDB API Reference, UpdateDbInstance

1. AWS CLI reference, timestream-influxdb create-db-instance

1. AWS CLI reference, timestream-influxdb get-db-instance

1. Amazon Timestream pricing

1. AWS Key Management Service pricing

1. AWS service endpoints and quotas, Amazon Timestream

Last updated: 21 August 2026.