- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
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
.
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.
Thanks for the detailed response. The bucket is private, the distribution has access through an OAI policy. I can switch to OAC but it's working as-is.
I'm not trying to rewrite the host, I am trying to access the subdomain from the request to rewrite the request.uri to the appropriate subdirectory in the origin bucket. Exposing the
Host
header in the CachingPolicy seems like the correct way to give the CloudFunction access to the information but in doing so, it also causes theSignatureDoesNotMatch
error.In my digging, an example using Lambda@Edge suggested manually changing the
request.header.host
to the origin host (bucket) in the function (my assumption being this is a means to avoiding theSignatureDoesNotMatch
issue)— and I agree with you, I don't want to do this. I don't think it should be necessary.I am building an internal dev tool with automated deployments that are low traffic / ephemeral / discarded. Using a single CloudFront distribution for the wildcard DNS and single bucket felt like the right amount of complexity. There's nothing more to automate other than syncing to s3 and letting the deployments expire with a reasonable cache policy.
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 ?
Single target bucket, I am asking if it's possible to use a CloudFunction and not Lambda@Edge. It does not seem to work.
Sure, I see now !
Why you would want to have it at CF function, is it so that you can take take advantage of CF caching I suppose (which will be no different even if you use Lambda@Edge)?
Anyway, were you able to test if path rewrite is working properly ?
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
I'm working on the same solution and I'm stuck on the same problem. Can you share more details how did you solved it? How do you rewrite request.uri?
here are the basics: