Configure multiple static sites mapping subdomains to S3 subdirectories using CloudFront, a CloudFunction, and Route53

Question

Is it possible to use a **CloudFunction** to configure the desired behavior? Are there some obvious things to try that I am missing? - `http://subdomain1.my-domain.com` >>> `s3://my-bucket/subdomain1/index.html` - `http://subdomain2.my-domain.com` >>> `s3://my-bucket/subdomain2/index.html` ---- Current configuration looks like this: **Route53** - A Record is configured for wildcard `*.domain.com` **S3** - A single private bucket - Contains deployments like the following: ``` my-bucket/subdirectory1/index.html my-bucket/subdirectory2/index.html ``` **CloudFront** - CachePolicy exposes `Host` - OriginRequestPolicy uses the managed `CORSS3Origin` - OAI policy grants the distribution access to the private S3 Bucket **CloudFunction** - Rewrites `request.uri` using subdomain as subdirectory from `request.headers.host.value`. The wildcard domain is configured correctly, I can reach the Cloudfront distribution at `abc.domain.com` and `def.domain.com` etc. I believe the problem exists between CloudFront and S3. When the CachePolicy header includes `Host` for the CloudFunction, I am able to use the value to grab the subdomain to rewrite `request.uri`. However, including `Host` results in a `SignatureDoesNotMatch` error response from CloudFront. I see this error: ``` SignatureDoesNotMatch The request signature we calculated does not match the signature you provided. Check your key and signing method. ... ``` I have found an older example using **Lambda@Edge** not a CloudFunction— I thought I would ask here before giving it a try because this example edits the `request.headers.host` and I have a feeling that the example was created before the header was readonly. FWIW, I also have many working deployments without the wildcard domain where the static site is in the root of the bucket. Thanks for any insights!

Accepted Answer

I figured it out, I was missing `s3:ListObjects` in permissions.

There was no need to include `Host` in the caching policy header items and in fact including `Host` did break the signing—which sent me down this path. Removing it set things right.

I was able to use the CloudFunction just fine to rewrite `request.uri`.

Answer

It's not clear to me why you need to rewrite the host header when requesting items from S3. I think what you're doing is setting up the S3 bucket as a website but you don't have to do that - it's far easier and more secure to disable public access on the S3 bucket and use Origin Access Control (OAC) to secure access from CloudFront to S3: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

When you do that you can configure a combination of behaviours and origins (you can have multiple origins, each pointing to a different prefix (read: folder) in S3) and then use a Lambda@Edge function to ensure that the correct origin is selected based on the `requests.headers.host` (because that will match the DNS request by the client).

That said: I'm also curious as to why use a wildcard in Route 53 and a single CloudFront distribution here. I'm not saying it doesn't make sense - if you have thousands of potential hosts/websites then having a single distribution and a single Lambda@Edge then it is (in a sense) quite simple.

However, consider that there is no charge CloudFront distributions. A simpler configuration would be to configure a CloudFront distribution per host/website. This gives you far more granular control over each individual website - there's no shared fate in terms of caching or other CloudFront settings. You can still use a single S3 bucket at the back end (sharing the OAC) so you don't have to change the structure there at all; but you could also have multiple S3 buckets if you wanted to. This mechanism allows you to do away with Lambda@Edge which saves some cost. But there would need to be more Route 53 records.

I could also argue that the existing solution is quite complex in that an erroneous change could affect all of your hosts/websites.

Either way: Whether you use the existing solution (wildcard DNS record, single CloudFront distribution, Lambda@Edge) or a different one (multiple DNS records, multiple CloudFront distributions) I strongly recommend that you automate the deployment and management of the solution. As you do more and add additional hosts/websites it will save you time and reduce errors through misconfiguration.

Answer

Not sure if I missed something in details, do you have a single target bucket or multiple ? If its single bucket and only sub folders need to map to subdomains, why cant you use OAC combined with origin Edge lambda to pick dynamic origin and apply the path instead ?

Configure multiple static sites mapping subdomains to S3 subdirectories using CloudFront, a CloudFunction, and Route53

Relevant content