With CloudFront signed URLs

In this chapter, we'll implement the same photo-sharing app but this time using CloudFront signed URLs. The functionality is the same as described in the Example app chapter. Here, we'll focus on the performance, for a more in-depth discussion on how CloudFront implements signed URLs, see the CloudFront signed URLs chapter.

Some problems that we'll solve in this chapter will be similar to the previous chapter, but there will be new ones too, for example when configuring uploads.

Architecture

Since we are not using S3 signed URLs for downloads, the setup is a bit different this time. As access control is moved to CloudFront, we'll need to give the distribution access to the bucket. This is what we'll discuss first in this chapter.

Next, as we've discussed in the Signing keys chapter, CloudFront signed URLs use cryptographic signatures instead of IAM permissions and that needs a keypair generated and stored. For a detailed discussion on how to do it securely, check the linked chapter as we won't cover that part here.

The baseline for signing is that a private key is accessible securely and the expiration time is set to 15 minutes:

return getSignedUrl({
  url:
    `https://${process.env.DISTRIBUTION_DOMAIN}/images/${key}`,
  keyPairId: process.env.KEYPAIR_ID,
  dateLessThan: new Date(new Date().getTime() + 15 * 60 * 1000),
  privateKey: (await getCfPrivateKey()).Parameter.Value,
});

Bucket access

Access control is checked by the CloudFront cache behavior. That means the distribution needs access to the file itself. This is in contrast to S3 signed URLs as in that case CloudFront was responsible only for routing to the S3 bucket endpoint but did not have any special access to the contents, as we've discussed this in the Single domain chapter. But when using CloudFront signed URLs, the permissions are different.