前提
AWSのManaged ServiceでMulti-AZ配置出来るものは幾つか(RDS / ElastiCache)ありますが、Security Groupの設定で少し注意が必要です。
先日、http://aws.amazon.com/blogs/aws/elasticache-redis-multi-az/ で ElastiCache for RedisのMulti-AZ配置とAuto Failoverが発表されました。
今まで、Multi-AZやAuto Failoverを考慮していないSecurity Groupの設定をそのまま使い続けると、知っていれば物凄く単純ですが少しハマりポイントがあるので簡単にまとめます。
これは、自前でMulti-AZでHA構成をとっている場合にも適用出来ると思います。(例えば、NATインスタンスや自前でMulti-AZで配置しているDBサーバやCacheサーバなどなど)
注意点
構成
今回は以下のVPCを使用します。今回はCacheを例に使用していますが、RDSや自前で構築したDB / Cache / NATインスタンスなどでも同様です。
また、問題が発生するタイミングは初回構築時だとテストで気づきやすいのですが、Failoverテスト時や実際にFailoverが発生したタイミングで問題が顕著化する可能性もあります。
Security Group
今回の様な構成で、今まで、Availability Zone AにのCacheサーバ(Redis)があり、今回Availability Zone BにReplication Groupを作成したとします。
ElastiCacheの構成は以下の様な状態とします。
test-002, 003が新規追加分のMulti-AZノードだとすると、今回はAZ-AとAZ-Cに1ノードずつ所属していることになります。
この状態で、以下の様なSecueity GroupがCacheノードに設定されていたとします(AZ-Aに今までノードが存在していたという前提で)
ElastiCache for RedisのReplication Groupではnode毎にSecurity Groupを設定するのではなくGroupで共通で設定されます。そのため今回の設定ではAZ-Bのノードにアクセスすることが出来ません。
もちろん
の様にすることでアクセスすることが出来ますが、先ほどの設定もこちらの設定も、このサブネットやVPCに所属するインスタンス全てからアクセス出来てしまいます。
Secueity GroupはSourceにSecueity Groupを指定出来るため、Cacheノードにアクセスを許可するインスタンスのみに絞ってアクセス許可を与える事ができますし、こちらがセキュリティの観点からもお勧めです。
以下の例では、アプリケーションサーバ用とCacheノード用のSecurity Groupを作成して、cacheノードに対して、アプリケーション用Security Groupからのみアクセスを許可しています。
- アプリケーション・サーバ用 (例: survey)
- SSHを全ての接続元から許可していますが、これはテスト用なので、必ず接続元は絞るようにして下さい
- cacheノード用
このようにSecurity GroupをSourceてして指定することで、VPCやSubnetに依存することなくPrivate subnetやManaged Subnetなどのインターネットからアクセスする必要がない(接続元が可変)場合Secueity Groupを再利用可能しやすくなると思います。
おまけ
Security Groupをうまく使うことで、Single Subnetで複数階層構造を作成することが可能です。Public / Private Subnetを作成してNATインスタンスなどを経由してなどという設計も1つのVPCのNW設計ではあるのですが、以下の図の様に1つのSubnetでSecurity Groupをうまく用途ごとに使用してNWを設計することも可能です。
もちろん、Security Groupが増える可能性や管理の問題・パフォーマンスの問題があるのであくまで1つの考えでこのようなものがあるということで、VPCのやSubnetの設計をする際は慎重に。
こちらは個人の意見で会社とは関係ありません。お約束です。