AWS CloudFront is a powerful reverse proxy tool than can help speed up and secure your websites. Here are a few steps to help you integrate it with your Servd project:
Create the Distribution(s) - CloudFront distributions are the wrappers around everything else. Each distribution can be set up to handle multiple domains, but we normally recommend creating one distribution per domain. Some general settings such as domains and SSL certificate management are defined on the distribution directly.
Set up the Origin(s) - Each distribution can have multiple origins. An Origin is a back-end server that CloudFront will proxy traffic through to. The settings for these are things like the domain for the origin, whether to connect via HTTP/HTTPS, timeouts, etc.
Set up the Behaviour(s) - these map incoming requests to Origins, following specific rules. All distributions have a default behaviour which acts as a catch-all, but you can also create other behaviours which only apply to specific paths. This can be useful if you only want to capture traffic hitting a specific subpath for a domain.
DNS and SSL Certificates
When creating an Origin which points to Servd, CloudFront will require a domain name, as it doesn't allow IP addresses. So you'll need to create a domain within Servd (e.g `origin.mysite.com`) and hook up the DNS for it. You can then use `origin.mysite.com` as the origin domain in your CloudFront settings. You should also add into Servd the domain that end users will be using because...
By default AWS will then send `origin.mysite.com` over to Servd as the `Host` header. Craft will think that this is the domain being used to access the site by the end user, so by default it'll start outputting things like control panel links with this domain. To get Craft to stop doing that, we need to forward the original client `Host` header to Servd instead. You can do this in the behaviour settings by adding `Host` as a whitelisted header.
This creates an SSL complication however: AWS expects the Origin to respond with an SSL certificate that matches the `Host` header, but Servd can't generate an SSL cert for `mysite.com`, because the DNS for that is pointing to CloudFront, not Servd. So Servd will send back an `origin.mysite.com` SSL cert, and AWS will reject the connection.
There's a couple of ways to get around this:
Use a custom certificate for `mysite.com` and add it to Servd for that domain. This is a quick way to make sure that Servd is able to respond to AWS's requests with a `mysite.com` certificate, even though we haven't been able to generate one for you.
Set everything up with expected settings, but leave the Origin settings in CloudFront to only connect to Servd via HTTP, not HTTPS, then let us know via one of our support channels that we need to perform a manual certificate generation process. We can then forcibly validate the domain DNS (which would normally fail) and trigger the certificate generation process. This should go through ok because AWS is only talking to Servd via HTTP. Your Craft project will have errors during this process because the end user will have connected via HTTPS, but Craft will think they used HTTP, but that'll only be temporary. Once the certificates have generated on Servd the origin can be switched back to HTTPS.