Before Marketplace activation, verify the selected engine variant’s permissions in the AWS managed policies for Timestream for InfluxDB documentation and the IAM policy versions. Attach only policies the documentation requires. If it requires or for activation, remove them immediately afterward and replace them with a scoped custom policy.
For existing resources, read publiclyAccessible from GetDbInstance or GetDbCluster. Before creation or update, inspect the API model before asserting public-access availability or mutability. Prefer private placement when the service supports it unless public access is explicitly required.
For existing resources, use the port returned by GetDbInstance or GetDbCluster; before creation, verify the Create API or SDK model. Restrict security-group ingress for that port to known CIDR ranges or security-group IDs. Never use 0.0.0.0/0.
For private resources, choose a remote-access path supported by the Timestream for InfluxDB and VPC documentation.
For a directly accessible public endpoint, treat security-group restrictions as the minimum network control, not as rate limiting. Allow only trusted client CIDRs, and enforce request-rate and concurrency limits in each calling application or an approved reverse proxy before traffic reaches InfluxDB.
Callers MUST validate line-protocol writes before submission: reject malformed records, enforce expected measurement, tag, and field names and types, bound payload and batch sizes, and reject or normalize unbounded tag values that could cause cardinality exhaustion.
Before recommending a load balancer or AWS WAF, verify the Timestream connectivity options and AWS WAF supported-resource matrix (opens in a new tab). Use WAF only through a supported integration; do not present it as direct protection for the native endpoint unless the matrix explicitly lists that resource.
Before configuring browser response headers, verify the Elastic Load Balancing or CloudFront capability. When supported, emit Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, and a restrictive Content-Security-Policy; choose values compatible with the InfluxDB UI and authorized embedding, and test API clients before deployment.
You MUST require encryption at rest and in transit for every deployment. Verify the service-applied at-rest encryption behavior and supported key choices in the Data protection documentation (opens in a new tab) and the Create and Update API models, including whether and when kmsKeyId is accepted. For production workloads, prefer a customer-managed KMS key when the API supports it and the workload requires customer-controlled policy, rotation, revocation, or CloudTrail visibility.
Before configuring S3 log-delivery encryption, verify the bucket account and Region constraints and supported KMS key ownership arrangements in the log-delivery documentation.
Enable SSE-KMS on Amazon SNS topics used for alarm notifications and on CloudWatch Logs log groups receiving operational data. Confirm that every SNS topic subscription delivers only to authorized security or operations personnel, and periodically audit subscriptions to prevent unauthorized recipients from receiving sensitive alarm data.
Verify the log-delivery service principal, object prefix, bucket ownership constraints, and supported source-condition keys before writing the bucket policy. Use aws:SourceArn and aws:SourceAccount when the documentation prescribes them.
Verify log and data-bucket ownership in the service documentation, and apply a customer bucket policy only to buckets the customer manages.
Encrypt CloudTrail log files in the associated S3 delivery bucket with SSE-KMS, and enable CloudTrail log file validation to detect modification or deletion.
Verify data-plane, /metrics, and native audit-log availability for the selected engine, and state only the coverage the observability documentation confirms.