Unable to Successfully Create a CloudFront Distribution - Please Help

Yep. It's too bad we couldn't sort out the immediate issue right now, but for some general advice, CloudFormation is reasonably good at dependency management, if the feature is just used.

For example, if one CloudFormation stack creates an S3 bucket for logs, and a different CloudFormation stack uses that bucket as the destination for a CloudFront distribution to send its logs, then the way to prevent these kinds of confusing situations is to "export" the name and ARN of the S3 bucket from the stack that created the bucket, and to "import" that reference into the other stack that declares the CloudFront distribution.

This way, CloudFormation will understand that the S3 bucket stack shouldn't be deleted or the S3 bucket removed from it, as long as any other stack still has a reference to it. It wouldn't even allow deleting the dependent resource or its containing stack, as long as the reference existed.

However, technically, there's nothing to prevent the S3 bucket or any other resource from being provisioned with CloudFormation in one stack and its name simply to be specified manually as input for another stack, or even a resource created entirely manually, without CloudFormation. In either situation, CloudFormation would not know that there's a dependency, leaving it up to the operator to understand and deal with the dependencies and the proper order for disposing of the resources.

Find the embedded stack in the CloudFormation console (probably in "Deleted" status) and check on its "Events" tab if there's a more detailed error there. There's probably something attempted to be embedded in the response header policy in the nested stack, but it's impossible to guess with any accuracy what it might be, without seeing the template or a more specific error message.

Maybe this, from the ACM Certificate stack whose state is now "DELETE_IN_PROGRESS"

2024-07-02 13:20:51 UTC-0700
Certificate
DELETE_FAILED
-
Certificate arn:aws:acm:us-east-1:891377000524:certificate/e4a48654-b445-4dc9-8bbe-fc3e5e9dd10f in account 891377000524 is in use. (Service: AWSCertificateManager; Status Code: 400; Error Code: ResourceInUseException; Request ID: f5422efb-8926-44d6-bc01-1faab504f8be; Proxy: null)

I tried that too but the original bucket name (created by CloudFormation) is 83 characters long while the character limit for new buckets is 63 characters.

Here is the original bucket name: amazon-cloudfront-secure-static-site--s3bucketlogs-gqssvd4h8bn9.s3.amazonaws.com

Its not clear if any portion of that can be truncated and still be a) legal and b) recognizable

Yes I found it. I presume that I don't want to delete it, only disassociate it. If so, whats the best way to do that?

Thank you.

You can delete the stack again. It will ask what you want to do with the resources that failed to get deleted on the previous round. You can choose to retain them. That will cause the stack to be deleted but the resource/s you selected to be left behind, no longer managed by CloudFormation.

If you want, you can later import those resources into a newly created stack, only containing the remaining resources.

I think the issue might be related to a stack that is stuck in the deletion state for a few hours now. More than likely its holding on to all of those resources.

Is there any way for force delete a deletion job that appears "stuck"?

2024-07-02 13:20:52 UTC-0700
amazon-cloudfront-secure-static-site-templates-main-mycompany-AcmCertificateStack-G4OMNUYZZH2X
DELETE_FAILED
-
The following resource(s) failed to delete: [Certificate].

Then when I go into certificate manager to delete the certificate, I get this:

Certificate in use
1 of the 1 selected certificates to delete is in use (associated with other AWS resources) and cannot be deleted. Disassociate the certificate below from each of its associated resources and try again.
www.my.company.com
(e4a48654-b445-4dc9-8bbe-fc3e5e9dd10f)

You might be able to disentangle linked resources, such as removing the association between an ACM certificate and a resource using it, such as a CloudFront distribution or Application Load Balancer, by modifying the TLS settings of the resource. But in general, it's best to find the root dependency and resolve whatever issue is blocking it from progressing. Once it's sorted out, the rest might fall neatly like dominoes.

I am not really sure how to do that, given that this is for an S3 static website.

Which resource is shown by ACM as using the certificate? Is it a CloudFront distribution or something else?

Definitely Cloudfront.

arn:aws:cloudfront::891377000524:distribution/E3VYSS4CUWYVG

