[M5/C5/i3.metal] VPC ピアリングを経由してNLBにアクセスできるEC2インスタンス

こんにちは、菊池です。

PrivateLinkを使ったVPCエンドポイント（インターフェースエンドポイント）に対して、一部のEC2インスタンスタイプではVPCピアリングを経由したアクセスが可能であることを、以下の記事で紹介しました。

[M5/C5] VPC ピアリングに隠された Nitro 世代 EC2 と PrivateLink の不思議な関係　

さらに調べてみると、同様の制約がNLB（Network Load Balancer）にも当てはまることが公式ドキュメントの記載からわかりました。（以下、公式ドキュメントの記載は最新の情報を確認するためにはEnglish表示でご確認ください。）

• Network Load Balancers

Network Load Balancers do not support connections from clients to your load balancer over VPC peering or AWS managed VPN unless the clients are C5, i3.metal, or M5 instances. For VPC peering, both VPCs must be in the same region.

• Target Groups for Your Network Load Balancers

Registered Targets

Limits

• The only targets that you can register in a peered VPC are C5, i3.metal, and M5 instances. The instances must be in the same region as the load balancer.

クライアントとしてNLBへアクセスする場合、あるいはサーバとしてNLBのターゲットに登録する場合、どちらのケースにおいても、C5/M5/i3.metalインスタンスのみがリージョン内のVPCピアリングを経由してアクセスできるということです。

VPCピアリング経由のNLBアクセス

実際に、各パターンでのNLBアクセスを試してみました。

VPCピアリング経由のクライアントからNLBへアクセス

まずは、内部NLBに対して、VPCピアリングを経由したアクセスを試してみます。

上の図のようにNLBに同一VPC内のwebサーバを登録して、アクセス可否を確認しました。

M5インスタンス

[ec2-user@ip-172-31-0-99 ~]$ curl http://169.254.169.254/latest/meta-data/instance-type
m5.large
[ec2-user@ip-172-31-0-99 ~]$ curl test2-4dbc94637acf6625.elb.ap-northeast-1.amazonaws.com
Hello via NLB

M4インスタンス

[ec2-user@ip-172-31-0-205 ~]$ curl http://169.254.169.254/latest/meta-data/instance-type
m4.large
[ec2-user@ip-172-31-0-205 ~]$ curl test2-4dbc94637acf6625.elb.ap-northeast-1.amazonaws.com
curl: (7) Failed to connect to test2-4dbc94637acf6625.elb.ap-northeast-1.amazonaws.com port 80: 接続がタイムアウトしました

確かに、m5.largeではアクセスできて、m4.largeではアクセスできませんでした。

VPCピアリング経由のNLBターゲットへのアクセス

続いて、VPCピアリングを経由したターゲットへのアクセスも試してみます。

以下のように、m5.large/m4.largeのインスタンスをNLBとは別の、ピアリングしたVPCに起動します。

この2つのインスタンスをNLBのIPターゲットに指定します。この時点で、m5.largeは[healthy]ステータスになりますが、m4.largeのインスタンスは[unhealthy]のままです。

NLB経由でアクセスしても、当然、m5.largeのインスタンスのみアクセスが可能です。

$ curl test2-4dbc94637acf6625.elb.ap-northeast-1.amazonaws.com
Hello m5 via NLB

VPCピアリング経由のクライアントからVPCピアリング経由のNLBターゲットへのアクセス

最後に、これまでの2つを組み合わせたケースを検証します。つまり、以下の図のように、VPCピアリングを経由したターゲットに対し、VPCピアリングを経由したクライアントからアクセスします。これまでの検証から、M4インスタンスではアクセスできないのは明らかなので、M5 -> NLB -> M5でアクセスができるのかを確認します。

[ec2-user@ip-172-31-0-99 ~]$ curl test2-4dbc94637acf6625.elb.ap-northeast-1.amazonaws.com
Hello m5 via NLB

なんと、VPCピアリングを2つ経由してもアクセスできました！ちなみに、アクセスログをみると、

[ec2-user@ip-172-16-0-240 ~]$ sudo tail -f /var/log/httpd/access_log
10.0.0.242 - - [09/Jun/2018:16:15:31 +0000] "GET / HTTP/1.1" 200 17 "-" "curl/7.53.1"
10.0.0.239 - - [09/Jun/2018:16:16:35 +0000] "GET / HTTP/1.1" 200 17 "-" "curl/7.53.1"
10.0.0.239 - - [09/Jun/2018:16:16:38 +0000] "GET / HTTP/1.1" 200 17 "-" "curl/7.53.1"

このように、Source IPはNLBが配置されたVPCのものになっています。

まとめ

またしても、特定インスタンスタイプにのみ許容される通信の仕様があることがわかりました。

興味深いのは、最後のケースです。NLBを中継することで、VPCピアリング2つにまたがる通信が実現できています。頑張れば、NLBを中核にしたトランジットVPCも実現できそうな気がしています。

とはいえ、現時点では一部のインスタンスのみという制約もあり、リスクも大きいと思います。

一方で、今後さらに新しいインスタンスタイプが登場し、現状では一部のインスタンスのみであるものが一般化した仕様となることで、現状あるVPCの制約が取り払われて行くのではないかと期待します。