How does Amazon SSE-S3 key rotation work?
For each object you upload, a new encryption key is generated, and used to encrypt the object before it's stored to disk.
Having the object stored encrypted means the it's computationally infeasible for someone in possession of the raw data as stored on disk to decrypt it... but, of course, anyone in possession of that key could decrypt it, so the keys have to be stored securely, and in a relatively useless form, and that's done by encrypting them with the master key.
To compromise the stored object, you have to have the specific encryption key for that object... but even if you have it, it's useless since it's also been encrypted. To get it decrypted, or at least have it used on your behalf, you have to have the master key, or have a trust relationship with an entity that controls the master key and can use it on your behalf.
So far, all I've really done is stated the obvious, of course.
The encryption keys, themselves, are tiny, only a few tens of bytes each. When the master key is rotated, the object-specific encryption keys are decrypted with the old key, and re-encrypted with the new key. The new versions are stored, and the old versions are discarded.
Since the keys are small, this is not the massive operation that would be required if the objects themselves were decrypted and re-encrypted... but it's only the per-object encryption keys that are decrypted and re-encrypted when the master key is rotated.
Several analogies could be drawn to an apartment complex, where keys are stored in a common lockbox, where changing the lockbox lock would restrict future access to individual apartments by restricting access to the individual apartment keys by restricting access to the common lockbox. The analogy breaks down, because physical keys are easily copied, among other reasons... but it's apparent, in this illustration, that changing the lockbox lock (relatively simple operation) would be unrelated to changing the lock on one or more apartments (a much more substantial operation).
The bottom line, in this scenario, they create a new secret key to encrypt/decrypt each object you upload, then store that secret key in an encrypted form... periodically, and transparently to you, they change their stored representation of that secret key as a preventative measure.
The answer from Michael is a good explanation of envelope encryption and rotation of unbacked master key material.
Unfortunately, that's not how AWS works. When you rotate master keys, AWS NEVER re-encrypts any data keys (or data). If you are rotating a CMK generated using AWS key material, a new backing key is simply added to the existing CMK. The AWS-managed CMK is made up of the current backing key and ALL historical backing keys (which are used to decrypt old, rotated data keys). AWS never throws away HBK backing material unless the entire keychain is deleted by the customer. Every time you rotate the keys, the CMK accumulates more HBK material.
Imported master keys do not support key backing. If you are manually rotating a CMK that uses customer imported key material, you must keep your old keys if you wish to decrypt old data that was encrypted with this key prior to rotation. You can associate the new key with the old key alias to switch security contexts within your application without making any code changes.
Following your analogy above, AWS never replaces the lockbox. It creates another (new) lockbox right next to the old one (and pretends they are both 'the lockbox'). It continues to use the keys in the old lockbox to open existing apartments, while new keys get put in the new lockbox. When you instruct it to 'delete', it destroys all the associated lockboxes.
You can read the full details on pages 11 and 12 of the AWS "Cryptographic Details" whitepaper, here:
https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf