|

Kinesis Data Firehose – Consider Making Delivery Streams Encrypted at Rest

Kinesis Data Firehose delivery streams should be configured with server-side encryption (SSE) to protect sensitive data in transit to its destination. Without encryption at rest, data such as logs, metrics, and transactions is stored in plaintext, creating a compliance and security risk.

This FinOps policy applies to any organization using Kinesis Data Firehose to deliver data to Amazon S3, Redshift, OpenSearch, or other targets—particularly in regulated industries or environments handling personally identifiable information (PII).

Why This Policy Matters

Kinesis Data Firehose is commonly used to stream high-volume, sensitive data. That data often includes application logs, financial transactions, clickstream events, and system metrics. If the delivery stream is not encrypted at rest, that data is exposed in plaintext at the storage layer.

Unencrypted streams fail common compliance requirements, including PCI DSS, HIPAA, SOC 2, and GDPR. Violations can result in audit failures, financial penalties, and reputational damage.

How It Helps Reduce Cloud Costs

Encryption at rest does not directly reduce compute or storage costs. However, the cost of not encrypting can be significant:

  • Compliance penalties can reach tens of thousands of dollars per violation.
  • Security incident remediation typically costs far more than proactive controls.
  • Failed audits delay product delivery and create unplanned engineering work.

Enforcing this policy through Infrastructure-as-Code (IaC) prevents costly remediation cycles after the fact.

Potential Savings

A single HIPAA violation can result in fines ranging from $100 to $50,000 per violation, with annual caps up to $1.9 million per category. Proactively encrypting Firehose streams eliminates this exposure entirely.

For teams operating at scale—managing dozens of delivery streams across multiple AWS accounts—automated enforcement via policy tooling (such as Infracost) prevents violations from accumulating undetected.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following example shows a misconfigured Kinesis Firehose delivery stream without encryption, followed by the corrected configuration.

Violation: No encryption configured

resource "aws_kinesis_firehose_delivery_stream" "example" {
  name        = "example-stream"
  destination = "s3"

  s3_configuration {
    role_arn           = aws_iam_role.firehose_role.arn
    bucket_arn         = aws_s3_bucket.destination.arn
    buffering_size     = 5
    buffering_interval = 300
    compression_format = "GZIP"
  }
}

This configuration delivers data to S3 without server-side encryption. Any data buffered in Firehose before delivery is not encrypted at rest.

Fixed: Encryption enabled using AWS-managed key

resource "aws_kinesis_firehose_delivery_stream" "example" {
  name        = "example-stream"
  destination = "s3"

  server_side_encryption {
    enabled  = true
    key_type = "AWS_OWNED_CMK"
  }

  s3_configuration {
    role_arn           = aws_iam_role.firehose_role.arn
    bucket_arn         = aws_s3_bucket.destination.arn
    buffering_size     = 5
    buffering_interval = 300
    compression_format = "GZIP"
  }
}

The server_side_encryption block enables SSE using an AWS-owned customer master key (CMK). This requires no additional KMS cost when using AWS_OWNED_CMK.

Optional: Encrypt with a customer-managed KMS key

resource "aws_kinesis_firehose_delivery_stream" "example" {
  name        = "example-stream"
  destination = "s3"

  server_side_encryption {
    enabled  = true
    key_type = "CUSTOMER_MANAGED_CMK"
    key_arn  = aws_kms_key.firehose_key.arn
  }

  s3_configuration {
    role_arn           = aws_iam_role.firehose_role.arn
    bucket_arn         = aws_s3_bucket.destination.arn
    buffering_size     = 5
    buffering_interval = 300
    compression_format = "GZIP"
  }
}

Using a customer-managed CMK provides greater control over key rotation, auditing, and access policies. This option incurs a KMS API cost of $0.03 per 10,000 requests.

Manual Step-by-Step Instructions

Follow these steps to identify and fix unencrypted Kinesis Firehose delivery streams:

  1. List all delivery streams in each AWS account and region using the AWS CLI:
    aws firehose list-delivery-streams –region us-east-1
  2. Check encryption status for each stream:
    aws firehose describe-delivery-stream \
      –delivery-stream-name example-stream \
      –query “DeliveryStreamDescription.DeliveryStreamEncryptionConfiguration”
  3. Identify streams where Status is DISABLED or where no encryption block is returned.
  4. Update the stream to enable encryption:
    aws firehose start-delivery-stream-encryption \
      –delivery-stream-name example-stream \
      –delivery-stream-encryption-configuration-input \
        KeyType=AWS_OWNED_CMK
  5. Verify the change by re-running the describe command and confirming Status is ENABLED.
  6. Update your Terraform code to reflect the new configuration and prevent drift.

