Redirect any request to another hostname by using this function as Lambda@Edge.
Warning
Host redirecting can also be achieved with CloudFront Functions. We prefer that way because it's easier to maintain and cheaper. We wrote a blogpost about it.
Developed with ❤️ by GRRR
Create a .env
(and/or .env.staging
and .env.production
if you like, or any stage you'd like).
Note that the environment variables are used solely for deployment – a Lambda@Edge function cannot have environment variables.
Deploy the function to your AWS environment, publish a version, and use the ARN of the specific version in a Viewer Request
event handler. This can be configured under Behaviors in your CloudFront distribution.
The role that executes this function should have the permissions as described in the AWS documentation.
Create the file redirect_rules.json
, in which you can add one or multiple host-mappings, like so:
{
"rules": [
{
"origin": "www.example.com",
"target": "example.com"
},
{
"origin": "www.foo.com",
"target": "com.bar.www"
}
]
}
The hostname will be replaced 1:1, no magic is involved.
Optionally, configure a max-age
to determine the time this response will be cached:
{
"rules": [
{
"origin": "www.example.com",
"target": "example.com",
"max-age": 86400
}
]
}
The above would cache the redirect 1 day. If omitted, a Cache-Control
header of max-age=0
(meaning no cache) will be set.
You can use stages to deploy to development
, staging
and production
(default: development
).
- You have the AWS cli tool installed.
- You have configured a profile for this service.
- You have created
.env.staging
and.env.production
files, based on.env.example
(or any stages you wish to deploy). - Make sure the value for
AWS_PROFILE
in the applicable.env
file corresponds to the profile you created in step 2.
npx serverless deploy --stage=staging --env=staging
Replace staging
with any other stage, but make sure the corresponding .env.{stage}
file exists.
.env
is used when stage = development
, which is the default.