【入門編】 ENI(Elastic Network Interface)のセカンダリプライベートIPアドレスとアタッチメント制御 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！SRE兼クラウドアーキテクトの私です。

日々のインフラ運用やAWSでのシステム設計、本当にお疲れ様です！「AWSのVPCって何となく動いているけれど、パケットやネットワークの裏側で何が起きているのか、実はモヤモヤしている……」そんな風に感じたことはありませんか？

今回は、AWSのネットワークの心臓部とも言える「EC2インスタンスへの複数IPアドレスの割り当て」と、そこでこっそり裏で動いている「ちょっとずる賢いネットワークの仕組み」について、一緒に紐解いていきましょう。

難しい専門用語はなるべく避けて、身近な例え話から一歩ずつ進んでいきますので、どうぞリラックスしてついてきてくださいね！

—

郵便配達で例える「IPアドレス」と「ENI」の基本

まずは、私たちが普段暮らしている現実世界に置き換えて考えてみましょう。

AWSのEC2インスタンスという「マンション（サーバー）」を想像してください。このマンションには、最初は「1つの部屋番号（プライマリIPアドレス）」が割り振られています。郵便局（AWSのネットワーク）は、その部屋番号宛てに手紙（パケット）を配達しますよね。

ここで、ENI（Elastic Network Interface）というのは、そのマンションに新しく取り付けた「別の玄関口（ネットワークの差込口）」のようなものです。そして、セカンダリプライベートIPアドレスとは、その玄関口のなかにさらに追加した「同じ部屋の中の別のポスト（追加のIPアドレス）」だとイメージしてください。

さて、ここで一つの疑問が湧き上がってきます。
「同じマンション（1台のEC2）に、複数の玄関口やポストを付けたとき、外から来た郵便屋さんは、どうやって宛先のポストを正確に見分ければいいのでしょうか？」

ここで登場するのが、今回の主役である「Proxy ARP（プロキシ・アープ）」という、AWS仮想ルーターのちょっとした「裏技」なんです。

—

ARP（アープ）ってなぁに？

ネットワークの世界では、手紙（パケット）を届けるときに「相手のIPアドレス（宛先の住所）」だけでは届きません。最終的には「MACアドレス（相手の物理的な玄関の表札）」を指定しないと、同じネットワーク内の機器には届かないルールになっています。

そこで、ネットワーク機器はこう叫びます。
「おい！『10.0.1.50』っていうIPアドレスを使っている人、表札（MACアドレス）を教えてくれ！」

これが ARP要求（アドレス解決プロトコル） です。現実世界で言うなら、アパートの廊下で「この住所の人、誰ですかー？」と大声で叫ぶようなものですね。

普通の世界であれば、そのIPアドレスを持っている本人が「はい、私です！私の表札はこれです！」と返事をします。これをARP応答と言います。

しかし、AWSのクラウド世界（仮想化ネットワーク）では、このやり取りがちょっとユニークに、かつスマートに行われています。

—

AWS仮想ルーターが仕掛ける「Proxy ARP」の魔法

1台のEC2インスタンスに、複数のENIやセカンダリIPを設定したとき、AWSの基盤側にある「仮想ルーター」が非常に巧妙な動きをします。

外部の誰かが、「おい、10.0.1.100（セカンダリIP）の表札を教えてくれ！」とARP要求を投げたとしましょう。

本来なら、そのIPアドレスを持っているEC2インスタンス自身が返事をすべきですが、AWSの仮想ルーターは、EC2インスタンスの代わりに、こう割って入ります。

「あ、その人なら私（仮想ルーター）の管轄だよ！宛先はこのENIのMACアドレスにして送ってよ！」

これが Proxy ARP（代理ARP） の正体です。
つまり、AWSの仮想ルーターが「代理人」となって、宛先のIPアドレスに対する正しいMACアドレス（ENIの物理的な表札）を代わりに答えてくれるのです。

これにより、EC2インスタンスの中のOSが特に複雑な設定をしなくても、AWS基盤側がよしなにトラフィックを適切なENIやセカンダリIPへと導いてくれるというわけなんですね。優しい世界です！

—

実務で役立つ！AWS CLIでのENI・セカンダリIPアタッチメント制御

「なるほど、裏側では仮想ルーターが頑張ってくれているんだな」と分かったところで、今度は実際にAWS上でこれをどう設定するのか、実務で使える手順を見ていきましょう。

