【Amazon Route 53】2014-07-02のヘルスチェック機能の強化・追加を確認してみた
こんにちは、三井田です。
昨年よりAmazon Route 53のヘルスチェック機能の強化・改善が続いています。今年に入ってからも、既に4つのリリースがありました。
- 2014-02-18: ヘルスチェック間隔と閾値
- 2014-04-09: CloudWatchメトリックHealthCheckStatusの「0」か「1」かのブーリアン値化
- 2014-04-30: ドメイン名によるヘルスチェック
- 2014-07-02: ヘルスチェック設定の編集が可能に。タグ付け機能追加。新APIでヘルスチェックのアクセス元IPアドレスレンジ、ヘルスチェック総数が取得可能に。
このエントリーでは、4について紹介したいと思います。1〜3までは、以下のエントリーを参照ください。
『Amazon Route 53に多数の新機能が追加されてた』
では、これから、2014-07-02の機能強化・追加を確認していきます。
AWSのブログ『【AWS発表】Route 53のヘルスチェック機能のアップデート - 編集とタグ付け』に既に紹介されているので、差分やちょっとした注意点を説明したいと思います。
ヘルスチェック設定の編集
既存のヘルスチェックの設定を編集できるようになりました。
ただし、注意点があります。課金が変わるオプション項目は編集できません。また、IPアドレスでチェックをするかドメイン名でチェックをするかは編集できないようです。
タグ付け機能
こちらは、AWSのブログにあるとおりなので割愛します。
新しいAPI:ヘルスチェック元IPレンジの取得
こちらは非常にうれしい機能です。ヘルスチェックは世界中のリージョンより実施されます。
送信元をセキュリティグループで絞ることができないと、全世界からのアクセスを許可しなくてはならないこととなり、便利なヘルスチェック機能を積極的に使うことが出来ません。
改めて調査すると、従来もDiscussion Forumsに、『Amazon Route 53 DNS Failover - IP Ranges Used By Health Checkers』というエントリがあり、IPレンジが公開されてました。しかし、機械的に更新有無をチェックしたり処理するには不便といった印象でした。
では、今回追加された『GET GetCheckerIpRanges』APIで、ヘルスチェックのアクセス元のIPレンジを取得してみましょう。
AWS CLIは、1.3.22以降でサポートされている模様です。
$ aws --version aws-cli/1.3.24 Python/2.7.5 Darwin/13.2.0
$ aws route53 get-checker-ip-ranges { "CheckerIpRanges": [ "54.228.16.0/27", "54.228.16.32/27", "54.232.40.64/27", "54.232.40.96/27", "54.241.32.64/27", "54.241.32.96/27", "54.243.31.192/27", "54.243.31.224/27", "54.245.168.0/27", "54.245.168.32/27", "54.248.220.0/27", "54.248.220.0/27", "54.248.220.32/27", "54.251.31.128/27", "54.251.31.160/27", "54.252.79.128/27", "54.252.79.160/27" ] }
(14行目と15行目に重複した値が入ってますが)バッチリIPアドレスのレンジが取得できますね。
Forumの記載とは、CIDRが異なってますが同一のレンジを示してますね。
これでしたら、容易にIPレンジを取り出して、EC2のセキュリティグループのルールと照合したり、追加・削除が出来そうですね。
ヘルスチェックはCloudWatch *1で状態を監視できますので、異常を検知した際の一次切り分け手順も容易にスクリプトとして実装できそうです。
新しいAPI:ヘルスチェック総数の取得
従来も『GET ListHealthChecks』APIでリストを取得し、要素をカウントすれば総数は取得できましたが、『GET HealthCheckCount』直接値を取得できるようになったようです。
$ aws route53 get-health-check-count { "HealthCheckCount": 4 }
まとめ
今回のリリースでは、次のような点で非常に使い勝手が向上したと思います。
- 設定変更時に、削除+追加ではなく編集できることにより、課金も2重にならず、CloudWatchの値も引き継がれます
- タグ付けにより、コスト配分レポートによりこすと管理できるようになりました
- アクセス元を絞る処理が容易に実装できそうです
次のエントリーでは、Elastic Load Balancingサービスがどうしても利用できないというニッチなケースに、Amazon Route 53のヘルスチェックとWeightベースクエリを利用して対処する方法を考えていきたいと思います。
脚注
- ヘルスチェックのCloudWatchメトリックは、us-east-1リージョンを指定する必要があります。 ↩