Whether Cloudfront Origin can be a Route 53 recordset created for Application Load Balancer DNS?

Question

Я создал набор записей Route53 для DNS балансировщика нагрузки приложений AWS. Мой вопрос в том, может ли источник AWS Cloudfront содержать этот URL-адрес набора записей или нет?

For example: ALB DNS name: xxxx.us-east-1.elb.amazonaws.com. Recordset Entry in Route53 for application load balancer DNS: www.abc.com

Now can I put www.abc.com as origin in cloudfront ?

Answer 1

If you set the Origin Protocol to HTTPS Only, the traffic between CloudFront and the ELB will be secured by TLS, and you can configure the actual origin domain name either way. The Cloudfront-Forwarded-Proto header will indicate the protocol used between CloudFront and the viewer (since in this configuration, the load balancer will always set X-Forwarded-Proto: https).

CloudFront insists that the TLS negotiation between itself and the Origin be trustworthy. A factor commonly overlooked is that TLS (SSL) certificates do two things: provide for encryption of the connection (obvious) and provide for authentication of the server -- attestation that the server is authorized to be a server for the requested hostname, and is not an impostor (less obvious). This is why you get browser warnings if the server's certificate's subject and/or subject alternative name doesn't match the hostname in the browser's address bar.

CloudFront allows a limited exception to this requirement, allowing certificate validation to succeed as long as one of two conditions is met:

• The ELB must present a certificate matching the Origin Domain Name, or
• The ELB must present a certificate matching the Host header that CloudFront is forwarding from the browser to the ELB.

Otherwise, CloudFront returns 502 Bad Gateway.

The first condition isn't possible if you use the ELB hostname as the Origin Domain Name, which is why the CloudFront console prompts you to whitelist the Host header for forwarding if it sees that your target is an ELB.

But as long your environment looks like this...

• www.example.com points to CloudFront and is configured in the distribution's Alternate Domain Name, and
• The Host header is configured for whitelisting, and
• The ELB hostname is set as the Origin Domain Name, and
• The ELB has a valid cert for www.example.com

...then it works, with one exception: the dzczcexample.cloudfront.net domain can't be used in the browser to access your origin through CloudFront. In some configurations, this is desirable, because you don't actually want your content accessible via that second entry point.

Otherwise, your best bet is indeed to do what you have suggested -- mapping a hostname in a domain that you control onto the ELB in DNS, and configuring that hostname as the origin domain name in CloudFront.

CloudFront can use any Internet-accessible hostname as its origin -- the origin doesn't have to be inside AWS. You could, for a random example, use a Google Cloud Storage bucket as an Origin in CloudFront. The integration between CloudFront and the Origin is a loose one -- by that, I mean that CloudFront has no special awareness of ELB. It just resolves the hostname via public DNS and makes connections.

Note also, if you want to ensure that only your CloudFront distribution can talk to your origin, you will want to configure a secret Custom Origin Header in CloudFront, and the Origin needs to reject requests that lack this value. While it is possible to use the ELB security group to allow access only from the CloudFront address space, that space grows fairly often and you need a way to keep your security groups updated to allow new address ranges... but it is my opinion that this provides a false sense of security, since anyone can technically create a CloudFront distribution and point it anywhere, including your ELB. Using a custom header avoids this.