I'll preface this by saying that I haven't seen any official resources confirming that it was an S3 bucket issue (although the statement from hacker mentioned releasing "buckets" so it very well could be).
S3 provides server side encryption that encrypts the files at rest. This is done entirely on the server side and does not require any additional keys from the client. However, it is possible to do your own file encryption using your own keys ahead of time, but I imagine that a very small subset of AWS users actually do that.
The way these hacks usually happen is that someone configures the bucket to enable public access, either to the entire bucket or certain files within it, and then someone stumbles upon the bucket's endpoint.
The mitigation is simply not to configure your buckets to be publicly available. That used to be relatively more difficult than it sounds because of a confusing S3 UI, but AWS has recently pushed a number of changes that try to address this issue, including putting a very clear "Public" label next to buckets with these settings, sending emails to users with public buckets, and providing configurations that allow account owners to prevent users from setting buckets to public access.
Some articles are referencing a WAF configuration issue, in which case the above may not fully apply here. The commenter below me mentioned the use of temporary AWS access keys, which can be obtained from an internal AWS service known as the metadata endpoint. Typically this endpoint is only accessible from EC2 nodes (or services that rely on EC2 like Lambda or CodeBuild) and allows AWS to deliver short-lived credentials to the node that can rotate frequently. If this truly was the issue, then it's possible a WAF issue allowed the remote attacker to query the internal endpoint from an external source and obtain credentials that were previously only available to the node itself. From there, the attacker could make AWS API calls to the S3 buckets and download the files.