以前は ELB で負荷分散してたんだけど、そろそろ限界を感じてきたり、世界展開などを考えて CloudFront を CDN として導入したいようなケースは結構あるように思います。
- 以前の構成：クライアント <---- https ----> ELB <---- http ----> EC2
- 改善後の構成：クライアント <---- https ----> CloudFront <---- https ----> ELB <---- http ----> EC2
例えば元々 ELB に「www.domain.com」というドメインとその SSL 証明書が配置されていた場合、クライアントからのエンドポイントは変更出来ないので「www.domain.com」の向け先を CloudFront に変更する必要があります。
ただこのとき
- CloudFront のオリジンサーバーとして ELB を設定する
- CloudFront に ELB と同じ SSL 証明書を配置する
- 「www.domain.com」の向け先を CloudFront に変更する
というような単純なステップではうまくいきません。
Cloudfront SSL + ELB SSL, both custom SSL, returns gateway 502
When reviewing your CloudFront distribution it looks like your Origin is listed as the ELB's FQDN. 〜（中略）〜 Since CloudFront makes an SSL connection to your Origin using the "Origin's" domain name, this willf ail since the certificate you have is domain.ca not the ELBs FQDN.
こちらにあるように、CloudFront から ELB に接続する際、ELB の FQDN でアクセスするため、それ用の SSL 証明書でないと通信できません。
例えば東京リージョンで ELB をセットアップした場合は「xxxx.ap-northeast-1.elb.amazonaws.com」のようになるので、元々 ELB に配置されている「www.domain.com」用の SSL 証明書ではアクセス出来ないということです。
ではどうすれば良いか？ということですが、同フォーラムに解決策も書いてあります。
Setup either a wildcard cert (*.domain.ca) or a certificate specifically for your origin (origin.domain.ca)
Modify your distribution to use the CNAME of the Origin (origin.domain.ca). Create a CNAME in Route53 for origin.domain.ca and point that to your ELBs FQDN.
ワイルドカード証明書か ELB 用の新たな証明書をゲットしてそれを利用しましょう、ELB には Route53 設定しましょう、ということが書いてあります。
今回のケースに照らし合わせて考えてみると、下記のような施策で対応できるということです。（ワイルドカード証明書のパターン）
- ワイルドカード証明書をゲットする
- CloudFront／ELB にその証明書を適用する
- ELB に Route53 設定する（例えば「elb.domain.com」）
- CloudFront のオリジンサーバー設定を「elb.domain.com」にする
- CloudFront のエンドポイントを「www.domain.com」にする
これでクライアントからのエンドポイントは変更せず、フロントエンドに CloudFront が配置できるようになります。
めでたしめでたし。