Transit Gatewayを共有して複数AWSアカウントと
Azure環境をサイト間接続してみた
投稿日: 2024/6/10
はじめに
こんにちは。CTCの朴木です。
前回の記事では、Site to Site VPNを用いてAWSとAzureの環境を接続しました。今回は予告通り、別のAWSアカウントを加えて、AWS Resource Access Manager(以下 RAM)でTransit Gatewayを共有してAzureからそのアカウントへの通信を可能にするような環境構築をしてみたいと思います。
AWS環境とAzure環境のサイト間接続については前回の記事をご参考ください!

事前準備
上記青枠の環境については前回の記事をご参考ください。
事前準備として今回もAWS側のVPCやサブネット等の作成は済ませた状態とさせていただきます。なお、本記事ではTransit GatewayがあるアカウントをアカウントA、追加アカウントをアカウントBとして記載します。
AWS側
・VPCのCIDR:10.2.0.0/16
サブネット名 | AZ | CIDR | ルートテーブル名 |
---|---|---|---|
subnet-private01-2a | 2a | 10.2.1.0/24 | rtb-private01-2a |
subnet-private01-2c | 2c | 10.2.101.0/24 | rtb-private01-2c |
subnet-transit-2a | 2a | 10.2.5.0/28 | rtb-transit-2a |
subnet-transit-2c | 2c | 10.2.105.0/28 | rtb-transit-2c |
前回の記事ではTransit Gatewayの設定について書けなかったため、今回の記事で設定値を記載させていただきます。
Transit Gatewayの共有
リソースの共有にはRAMを利用します。
まずはTransit Gatewayが作成されているアカウントA側で共有の設定を実施します。
AWSコンソールへログインし、検索画面からRAMを検索してサービス画面へ遷移します。
左ペインの「リソースの共有」を選択し「リソース共有を作成」をクリックします。

リソースに名前を入力し、リソースオプションにて「トランジットゲートウェイ」を選択します。今回共有したいリソースにチェックをいれ、「次へ」ボタンをクリックします。

マネージド型アクセス許可の関連付け画面に遷移し、「次へ」ボタンをクリックします。

プリンシパルオプションにて、「すべてのユーザとの共有を許可」を選択します。プリンシパルタイプを「AWSアカウント」とし、共有するアカウントBのアカウントIDを入力して「追加」ボタンをクリックします。
追加されたアカウントにチェックをいれ、「次へ」ボタンをクリックします。

確認と作成画面に遷移後、「リソース共有を作成」ボタンをクリックします。
これでリソースの共有がされますのでアカウントBのTransit Gateway画面を確認してみましょう。
Transit Gateway画面にリソースが表示されていない場合は、アカウントB上でRAMを確認し、招待を許可してください。
Transit Gatewayアタッチメントの作成
アカウントB側でVPCサービスへ画面遷移し、左ペインの「Transit Gateway アタッチメント」を選択して「Transit Gateway アタッチメントを作成」ボタンをクリックします。

名前を入力し、先ほど共有したTransit Gatewayを選択します。
対象のTransit Gatewayが出てこない場合はRAMにて共有の招待がきていることを確認し、許可してください。
アタッチメントタイプに「VPC」を選択し、Transit GatewayにアタッチするVPC、サブネットを選択して「Transit Gatewayアタッチメントを作成」ボタンをクリックします。
(下記はアカウントBのアタッチメントになりますが、アカウントAにも同様にアタッチメントを作成してます。)

アカウントAに移ります。アカウントBで作成したTGWアタッチメントが表示されているので、「アクション」ボタンより「Transit Gatewayアタッチメントを承認」を選択します。

確認のポップアップが表示されるので、「承認」ボタンをクリックします。

ルーティング設定
ルーティングの設定についてみていきましょう。まずはTransit Gatewayのルートテーブル情報です。
ルートにはアタッチメントタイプがVPCのTransit Gatewayアタッチメント(アカウントAとアカウントBの2つ)と、Site to Site VPN設定時に自動的に作成されるアタッチメントタイプがVPNのTransit Gatewayアタッチメントが設定されています。
今回は動的ルーティングで構築しているため、追加で設定するものはありません。

サブネットのルートテーブルについては設定が必要になります。Azure側と通信できるようルートテーブルの設定は下記のようにしています。
・アカウントA
サブネット | 送信先 | ターゲット |
---|---|---|
Privateサブネット | 10.1.0.0/16 | local |
172.17.0.0/16 | tgw-xxxxxxxxxxx(TGWのID) | |
TransitGatewayサブネット | 10.1.0.0/16 | local |
・アカウントB
サブネット | 送信先 | ターゲット |
---|---|---|
Privateサブネット | 10.2.0.0/16 | local |
172.17.0.0/16 | tgw-xxxxxxxxxxx(TGWのID) | |
TransitGatewayサブネット | 10.2.0.0/16 | local |
以上の設定によって、Azure側のサーバからアカウントAとアカウントBのサーバへ通信が可能になります。
疎通確認
それではAzure側のサーバからpingを打ってみましょう!

上記のとおり、2つのAWS環境側のサーバそれぞれに対してpingが通ったことを確認しました。AWS側からもAzureに構築したサーバに対してpingを打ちましたが、同様にリスポンスが返ってきました!
これにより正しくTGWの共有やルーティングの設定がされていることが確認できました。
通信ができない場合にはほかの設定で妨げている可能性があります。セキュリティグループやネットワークACL等で制限をしていないか確認をしてみましょう。
おわりに
いかがでしたでしょうか。
前回のブログと合わせてAzure環境からAWS環境への接続において、Site to Site VPNやTransit Gatewayの共有設定を実施し、複数アカウントへの接続を確立しました。
今回の検証環境ではRAMでのリソース共有オプションを「すべてのユーザとの共有を許可」にしましたが、同じ組織内であれば「自分の組織内でのみ共有を許可」も選択可能です。組織内でのみの共有をする場合は、マスターアカウントのAWS Organizationsサービス画面にてRAMの有効化を事前に実施しておく必要がありますので設定しておきましょう。
ここからは感想になりますが、個人的にはAzureに詳しくないためAzure側の設定でだいぶ引っかかりました…。あまり構成には関係ありませんが、Windowsサーバを今回利用したのですが、Windowsファイアウォールの設定を抜かしてしまい、pingが通らず原因に気づくまで時間がかかってしまったこともありました…。
結果としては今回学ぶことが多かったのでこれからもこういった内容も発信していきたいと思います!今回の記事が誰かの参考になれば幸いです。
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。