今回は、AWS CLIを使って、既存のEC2インスタンスに新しいENIを作成し、アタッチした上で、セカンダリIPアドレスを割り当てる一連の流れをご紹介します。

ステップ1：セカンダリENIの作成とアタッチ

まずは、VPC内に新しいENIを作成し、それを対象のEC2インスタンスにガチャンと差し込みます。

# 1. サブネット内に新しいENI（ネットワークインターフェース）を作成する
aws ec2 create-network-interface \
    --subnet-id subnet-0123456789abcdef0 \
    --description "Web-Server-Secondary-ENI" \
    --groups sg-0123456789abcdef0 \
    --region ap-northeast-1

# 上記コマンドの実行結果として返される "NetworkInterfaceId" (例: eni-0abcdef123456789) をメモしておきます。

# 2. 作成したENIを既存のEC2インスタンスにアタッチする（デバイスインデックスは 1 を指定）
aws ec2 attach-network-interface \
    --network-interface-id eni-0abcdef123456789 \
    --instance-id i-0123456789abcdef0 \
    --device-index 1 \
    --region ap-northeast-1

ここで重要なのが --device-index 1 というパラメータです。
デバイスインデックス 0 はすでにメインの玄関（プライマリENI）で使われているため、追加のENIには 1 以降の番号を割り当てていきます。

ステップ2：セカンダリプライマリIPアドレスの追加

次に、すでにあるENIに対して、さらに「追加のポスト（セカンダリIPアドレス）」を紐づけてみましょう。

# 指定したENIに対して、セカンダリIPアドレスを自動割り当て（または手動指定）する
aws ec2 assign-private-ip-addresses \
    --network-interface-id eni-0abcdef123456789 \
    --secondary-private-ip-address-count 1 \
    --region ap-northeast-1

これで、AWS側の設定は完了です！
AWSの仮想ルーターとProxy ARPの仕組みによって、この新しく追加されたIPアドレス宛てのパケットも、正しくこのENIへと届くようになります。

—

OS側（Linux）でのルーティング設定の注意点

AWS側で準備が整い、Proxy ARPがうまく働いてパケットがインスタンスの玄関口（ENI）まで届いたとしても、LinuxなどのOS側が「あれ？どの玄関から入ってきた通信だっけ？」と迷子になってしまうことがあります。

特に複数のENIを使うマルチホーム環境では、「入ってきた通信は、同じ玄関からお返しする（ポリシーベースルーティング）」という設定をOS側で行うのが、現場のエンジニアとしての腕の見せ所です。

Linuxのルーティングテーブルや iproute2 を使った設定の一例を見てみましょう。

# 1. 追加したセカンダリENI用のルーティングテーブルを /etc/iproute2/rt_tables に定義する
echo "200 eni1" >> /etc/iproute2/rt_tables

# 2. 独自のルーティングルールを追加（ENI1宛てのトラフィック専用の通り道を作る）
ip route add 10.0.1.0/24 dev eth1 table eni1
ip route add default via 10.0.1.1 dev eth1 table eni1

# 3. そのIPアドレスからの発信通信は、必ず専用のテーブルを使うようにルールを設定
ip rule add from 10.0.1.50 table eni1

※上記の設定は一時的なものです。実運用では、ディストリビューションごとのネットワーク設定ファイル（NetplanやNetworkManagerなど）に記述して、永続化させることを忘れないようにしてくださいね！

—

まとめ

今回は、AWSのENIとセカンダリIPアドレス、そしてそれを支える仮想ルーターのProxy ARPの挙動について、郵便配達の例えを交えながら解説しました。

ENIとセカンダリIP は、1台のサーバーに複数の玄関とポストを追加するようなもの。
Proxy ARP は、AWSの仮想ルーターが「代理人」となって、宛先のMACアドレスを賢く答えてくれる仕組み。
実務では、AWS側の設定だけでなく、OS側のルーティング（ポリシーベースルーティング）もセットで整えることが大切。

一見すると難しそうに見えるクラウドのネットワークも、一つひとつの挙動を紐解いていくと、非常に理にかなった、よくできた仕組みであることが分かりますよね。

日々のインフラ構築やトラブルシューティングで、「お、あのときブログで読んだProxy ARPがここで動いているな！」とイメージを膨らませていただけたら、SREとしてこれほど嬉しいことはありません。

それでは、また次回の技術解説でお会いしましょう！快適なクラウドライフを！