オンプレのファイアウォールポリシーをAWSに移行する

　オンプレミスに設置されているサーバをAWSに移行する場合、サーバの通信経路上の存在するファイアウォールのポリシーもAWSへ移行する必要があります。多くの場合、ポリシーの移行先はセキュリティグループになると思います。セキュリティグループはオンプレのFWと実装方法が違いますので、そのまま移行するのは難しいです。

　自分の備忘の含めて、これまで見つけたいい感じの移行方式をまとめます。

移行方式その１

オンプレミスのファイアウォールポリシー

　同一システムのWEBサーバ群から、同一システムのDBサーバ群へのDBアクセスの通信を一括で許可するポリシーです。よく見る設定方法だと信じたい。

セキュリティグループの実装方法

　以下の二つのセキュリティグループを作成します。そして、AWS上に移行したWEB1とWEB2、WEB3に「sg-web-server」を、DB1とDB2、DB3に「sg-db-server」を適用します。

sg-web-server

sg-db-server

　セキュリティグループの「Source/Destination」には、IPアドレスだけではなく、セキュリティグループを選択することができます。この設定を行った場合、「Source/Destination」は、選択したセキュリティグループが適用されているEC2のIPアドレスが利用されます。

　上記の例ですと、sg-db-serverはDB1とDB2、DB3に適用されていますので、sg-web-serverで許可されるMySQLの宛先アドレスはDB1とDB2、DB3になります。

　この便利な機能は、オンプレのファイアウォールにおける「グルーピング」の機能だと考えることが出来ます。この機能を利用することで、サーバごとに設定を行う必要があるセキュリティグループを効率的に設定することができます。

移行方式その２

オンプレミスのファイアウォールポリシー

　とあるセグメント内の端末が共通で利用するシステムを許可するポリシーです。これもよく見る設定方法だと信じたい。

セキュリティグループの実装方法

　以下のセキュリティグループを作成し、セグメント内に配置するサーバに適用します。

Name:network-service

　セキュリティグループは、1つのサーバに複数個適用することができます。そこで、サーバ共通の設定を一つのセキュリティグループに集約することで、メンテナンス性を向上することができます。

　たとえば、DNS resolverをリプレースしIPアドレスが変更となった場合、上記のセキュリティグループがあれば、このセキュリティグループのDNS resolverのIPアドレスだけを変更するだけでOKです。

　もし、サーバごとに一つのセキュリティグループを設定しており、そのセキュリティグループでDNS resolverへのDNSを許可していたとしたら、すべてのサーバに適用されているセキュリティグループを変更しなければなりません。

最後に

　セキュリティグループの仕様を利用した移行方式をまとめました。なお、移行にあたって一番大変な作業は通信要件の精査です。俺「このポリシー何？いるの？いらないの？」サーバ担当「昔のことは知らん」みたいなやり取りを繰り返すのはこりごりです。