AWS Transit Gateway ハンズオンをやってみた

AWS Transit Gateway ハンズオンをやってみた

#AWS
#AWS Transit Gateway
#ハンズオン
ai

ai

facebook logohatena logotwitter logo
Clock Icon2025.02.25

Classmethod Canadaでオペレーション業務をしているaiです。日々いろいろなサービスの調査等をしていますが、復習を兼ねてAWS Transit gatewayのハンズオンをやってみました。このハンズオンの内容を忘れないようまとめて書きたいと思います。

今回やってみたハンズオンについて

下記のハンズオンを一通り実施しました。Transit gatewayを使用しシングルアカウントやクロスアカウント構成でVPC間接続する環境を作成したり、Transit gatewayピアリングによるクロスリージョン構成の環境を作成しました。

https://catalog.us-east-1.prod.workshops.aws/workshops/e0d1c19d-c80b-4695-a3fc-5c4a25132f47/ja-JP

Lab1: トランジットゲートウェイによるVPC間接続

CloudFormationで環境を作成

用意されているCloudFormationを使用して下記のような構成にします。まずは1つのAWSアカウント内で異なるVPCをTransitGatewayを使用して接続します。

design-lab1
画像引用元: AWS Transit Gateway ハンズオン Lab1

疎通確認

BoundaryVPC内のPrivate SubnetのEC2にシステムマネジャーで接続して疎通確認をします。

sh-5.2$ bash
[ssm-user@ip-192-168-1-100 bin]$

// PrivateVPC1へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=126 time=2.53 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=126 time=1.23 ms

// インターネットへ OK
[ssm-user@ip-192-168-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.56) 56(84) bytes of data.
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=1 ttl=248 time=3.22 ms
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56):

PrivateVPC1のPrivate SubnetのEC2からも同様に疎通確認をします。

sh-5.2$ bash
[ssm-user@ip-10-0-1-100 bin]$

// BoundaryVPCへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.22 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=0.734 ms

// インターネットへ NG
[ssm-user@ip-10-0-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.56) 56(84) bytes of data.

現時点で以下のようになりました。

Src\Dst 192-168-1-100 10.0.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (OK) OK OK
PrivateVPC1(10.0.1.100) OK (OK) NG

現時点では、PrivateVPC1内のEC2からインターネットへの接続ができないことが分かりました。

ルートテーブルの確認

ここでは、PrivateVPC1のEC2からインターネットへ接続可能な状態にするため、各サブネットのルートテーブルを確認し必要な設定を行います。

まずは、BoundaryVPC内のサブネット3つのルートテーブルを確認します。

NAT Subnet
001

Private Subnet
001b

TGW Subnet
001c

次に、PrivateVPC1内のサブネット2つのルートテーブルを確認します。

Private Subnet
002

TGW Subnet
002b

PrivateVPC1のルートテーブルに関連付いているTransit Gatewayルートテーブルを確認します。
003

問題: PrivateVPC1のEC2からトランジットゲートウェイ経由のインターネット接続がへ接続できない
原因: PrivateVPC1のトランジットゲートウェイにインターネット向きのルート(デフォルトルート)が存在しないため

Transit Gateway ルートテーブルにデフォルトルート(0.0.0.0/0)を追加します。

004

追加しました。
005

疎通確認2回目

再度、PrivateVPC1から疎通確認をします。

// インターネットへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.49) 56(84) bytes of data.
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=1 ttl=247 time=2.75 ms
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=2 ttl=247 time=2.13 ms

PrivateVPC1のEC2からインターネットへ接続できました。

Src\Dst 192-168-1-100 10.0.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (OK) OK OK
PrivateVPC1(10.0.1.100) OK (OK) OK

Lab2: 別のアカウントから VPC を追加する

CloudFormationで環境を作成

下記のような構成にします。2つ目のAWSアカウントで環境を作成します。

design-lab2
画像引用元: AWS Transit Gateway ハンズオン Lab2

AWSアカウント2で、用意されているCloudFormationで環境を作成します。

