TL;DR
Amazon Route53 のトラフィックフローは、複雑なルーティングポリシーを実現するための魅力的なソリューションです。ただし、カンニングはできなさそうです（後述）。
目的
オンプレに２台のWebサーバがあり、それぞれ個別のグローバルIPを持っています。これら２台ともコケた場合の BCP 対策として、S3+CloudFront で構築した Sorry ページを表示するというのを Route53 を使って実現することを考えます。なお、HTTPS 対応の構成図を掲載しますが、HTTPS 自体は本質的ではないので説明は省略します。
本来の構成は、インターネットから見て Web サーバー群の前段にロードバランサーがあって、そいつが回線負荷を考慮してこれらのいずれか一方 の A Record を返す（ように DNS Responseを書き換える）ということをやっているらしいです。しかしながら、Route53 からは回線負荷の状況などわかるはずもないので、A Record として両方の IP をなるべく公平に返してやることにします。
考え方
２台のWebサーバーを合わせた１個の仮想的なサービスを現用系、Sorry ページを待機系とするフェイルオーバー構成として構築します。まず、テスト用に立てた２台のサーバ fo-test1, fo-test2 に対して、それぞれ HTTP でヘルスチェックを行います。さらに、『これらいずれかが稼働中』を表す仮想的なヘルスチェック either-ok を作りました。ちなみにヘルスチェックの価格は、AWS 以外のエンドポイントに対して１件あたり0.75$／月です。HTTPS監視とか監視間隔を短くしたいといった向きには、多少オプション価格が上乗せされます（Amazon Route53 料金）。
複数の IP アドレスを公平に返すのは、ルーティングポリシーの Multivalue Answer で実現可能です。これらを組み合わせて、以下のようにすることにします。
| Case | fo-test1 | fo-test2 | either-ok | A Record |
|---|---|---|---|---|
| 1 | Healthy | Healthy | Healthy | fo-test1, fo-test2 |
| 2 | Healthy | Unhealthy | Healthy | fo-test1 |
| 3 | Unhealthy | Healthy | Healthy | fo-test2 |
| 4 | Unhealthy | Unhealthy | Unhealthy | xxx.cloudfront.net |
ところが、『これらいずれかが稼働中』をフェイルオーバーの現用系とするための設定方法が、どうしてもわかりませんでした。仕方がないので、最後の手段としてトラフィックフローというのを試してみました。これは、複雑なルーティングをビジュアルエディタで構成でき、ルールのバージョン管理やロールバックも自由にできるという優れものです。
なぜ最初からこれでやらなかったかというと、これがちょっとお高いからです（ポリシーあたり50$／月）。
結果的には、めちゃくちゃ簡単。２分で設定完了。
カンニング失敗
実は、トラフィックフローとかいいながら、実は単にビジュアルエディタで設定した内容を通常のリソースレコードに展開するんだろう。だからそれを書き留めて、トラフィックフローを解除してそれらのルールを手で追加すれば料金かからないはず。俺って天才じゃね？、的なことを当初考えていました。
ところが、トラフィックフローの機能としてはちゃんと動いているのに、リソースレコードの一覧には "Traffic policy record" の１件しか表示されません。どうも、トラフィックフローはリソースレコードとは完全に別管理になっており、その詳細ルールはリソースレコードとしては見えないようです。使いたかったらちゃんと金払えってことですね。
