Yeah I generally have a pretty negative take about tech regulations, especially security ones. They are often written by people who don't understand either the technology or the threats, and are often implemented by people who don't really care about the threats, just about compliance.

Client-side encryption is a lot better. If the regulations were drafted in a technology and security aware way, maybe they would include something more detailed than "data must be encrypted at rest" which would require such practices. As it stands today, you can be in compliance without actually gaining much in the way of practical security improvement.

> A lot of threats. A rogue employee sucking up data. Malware on AWS servers.

IMO server-side encryption-at-rest does not protect against either of these, although there might be some edge cases where it does. For example, malware on the S3 gateway would see the data decrypted. A rogue employee with very limited access may be stopped by this, but I would guess that most rogue employees would be abusing the support impersonation processes or would deploy evil code that can access the data after decryption.

Client-side encryption would prevent both of these threats as well as the more common ones like losing access to your AWS keys somehow. As long as the method that leaked the AWS key didn't just leak your client-side encryption key as well.

All security evaluations should start with a threat model. If you're trying to protect yourself against APTs or nation states, you have a very different challenge than if you're trying to protect against drive-by ransomware.