[t_sawyer]

Different levels of encryption at rest play different roles in your particular scenario.

If you use a cloud service and they have an encryption at rest feature that you enable, the default is for them to control the key. Or, for Azure, put a "customer controlled" key in Key Vault. But again, that's their service. In this scenario you're only protected against people physically in the data centers not their DevOps folks. But, that feature gives you a checkmark for SOC2 or other regulations...

The problem protecting against DevOps folks at a cloud is: 1. You are burdened with putting a key somewhere outside of their cloud. If you do something at the filesystem level like enable bitlocker on a VM you're going to experience pain during reboots and it's not possible on a root volume if you're not given a console. 2. You can't do this on a cloud service like RDS. You'd have to do row level encryption with your application doing the decryption/encryption. But, your application has to have the key and now your back to #1. The VM with the key needs the root disk encrypted or the drive where the key is store encrypted. And again, you're not able to use a cloud service like EKS or App Service you're stuck with VMs.

Generally, I tend to just stick with regulation requirements which protect against the physical hard disk.