Continuation of our series on how to build a CloudFront distribution that serves your S3 Media, performs on-demand image transformation and even authenticates incoming requests.

This is part II of the series of posts where we are building a CloudFront distribution that serves your S3 Media, performs on-demand image transformation, and authenticates incoming requests.

If you missed part I, you can check it out here!

Creating a Cloudinary account

For this step, you need a Cloudinary account. You can signup for free here, and then grab your Cloudinary ID to be used on Cloudinary Fetch API.

Note: If you do not want to create your account now, it's possible to just use the Cloudinary Demo account to try things out. Just remember to set up your account before sending your code to live environments.

Creating the Origin Request lambda source code

First, we run npm init to create a package.json.

Now, we create an origin-request.ts file that will contain our source code. You can see that we will be using Typescript for developing our lambdas. We need then to add some dependencies needed for TS:

npm run --save-dev @types/aws-lambda @types/node typescript ts-node

We also need a tsconfig-build.json and tsconfig.json file respectively:

We can now finally add some code. Let's start simple: we want to create a lambda that receives CloudFront events and check the existence of query parameters: if they are not present, just let the request pass along without modifying anything, as it will then go to the S3 we already have configured on our CloudFront distribution, if there is a query parameter present though, we want to proxy the request to Cloudinary.

So first, we get the request from the event passed to the Lambda. Then, if the query string is empty, we just return the request without changing anything. This will basically make the request continue as usual to S3. Now, if there is a query string existing, we want to send the request to Cloudinary as a Custom Origin. Note that we are not using the query string for anything else yet, we just want to set up the proxy to Cloudinary first without any transformations.

So then, we grab the distributionDomainName (e.g.: https://d2idpesxy6e6el.cloudfront.net) and use it to create the media URL that Cloudinary needs to fetch the image in order to transform it. Then we change the origin of the request and point it to res.cloudinary.com and change the URI to /{cloudinary_id}/images/fetch/{media_url}. So, as an example, if you request https://d2idpesxy6e6el.cloudfront.net/nebula.jpg?width=300, the lambda will proxy the request to https://res.cloudinary.com/demo/image/fetch/https://d2idpesxy6e6el.cloudfront.net/nebula.jpg.

But wait a minute, if Cloudinary fetches the image from https://d2idpesxy6e6el.cloudfront.net/nebula.jpg, wouldn't CloudFront proxy it again to Cloudinary and start an infinite loop? Well, no, because in this case, the request contains no query parameters, and CloudFront will serve the image from S3.

So the flow of requests is something like: User -> CloudFront (with query params) -> Cloudinary -> CloudFront (without query params) -> S3.

And then, when it reaches S3, it will then find the image (or not) and bubble the response all the way back to the user (passing through Cloudinary who might perform some image transformations). Pretty cool right?

So now let's add some transformations!

This might seem complicated, but what transformQueryString does is pretty simple in the end: It transforms a query string like width=300&height=500 into something that Cloudinary understands, like w_300,h_500. We only have width and height transformation for now. If any other query parameter comes we throw an error for an unknown parameter. We also have some validations to ensure that the values we get are usable and not malformed.

Now we modify our Cloudinary Custom Origin to something like:

We call cloudinaryTransformations to grab Cloudinary transformation parameters and use them in the path we send to Cloudinary. Note that this function may throw, and in this case, we catch it and return a 400 instead with the error message. This will make CloudFront immediately return a response and not go to any Origin at all.

Bundling our source code

Awesome! So are we ready to deploy this to CloudFront? Not yet actually. You see, Typescript is great for developing but we cannot just use a .ts file on our lambdas. So we need to first transpile all of the above into a .js file that can be used to deploy code to AWS Lambdas. We are going to use Rollup for creating a bundle file that can be easily deployed as a lambda handler.

First, add the dependencies we need for this:

And then add the rolloup.config.js file:

Now run the following command and you should have a bundled JS file in /built/origin-request.js.

This will create the output file using the Cloudinary demo account. To use your own account, please run the following instead:

Attaching the lambda using Terraform

The last step now is to add some Terraform changes to attach this file as our Lambda@Edge. Same as part I, you can create separated files or keep building them on your main.tf file.

First we create zip file with our code:

Quite straightforward: we grab the .js bundled file and create a .zip with it.

Now we create an actual AWS Lambda with it. Please note, you need to create the lambda in the us-east-1 region, as it's required that all edge lambdas attached to CloudFront distributions are deployed there.

You can see that we are creating an IAM Role. That is because Lambdas need some permissions in order to run. All of the permissions needed are in this pre-existing AWSLambdaBasicExecutionRole, so we just use it. Then, we create a Lambda function using the zip file we have.

Almost done! We just need to now attach this lambda to our CloudFront distribution. This is actually quite simple: just go to the CloudFront distribution that we have on terraform, and inside the default_cache_behavior, add this:

Nothing special here. We just use the lambda we created as the origin-request of the distribution. Now, go ahead and run terraform plan and terraform apply. After everything is done and applied, you should be able to do on-demand transformations: https://{randomId}.cloudfront.net/{imagePath} will still go to S3 as usual, but https://{randomId}.cloudfront.net/{imagePath}?width=300 as an example returns the image transformed by Cloudinary!

You can check the full solution we went through up to this point (including part I) here in this GitHub repo.

Done! We now have on-demand image transformations on our CloudFront distribution! In the next steps, we will add response formatting and authentication to our distribution. See you in part III!

This post is a part of series, the first part of which you can find here. If you want to see more guides, or generally more updates on developer related topics, check out our developer newsletter!

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.