Are AWS Cloudfront custom error pages slow?

Question

I have a single page application hosted on S3 and served with Cloudfront. Everything works fine, but I am trying to improve the performance of the first load of the application by caching all files on Cloudfront. Right now all files are served very quickly except one: the page HTML. There is only one HTML file (/index.html), that is served every time the file cannot be found on the origin (S3) by using a custom error page on Cloudfront. This file is served, for example, on the root of my domain.

I setup the Error Caching Minimum TTL of the custom error page to cache the response for 1 whole day (86400 seconds), as the image shows. Cloudfront customer error page settings

This cache configuration, however, seems to have no effect. Everytime the URL is not present on the origin (and S3 returns the status 403), the response is correct, but Cloudfront indicates a Miss on the x-cache header and takes around 500ms to respond. If the file is requested by the path "/index.html" on my domain, Cloudfront indicates a Hit on the x-cache header and responds in 20ms.

The index.html file has a cache control header set for a max age equal to the Cloudfront error caching minimum TTL.

Am I missing something or Cloudfront custom error pages are just slow?

Answer 1

There's a workaround for this problem by setting the S3 bucket policy to include "s3:ListBucket" on the bucket resource itself. For example,

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity INSERT-CLOUDFRONT-OIA-ID"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::EXAMPLE-BUCKET/*",
                "arn:aws:s3:::EXAMPLE-BUCKET"
            ]
        }
    ]
}

The difference is that error pages will then have a 404 HTTP status code (from S3) instead of 403 (from S3), which means CloudFront will actually respect the cache TTL of the custom error page so it won't hit origin (S3) again.

After this change I was seeing 10ms response times on the non-root / routes on CloudFront.

Important side effect of this change is that people could in theory view your bucket's directory listings with the ListObjects API e.g. http://EXAMPLE-BUCKET.s3.amazonaws.com/?delimiter=/, so it is important to use OAI (Origin Access Identity) to protect the S3 bucket to be only accessible from CloudFront (where the ListObjects URL will not work).