CloudFrontToS3 error "bucket already exists" when providing cloudFrontLoggingBucketProps.bucketName

[acbellini]

When providing CloudFrontToS3 a bucketName for cloudFrontLoggingBucketProps, CDK returns an error <bucketname> already exists in <stackname>

Reproduction Steps

new CloudFrontToS3(this, "Cloudfront", {
      cloudFrontLoggingBucketProps: {
        bucketName: "website-cloudfront-logging",
      },

Error Log

16:20:42 | CREATE_FAILED | AWS::S3::Bucket | WebsiteCloudfrontC...gingBucket72256605
<bucket_name> already exists in stack <stack_name>

Environment

• CDK CLI Version :2.142.0
• CDK Framework Version: 2.137.0
• AWS Solutions Constructs Version :2.57.0
• OS : MacOS
• Language : Typescript

Other

Upon investigation, it seems that CloudFrontToS3 creates four buckets, and not three as expected:

• a website bucket: S3Bucket
• an S3 logging bucket: S3LoggingBucket
• a cloudformation log bucket: CloudfrontLoggingBucket
• another log bucket: CloudfrontLoggingBucketAccessLog

As the last two buckets seem to read the same properties, CDK tries to create them with the same name, hence failing.

This conflicts with the expected architecture

I am not sure if one bucket is created and never used, or if all are needed and one needs some extra configuration.

My workaround for now is not to provide the bucket name.

---

This is 🐛 Bug Report

[biffgaut]

Thanks for pointing this out, several things going on here.

• There are 4 buckets created: the content bucket, an access log bucket for the content bucket, the CloudFront log bucket and an access log bucket for the CloudFront log bucket. The last one was added recently at the suggestion of our AppSec team. We'll update the architecture diagram to show this.
• We apparently reuse the props from the CloudFront bucket when creating its access bucket, hence the name collision. We will also look at the interface to give more granular control over each of the four buckets (and expose each Bucket construct in the Construct properties.
• All that said, we strongly recommend against providing hardcoded resource names (especially bucket names) in favor of letting the CDK and CloudFormation generate names specific to each individual stack. For most resources, a hardcoded resource name can prevent two instances of the stack in the same account/region due to the name collision. This situation is even more constraining in the S3 service, where bucket names have to be unique across all AWS. When I attempted to use your sample code, I received the error "Resource handler returned message: “website-cloudfront-logging already exists." I had to choose a different, unique bucket name to replicate the error you list above.

[acbellini]

Thanks for the speedy reply and resolution! And thanks for the advice on not providing hardcoded names. Indeed all my bucket names are generated, just with my conventions :) Thanks again!

[biffgaut]

The code for this is staged, but hasn't been published to npm, etc. yet. Hopefully we can get that done today or this weekend.

[biffgaut]

2.59.0 addresses this and is now available in npm, PyPi and Maven