VPC ピアリング接続時にセキュリティグループの接続元として他 VPC で利用しているセキュリティグループが指定可能か教えてください。

2023.01.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

困っていた内容

VPC ピアリング接続を利用して VPC-A を VPC-B と接続する予定です。
VPC-A で利用している EC2 のセキュリグループでは、インバウンドルールのソース(接続元)にセキュリティグループを指定しているのですが、VPC ピアリングで接続する VPC-B のセキュリティグループもソースとして指定可能なのでしょうか?

結論

VPC ピアリング先(VPC-B)が同一リージョンの場合

ソースに VPC ピアリング先のセキュリティグループを指定することが可能です。

VPC ピアリング先(VPC-B)が異なるリージョンの場合

ソースに VPC ピアリング先のセキュリティグループを指定することができません。

セキュリティグループの更新とピアセキュリティグループの参照

VPC セキュリティグループのインバウンドルールまたはアウトバウンドルールを更新して、ピアリング接続 VPC のセキュリティグループを参照できます。

別のリージョンにあるピア VPC のセキュリティグループは参照できません。代わりに、ピア VPC の CIDR ブロックを使用します。

なお、異なる AWS アカウントとの VPC ピアリング接続の場合でも、同一リージョンであればソースにセキュリティグループを指定することが可能です。

別の AWS アカウントのセキュリティグループを参照するには、[Source] (送信元) または [Destination] (送信先) フィールドにアカウント番号 (123456789012/sg-1a2b3c4d など) を含めます。

セキュリティグループとリソースとの関連付けについて

下記 AWS ドキュメント内容については覚えていたので、VPC 内のリソースであるセキュリティグループは他 VPC から参照できないのではないかと思いましたが、見事に違っていました。VPC ピアリング接続時のセキュリグループの参照については、同一リージョン内であれば他の VPC からも可能でした。
セキュリティグループを使用してリソースへのトラフィックを制御する   

セキュリティグループは、作成された VPC 内のリソースにのみ関連付けることができます。

やってみた

実際に同じリージョン内に 2 つの VPC(VPC-A と VPC-B)を作成したのち VPC ピアリングで接続し、セキュリティグループの接続元として他 VPC で利用しているセキュリティグループを設定してみました。

下準備

VPC-A と VPC-B の構成は以下のようにシンプルにしました。
東京リージョンには多くの既存セキュリグループがある為、リージョンは普段検証で使うことがなくクリーンな状態のシドニーを使いました。

VPC-A
リージョン:シドニー
IPv4 CIDR:10.0.0.0/16
AZ の数:1
プライベートサブネットの数:1

VPC-B
リージョン:シドニー
IPv4 CIDR:192.168.0.0/16
AZ の数:1
プライベートサブネットの数:1

それぞれの VPC において、EC2 を 1 台ずつ作成してあります。
また、EC2 にアタッチしているセキュリグループのインバウンドルールは何も記載が無い状態です。(全てのインバウンド通信が許可されていない状態です)

VPC ピアリングを作成してみた

1. VPC ダッシュボード左ペインの VPC ピアリングを選択した後に、ダッシュボード右上の「ピアリング接続を作成」を押下します。

2. VPC-A から VPC-B に対して VPC ピアリング接続をリクエストするように設定しました。

3. VPC ピアリング接続が作成されてもアクセプタから承諾されるまで、ステータスは Pending のままで、VPC-B との接続はできません。

4. ピアリング接続の画面で、先ほど作成した VPC ピアリング接続のリクエストを承諾します。

5. VPC ピアリング接続リクエストの内容を確認してリクエストを承諾します。

6. リクエストが承諾されて、ステータスがアクティブへと変わりました。
なお、VPC ピアリング接続が作成されていてもステータスがアクティブとなるまではセキュリグループの参照はできないようになっています。
セキュリティグループの更新とピアセキュリティグループの参照

ピア VPC でセキュリティグループを参照するには、VPC ピアリング接続の状態が active である必要があります。

7. VPC ピアリング接続は完成しましたが、VPC-A と VPC-B のプライベートサブネットで利用しているルートテーブル上に VPC ピアリングへのルートが無い為、それぞれのルートテーブルにおいて VPC ピアリングへのルートを追加します。

8. VPC-A のプライベートサブネットに紐づくルートテーブルにおいて、送信先が 192.168.0.0/16(VPC-B の CIDR)の場合のルートが VPC ピアリングに向かうように設定します。

9. VPC-B のプライベートサブネットに紐づくルートテーブルにおいて、送信先が 10.0.0.0/16(VPC-A の CIDR)の場合のルートが VPC ピアリングに向かうように設定します。

10. 事前に VPC-A のプライベートサブネットで作成した EC2 にアタッチしているセキュリティグループを EC2 ダッシュボード上で確認します。セキュリグループ ID は、sg-0dc5cd2095a6936dd です。

11. 事前に VPC-B のプライベートサブネットで作成した EC2 にアタッチしているセキュリティグループを EC2 ダッシュボード上で確認します。セキュリグループ ID は、sg-04719c41b1568b5ab です。

12. セキュリティグループ sg-0dc5cd2095a6936dd(VPC-A のセキュリグループ)のインバウンドルールを編集します。

13. セキュリティグループ sg-0dc5cd2095a6936dd(VPC-A のセキュリグループ)において、インバウンドルールのソース(接続元)として VPC-B で利用しているセキュリティグループ ID sg-04719c41b1568b5ab を入力して「ルールを保存」ボタンを押下してみます。

14. ソース(接続元)にセキュリティグループ sg-0dc5cd2095a6936dd(VPC-B のセキュリグループ)を設定することができました!

異なるリージョン間の VPC ピアリングの場合

別のリージョンにあるピア VPC のセキュリティグループは参照できないとドキュメントにはありましたが、いちおう確認してみます。
VPC-C をシンガポールリージョンに作成して、VPC-A のセキュリグループ sg-0dc5cd2095a6936dd において VPC-C で利用しているセキュリティグループを接続元として設定できるか確かめてみます。なお、VPC-C との VPC ピアリング接続作成手順については一部省略しています。

構成は、以下のとおりです。

15. VPC-A から VPC-C に対して VPC ピアリング接続をリクエストするように設定しました。

16. リクエストが承諾されて、ステータスがアクティブへと変わりました。

17. 事前に VPC-C のプライベートサブネットで作成した EC2 にアタッチしているセキュリティグループを EC2 ダッシュボード上で確認します。セキュリティグループ ID は、sg-0a733e0321d87ded7 です。

18. セキュリティグループ sg-0dc5cd2095a6936dd(VPC-A のセキュリグループ)において、インバウンドルールのソース(接続元)として VPC-C で利用しているセキュリティグループ ID sg-0a733e0321d87ded7 を指定して「ルールを保存」ボタンを押下します。セキュリティグループ ID を入力した時点では、エラーは発生していません。

19. やはり次画面でエラーが発生して、別のリージョンにあるピア VPC のセキュリティグループをソース(接続元)として指定することはできませんでした。ドキュメント記載どおりの結果となりました。

まとめ

手順 7、8、9 においてルートテーブルの設定をしていますが、疎通確認していないので必要無かったですね。。。
VPC ピアリング接続のハンズオン手順としてご利用くださいw

この記事がどなたかのお役に立てば幸いです。

参考資料