Transit Gatewayリソースの共有

AWSアカウント1のTransit GatewayをAWSアカウント2へ共有します。
001

002

これ以降、AWSアカウント2で操作します。
AWSアカウント2で承諾します。

003
004

Transit Gatewayアタッチメントを作成

AWSアカウント2のPrivateVPC2と共有したTransit Gatewayを関連づけるため、Transit Gatewayアタッチメントを作成します。

005
006
007

Transit Gatewayルートテーブルを編集

アタッチされたトランジットゲートウェイを通して、AWSアカウント1の BoundaryVPC, PrivateVPC1 およびインターネットとの経路を作成します。

ルートを編集します。
008

デフォルトルートとして送信先 0.0.0.0/0、ターゲット トランジットゲートウェイを選びルートを追加します。
009

追加できました。
010

疎通確認

AWSアカウント2のPrivateVPC2のEC2へ接続し疎通確認をします。

// AWSアカウント1 BoundaryVPCへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.43 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=1.06 ms

// AWSアカウント1 PrivateVPC1へ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=126 time=1.29 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=126 time=0.989 ms

// インターネットへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.49) 56(84) bytes of data.
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=1 ttl=247 time=2.98 ms
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=2 ttl=247 time=2.03 ms

この時点で全てのVPCが通信できる状態です。

Src\Dst 192-168-1-100 10.0.1.100 10.1.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (OK) OK OK OK
PrivateVPC1(10.0.1.100) OK (OK) OK OK
PrivateVPC2(10.1.1.100) OK OK (OK) OK

Lab3: ルートテーブルを使用してトラフィックを分離する

ここではすべてのVPCが相互に通信できる環境から、アカウント1のPrivateVPC1とアカウント2のPrivateVPC2を通信できないよう構成変更します。

design-lab3
画像引用元: AWS Transit Gateway ハンズオン Lab3

Transit Gateway ルートテーブル作成

AWSアカウント1で操作します。Transit Gatewayルートテーブルを新規作成します。

001
002

デフォルトルートテーブルからPrivateVPCアタッチメントの関連付けを削除する

wstgwTgwVpcAttachmentPrivateVpc1(PrivateVpc1のアタッチメント)とブランク(PrivateVpc2のアタッチメント)のTransit GatewayアタッチメントIDをメモします。この2つを削除します。

003

(注)共有先のアタッチメント名は表示されません。[詳細] から「リソース所有者ID」を確認すると AWS Account ID(Shared)となっていることを確認できます。

  • アカウント1のPrivateVpc1のアタッチメント

    • tgw-attach-0eb788cfce6467691(wstgwTgwVpcAttachmentPrivateVpc1)　vpc-032c5a5f22d3be7f4　
      005

  • アカウント2のPrivateVpc2のアタッチメント

    • tgw-attach-0b9f58fb8faf976b8(ブランク)　vpc-01d0d875ca1e45ff4
      004

2つのアタッチメントを削除していきます。

006
007a
007b

PrivateVPCアタッチメントを作成したルートテーブルに関連付ける

新しく作成したルートテーブル(wstgwRtbPrivateVPC)を選択し、wstgwTgwVpcAttachmentPrivateVpc1(PrivateVpc1のアタッチメント)を関連付けます。
008
009

PrivateVPC2のアタッチメントも同様に関連付けます。

010

2つのアタッチメントの関連付けを作成できました。
011

ルートを追加

作成したルートテーブルに デフォルトルート(0.0.0.0/0) を追加します。
012

BoundaryVPCのアタッチメントを選択します。
013
014

Blackhole ルート を追加

作成したルートテーブルに Blackhole ルート を追加します。

014
015
016

疎通確認

まずは、AWSアカウント1 BoundaryVPC のEC2に接続し疎通確認を行います。

// AWSアカウント1 PrivateVPC1へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=126 time=0.982 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=126 time=1.13 ms

// AWSアカウント2 PrivateVPC2へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=126 time=1.91 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=126 time=1.30 ms

