9
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Transit Gatewayを導入するときに気をつけたいポイント4選

Posted at

0.はじめに

以下のような構成でVPC-AとVPC-Bを接続するためにTransit Gatewayを導入することを検討していました。検討時に気をつけたことやはまったことを共有します。

TransitGWを使うときに気をつけるポイント-全体像.png

1.Transit Gatewayのデフォルトのルートテーブルを使うかどうか

Transit Gatewayにはデフォルトのルートテーブルが備わっています。これを用いることでTransit Gatewayにアタッチ/アソシエート/プロパゲートした任意のVPCの組み合わせで通信できます。一方、デフォルトのルートテーブルを使わない場合は、通信させたいVPCの組み合わせをTransit Gatewayのルートテーブルに設定していくことになります。

Transit Gatewayを経由するVPC間の通信が、1対1で決まることが多いのであれば独自のルートテーブルを使う、逆に複数のVPCと通信したい場合はデフォルトのルートテーブルを用いるのが良いのではないでしょうか。設定が煩雑になって運用がしにくくなるためです。デフォルトのルートテーブルを使った場合でも、各セキュリティグループやACLでIngressの通信を制御することもできます。

2.インターネット接続を集約するかどうか

インターネットへのEgressの口を各VPCごとに持つのか、あるVPCのpublicサブネットに集約するのかどうか、というのは一つの検討ポイントだと思います。集約する場合の検討ポイントとして、Transit GatewayやNAT Gateway、Internet Gatewayの可用性を考えておく必要があります。
Transit Gatewayの制限事項としては以下のような項目があります。帯域に関してはVPC間を接続する場合は最大でバースト 50 Gbps出るので、Transit Gateway自体の帯域が不足することはまずないでしょう。帯域に関してはInternet Gatewayは無制限、NAT Gatewayも 5 Gbpsの帯域をサポートして 45 Gbps まで自動的に拡張するので、集約したとしても問題ないと考えられます。

Transit Gatewayのパフォーマンスと制限

制限 デフォルト
AWS Transit Gateway アタッチメントの数 5000
VPN 接続ごとの最大帯域幅* 1.25 Gbps
VPC、Direct Connect Gateway、またはピア Transit Gateway 接続あたりの最大帯域幅 (バースト) 50 Gbps
アカウントあたりの AWS Transit Gateway の数 5
VPC あたりの AWS Transit Gateway アタッチメントの数 5
ルートの数 10000
AWS Transit Gateway あたりの Direct Connect Gateway の数 20

https://aws.amazon.com/jp/transit-gateway/faqs/
https://aws.amazon.com/jp/vpc/faqs/
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html

3.インターネット接続を集約するときのルートテーブルの設定

インターネットに接続しない、純粋にVPC間をTransit Gatewayで接続する場合は Transit GatewayでVPC間通信する構成をTerraformで作成してみた で説明されている手順でできます。

ここで、例えばB-VPCからインターネットに抜ける通信を考えてみます。以下のようなイメージです。

TransitGWを使うときに気をつけるポイント-インターネット.png

Transit Gateway越しにインターネットに抜ける場合ポイントは以下です。

  1. publicサブネットを持たないVPC(本説明の場合はB-VPC)にあるサブネットのデフォルトゲートウェイはTransit Gateway
  2. publicサブネットを持つVPC(本説明の場合はA-VPC)の publicサブネット のルートテーブルに、B-VPCのCIDRに含まれる宛先IPアドレスの通信の経路を Transit Gateway宛 に設定する
  3. Transit Gatewayのデフォルトのルートテーブルにstaticな経路としてデフォルトルートをpublicサブネットを持つVPC(本説明の場合はA-VPC)宛に設定する

ということです。私がはまったポイントとして、A-VPC側のpublicのルートテーブルにはA-VPCの(Transit Gatewayとアタッチ/アソシエート/プロパゲートしている)private側へのルートを設定していたため通信できず、はまりました。

4.同じアベイラビリティゾーンを使って通信する

仕様的な話なので知っておけばOKです。が見落としそうなポイントでもありそうです。可用性や拡張性設計の際に注意しましょうということなのですが、同一のAZをENIを経由して通信します。BlackBeltの資料や以下のClassmethodさんの記事にもあります。

x.落ち葉拾い

Terraformを使った場合、デフォルトのTransit Gatewayのルートテーブルは自動で作成されるため、staticなルートを追加したい場合、手動で追加しないといけませんでした。以下のような tf ファイルでリソースを生成したときに生成されるデフォルトのルートテーブルのIDを取得できるとよいのですが、取得方法わからずです。data で作成したリソースを元に追加するのが良いのかも知れません。

resource aws_ec2_transit_gateway test {
  vpn_ecmp_support                = "disable"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  auto_accept_shared_attachments  = "disable"
  tags = {
    Name = "test_transit_gateway"
  }
}

Terraformで検証環境を構築したときのtfファイルたちは こちら に置いておきました。

参考

全般的に以下の資料が参考になります。Transit Gatewayを導入する際はぜひ読んでおく資料かと思います。

9
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?