hiroohiのメモ

はてななのでITやスタートアップ周りの話(ほとんどが自分への備忘録だけど)を書いています。

S3+CloudFront+Route53で503なSorryページを安価に実現する

Amazon Route53のフェイルオーバー機能を使ってサイトのメンテナンス(Sorry)ページを表示しようとするとき、 お手軽にS3のwebホスティングでsorry画面を出してしまうと、ステータスコードが200や403になるため、検索エンジンにSorry画面が登録されてしまいます。 ちょっと恥ずかしいです。

それを防ぐために、シンガポールregion等に一番安いEC2インスタンスをたてて、sorry画面を出すwebサーバを動かしてたのですが、 S3+CloudFrontでステータスコード503を出すsorryページを運用できそうなので、やってみました。

S3に適当なbucketを作り、sorryページ用のhtmlや画像をアップする。

※画像やcssはサイト相対パスで参照するとはがれないです。

CloudFrontディストリビューションを作る

  • Origin Domain Nameには上で作ったS3 bucketを指定。

  • Distribution Settings の Alternate Domain Names(CNAMEs)に、sorry画面を出す対象のwebサイトのFQDNを指定。

  • 他はデフォルトでOK

ディストリビューションを作成したら、その編集画面を表示して、

Error Pages タブの「Create Custom Error Response」をクリック、

  • HTTP Error Codeに403を設定

  • Resonse Page PathにはS3にあげたsorryページのhtmlファイル名を相対パスで設定

  • HTTP Response Code には 503:Service Unavailable を指定。

CloudFrontにアクセスできるようになったら、確認

sorryページを直接指定して200が返ってくること、 存在しないページを指定したときは503とsorryページが返ってくることを確認

Route53を設定

Route53で、対象のwebサイトの

  • Routing PolicyをFailoverに設定し、

  • Failover Record TypeをPrimaryに、

  • Evaluate Target Health:をYesに設定変更する。

対象webサイトと同じ名前のレコードを新しく作り、

これで完成。

動作確認するには、対象のwebサイトのnginx等を落としてELBがOut of Serviceになるようにし、 その後URLをたたくとSorryページが表示され、その後nginx等を起動してELBがIn Serviceになったらサイトが表示されればOK

どっちが安いの?

EC2インスタンスをus-eastでt2.nanoでたてた場合、アクセスがあってもなくても月額$4.7くらい掛かる計算でした。

一方、この方法ですと、S3の費用も容量がわずかですし、CloudFrontへのアクセスもsorry画面ですから殆どなく、$0.2程度ですみそうです!

デメリットは?

既にCloudFrontでホストしているサイトは、同じFQDNでAレコードのエイリアスとして登録できないので、この方法ではRoute53のFailover機能のセカンダリとして登録できなさそうです…。