Hi, can some help me with this use case
Today I am serving content for say example.com via Cloud front and created custom origin/behaviours for different paths leading to S3 and some for ALB. All are working fine.
One use case is example.com/anything to be redirected as www.example… basically append www to all the requests. For this someone suggested to build lambda at edge as a function and just use simple javascript based redirection 301 to all the responses with www.example…
Though this approach is working, all the js images and basically any request is going through lambda at edge and adding latency plus all the requests are checked and prepended with www this increasing the cost as well. There’s no caching it seems (by looking at the Lambda execution logs,)
Can anyone suggest the alternative ?
• Can we examin fqdn to see if it has www.example skip it and pass to function to redirect only if it’s example.com ?
• Is there a better way to redirect all example to www.example at some other level?
• R53 we have added a www.example as CNAMe to example, but someone posted R52 won’t do any redirection so we gotta depend on lamda at edge.
Any pointers appreciated, Thanks
I think you have to question the origin of the request. Why does [example.com/thing](http://example.com/thing) need to be redirected to [www.example.com](http://www.example.com) what’s the purpose of that redirect
Thanks for the revert. In general they want to redirect all the example.com to www.example.com not sure if this is related to SEo or something else.
• there are multiple endpoints today severed for ex /abcd is from a S3, /efgh is from another set of ALB so on… default is from another ALB on the Cloudfront behaviours
• Can you please elaborate on the question the origin request? There are some sample codes given in Amazon docs to query for eg: event.Records[0].cf.request would contain request but somehow this code is throwing error saying no reference for [0] with 502 etc.
• Asking in general, how does people redirect these example to www.example?
> Though this approach is working, all the js images and basically any request is going through lambda at edge
That doesn’t sound right. When somebody visits [example.com](http://example.com), they will be served a 301, they will load [www.example.com](http://www.example.com) , they will be served the HTML, which will then load the resources from [www.example.com](http://www.example.com) normally.
Are you referencing all your assets with absolute URLs for the wrong hostname or something? You mention “JavaScript based redirection” – you’re definitely doing a proper HTTP redirect and not serving an HTML page containing a bit of JavaScript, right?
Thanks for the revert.
Yes when I mean all the contents that means whoever come via https:// example . com/js/files or anything is getting redirected via lamda at edge. What I meant by all js and images is, everything. Problem with this approach is no caching so each and every request is checked via the function (all it does is adds location 301 and says take this new location with www.) and that adds latency plus there are charges for the amount of request (today it’s close to 350K+ per hour).
• asking help in A) how does anyone do example to www in general ( not sure this is called redirection or something else)
• B) can we introduce some kind caching for lamda edge if that’s only option so that not everything is hit lamda but intelligently severed because of caching
• C) can the incoming request url be checked inside lambda saying only if the request doesn’t have www then add it else ignore (so that means incoming has www)
thanks
There must be a factor you aren’t mentioning here because what you are describing wouldn’t ordinarily give those results.
Let me give an example. Let’s assume you are serving this as index.html:
<title>Test</title>
<img src="/images/foo.png" alt="Foo">```
And let’s also assume you have `/images/foo.png`.
When a person visits `[https://example.com/](https://example.com/)`, their browser’s request gets sent to the lambda. This then serves an HTTP 301 redirect to `[https://www.example.com/](https://www.example.com/)`. The user’s browser then visits `[https://www.example.com/](https://www.example.com/)`. This is served by CloudFront, which responds with the HTML above. At this point, the user’s browser parses the HTML, sees the `<img>` element, and loads… `[https://www.example.com/images/foo.png](https://www.example.com/images/foo.png)`. Which is, again, served by CloudFront. No redirect. It _doesn’t_ load `[https://example.com/images/foo.png](https://example.com/images/foo.png)`, which would then result in a redirect.
So given the configuration you describe, what you would expect to see is redirects for when people type `[https://example.com](https://example.com)` directly, but what you would *not* expect to see is redirects for any of the assets or subsequent page loads.
Before you mess around trying to cache things or check extra things, first you should figure out what is going on. You can’t solve a problem you don’t understand. So the question is: why are the requests for assets ending up at the lambda?
One explanation is that you aren’t linking your assets with relative URLs and you have the absolute URL wrong. For instance, if the HTML was this instead, that would do it:
```[!DOCTYPE html](!DOCTYPE html)
<title>Test</title>
<img src="[https://example.com/images/foo.png](https://example.com/images/foo.png)" alt="Foo">```
Another explanation is that you have set up `[www.example.com](http://www.example.com)` to go to the lambda, not just `[example.com](http://example.com)`. If you don’t need `[www.example.com](http://www.example.com)` URLs to redirect anywhere, then don’t point `[www.example.com](http://www.example.com)` to a lambda that serves redirects.Thanks for the reply. Looks like hardcoded urls are hitting back to lambda function.
• Since lamda at edge is expensive ( showing ~ 1K$ per month, I am now trying to place set of ec2 instances with nginx running to redirect 
hope this works.
• Idea is to tie ALB to R53 , and this ALB will have a auto scalling groups of nginx which would only do redirection with www.
• But On a separate note, how does one setup these kind of redirections ?
Thanks
If you’ve got an ALB in the way, the ALB can perform the redirect.
I would caution against an ALB. It is likely the most expensive, least reliable solution, since it is basically running all the time, and is region constrained. Also it won’t do url rewrites.
So nginx based redirect is the only cost effective one when put inside auto scaling that can be the reliable one I guess. Thanks all for the reply.
