# Resource Not Encrypted At Rest

> Coverage here is exactly 2 resource types: RDS instances and S3 buckets. Each fires only when discovery confirms encryption is off. EBS volumes are deliberately excluded to avoid double-flagging the same volume alongside the dedicated EBS rule, and both remediations require rebuilding the resource rather than flipping a setting.

Source: https://zop.dev/integrations/aws/recommendations/resource-not-encrypted-at-rest
Updated: 2026-08-19

---

## Two resource types, on purpose

The rule sounds generic but its scope is exact: RDS instances (reading the engine's storage
encryption state) and S3 buckets (reading the default-encryption probe). EBS volumes used to
be in scope too, and every unencrypted volume then received two findings (this rule plus the
dedicated EBS rule) reading the same underlying flag. The EBS branch was removed so each
resource has one owner, which is worth knowing when you wonder why your unencrypted volume
appears elsewhere in the directory.

## Only a confirmed "no" fires

Discovery writes the encryption state as an explicit boolean. When the flag is absent, because the
probe failed or was denied, the rule abstains rather than treating silence as exposure. So
findings here are proven states, not inferences, and severity is high because the exposures
are real: unencrypted RDS storage and snapshots readable if access controls slip, and required
by PCI DSS, HIPAA, and SOC 2 alike.

## RDS: the fix is a rebuild

RDS storage encryption cannot be enabled on a live instance. The path is snapshot → copy the
snapshot with encryption and a KMS key → restore a new instance from the encrypted copy →
repoint applications. On a large production database that is a scheduled migration with a
cutover window, not a settings change. That is exactly why these findings age badly and why
starting encrypted is so much cheaper than retrofitting.

## S3: the gap is subtler than "unencrypted"

Since January 2023 every S3 bucket applies SSE-S3 by default, so on recent buckets the real
findings are usually the absence of SSE-KMS with a customer-managed key (no audit trail, no
revocation lever) or the absence of enforcement on writes. Upgrading default encryption does
not touch existing objects; re-encrypting history takes an S3 Batch Operations copy. A
bucket policy denying unencrypted PUTs is what stops regression.

## Spot-check the RDS side

```bash
aws rds describe-db-instances \
  --query 'DBInstances[?StorageEncrypted==`false`].[DBInstanceIdentifier,Engine]' --output table
```

Pair it with `aws s3api get-bucket-encryption --bucket <name>` per bucket on the S3 side, and
enable default EBS encryption separately. That account-level switch prevents the sibling
rule's findings, not this one's.