Kinesis.3: Kinesis streams should have adequate retention

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub Kinesis.3 check?

Kinesis.3 fails when a data stream's retention period is below the control's minimumBackupRetentionPeriod parameter, which defaults to 168 hours. The control reads the stream's RetentionPeriodHours against that threshold; the stream default of 24 hours falls short.

Why does Kinesis.3 matter?

Retention is your replay window. With it left at the 24-hour default, a consumer bug that silently drops records over a weekend can age the lost data out before anyone notices on Monday, leaving nothing to reprocess. A longer retention period (168 hours or more) gives you room to detect a problem and replay the affected records rather than losing them permanently.

How do I fix Kinesis.3?

Audit retention across streams to find those below the required period.
Raise retention with increase-stream-retention-period to 168 hours or your chosen floor.
Account for the added storage billing that longer retention incurs.
Set the retention period explicitly when provisioning new streams rather than relying on the 24-hour default.

Remediation script · bash

# Set a 7-day backup floor on production databases below it (skip read replicas).
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?ReadReplicaSourceDBInstanceIdentifier==`null` && BackupRetentionPeriod<`7`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --backup-retention-period 7 --no-apply-immediately
done

# Turn on DynamoDB point-in-time recovery (instant, no downtime).
aws dynamodb update-continuous-backups --table-name prod-orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Stop any snapshot in the account from being shared publicly, ever.
aws ec2 enable-snapshot-block-public-access --state block-all-sharing

Full walkthrough (console steps, edge cases and verification) in the lesson Configure backups and retention.

Is Kinesis.3 a false positive?

A stream feeding a real-time consumer that commits offsets within seconds (clickstream into a Lambda, telemetry into an analytics pipeline) has no replay requirement, and the 24-hour default is a deliberate cost choice rather than an oversight; extended retention is billed per shard-hour, so 168 hours on a high-throughput stream is real money for data nobody will ever re-read. The 168-hour default is just the control's parameter, not a Kinesis requirement. Where a shorter window is intentional, either set minimumBackupRetentionPeriod to your actual floor (the rule accepts 24 to 8760) so the threshold matches your design, or record a suppression with the business justification rather than paying to inflate retention you won't use.

Full lesson Configure backups and retention Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for Kinesis controls ↗ Check your own account for Kinesis.3 →

Part of the learning path Lock down access

Kinesis.1 Kinesis streams should be encrypted at rest