Encrypt other services at rest (queues, streams, logs, ML)

For most of this group the AWS spend is zero: AWS-managed encryption (such as SSE-SQS or the EMR security-config key) is free, has no performance penalty, and clears the finding with a single attribute change. There is no savings line to chase, which is why these items get deprioritised and why they should not be: the relevant ledger is compliance and breach-disclosure risk, not cost.

There is one cost trap worth modelling. SQS and Kinesis under SSE-KMS with a customer-managed key charge per cryptographic API call, and on a high-throughput stream that can run to thousands of dollars a month if the data-key reuse window is left at a naive setting. The same parameter (KmsDataKeyReusePeriodSeconds, default five minutes) collapses a 40-million-message-a-day queue from millions of KMS calls to a few hundred, the difference between a few cents and a few thousand dollars. So this is a per-resource tiering decision: free AWS-managed encryption for the bulk, customer-managed keys with a sane reuse window only where regulated data justifies the audit trail.

Two members, OpenSearch domains and the recovery points behind Backup.1, are migrations rather than flips, so budget those as distinct one-time projects (engineering time, temporary double-running storage) and prioritise by data sensitivity. Track the count of unencrypted long-tail resources holding regulated data, trending to zero, each with an owner and a date.

Priya, the finance partner at a fintech, sees a quarterly scan light up with at-rest encryption failures across SQS, Kinesis, OpenSearch and AWS Backup, with the SOC 2 evidence package due Friday. Her instinct is to slow the team down before they reach for a customer-managed key on everything, because she knows the one place this group has a real cost: SQS and Kinesis under SSE-KMS charge per cryptographic API call, and the payment-events queue alone handles 40 million messages a day.

She asks for the inventory split three ways. Most of the failing resources can take the free AWS-managed option (SSE-SQS, the aws/kinesis key, the EMR security-config key) with no spend and no performance penalty, so those are a no-cost flip. The high-throughput regulated streams get a customer-managed key, but only after she sees a cost model: daily volume, proposed data-key reuse window, resulting monthly KMS charge. With KmsDataKeyReusePeriodSeconds left at its five-minute default, the payment-events queue makes roughly 288 KMS calls a day instead of 40 million, the difference between a few cents and a few thousand dollars. The two OpenSearch domains and the unencrypted recovery points behind Backup.1 she books separately as one-time migration projects, prioritised by data sensitivity, so a vague compliance liability becomes a planned, costed line.

The cost model is favourable in a way that is rare for security work. Most of these fixes are free flips with no performance penalty, and the compliance exposure they remove (an audit citation, a breach-disclosure liability on personal data) is large and lumpy. The right frame is not what does encryption cost, but what does an unencrypted queue or recovery point cost us if it appears in an audit finding or a breach disclosure. Priced that way, the remediation is almost always the obvious choice.

The finance role is to manage the two places where cost is real. For high-throughput SQS and Kinesis under SSE-KMS, ask for a cost model (daily volume, proposed reuse window, resulting monthly KMS charge) before approving the customer-managed-key path, because the default reuse window decides whether SSE-KMS is affordable or absurd. For OpenSearch and Backup migrations, fund them as distinct one-time projects prioritised by data sensitivity. Track the regulated-data subset, not the raw finding count, and treat any queue still unencrypted after the sprint as a documented exception with an owner.

The services in this group, queues, streams, caches, logs, backups and ML state, carry sensitive data between and beneath the systems that make up an application: customer records, transaction events, authentication tokens, payment data. This capability checks whether that data is encrypted where it lands, and the report shows the gap as a scatter of findings across many services nobody thinks of as a database.

Most of the fixes are free, single-setting flips, so a finding here is usually a missed default rather than a hard decision. Two members (OpenSearch and the recovery points behind AWS Backup) cannot be retrofitted in place and need an owned, dated migration. The leadership signal is whether these get caught and closed by enforced defaults, or sit open waiting for someone to notice.

This is a governance decision, not a budget one. The defensible end state is that every service holding sensitive data is encrypted by policy, every exception is a documented decision with an owner, and automated guardrails stop a new unencrypted queue, stream or domain from reintroducing the gap.

The leadership team learned an uncomfortable lesson from the calendar, not from a breach. A Security Hub scan run ahead of an audit showed that the company's oldest, most business-critical queues and streams, the ones carrying transaction events and authentication tokens, were the exact resources still running unencrypted, because AWS only switched on encryption by default for new resources and nobody had revisited the ones that predated the change. The assumption that AWS encrypts everything these days had quietly become false at the edges of the estate.

The response was to stop treating each encryption finding as a separate chore and to set one policy: every service holding sensitive data is encrypted by policy, every exception is a documented decision with an owner, and automated guardrails stop a new unencrypted queue, stream or domain from reintroducing the gap. Most of the fixes turned out to be free single-setting flips, so the policy cost almost nothing; the two members that cannot be retrofitted in place, OpenSearch and the recovery points behind AWS Backup, became owned, dated migrations. The leadership signal at the review is no longer the raw finding count but whether the gaps get caught and closed by enforced defaults, or sit open waiting for someone to notice.

These services are common audit citations and, for most of them, among the cheapest things to close: the free baseline option satisfies the control for the bulk, and the stronger option costs little at a sensible configuration. The risk is less the day-to-day probability of a storage breach than what happens when something does go wrong: encrypted data is often exempt from disclosure obligations, unencrypted data is not, and that difference can be a liability of material size.

What makes it a leadership item is the pattern, not the individual finding. A scatter of cheap encryption gaps that stay open or keep reopening means secure-by-default is not enforced, which tends to predict harder, costlier gaps elsewhere. The useful question is whether the policy is clear (which resources at which tier) and whether every exception is on the record.