BIG-IP on EC2のInternal ENIは同一のサブネットにターゲットが存在しないのであれば不要な件
2025.07.25BIG-IP on EC2において、Internal ENIは本当に必要なのか気になる
こんにちは、のんピ(@non____97)です。
皆さんはBIG-IP on EC2を用意するとき、Internal ENIは必要なのか気になったことはありますか? 私はあります。
F5公式ドキュメントを見ると、BIG-IP VEを使って、BIG-IP on EC2のHAクラスターを組む場合、以下のようにInternal Subnetを用意し、そこにInternal ENIを生やしているものがあります。
抜粋 : f5-aws-cloudformation-v2/examples/failover at main · F5Networks/f5-aws-cloudformation-v2
抜粋 : Amazon Web Services: Three-NIC F5 BIG-IP Virtual Edition
しかし、以下検証で確認しているとおり、BIG-IPインスタンスからターゲットとなるWebサーバーのアクセスログを確認すると、ヘルスチェックやクライアントからのアクセス時は全てExternal ENIのプライマリIPアドレスが記録されていました。
つまりは、Internal ENIから通信は流れていなさそうです。
実際にInternal ENIが必要かどうか確認をしていきます。
いきなりまとめ
- 以下理由からBIG-IP on EC2において、Internal ENIを必ずしも用意する必要はない
- Internal Subnetにターゲットが存在するとは限らない
- Multi-AZのBIG-IP HAクラスターを組む場合、フェイルオーバーをするとExternal ENIが使われる
- 1や2のケアのためにターゲットが存在するCIDRブロックごとにスタティックルートを追加するのが手間
- ENIを分けるメリットが特にない
- Virtual Serverに割り当てるためのENIとして、不要なら積極的に削除したい
やってみた
検証環境
検証環境は以下のとおりです。
以下記事で使用した構成をそのまま流用しています。
現状
現状を確認します。
各Virtual ServerのEIPにアクセスします。それぞれの結果とアクセスログは以下のとおりです。
> curl 98.80.114.203 # application1
big-ip-application1-01
{"time_local":"24/Jul/2025:13:08:25 +0000","remote_addr":"104.28.196.8","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}
> curl 35.153.164.7 # application2
big-ip-application1-01
{"time_local":"24/Jul/2025:13:08:56 +0000","remote_addr":"104.28.196.8","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}
> curl 98.86.126.154 # application3
big-ip-application1-01
{"time_local":"24/Jul/2025:13:13:54 +0000","remote_addr":"10.0.0.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}```
application3以外はSNATをしていないので、remote_addrはクライアントのIPアドレスを維持しています。見るべきはapplication3です。application3ではAuto Mapを使用しています。remote_addrの10.0.0.11のExternal ENIのプライマリIPアドレスです。
図にすると、以下のとおりです。
ヘルスチェックの通信のアクセスログを確認しましょう。
{"time_local":"24/Jul/2025:13:24:00 +0000","remote_addr":"10.0.0.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:13:24:02 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:13:24:05 +0000","remote_addr":"10.0.0.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:13:24:08 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:13:24:10 +0000","remote_addr":"10.0.0.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:13:24:12 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
いずれも10.0.0.11もしくは10.0.4.11となっており、これは各BIG-IPインスタンスのExternal ENIのプライマリIPアドレスです。
念の為、Internal ENIのInterfaceが通信していないことをtcpdumpで確認します。
> ssh admin@23.20.172.35
The authenticity of host '23.20.172.35 (23.20.172.35)' can't be established.
ED25519 key fingerprint is SHA256:vhM2fRvW9P3V2ZEzS81mfVcjJ2qDhxxxI3msxCbacIo.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '23.20.172.35' (ED25519) to the list of known hosts.
(admin@23.20.172.35) Password:
[admin@failover01:Active:In Sync] ~ #
[admin@failover01:Active:In Sync] ~ # date
Thu Jul 24 23:05:05 UTC 2025
[admin@failover01:Active:In Sync] ~ # sudo tcpdump -i 1.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 1.2, link-type EN10MB (Ethernet), capture size 65535 bytes
23:05:38.320921 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:05:38.323808 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:06:39.761798 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:06:39.761962 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:07:41.202629 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:07:41.202926 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:08:42.643790 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:08:42.644205 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:09:44.084745 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:09:44.084931 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:10:45.525839 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:10:45.525907 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:11:46.966904 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:11:46.967049 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:12:48.407941 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:12:48.407983 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:13:49.848964 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:13:49.849288 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:14:51.290089 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:14:51.290159 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:15:52.731115 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:15:52.731466 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:16:54.172410 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:16:54.172445 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:17:55.614028 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:17:55.614156 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:18:57.055641 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:18:57.056107 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
23:19:58.497257 ARP, Request who-has ip-10-0-2-11.ec2.internal tell ip-10-0-2-1.ec2.internal, length 57 in slot1/tmm0 lis= port=1.2 trunk=
23:19:58.497534 ARP, Reply ip-10-0-2-11.ec2.internal is-at 0e:20:1a:b8:e9:bf (oui Unknown), length 57 out slot1/tmm1 lis= port=1.2 trunk=
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel
[admin@failover01:Active:In Sync] ~ # date
Thu Jul 24 23:20:05 UTC 2025
10分ほど放置しましたが定期的に実行されるARPのみで、Internal ENIを使ってターゲットとなるWebサーバーとは通信していないことが分かります。
Webサーバーの追加
では、Internal ENIを使って通信するタイミングはいつでしょうか。
答えはInternal ENIと同じサブネットにターゲットが存在している場合です。
そもそも、現在ターゲットのWebサーバーに通信を流す際にExternal ENIを使用しているのは、BIG-IPのデフォルトゲートウェイがExternal ENIがあるサブネットのVPC Routerとなっているためです。
これは通信相手がInternal Self IPと同一のネットワーク = Internal ENIと同じサブネットに存在している場合はInternal ENIを使いますが、そうではない場合はExternal ENIを使うことを指しています。
実際に確認をしてみます。
Internal Subnetに他Webサーバーと同様の設定をしたWebサーバーを一台追加しました。
この時のヘルスチェックのアクセスログは以下のとおりです。
{"time_local":"24/Jul/2025:14:11:05 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:11:06 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:11:10 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:11:11 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
10.0.2.11と10.0.4.11から通信があることが分かります。
10.0.2.11はBIG-IP AのInternal ENIのIPアドレスです。
一方で、10.0.4.11はBIG-IP BのExternal ENIのIPアドレスです。BIG-IP BのInternal ENIとは別のネットワークなので、デフォルトゲートウェイ10.0.4.1に抜けていく都合で、External ENIが使用されています。
実際にアクセスをして動作確認します。
各Virtual Serverにアクセスします。
> curl 98.80.114.203 # application1
big-ip-application1-02
> curl 98.80.114.203 # application1
curl: (52) Empty reply from server
> curl 35.153.164.7 # application2
big-ip-application1-01
> curl 35.153.164.7 # application2
big-ip-application1-02
> curl 35.153.164.7 # application2
curl: (52) Empty reply from server
> curl 98.86.126.154 # application3
big-ip-application1-01
> curl 98.86.126.154 # application3
big-ip-application1-02
> curl 98.86.126.154 # application3
big-ip-application1-01
> curl 98.86.126.154 # application3
big-ip-application1-02
> curl 98.86.126.154 # application3
big-ip-application1-03
application1とapplication2はEmpty reply from serverとなる場合がありますね。
これは、こちらのVirtual ServerはSNATをしていないためです。ターゲットとなるWebサーバーのデフォルトゲートウェイをActiveなBIG-IPに向ける必要があるのですが、それをしていないがために、Webサーバーからのレスポンスの通信がBIG-IPに辿り着いていません。
application3はAuto Mapなので、問題なく通信できています。
この時のアクセスログは以下のとおりです。
{"time_local":"24/Jul/2025:14:12:59 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}
{"time_local":"24/Jul/2025:14:13:00 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:13:01 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:13:04 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}
実際の通信も10.0.2.11とBIG-IP AのInternal ENIから来ていることが分かりますね。
図にすると以下のとおりです。
フェイルオーバー後も通信できることを確認します。
フェイルオーバー後のアクセス結果と、その時のアクセスログは以下のとおりです。
> curl 98.86.126.154 # application3
big-ip-application1-02
> curl 98.86.126.154 # application3
big-ip-application1-01
> curl 98.86.126.154 # application3
big-ip-application1-03
{"time_local":"24/Jul/2025:14:16:12 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.196.8"}
問題なく通信できていますね。ただし、先述の理由のとおり、BIG-IP BのExternal ENIのIPアドレスで通信が行われています。
図にすると、以下のとおりです。
Application Subnetへのスタティックルートを追加してみる
Internal SubnetにターゲットとなるWebサーバーを配置することで、Internal ENIから通信が流れることを確認しました。
そのため、ターゲットとなるWebサーバーがActive側のBIG-IPインスタンスのInternal ENIと同一のサブネットに配置するのであれば、まだ役目があるでしょう。
一方で、BIG-IP Bからは変わらずExternal ENIから通信が流れています。フェイルオーバーした場合についてはExternal ENIが使われてしまいます。つまりはMulti-AZでBIG-IP HAクラスターを組んでいる以上、常にInternal ENIを使うわけではありません。
そもそも、複数のシステムで使用するBIG-IPの場合はターゲットを一つのInternal Subnetにまとめることは考えにくいです。システムや役割ごとにサブネットを切ったり、場合によってはターゲットは別アカウントの別VPCに配置するということもあるでしょう。
このように、どうしてもInternal ENIと別ネットワークにあるリソースに対してもInternal ENIを使って通信をさせたい場合は、スタティックルートを追加する必要があります。
BIG-IP Aで以下のようにApplication SubnetのCIDRブロックに通信する際は、Internal SubnetのVPC RouterのIPアドレスである10.0.2.1に抜けていくように設定をします。
これをBIG-IP B側でも行います。
スタティックルートを追加すると、以下のようにヘルスチェックの通信が10.0.2.11と10.0.6.11になりました。
{"time_local":"24/Jul/2025:14:44:47 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:44:47 +0000","remote_addr":"10.0.6.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:44:52 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:44:52 +0000","remote_addr":"10.0.6.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
これはBIG-IP AとBIG-IP BのInternal ENIのプライマリIPアドレスです。正常に動作していますね。
先ほどはExternal ENIからの通信が発生していた、application1に通信をしてみます。
事前準備として、application1をAuto Mapに変更します。これはWebサーバーのデフォルトゲートウェイをExternal ENIにしているため、SNATを行わない場合は非対称ルーティングになってしまうためです。
Auto Map変更後にアクセスをすると、以下のように各Webサーバーから正常にレスポンスが返ってきました。
> curl 98.80.114.203 # application1
big-ip-application1-03
> curl 98.80.114.203 # application1
big-ip-application1-03
> curl 98.80.114.203 # application1
big-ip-application1-01
> curl 98.80.114.203 # application1
big-ip-application1-01
> curl 98.80.114.203 # application1
big-ip-application1-02
アクセスログは以下のとおりです。いずれもBIG-IP AのInternal ENIから通信が行われています。
{"time_local":"24/Jul/2025:14:53:02 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
{"time_local":"24/Jul/2025:14:53:04 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
{"time_local":"24/Jul/2025:14:53:01 +0000","remote_addr":"10.0.2.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
図にすると以下のとおりです。
BIG-IP Bにフェイルオーバーをします。
以下のように正常にアクセスできました。
> curl 98.80.114.203 # application1
big-ip-application1-02
> curl 98.80.114.203 # application1
big-ip-application1-01
> curl 98.80.114.203 # application1
big-ip-application1-01
> curl 98.80.114.203 # application1
big-ip-application1-03
この時のアクセスログは以下のとおりです。Application Subnetに属するbig-ip-application1-01はBIG-IP BのInternal ENIのIPアドレスが使用されています。
{"time_local":"24/Jul/2025:14:54:52 +0000","remote_addr":"10.0.6.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
{"time_local":"24/Jul/2025:14:54:52 +0000","remote_addr":"10.0.6.11","remote_user":"","request":"GET /","status": 200,"body_bytes_sent": 23,"request_time": 0.001,"http_referrer":"","http_user_agent":"","http_x_forwarded_for":""}
{"time_local":"24/Jul/2025:14:54:53 +0000","remote_addr":"10.0.6.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
一方、Internal Subnetへのスタティックルートを追加していないため、big-ip-application1-03はBIG-IP BのExternal ENIが使用されています。
{"time_local":"24/Jul/2025:14:54:54 +0000","remote_addr":"10.0.4.11","remote_user":"","request":"GET / HTTP/1.1","status": 200,"body_bytes_sent": 23,"request_time": 0.000,"http_referrer":"","http_user_agent":"curl/8.14.1","http_x_forwarded_for":"104.28.228.2"}
図にすると、以下のとおりです。
結局Internal ENIを用意する必要はあるのか
色々検証しましたが、結局Internal ENIを用意する必要はあるのでしょうか。
答えはNoです。
理由は以下のとおりです。
- Internal Subnetにターゲットが存在するとは限らない
- Multi-AZのBIG-IP HAクラスターを組む場合、フェイルオーバーをするとExternal ENIが使われる
- 1や2のケアのためにターゲットが存在するCIDRブロックごとにスタティックルートを追加するのが手間
- ENIを分けるメリットが特にない
1つ目から3つ目はすでに説明済みなので、省略します。
4つ目については、メリットを改めて考えましたが思いつきませんでした。
「ENIを複数用意して帯域の負荷分散を」という話もありますが、私の認識ではENI単体の帯域制限はありません。帯域制限があるのはインスタンス単位です。
以下AWS公式ドキュメントで紹介されているように通信のさせ方やインスタンスタイプによって使用できる通信帯域は決定されます。
そもそもBIG-IPのライセンスを調達するタイミングで200 Mbpsや、1 Gbpsなどとスペックを選択します。インスタンスタイプに設定されたネットワーク帯域幅以上をサポートするBIG-IPライセンスを調達することはなかなかレアケースなのではないでしょうか。
そのため、帯域負荷分散用途でENIを追加することはほとんどありません。
ということで、AWS上でBIG-IP VEを動かす場合にInternal ENIは特段不要と考えます。
デフォルトルートをExternal ENIが属するサブネットのVPC Routerを指定する以上、特にInternal ENIは不要
BIG-IP on EC2のInternal ENIは同一のサブネットにターゲットが存在しないのであれば不要な件を紹介しました。
デフォルトルートをExternal ENIが属するサブネットのVPC Routerを指定する以上、特にInternal ENIは不要だと考えます。
Internal ENIを追加してもランニングコストは特に増えませんが、余計なリソースは作りたくありません。不要なのであれば削除しても良いでしょう。
むしろ、Virtual Serverに割り当てるためのENIとして、不要なら積極的に削除したいです。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
