Issues to Rollback when the KMS Alias already exists

[SgarciaSantillana]

we are creating KMS Keys via a custom cloudformation stack and noticing the following functionality when a user tries to create a KMS Key with an alias that already exists:

1. Cloudformation stack containing a 'name' param of an existing KMS Alias is created.
2. Cloudformation sends a create event which raises an exception due to a KMS Key already existing with the 'name'.
3. Due to the custom-resource-helper returning a PhysicalResourceId that is auto generated (on a failure) Cloudformation tries to rollback and sends a 'delete' event.
4. Due to the PhysicalResourceId not actually being a real resource the delete event fails and the stack is stuck in a ROLLBACK_FAILED state.

I reckon the issue is the same than in #7, there was a branch with a solution, but it was closed.

[benbridts]

@SgarciaSantillana You can usually work around this by first doing an existence check, before attempting a delete.

This is also in line with the "Delete [... s]hould not fail if the underlying resources are already deleted." comment

In pseudo-code:

try:
    kms.delete_alias(alias_arn=physical_resource_id)
except DoesNotExist:
    return

or

try:
    kms.describe_alias(alias_arn=physical_resource_id)
except DoesNotExist:
    return
kms.delete_alias(alias_arn=physical_resource_id)