Kinesis.3: Kinesis streams should have adequate retention

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?

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

# 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