Best Practices

  • Enable encryption by default on all new Firehose delivery streams, regardless of data sensitivity classification.
  • Use customer-managed CMKs for streams handling regulated data (PII, PHI, financial records).
  • Enforce encryption in CI/CD using policy-as-code tools to block non-compliant resources before deployment.
  • Audit existing streams regularly using AWS Config rules or CLI scripts to detect unencrypted streams across accounts.
  • Apply consistent tagging to classify streams by data sensitivity to prioritize remediation.
  • Document key rotation schedules when using customer-managed KMS keys.

Tools and Scripts to Help Implement

Infracost detects this policy violation automatically during Terraform plan evaluation. It identifies Kinesis Firehose delivery streams that are missing the server_side_encryption block or have encryption set to disabled.

This policy is available in Infracost, including in the free trial. Teams can:

  • Detect violations automatically as part of pull request checks, before infrastructure is deployed.
  • Prevent future occurrences by blocking or flagging non-compliant Terraform configurations in CI/CD pipelines.
  • Track remediation progress over time using Infracost’s FinOps dashboard to measure how many streams have been brought into compliance.

Infracost enables FinOps and platform engineering teams to burn down existing policy violations incrementally and enforce standards on all new deployments.

AWS Config also supports detecting unencrypted Firehose streams using the managed rule KINESIS_FIREHOSE_SSE_ENABLED.

Examples of Impact

Example 1: Healthcare Data Pipeline

A healthcare company uses Kinesis Firehose to stream patient event data to S3 for analytics. During a HIPAA audit, three delivery streams are found without encryption at rest. The audit remediation requires emergency engineering work, external consultant fees, and a 6-week delay to a product release. Total cost: over $80,000.

Enforcing this policy in Terraform from the start would have cost zero additional infrastructure spend when using AWS-owned CMKs.

Example 2: Multi-Account Platform Team

A platform engineering team manages 40 Firehose delivery streams across 8 AWS accounts. Using Infracost’s automated policy checks, they identify 12 streams missing encryption during a quarterly review. They apply a standardized Terraform module update, bringing all streams into compliance within one sprint—without a compliance incident.

Considerations and Caveats

  • Encryption at rest in Firehose only protects data buffered within the Firehose service itself. Ensure destination storage (e.g., S3 buckets, Redshift clusters) is also encrypted independently.
  • AWS_OWNED_CMK is free to use and suitable for most use cases. It does not support custom key policies or audit logging of individual key usage.
  • CUSTOMER_MANAGED_CMK provides full control and audit trails but adds KMS API costs. Budget approximately $1/month per key plus $0.03 per 10,000 API calls.
  • Existing streams can have encryption enabled without recreating the stream using start-delivery-stream-encryption. This avoids data loss or delivery interruption.
  • Direct PUT delivery streams support SSE. However, Firehose streams using Kinesis Data Streams as a source rely on the source stream’s encryption settings—Firehose SSE is not applicable in that case.
  • This policy does not apply uniformly to all Firehose destinations. Verify encryption support for each destination type in the AWS documentation.

Frequently Asked Questions (FAQs)

Yes. This policy is available in Infracost, including in the free trial. Infracost automatically detects Kinesis Firehose delivery streams that are missing server-side encryption configuration and surfaces them as policy violations during Terraform plan checks.

No. AWS handles encryption transparently within the Firehose service. There is no measurable impact on throughput, latency, or delivery reliability.

AWS_OWNED_CMK uses an AWS-managed key at no additional cost. CUSTOMER_MANAGED_CMK uses a key you create and manage in AWS KMS, providing full control over key policies, rotation, and usage auditing. The latter incurs KMS API charges.

Yes. You can use the start-delivery-stream-encryption API or CLI command to enable SSE on a running stream without interrupting delivery or losing data.

No. When a Firehose stream uses Kinesis Data Streams as the source, encryption is managed at the source stream level. The Firehose SSE setting is not applicable in that configuration.

Infracost integrates into CI/CD pipelines and evaluates Terraform configurations on every pull request. It flags non-compliant Firehose streams before deployment, tracks unresolved violations over time, and helps teams measure remediation progress across all accounts and regions.

Not on its own. Compliance frameworks like HIPAA and PCI DSS require encryption across the full data path. You must also encrypt the destination storage layer (e.g., S3 bucket SSE, Redshift encryption) and enforce encryption in transit using TLS.