[小ネタ]VPCピアリング接続のこぼれ話三選

[小ネタ]VPCピアリング接続のこぼれ話三選

VPCピアリング接続を検証した際に出てきた、前回のブログにまとめきれなかったこぼれ話を三つほどまとめてみました。
Clock Icon2019.10.30

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

前回のブログ で次のブログを書く頃には街はクリスマス一色かなぁなんて言った私ですが、ハロウィンが始まる前にブログを書いてしまいました。

▲ まだ呑気に栗を食べたりしていた

こんにちは、AWS事業本部のShirotaです。モンブランにハマりそうなので美味しいモンブランを追求していきたいです。あと今年の栗きんとんをまだ食べていないです、めっちゃ食べたい。

前回調べた時に出てきたこぼれ話を昇華したい

上記でも紹介致しましたが、前回のブログでVPCピアリング接続の接続のライフサイクルについて調べてまとめました。 その際に、VPCピアリング接続をいくつも作成して様々な検証を行い「こんな動作するんだ」とか「こんなものがあるのか!」などの気づきがいくつかありました。 前回のブログの趣旨からは少し逸れる為、載せなかったのですが折角なので改めてまとめてみる事にしました。

1. VPCピアリング接続削除時にルートテーブルの設定も削除できる(コンソールで)

VPCピアリング接続の削除を コンソール上で 実行する際、ルートテーブルの設定もまとめて削除する事ができます。 AWS CLIのドキュメントを確認した限り、AWS CLIでルートテーブルの設定もまとめて削除できるオプションは見つかりませんでした。 delete-vpc-peering-connection

実際に、ルートテーブルの設定ごとVPCピアリングを削除してみました。

▲ ルートテーブルにVPCピアリング接続が入ってます

コンソールで、対象のVPCピアリングを選択して「Delete VPC Peering Connection」をクリックします。 すると、以下のようなポップアップが出ます。

▲ ここをチェックするだけ

これでDeleteを実行して、VPCピアリング接続をルーティングしていたルートテーブルを確認してみます。

▲ ルーティングが消えていました!

ちなみに、 逆は現状できません 。逆とは、VPCピアリング接続の作成時にルートテーブルを指定してルーティングを登録させる事です。 AWS CLIでルーティングをルートテーブルに追加するコマンドは、以下のようになります。

  
aws ec2 create-route --route-table-id 追加したいルートテーブルID --destination-cidr-block XXX.XXX.XXX.XXX/XX --gateway-id 作成したVPCピアリング接続のID

自動化に近い事をやる場合には、

  • 追加したいルートテーブルID
  • 追加したい接続先のCIDR
  • 作成したVPCピアリング

を取ってくれば少しは楽ができたりヒューマンエラーが減らせそうです。

2. 逆方向からVPCピアリング接続を作成する事ができてしまう

VPCピアリング接続は基本的に双方向通信を可能にできる接続なので、1つ作成ができれば両VPCからの通信が可能になります。(勿論、ルートテーブルや接続先のセキュリティグループなどの設定を追加する必要はありますが) ですが、VPC-AからVPC-Bへの接続を作成した後、VPC-BからVPC-Aへの接続を作成する事ができてしまいます。 実際に作ってみて、承認(Accept)しようとすると以下のようになりました。

▲ 重複する接続は承認ができない

承認(Accept)が実行できないだけで却下(Reject)や削除(Delete)は実行できます。なので、逆方向からのVPCピアリング接続を作成してしまった場合は却下したり削除したりしましょう。

3. 同じ方向からのVPCピアリング接続を重複作成してみると……?

ワ◯ップみたいな見出しになってしまいました 逆方向からのVPCピアリング接続は 作成できてしまうものの承認できない というエラーが発生してしまう事が分かりました。 今度は、方向も(VPC-AからVPC-Bへ)全く同じになるVPCピアリング接続を作成した場合について見ていきましょう。

▲ このVPCピアリング接続と全く同じ接続を作成します

▲ 違うところはNameTagのところくらい

▲ 作成できてしまった

作成自体は成功したと表示されました。実際にどうなったか見てみましょう。

▲ 「Test1ToTest2」が「TestAToTestB」になった

何が起きたかを調べてみたところ、

  • NameTagが書き換わった
  • VPCピアリング接続のIDは変わっていない

という感じなので、NameTagだけが置き換わったという状況のようです。 つまり重複作成できたように見えて、 実際には重複作成は行われておらず、NameTagが更新された という事でしょう。 VPCピアリング接続のIDも変わっていない為、ルートテーブルの更新も実施する必要は無さそうです。

こぼれ話三選でした

一番実用的なのは「はじめのVPCピアリング接続の削除をコンソール上で実行する際、ルートテーブルの設定もまとめて削除する事ができる」というネタでした。 ですが実際に、間違えてVPCピアリング接続を複数作成してしまった場合にどのような挙動が起こるかといった事を知る事ができたのでまとめてみました。 もし、間違えて接続を作ってしまった時やVPCピアリング接続を削除する事になった時に、このブログを思い出して頂けると幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.