Serving a multitude of static sites from a wildcard domain in AWS

CloudFront + Lambda@Edge + S3 can do this “serverless.”

Lambda@Edge is a CloudFront enhancement that allows attributes of requests and responses to be represented and manipulated as simple JavaScript objects. Triggers can be provisioned to fire during request processing, either before the cache is checked (“viewer request” trigger) or before the request proceeds to the back-end (“origin server”, an S3 web site hosting endpoint, in this case) following a cache miss (“origin request” trigger)… or during response processing, after the response is received from the origin but before it is considered for storing in the CloudFront cache (“origin response” trigger), or when finalizing the response to the browser (“viewer response” trigger). Response triggers can also examine the original request object.

The following snippet is something I originally posted at the AWS Forums. It is an Origin Request trigger which compares the original hostname to your pattern (e.g. the domain must match *.example.com) and if it does, the hostname prefix subdomain-here.example.com is request is served from a folder named for the subdomain.

lol.example.com/cat.jpg        -> my-bucket/lol/cat.jpg
funny-pics.example.com/cat.jpg -> my-bucket/funny-pics/cat.jpg

In this way, static content from as many subdomains as you like can all be served from a single bucket.

In order to access the original incoming Host header, CloudFront needs to be configured to whitelist the Host header for forwarding to the origin even though the net result of the Lambda function’s execution will be to modify that value before the origin acually sees it.

The code is actually very simple — most of the following is explanatory comments.

'use strict';

// if the end of incoming Host header matches this string, 
// strip this part and prepend the remaining characters onto the request path,
// along with a new leading slash (otherwise, the request will be handled
// with an unmodified path, at the root of the bucket)

const remove_suffix = '.example.com';

// provide the correct origin hostname here so that we send the correct 
// Host header to the S3 website endpoint

const origin_hostname="example-bucket.s3-website.us-east-2.amazonaws.com"; // see comments, below

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;
    const host_header = headers.host[0].value;

    if(host_header.endsWith(remove_suffix))
    {
        // prepend "https://stackoverflow.com/" + the subdomain onto the existing request path ("uri")
        request.uri = "https://stackoverflow.com/" + host_header.substring(0,host_header.length - remove_suffix.length) + request.uri;
    }

    // fix the host header so that S3 understands the request
    headers.host[0].value = origin_hostname;

    // return control to CloudFront with the modified request
    return callback(null,request);
};

Note that index documents and redirects from S3 may also require an Origin Response trigger to normalize the Location header against the original request. This will depend on exactly which S3 website features you use. But the above is a working example that illustrates the general idea.

Note that const origin_hostname needs to be set to the bucket’s endpoint hostname as configured in the CloudFront origin settings. In this example, the bucket is in us-east-2 with the web site hosting feature active.