- Newest
- Most votes
- Most comments
Hello.
I would not destroy the stack yet.
Try running it against one of the failed change sets:
aws cloudformation describe-events \
--change-set-name "<failed-change-set-arn>" \
--region eu-west-1
The result can contain fields such as ValidationStatusReason and ValidationPath, which may identify the exact resource/property that AWS::EarlyValidation::ResourceExistenceCheck is rejecting.
https://docs.aws.amazon.com/cli/latest/reference/cloudformation/describe-events.html
The API you're looking for exists — note it's DescribeEvents, not the older DescribeStackEvents, which is why you found nothing (your failure happens before any stack events exist). aws cloudformation describe-events returns Early Validation failures. For a change-set-creation failure:
aws cloudformation describe-events \
--change-set-name <failed-change-set-ARN> \
--filters '{"FailedEvents":true}' \
--region eu-west-1
On a VALIDATION_ERROR event you get ValidationName, ValidationStatusReason, and crucially ValidationPath — the specific property that failed — plus LogicalResourceId. That's the detail the generic StatusReason is hiding. If describe-events isn't recognized, your CLI is too old; the SAM CLI in a GitHub Actions runner is often well behind, so check aws --version first.
For remediation text there's also:
aws cloudformation list-hook-results --target-type CHANGE_SET --target-id <change-set-ARN>
aws cloudformation get-hook-result --hook-result-id <id-from-above>
get-hook-result returns Annotations with StatusMessage and RemediationMessage.
Before chasing the caching theory: the check is called ResourceExistenceCheck, and existence isn't verification status. Your identity exists and get-email-identity says it's verified — so if the hook read live SES state it'd pass, and if it's truly an existence check then verification isn't what it's looking at. Read ValidationPath before assuming SES is involved at all.
Also worth separating your two errors. The Cognito "not verified" message was a send-time failure during the DKIM regeneration window; the current one is at change-set creation, before execution. Different layers at different times, not one contradiction — and treating them as a single symptom is probably what's anchoring you to the SES explanation.
To isolate it and unblock deploys meanwhile: you bisected template versions but not the resource. Create a change set with EmailSendingAccount set to COGNITO_DEFAULT, or with EmailConfiguration removed. If it creates cleanly, the problem is that property; if it still fails, SES was never the cause. COGNITO_DEFAULT is a stopgap only — low daily cap, Cognito-branded mail.
Don't tear the stack down. Early validation fails before the change set is created, so nothing has been mutated, which matches your clean drift check. Post the ValidationPath output and this should be answerable.
answered 13 days ago
Relevant content
asked 2 years ago
asked 8 months ago