Okay, then you can open the CloudFront console, find the distribution by the ID ACM showed, click Settings/Edit, and remove the "custom SSL certificate" specified for the distribution.

Unfortunately after selecting the one and only stack I don't see a Settings option. Could that be because it is stuck in a deletion state?

Not the CloudFormation stack but the CloudFront distribution. Type "cloudfront" in the search box at the top of the console screen to switch from CloudFormation to CloudFront.

Found it thank you. I removed the certificate. Assuming the deletion fails again I hope to restart the deletion and hopefully it should succeed a third time.

In the meantime, I assume its safe to start a new distribution. Should I be able to use the existing certificate that maps to my subdomain, www.my.domain.com, or should I delete that certificate?

Thanks in advance.

If you're using CloudFormation to provision and manage your infrastructure, it's definitely best to use it for all the dependent resources. I recommend you create a new certificate and a new CloudFront distribution with CloudFormation and not use the old resources left in a somewhat indeterminate state.

ACM certificates are completely free, so there's no harm in creating a new certificate.

Oh man, getting blocked from removing the certificate or disabling Standard Logging because the 3S bucket for logging was previously disabled.

The S3 bucket that you specified for CloudFront logs doesn't exist: amazon-cloudfront-secure-static-site--s3bucketlogs-gqssvd4h8bn9.s3.amazonaws.com

While removing the custom SSL certificate from the settings, you should be able to disable the "standard logging" option as well that points to the now-nonexistent S3 log bucket.

Yes thats what I tried the first time but no luck. Everytime I receive the following error:

The parameter S3 bucket has been deleted.

Are you sure you selected the "off" option for standard logging? There should be no bucket specification when it's set to off.

If it's definitely giving that error when trying to disable logging, then there might be no shortcut to simply waiting CloudFormation to give up on the operations that it still considers as pending. Once the deletions have failed, you'll have the option to delete the stacks again and retain the leftover resources, which you can clean up manually afterwards.

Yes, it gives that error even when I disable logging, very strange.

I think you are correct and I am just going to have to wait. AFAIK, there are no resources worth saving so should I just delete all?

It might make CloudFormation get even more confused as to what's happening. I think it might be best to just let it sort things out, unless you can pinpoint a specific knot to open, like we tried to do with the removal of the SSL certificate, although that failed.

OK thank you, I will just have to wait. Unfortunately I appear to be at a hard block for now, This has been a rough introduction to CloudFront/CloudFormation.

Thanks again for your help!

Thats all excellent advice, and hopefully the more hands-on I have with these tools strategies like that will come more naturally to me. I will save/bookmark/flag for future reference if there is a way to do so.

OK the last remaining CloudFormation stack FINALLY deleted but when I try to disable the distribution in CloudFront I am getting the same error message as before:

Failed: The S3 bucket that you specified for CloudFront logs doesn't exist: amazon-cloudfront-secure-static-site--s3bucketlogs-gqssvd4h8bn9.s3.amazonaws.com

I seem to be caught in a pretty nasty feedback loop. Any suggestions?

For a quick workaround, simply create a bucket by that name manually, then try to delete the CloudFront distribution again. Delete the bucket if the deletion succeeded.

My previous response appears to have been deleted. The character length of the original bucket created by CloudFormation is 83 which is 20 characters longer than what is allowed.

Is there a workaround for this?

Well I just discovered what a base name is, lol. All good.

Base-name as defined by documentation would suggest the following:

amazon-cloudfront-secure-static-site--s3bucketlogs-gqssvd4h8bn9.s3

But this is still 4 characters too long!

The bucket name was probably something like s3bucketlogs-gqssvd4h8bn9. The .s3.amazonaws.com suffix in any case isn't part of it.

To be sure, you can find the deleted CloudFormation stack that used to declare the S3 bucket by filtering the list of stacks by the "deleted" status. On the Resources tab of the stack, you'll probably still see the bucket's name.

Yes I found it, but sadly it does not look any different,

amazon-cloudfront-secure-static-site--s3bucketlogs-gqssvd4h8bn9

You are right! Maybe I should have bothered to count it. Once again, thank you for your gracious support and most of all, your time!