目次
はじめに
こんにちは、クラウド事業部の馬藤です。
最近Transit Gatewayを触ったので自身の備忘を兼ねて情報整理をしたいと思います。
こんな人に読んで欲しい
- Transit Gatewayに興味がある人
- Transit Gatewayをこれから構築予定の人
Transit Gatewayとは
VPCやオンプレミスなど複数の環境を相互接続するためのハブとして動作し、従来のVPCピアリングと比較してネットワーク構成を簡素化することが出来るサービスです。
以下の図はBlackBeltから引用。
これだけ複雑な構成が・・・
こんなにシンプルになります！
Transit Gateway構築のポイント
今回は3つのAWSアカウントのVPCをTransit Gatewayで接続します。
構成図と設定値は以下の通りです。
上記は各VPCのプライベートサブネットにあるEC2インスタンスに対してセッションマネージャーを利用して接続し、EC2インスタンス同士でping疎通を確認する構成にしています。
セッションマネージャーについて詳しく知りたい方は以下の記事を参照下さい！
VPCやサブネット、EC2等の環境は既にある前提で、Transit Gatewayの環境構築の流れとポイントを整理していきたいと思います。
以降の番号①～⑦は構成図に記載のある番号と紐づけしていますので、順番にご確認下さい！
①Transit Gatewayの作成
最初にTransit Gatewayを作成します。今回はAccount Aで作成しています。
以下のデフォルトで有効となっているチェックを外して作成をすることがポイントです。
・デフォルトルートテーブルの関連付け
・デフォルトルートテーブル伝搬
理由としては、後ほど明示的に関連付けと静的ルートを追加するため、分かりやすさの観点でおススメです。
②RAMでTransit Gatewayを別アカウントに共有
別のAWSアカウントからTransit Gatewayを利用するには、Transit Gatewayの作成元AWSアカウントからResource Access Managerを利用してTransit Gatewayの共有を行います。
①で作成したTransit Gatewayを共有する対象として選択し、12桁のAWSアカウントIDを入力して共有先のAWSアカウントの数だけ追加することがポイントです。
③Transit Gatewayアタッチメントの作成
Transit Gatewayに接続するにはTransit Gatewayアタッチメントが必要です。
①で作成したTransit Gateway IDを選択し、Transit Gatewayアタッチメントを紐づけるサブネットは、以下のベストプラクティスに従い、Transit Gateway専用のサブネットを選択することがポイントです。
Transit Gateway 設計のベストプラクティス - Amazon VPC
Transit Gateway共有先のAWSアカウント(Account BとC)でTransit Gatewayアタッチメントの作成処理を実施後、Transit Gateway共有元のAWSアカウント(Account A)で承諾処理を行うことで、共有先のAWSアカウントのTransit Gatewayアタッチメントが有効化されます※。
※自動承諾したい場合はTransit Gateway作成時に「共有アタッチメントを自動承諾」オプションを有効化する必要があります。
④Transit Gatewayルートテーブルの作成
③で作成したTransit Gatewayアタッチメントと関連付ける(⑥で後述)ためのTransit Gatewayルートテーブルを作成します。
①で作成したTransit Gateway IDを選択してTransit Gatewayルートテーブルを作成します。
Transit GatewayルートテーブルはVPCを跨ぐ際のルートを定義しているということがポイントです。
⑤静的ルートの追加
④で作成したTransit Gatewayルートテーブルに静的ルートを追加します。
どのIPアドレスレンジの時(CIDR)に、どこの宛先(Transit Gatewayアタッチメント)へ行くかを定義し、必要な数だけ追加することがポイントです。
⑥Transit Gatewayルートテーブルとアタッチメントとの関連付け
③で作成したTransit Gatewayアタッチメントと④で作成したTransit Gatewayルートテーブルの関連付けを行います。
1ルートテーブルにつき1アタッチメントを関連付けることで、設定がわかりやすくなるのでおススメです。
⑦各プライベートサブネットのルートを追加
各EC2インスタンスでping疎通を行い、Transit Gatewayの動作確認を実施する前段として、各プライベートサブネットのルートテーブルにTransit Gatewayをターゲットとしたルートを追加します(構成図の赤枠部分)。
④のTransit Gatewayルートテーブルとは異なり、サブネットのルートテーブルはVPC内のルートを定義しているということがポイントです。
Transit Gateway環境の構築は以上です。
pingでの疎通確認
Transit Gateway環境の構築後は、想定した挙動となるかping疎通を行い、動作確認※を実施します。
※各EC2インスタンスに紐づくセキュリティグループはそれぞれのEC2インスタンスからのping(ICMP4)を許可している前提とします。
ping疎通の結果は以下のようになります。
| 送信元＼送信先 | 10.010.0/24(EC2 A) | 172.16.10.0/24(EC2 B) | 192.168.10.0/24(EC2 C) |
|---|---|---|---|
| 10.010.0/24(EC2 A) | - | 〇 | 〇 |
| 172.16.10.0/24(EC2 B) | 〇 | - | × |
| 192.168.10.0/24(EC2 C) | 〇 | × | - |
Transit Gatewayを用いることで簡単にAWSアカウント間の接続や、疎通の制御を行うことが出来ました。
おわりに
「Transit Gatewayアタッチメントって何？」や「Transit Gatewayルートテーブルってサブネットのルートテーブルと何が違うの？」など最初は抵抗を感じるかもしれませんが、AWSアカウントやオンプレミスなど接続対象が増えるほどにTransit Gatewayの恩恵を感じることが出来ると思いましたので、皆さんも是非使ってみて下さい！
お知らせ
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
