ENIについて考えてみた

AWS VPC

VPCでENIが実現されてからしばらく経ったので、いろいろ試した上で出た考えをまとめてみた。

最初に

ライセンスサーバなどを持つ目的でMACアドレスを固定したい、というニーズについては確かに存在するので、これについては、是非使いましょう！

NIC２枚刺しをする目的

オンプレ環境でNICを２枚刺す場合には、以下のような前提や動機があると思われる

  1. アドレス空間が違う(Public IPを使うセグメント、Private IPを使うセグメント)
  2. それぞれのセグメントの間にルータがないため、直接通信ができない
  3. ネットワーク通信のパフォーマンスや冗長性を向上させる(bondingや、WebとDBのトラフィックを分けるなど)
  4. バックセグメントを作ることでセキュアになる

しかしVPCではENIを使ったとしても、

  1. そもそもすべてPrivateアドレス空間である
  2. Subnet間にはRouterがあるので、デフォルトでは何も考えなくても各Subnet間はRoutingされる(Firewall機能もある！)
  3. 物理的な帯域が上がるわけでも、冗長性が向上するわけではない
  4. 元よりインターネットから直接アクセスできない(インターネットゲートウェイ＋ElasticIPアドレスでNATする事はもちろん可能だが)

などの理由により、あまりメリットとはなりません。

そもそもVPCでSubunetを分ける目的は、

  1. Routingを変えたい(Internet GatewayやVPN Gatewayを使用する／しないにより、便宜上のPublic/Private Subnetを定義する)
  2. Network ACLを使ってSubnet間の通信を制御したい
  3. アドレス空間を別にしたい(IPアドレスベースでのアクセスコントロールをもししたいのであれば)

などが考えられますが、VPC(EC2)ではインスタンス単位でアクセスコントロールを行えるSecurity Groupが存在するので、２と３についてはそれほどの動機とはならないと思います。

ENIの落とし穴

ENIのというよりもNICを２枚刺したホストの宿命ともいえますが、Routingの問題が付きまといます。
OSが認識するdefault gatewayは基本的に１つであり(Linuxの場合は0.0.0.0を向けられるのは１つ、Windowsの場合も一見複数存在できるがMetricなどに応じて実際には１つしか機能しない)、２つNICを刺すとさまざまな問題が起こりえます。

meta data server問題

その最たるものは、EC2のmeta data serverへのアクセスができず、OSが起動しないという物です。

detault gatewayがeth0を向いている場合にはmeta data serverにアクセスできますが、eth1に向いてしまっているとmeta data serverにアクセスできません。
→鉄則その１：OS上のdefault gatewayはeth0！

public segment追加パターン

次に、元々privateなsubnetにいたインスタンスに、public subnetのENIを追加したパターンです。

tcpdumpするとわかりますが、public subnetからのパケットはインスタンスに届きますが、戻りのパケットをdefault gatewayであるeth0経由で戻そうとして、routeがないため届かないので、通信ができません。
→鉄則その２：追加したNICからは、routingが必要なホストと通信できない(と思え)
ENIを使う場合には、追加したSubnet内のホストとしか通信しないくらいのつもりで使用するべきです。
厳密にはOS上にstatic routeを設定することで、特定ホストやネットワークと通信させる事は不可能ではありませんが、美しくありませんので却下です。

ではどうするか？

極力ENIを使わない

必要がなければ使わないことです。VPCでは最初に説明したとおり、NIC２枚刺しにするメリットはほとんどありません。

それでもポリシー上使いたい

DBとFrontが同じネットワークに存在してはいけないようなポリシーがある場合を想定して、以下のような構成を考えてみました。

この例では、DBの存在するセグメントをNetwork ACLを使って自閉セグメントとし、同じセグメントとしか通信を行わないように設定します。
フロントサーバ、管理用サーバはDBの存在するSubnetにENIを持ち、default gatewayは元々ついていたeth0に設定します。
VPN Gateway越しに直接DBの存在するSubnetとは通信を行えないため、管理用のインスタンスを置くSubnetを作ります。

まとめ

オンプレミスと同じ構成をとるためだけにENIを使うというのは、あまりメリットがないことがお分かりいただけたと思います。
基本はSecurityGroupやACLによるアクセス制御を検討し、何かしらの制限(ポリシー、ソフトウェアの制約など)により必要な場合にのみENIを使用しましょう。

他にもこんな使い方があるぞ！というのを思いついたら、是非教えてください。