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

I've got a pretty specific problem here, we've got a system that we already have and maintain, the system involves using subdomains to route people to specific apps.

on a traditional server that goes like follows; we have a wildcard subdomain, * that routes to nginx and serves up a folder

so > nginx > serves up myapp app folder > myapp folder contains a static site

I'm trying to migrate this in some way to AWS, I basically need to do a similar thing in AWS, I toyed with the idea of putting each static app into an s3 bucket and then the wildcard domain in route 53 but i'm unsure how s3 would know which folder to serve up as that functionality isn't part of route 53

Anyone have any suggestions?

Thanks for all your help

Answers 1

  • 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 * and if it does, the hostname prefix is request is served from a folder named for the subdomain.        -> my-bucket/lol/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 = '';
    // provide the correct origin hostname here so that we send the correct 
    // Host header to the S3 website endpoint
    const origin_hostname = ''; // see comments, below
    exports.handler = (event, context, callback) => {
        const request = event.Records[0].cf.request;
        const headers = request.headers;
        const host_header =[0].value;
            // prepend '/' + the subdomain onto the existing request path ("uri")
            request.uri = '/' + host_header.substring(0,host_header.length - remove_suffix.length) + request.uri;
        // fix the host header so that S3 understands the request[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.

Related Articles