Encrypt AWS databases at rest

Encryption at rest is one of the rare controls where the AWS spend is essentially zero. AES-256 is free, encrypted snapshots cost the same per GB as unencrypted ones, and the only recurring charge is a customer-managed KMS key at roughly a dollar a month. There is no savings line to chase here, which is precisely why it gets deprioritised and precisely why it should not be: the relevant ledger is risk, not cost.

The genuine cost lives in the migration, and it is front-loaded by immutability. Because most engines cannot be encrypted in place, every unencrypted database is a latent migration project whose size scales with the data it holds. A small database is a few engineering hours; a multi-terabyte production cluster with tight uptime is a planned, change-managed cutover. The lever finance controls is timing: the earlier the migration, the cheaper it is, and there is no scenario where waiting makes it cheaper.

Frame each failing control as a line on the risk register, ordered by data sensitivity rather than by control count. An unencrypted production database holding regulated records carries a far higher expected loss than an unencrypted throwaway dev cluster, yet both show up as one red finding. The metric worth tracking is the count of unencrypted databases that hold regulated or sensitive data, trending to zero, each with a named owner and a committed date.

Priya is the finance partner on the SOC 2 programme. Security Hub returns at-rest encryption failures across RDS, Redshift and OpenSearch in three older accounts. There is no savings line to chase here, because the encryption itself is essentially free, so her first move is to reframe the work as liability discharge rather than cost reduction and to ask which of the failing stores actually hold regulated data.

The team pulls the list with engine, size and data classification. Two production RDS databases hold orders and billing records, the OpenSearch domain indexes customer tickets, and a staging Postgres instance is a throwaway that can simply be deleted. Priya separates the regulated subset from the noise, then makes the timing argument that finance is uniquely placed to make: because most engines cannot be encrypted in place, every unencrypted database is a latent migration whose cost only grows as it accumulates data, so the cheapest possible moment to migrate is now. Her output for the finance pack is one line: three regulated stores migrate this quarter on a committed timeline, the staging instance is deleted, and an encryption-by-default standard ships alongside so the same migration is never funded twice.

The cost model here is asymmetric in a way that is rare for security work. Encryption costs essentially nothing in AWS spend, while leaving a database unencrypted creates an unbounded tail risk: a future leak of a store holding regulated data carries notification, forensics, legal and reputational costs that run into six and seven figures. There is no savings column to populate, so do not manufacture one; the right framing is liability discharge, not cost reduction.

Because the fix is a migration that grows more expensive with delay, this is one of the clearest fix-now cases on the whole compliance backlog. The finance role is to attach data sensitivity to each failing database, fund the migrations for the regulated subset on a committed timeline, and insist that an encryption-by-default standard ships alongside so the same migration is not funded again next quarter. Track the regulated-data count, not the raw total.

Databases are where the most concentrated, most sensitive data in the estate ends up: customer records, financial history, analytics. This capability answers one binary question per database: if a backup of it leaked tomorrow, would it be readable? For an unencrypted store the answer is yes, and the report shows the gap as a scatter of separate findings across many engines.

The fix is effectively free in AWS terms, with one catch that matters at the leadership level: for most engines it cannot be retrofitted in place, so each unencrypted database needs an owned, dated migration rather than a config change. That makes the trend and shape of the list more important than the count: a short, shrinking list with regulated databases actively migrating and a default that prevents new ones is a healthy posture.

This is a governance decision, not a budget one. The defensible end state is that no database holding regulated or customer data is unencrypted, every exception has an owner and a date, and an account-level default plus a preventive guardrail stops a new database from reintroducing the gap.

After a vendor security questionnaire stalled a six-figure deal on a single line (was the customer database encrypted at rest), the CEO asked the CTO a blunt question: if a backup of any of our databases leaked tomorrow, would it be readable? The honest answer was that several older databases would be, because there had never been a stated standard and nobody owned the gap.

The response was to set encryption at rest as a non-negotiable standard for any database holding regulated or customer data, and to treat the existing findings as policy violations with owners and dates rather than backlog tickets. Each regulated database got a named owner and a committed migration date, the legacy unencrypted snapshots were cleaned up, and an account default plus a preventive guardrail was switched on so a new unencrypted database could not be created. A quarter later the questionnaire answer was a clean yes, and the more important answer (could this gap reopen) was no, because the platform itself now blocks it.

Nearly every major breach involving stored data came back to the same root cause: a data store that could be read without a key the organisation controlled. Encrypting databases at rest makes that root cause structurally difficult, and an account default plus a preventive guardrail makes it close to impossible to reintroduce. The cost of getting it wrong is large and well documented; the cost of getting it right is engineering time plus a small KMS fee.

The leadership question is not did we fix that one cluster, but why was an unencrypted database creatable at all. A short, shrinking list with regulated databases owned and dated signals a healthy posture; a long or growing one signals that databases are being created without an encryption standard and the org carries unquantified audit risk.