Server-Side Encryption

Server-side encryption places responsibility for encrypting stored data on the receiving service. An application submits data, normally over a TLS-protected connection, and the service encrypts it before persisting it within its documented encryption boundary. When an authorized reader requests the data, the service decrypts it transparently. This makes encryption at rest practical without requiring every application to implement cryptographic operations or manage encrypted file formats.

The important distinction from client-side encryption is where encryption occurs. With client-side encryption, the application encrypts data before sending it, so the storage service can receive only ciphertext. With server-side encryption, the receiving service can process plaintext. A requirement that a storage provider must never receive plaintext therefore cannot be satisfied by server-side encryption alone. TLS remains necessary because encryption at rest does not protect network traffic.

Cloud services commonly use envelope encryption. A data key encrypts the data, and a separate key-encryption key protects that data key. The encrypted data key can be stored alongside the ciphertext. A key-management service or hardware security module protects the higher-level key and controls its use. This design avoids sending entire datasets to a key-management API and supports scalable encryption of objects, volumes, and databases.

Choose key management according to the required control model. Service-owned or service-managed keys minimize administrative work. Customer-managed keys can provide explicit key policies, separation of duties, auditability, and control over key availability. However, customer-managed does not mean that the service cannot decrypt the data: the service still needs an authorized path to use the key. Similarly, supplying a key with an individual storage request does not make the operation client-side encryption if the service performs the actual encryption.

For example, an object archive can use Amazon S3 server-side encryption with a customer-managed AWS KMS key when policy requires a designated key and controlled decryption permissions. An S3 bucket policy can enforce encryption request requirements, but it must account for how bucket default encryption applies when upload headers are absent. Changing the default encryption configuration does not re-encrypt existing objects; those require a separate rewrite or supported bulk operation. Database and block-storage services have their own rules for enabling encryption, migrating existing data, and copying snapshots.

AWS KMS is generally appropriate for managed key policies, service integrations, and audited cryptographic operations. AWS CloudHSM addresses requirements for dedicated HSMs and greater control over cryptographic infrastructure, but adds operational responsibility. It is not a universal drop-in key provider for managed storage services. Where supported, an AWS KMS custom key store backed by CloudHSM connects supported KMS operations to keys held in the HSM cluster; service compatibility and operational constraints must be checked.

Server-side encryption does not prevent an authorized application, compromised role, or overly permissive service identity from reading plaintext. Combine it with least-privilege access, appropriate key policies, logging, and data-access monitoring. Include backups, replicas, exports, and temporary storage in the design. Key rotation generally does not rewrite all existing ciphertext, and disabling or deleting a required key can interrupt workloads or make data unrecoverable. Test restore procedures, cross-account access, regional recovery, key availability, quotas, and costs before relying on the design in production.