AWS CDK BucketDeployment — should you use it ?

2 minute read
IAC
, ,

The CDK construct in question is BucketDeployment which is part of the S3 deployment module or package. From the constructs api documentation you would read this : Example image

BucketDeployment populates an S3 bucket with the contents of .zip files from other S3 buckets or from local disk.

Use Case: Site hosted on S3 served by CloudFront.

The construct looks like an attractive option for anyone looking at an easy way to manage that deployment and then to invalidate the CloudFront distribution. Is it that easy, you ask ? Yes, it is. Below is a snippet of the reference api arguments out of which the “destination_bucket” & “distribution” would be what you are looking to associate for your use case.

For an application using CICD, the build artifacts can passed on to the construct to push up to the S3 bucket followed by an invalidation request by a custom lambda provisioned for you when you include BucketDeployment in your stack.This worked for me and the client I worked for , since we didn’t have to deal with cross account permissions as the stack and cdk code already handled them.

What went wrong : As the project ramped up and the site grew, we saw the strain on the two benefits we were using this construct for:

S3 deployment:

  • The deployment of the build artifact is handled by a lambda which pulls down the assets required as a zip file and then extracts the contents to upload the relevant files. See the problem ?
  • download a zip file and extract it . You have twice the size of your sites artifacts in the lambda which can top up to 512Mb on the filesystem unless you have additional storage managed with EFS or so. For a non-vpc reliant application architecture, this would be an unnecessary dependency .

CloudFront Invalidations:

  • Invalidations seemed to work well for us, till it didn’t. Waiter InvalidationCompleted Failed talks about an ongoing issue noticed from Aug ‘21 onwards.
  • We noticed multiple invalidations happening in parallel with a status of “In progress” and eventually having the custom resource timing out and failing the build. In many cases, the build and invalidation would have worked and builds would get marked as Failed. One might argue that it is better to alert you of any issues in the background which you may need to pay attention to.

What did we end up with ? We eventually removed the BucketDeployment construct and opted to handle the static site deployment and CloudFront invalidation using the aws cli after infrastructure deployment. The idea behind the construct is commendable and with further improvements on the issues noticed, this could help many in the long run.