Jan Varho

When AWS Services Don't Like Each Other

10.2.2018

aws
CodeCommit
S3
CloudFront
KMS
serverless

When my web host had a brief outage I decided to move my site to AWS. Since I'd been working with various AWS services recently, I decided that some automation would be nice as well.

There is CodeBuild and CodeCommit which ought to handle storing and building the site code, and S3 where I can serve a static site like I decided on easily. Since they are all on AWS, surely they will play nice with each other...

Yeah, no.

The first problem I ran into was that CodeCommit only has triggers for triggering a Lambda or sending a notification to SNS. So I wrote a lambda to do that.

Then I ran into problems between CodeBuild and S3. Clearly CodeBuild is meant to produce a JAR or something. It supports pushing them to S3, but only to a non-root prefix. I could not push to the root, which I had set up to serve the site. Ok, no big deal, I can set up an origin in CloudFront that uses that prefix instead.

And I get a bunch of permissions errors.

Some googling reveals that they are due to KMS. I try to work around that in CloudFront and/or add more permissions to the IAM roles involved, but no luck. As far as I can tell, CloudFront only allows serving encrypted data from S3 over signed requests, rather than publicly.

Eventually I wrote the S3 push into the buildspec.yml file using:

aws s3 cp output s3://my-bucket-name/prefix/ --recursive

And leave the artifact definition empty.

This is clearly not the use case they intended. Presumably the recommended process would involve CodePipeline, but that is totally overkill for something that I would trigger every few months.

Filed under: Internet