Encryption at Rest

Encryption at rest protects data while it is stored rather than traveling across a network or being processed in memory. An encryption algorithm transforms readable plaintext into ciphertext using a cryptographic key. Authorized systems can recover the original data through decryption. Typical targets include object storage, virtual machine disks, database files, snapshots, backups, and application-generated exports.

The main objective is confidentiality: obtaining stored bytes alone should not reveal their contents without access to the necessary keys. This helps reduce exposure from lost storage media, improperly handled backups, or unauthorized access to underlying storage. However, encryption does not automatically prevent access through a legitimate application or cloud API. If an attacker gains permissions that allow a service to retrieve and decrypt data, storage encryption may not stop that access.

Cloud platforms commonly offer server-side encryption, where the storage service encrypts data before persisting it and decrypts it for authorized reads. This is often transparent to applications. Client-side encryption instead encrypts data before uploading it, placing responsibility for encryption and decryption in the application or client tooling. Disk-level, database-level, and application-level encryption protect different boundaries, so engineers should select controls according to the threat model rather than assume every encryption option provides identical protection.

Key management is as important as the encryption algorithm. Managed services often use envelope encryption: a data key encrypts the stored data, and a separate key protects that data key. Access policies, auditing, rotation, and deletion controls govern how keys can be used. Customer-managed keys can provide additional policy and lifecycle control, but they introduce operational responsibilities. Disabling or deleting a required key can make otherwise healthy data unavailable. Rotating a key does not necessarily re-encrypt existing data.

For example, Amazon S3 encrypts all new object uploads at rest by default using server-side encryption. An organization can choose AWS Key Management Service keys when it needs additional control over key permissions and auditing. Amazon EBS supports encrypted volumes and snapshots, while Amazon RDS supports encryption for database storage and associated artifacts such as automated backups. Defaults and migration procedures differ by service, so enabling an account setting or changing a default should not be assumed to encrypt every existing resource retroactively.

Encryption at rest and encryption in transit address different stages of the data lifecycle. Encrypting a stored customer report does not protect its download over an unencrypted connection; TLS is needed for network protection. Likewise, HTTPS does not establish that the destination stores the report encrypted. Neither control by itself protects data while an application is actively processing it.

Under the shared responsibility model, the provider secures the underlying infrastructure, while customers remain responsible for appropriate configuration, permissions, and key choices for their workloads. Practical designs also cover replicas, temporary files, logs, exports, and backup copies. Managed encryption often has low application overhead, but key-service requests, quotas, costs, and recovery dependencies still matter. Test restores and key access before relying on an encrypted backup for recovery.