//インターネットへ OK
[ssm-user@ip-192-168-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.56) 56(84) bytes of data.
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=1 ttl=248 time=2.48 ms
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=2 ttl=248 time=2.34 ms

AWSアカウント1 PribateVPC1 のEC2に接続し疎通確認を行います。

// AWSアカウント1 BoundaryVPCへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.41 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=2.02 ms

// AWSアカウント2 PribateVPC2へ NG
[ssm-user@ip-10-0-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.

// インターネットへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.49) 56(84) bytes of data.
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=1 ttl=247 time=2.15 ms
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=2 ttl=247 time=2.10 ms

AWSアカウント2 のEC2に接続し疎通確認を行います。

// AWSアカウント1 BoundaryVPCへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.42 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=1.51 ms

// AWSアカウント1 PrivateVPC1 へ NG
[ssm-user@ip-10-1-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.

// インターネットへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.49) 56(84) bytes of data.
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=1 ttl=247 time=2.50 ms
64 bytes from server-18-65-168-49.nrt57.r.cloudfront.net (18.65.168.49): icmp_seq=2 ttl=247 time=1.40 ms

Lab3の終了時点では、このような疎通状況となりました。

Src\Dst 192-168-1-100 10.0.1.100 10.1.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (ok) OK OK OK
PrivateVPC1(10.0.1.100) OK (ok) NG OK
PrivateVPC2(10.1.1.100) OK NG (ok) OK

PrivateVPC1 と PrivateVPC2 間では疎通できなくなっています。

「Blackhole ルートを追加 は必要だったのでしょうか？考察してみてください。」と書いてあったので検証のため Blackhole ルートを削除して疎通確認してみました。

017

AWSアカウント１BoundaryVPCのEC2に接続し疎通確認を行います。

//AWSアカウント1 PrivateVPC1 へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=126 time=1.51 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=126 time=0.693 ms

//AWSアカウント2 PrivateVPC2 へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=126 time=1.55 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=126 time=0.894 ms

//インターネットへ OK
[ssm-user@ip-192-168-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.56) 56(84) bytes of data.
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=1 ttl=248 time=2.55 ms
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=2 ttl=248 time=2.48 ms

AWSアカウント1 PrivateVPC1のEC2に接続し疎通確認を行います。

//AWSアカウント1 Boundary VPCへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.13 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=0.903 ms

//AWSアカウント2 PrivateVPC2 へ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=124 time=1.88 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=124 time=0.707 ms

//インターネットへ OK
[ssm-user@ip-192-168-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.65.168.56) 56(84) bytes of data.
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=1 ttl=248 time=2.55 ms
64 bytes from server-18-65-168-56.nrt57.r.cloudfront.net (18.65.168.56): icmp_seq=2 ttl=248 time=2.48 ms

AWSアカウント2　PrivateVPC2のEC2に接続し疎通確認を行います。

//AWSアカウント1 Private VPCへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=124 time=1.87 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=124 time=1.09 ms

//AWSアカウント1 BoundaryVPCへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.06 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=1.06 ms

//インターネットへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (18.172.52.47) 56(84) bytes of data.
64 bytes from server-18-172-52-47.nrt20.r.cloudfront.net (18.172.52.47): icmp_seq=1 ttl=248 time=1.43 ms
64 bytes from server-18-172-52-47.nrt20.r.cloudfront.net (18.172.52.47): icmp_seq=2 ttl=248 time=1.31 ms

全てのVPCで疏通可能となりました。

Src\Dst 192-168-1-100 10.0.1.100 10.1.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (ok) OK OK OK
PrivateVPC1(10.0.1.100) OK (ok) OK OK
PrivateVPC2(10.1.1.100) OK OK (ok) OK

結果、PrivateVPC1とPrivateVPC2を疎通不可にするためにはBlackholeルートは必要でした。

Lab4: トランジットゲートウェイピアリングでTGW同士を接続する

CloudFormation Template の展開

AWSアカウント1のバージニア北部リージョンで操作します。用意されているテンプレートを使用して下記環境(PrivateVPC3の環境)を作成します。

design-all
画像引用元: AWS Transit Gateway ハンズオン Lab4

Transit gatewayアタッチメントを作成する

東京リージョンで操作します。下記のようにTransit gatewayアタッチメントを作成します。アタッチメントタイプは「Peering Connection」を選びます。

001

ピアリングリクエストアタッチメントの承認

バージニア北部リージョンで操作します。先ほどのTransit gatewayアタッチメントを承諾します。
002

Transit Gateway ルートテーブルの関連付けの確認

バージニア北部リージョンで操作します。
003

ルートタブを確認すると、PrivateVPC3(10.2.0.0/16) の経路が伝播されています。

004

東京リージョンで操作します。
リソースタイプが Peering のアタッチメントがデフォルトのルートテーブルに関連づけられています。
005

PrivateVPC3(10.2.0.0/16) の経路はルートテーブルに存在しません。
006

ルートの追加

  • 東京リージョン

Transit Gateway ルートテーブルに PrivateVPC3(10.2.0.0/16) を追加します。

007
008

ルートテーブル(wstgwRtbPrivateVPC)も同様にPrivateVPC3(10.2.0.0/16) を追加します。

016
010
011

  • バージニア北部リージョン

Transit Gateway ルートテーブルにデフォルトルート(0.0.0.0/0)を追加します。
012
013
014

疎通確認

  • アカウント1 BoundaryVPCから
//アカウント1 PrivateVPC1へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=126 time=1.87 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=126 time=1.38 ms

//アカウント2 PrivateVPC2へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=126 time=1.21 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=126 time=1.02 ms

//アカウント1 PrivateVPC3へ OK
[ssm-user@ip-192-168-1-100 bin]$ ping 10.2.1.100
PING 10.2.1.100 (10.2.1.100) 56(84) bytes of data.
64 bytes from 10.2.1.100: icmp_seq=1 ttl=124 time=146 ms
64 bytes from 10.2.1.100: icmp_seq=2 ttl=124 time=145 ms

//インターネットへ OK
[ssm-user@ip-192-168-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (3.166.228.72) 56(84) bytes of data.
64 bytes from server-3-166-228-72.nrt20.r.cloudfront.net (3.166.228.72): icmp_seq=1 ttl=249 time=1.11 ms
64 bytes from server-3-166-228-72.nrt20.r.cloudfront.net (3.166.228.72): icmp_seq=2 ttl=249 time=0.365 ms
  • アカウント1 PrivateVPC1 から
// BoundaryVPC へ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=1.63 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=0.811 ms

// PrivateVPC2へ NG
[ssm-user@ip-10-0-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.

// PrivateVPC3 へ OK
[ssm-user@ip-10-0-1-100 bin]$ ping 10.2.1.100
PING 10.2.1.100 (10.2.1.100) 56(84) bytes of data.
64 bytes from 10.2.1.100: icmp_seq=1 ttl=124 time=146 ms
64 bytes from 10.2.1.100: icmp_seq=2 ttl=124 time=145 ms

// インターネットへ OK
[ssm-user@ip-10-0-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (3.166.244.23) 56(84) bytes of data.
64 bytes from server-3-166-244-23.nrt20.r.cloudfront.net (3.166.244.23): icmp_seq=1 ttl=248 time=1.39 ms
64 bytes from server-3-166-244-23.nrt20.r.cloudfront.net (3.166.244.23): icmp_seq=2 ttl=248 time=0.835 ms
  • アカウント2 PribateVPC2 から
// BoundaryVPC へ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=126 time=0.962 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=126 time=1.02 ms

// PrivateVPC1 へ NG
[ssm-user@ip-10-1-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.

// PrivateVPC2 へ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=127 time=0.017 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=127 time=0.031 ms

// PrivateVPC3 へ OK
[ssm-user@ip-10-1-1-100 bin]$ ping 10.2.1.100
PING 10.2.1.100 (10.2.1.100) 56(84) bytes of data.
64 bytes from 10.2.1.100: icmp_seq=1 ttl=124 time=147 ms
64 bytes from 10.2.1.100: icmp_seq=2 ttl=124 time=146 ms

// インターネットへ OK
[ssm-user@ip-10-1-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (3.166.228.17) 56(84) bytes of data.
64 bytes from server-3-166-228-17.nrt20.r.cloudfront.net (3.166.228.17): icmp_seq=1 ttl=248 time=1.15 ms
64 bytes from server-3-166-228-17.nrt20.r.cloudfront.net (3.166.228.17): icmp_seq=2 ttl=248 time=0.505 ms
  • アカウント1 バージニアリージョン　PrivateVPC3 から
// BoundaryVPC へ OK
[ssm-user@ip-10-2-1-100 bin]$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=124 time=145 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=124 time=144 ms

// PrivateVPC1 へ OK
[ssm-user@ip-10-2-1-100 bin]$ ping 10.0.1.100
PING 10.0.1.100 (10.0.1.100) 56(84) bytes of data.
64 bytes from 10.0.1.100: icmp_seq=1 ttl=124 time=145 ms
64 bytes from 10.0.1.100: icmp_seq=2 ttl=124 time=144 ms

// PrivateVPC2 へ OK
[ssm-user@ip-10-2-1-100 bin]$ ping 10.1.1.100
PING 10.1.1.100 (10.1.1.100) 56(84) bytes of data.
64 bytes from 10.1.1.100: icmp_seq=1 ttl=124 time=145 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=124 time=144 ms

// インターネットへ OK
[ssm-user@ip-10-2-1-100 bin]$ ping aws.amazon.com
PING dr49lng3n1n2s.cloudfront.net (99.84.188.15) 56(84) bytes of data.
64 bytes from server-99-84-188-15.iad89.r.cloudfront.net (99.84.188.15): icmp_seq=1 ttl=224 time=289 ms
64 bytes from server-99-84-188-15.iad89.r.cloudfront.net (99.84.188.15): icmp_seq=2 ttl=224 time=287 ms
Src\Dst 192.168.1.100 10.0.1.100 10.1.1.100 10.2.1.100 Internet(aws.amazon.com)
BoundaryVPC(192-168-1-100) (OK) OK OK OK OK
PrivateVPC1(10.0.1.100) OK (OK) NG OK OK
PrivateVPC2(10.1.1.100) OK NG (OK) OK OK
PrivateVPC3(10.2.1.100) OK OK OK (OK) OK

アカウント1 PrivateVPC1 と アカウント2 PrivateVPC2 間以外は疎通可能な状態となりました。

おわりに

お客様の環境を調査する際に、Transit Gateway でVPC同士を接続していることが多々あり調査が複雑になります。今回ハンズオンを通して実際に自分で作成してみることでクリアになった部分もあるので今後の業務に活かせたらと思います。

Share this article

facebook logohatena logotwitter logo

関連記事

AIによるスパイクアクセスを受けたので、 robots.txtの調整や AWS WAFによる対策を試みてみた

AIによるスパイクアクセスを受けたので、 robots.txtの調整や AWS WAFによる対策を試みてみた

User avatar
suzuki.ryo
2025.02.24
Q in QuickSight の機能はトピック無しでどこまで使えるのか色々試してみた

Q in QuickSight の機能はトピック無しでどこまで使えるのか色々試してみた

User avatar
emi
2025.02.24
Mountpoint for Amazon S3 にファイルを直接ダウンロードできるのか検証してみた

Mountpoint for Amazon S3 にファイルを直接ダウンロードできるのか検証してみた

User avatar
大村 保貴
2025.02.24
AWS DataSyncの検証で使用するチェックサムの計算タイミングを確認してみた

AWS DataSyncの検証で使用するチェックサムの計算タイミングを確認してみた

User avatar
のんピ
2025.02.24
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.