Crawlers failed due to KMS key deletion

If you have data that is previously encrypted under a KMS key and you set any service to use a new KMS key in its place, it won't trigger re-encryption of previously encrypted data. It depends on the service whether there's a way to re-encrypt with a different key, regenerate indexes or other generated data to get it encrypted with the new key, or if the configurations or resources have to be rebuilt.

You should never delete a KMS key until you're sure it isn't in use. Instead, you should disable the key, so that it cannot be used for encryption or decryption operations, allowing you to confirm assumptions on its use. The key can be re-enabled trivially, but a deleted key is gone forever, with no way to roll back.

For this reason, there's a hardwired failsafe in KMS that prevents deleting a KMS key directly. Instead, it can only be scheduled for deletion later, a minimum of 7 days and default of 30 days later. This doesn't guarantee that data won't be lost but increases the likelihood of noticing an unknown dependency before it's too late.

If you have your old KMS key scheduled for deletion but not deleted yet, you should cancel the deletion to regain access to the previously encrypted data.