こんばんは。小寺です。
先月リリースされたAmazon Elastic Cloud Compute (EC2) インスタンス用のマルチ Virtual Private Cloud (VPC) Elastic Network Interface (ENI) アタッチメントの検証と使いどころをまとめてみました。
https://aws.amazon.com/jp/about-aws/whats-new/2023/10/multi-vpc-eni-attachments/
Multi-VPC ENI アタッチメントとは
・1つのVPC でプライマリ ENI を使用してEC2インスタンを起動し、別のVPCからセカンダリENIの接続ができる
・今までも1つのインスタンスに対して、同一VPC内の複数のENIをアタッチすることはできたが、今回のアップデートでは、別のVPCのENIもアタッチできるよう変更
・別々の VPC の ENI がアタッチされている EC2 インスタンスは、AWS 公式ドキュメントでは「dual-homed インスタンス」と呼ばれる
Multi-VPC ENI アタッチメントの利用上の制約
当然、利用するための前提条件があります。
・セカンダリENIはプライマリ ネットワーク インターフェイスと同じアベイラビリティ ゾーン (AZ) に配置が必要です
・異なる AWS アカウントの VPC にまたがってマルチホーム インスタンスを作成することはできない、つまり同じアカウント内の配置が必須です。
VPCまたぎができる他のサービスとの違い
複数VPCが利用できるほかサービスにマルチ VPC ENIアタッチメントとの違いをまとめてみました。
・VPC Peering
・2つのVPC 間でプライベートなトラフィックのルーティング
・IPアドレスの重複はサポートされない
・同一AWSアカウントVPC 間、別の AWSアカウントのVPC との間、または別のAWS リージョンのVPC との間に作成できる
・AWS PrivateLink
・1対多のコネクティビティ
・IPアドレス重複のサポート
・ELBの利用が必要
・ロードバランサと1時間当たりのエンドポイントコストがかかる
・別アカウントの接続可能
・AWS Transit Gateway
・多対多、1対多でルーティングテーブルを利用する
・1時間当たりのAZエンドポイントコストがかかる
・他のAWSアカウントと Transit Gateway を共有した後、VPC をアタッチすることができる
・Amazon VPC Lattice
・アプリケーション同士をシンプルかつ安全に接続するためのアプリケーション層のネットワークサービス
・Transit GatewayやVPC Peering、Private LinkにあったIP Routeingの詳細設計の必要がなく、通信環境が構築できる
・Multi-VPC ENI アタッチメント
・同一アカウントの接続のみをサポート
・アタッチできるのも同じAZのみ
・OS側でルートテーブルの設定が必要
試してみた
(1) EC2インスタンスを作成します。この時点ではENIが1つアタッチされている状態です。
(2) ネットワークインターフェースのアタッチはマネージメントコンソールからはできないようです。
(3) CLIから別AZのENIをアタッチしてみます。別AZのENIを選んでみます。
# aws ec2 attach-network-interface --device-index 1 --instance-id i-XXXXXXXX --network-interface-id eni-0
XXXXXXXXXX
An error occurred (InvalidParameterCombination) when calling the AttachNetworkInterface operation: You may not attach a network interface to an instance if they are not in the same availability zone
(4)別VPCの同じAZのENIを選びました。
# aws ec2 attach-network-interface –device-index 1 –instance-id i-xxxxxxx –network-interface-id eni-0xxxxxxx
{
“AttachmentId”: “eni-attach-0ab2b0df9c430ee7b”,
“NetworkCardIndex”: 0
}
無事にアタッチできたようです。
どんなときに役立ちそう?
マルチVPC ENI アタッチメントを使用すると、セグメント化された VPC 間で接続されたワークロードを実行することができるのがメリットだとオフィシャルでは記載があります。
例えば、コントロール プレーン トラフィックやデータ プレーン トラフィックなど、さまざまなタイプのネットワーク トラフィックに異なる VPC を使用するようなケースです。
もしくは、AWS内とAWSとオンプレ間で異なるタイプの通信を利用する想定で、論理ネットワークを分離しつつ、リソースを共有したい場合です。
後はNAT Gatewayを使うのがもったいないときに、NATインスタンスを共有するのもあり?かもしれないですね。ただ、踏み台を使うパターンはセキュリティのリスクも上がるので推奨はしないですよね。