こんにちは。 「AWS 認定 高度なネットワーキング - 専門知識」の認定取得に向けて猛勉強をしていますが、まだまだネットワーク界の幕下にも上がれない尾谷です。
2 月 5 日に試験を受けまして、残念ながら不合格でした。
これまで AWS 認定試験を 10 回受験して (再認定含む) 全部合格だったのに、11 回目にしてとうとう落ちました。
AWS 認定プログラムアグリーメントの関係上、具体的な試験問題に関してはお話しできかねますが自分に足りなかった知識の一つである AWS Transit Gateway を学びましたのでアウトプットしたいと思います。
元ネタ
AWS Transit Gateway の概念を学ぶにあたり AWS Summit Tokyo 2019 の動画が非常に分かりやすいです。
若干情報が古く、CloudWAN などのリージョン間通信の概念が触れられていませんが、すごく勉強になりました。
覚えておきたい用語
それでは、覚えておきたい用語からまとめていきます。
アタッチメント
VPC と Transit Gateway を繋ぐ操作をアタッチメントと言います。
物理で言うと L3 スイッチにポートを突き挿した状態で、リンクアップをしただけの状態と理解ください。
(と、登壇された菊池さんがおっしゃっていました。)
ルートテーブル
VPC でも利用をする経路情報テーブルは、VPC と違い複数作成ができます。
アソシエーション
ルートテーブルをアタッチメントに紐づける作業をアソシエーションと言います。
L3 スイッチでいうところの、ポートにルートテーブルを結びつける作業です。
ルートテーブルは、アタッチメントに一つだけアソシエイトできます。
プロパゲーション
プロパゲーションはルートテーブルの伝播のことです。
ルートテーブルはアタッチメントに一つしかアソシエイトできませんが、複数のルートをプロパゲーションできます。
ここが非常に説明しづらく、分かりづらいです。
僕は、アタッチは一つ、ルーティングの伝播は複数 と覚えました。
スタティックルート
デフォルト設定だと自動で伝播するルートが、伝播しないスタティックルートを書くことができます。
要は、デフォルト設定だと、繋いだ VPC は何も設定しなくても接続できるが、ちょっと複雑なことをやろうとすると用語の理解が必須という感じでしょうか。 実際に設定してみたいと思います。
デフォルト設定で Transit Gateway を作成してみる
それでは、ここから表題の通り、Transit Gateway をリージョン間でクロスアカウントで設定してみます。
具体的には、会社の検証用アカウントと個人の検証アカウントを接続してみます。
デフォルトだと自動でプロパゲートされるため、自動的にルートテーブルが伝播されるところを確認できればと思います。
構成図
冒頭に記載した通り、NDA の関係上試験問題の内容は記載できませんが、クロスアカウントリージョン間 Transit Gateway の接続方法を理解しておくべきだと感じたので、初っ端からかなり複雑な環境にて検証しています。
環境構築
会社のアカウント「yyyy-yyyy-yyyy」は、東京リージョンに VPC を作りました。
ここでは「vpc-07f9726ed2bbXXXXX」という VPC ID が割り振られたことにします。
そして、VPC 内に 1 台 i-0f12786a747704d9c という EC2 インスタンスを起動しました。
IP アドレスは、172.16.0.202 が割り振られました。
個人アカウント「XXXX-XXXX-XXXX」は、バージニア北部リージョンに VPC を作りました。
ここでは「vpc-087df69e0937XXXXX」という VPC ID が割り振られたことにします。
そして、VPC 内に 1 台 otani-test-php (i-044b4bcdd3a742596) という EC2 インスタンスを起動しました。
IP アドレスは、10.0.1.92 が割り振られました。
Transit Gateway を作成
それでは、会社のアカウント側に Transit Gateway を作成していきます。Transit Gateway は VPC コンソール からアクセスできます。
画面右側にある [ Transit Gateway を作成 ] ボタンをクリックしました。
以下、AWS ドキュメント *1 に従って設定をしてきました。 AS 番号は、64512 を割り振りました。
以下チェックを入れると、Transit Gateway にアタッチされたクロスアカウントアタッチメントを自動的に承諾するとのこと。
『これは便利かもしれんが危険なんじゃないか？』と感じ、一旦チェックを入れずにおきました。
Transit Gateway CIDR ブロック は重複しないアドレス空間にする必要があるそうで、172.31.0.0/24 を割り当てました。
IP CIDR は、複数入れられそうです。
ドキュメントを確認すると、これは中継ゲートウェイの CIDR だと理解できました。 *2
ひとまず一つだけにします。
2 分程度でステータスが Pending から Available に変わりました。
アタッチメントを作成する
ケーブルをポートに挿し込む作業です。
アタッチメントの UI は秀逸だと感じました！Transit Gateway ID を選択して、VPC を選択すると必要な選択肢だけが表示されます。
対向の Transit Gateway も用意する
続いて個人アカウントにて、バージニア北部の Transit Gateway をプロビジョニングします。
Transit Gateway はリージョナルサービスなので、東京リージョンのものとは別にバージニア北部用に作ります。
単一リージョンで構築する場合は、Transit Gateway は一つで事足ります。繰り返しになりますが、今回は複雑な構成であることを予めご理解ください。
対向 Transit Gateway にもアタッチメントする
対向もササっとアタッチメントしました。
2 つの Transit Gateway を繋ぐアタッチメント
それでは相互を接続します。
これから行うのは、アタッチメント 03 とアタッチメント 04 の接続です。
以下のようなピアリングにて、アタッチメント 03 を作成しました。
対向のアカウント ID と Transit Gateway ID を挿入します。
対向でもアタッチメントを作成しようとしたら
エラーになりました。
原因が分からずに、少しハマりましたが VPC Peering と同様、リクエスタ側で設定すると、アクセプタ側に自動で表示される仕様でした。
承諾しました。
VPC のルーティングを設定
ここからさまざま試行錯誤を行いましたが、なかなか接続できず、結局双方のルートテーブルにスタティックルートを設定していきました。
Transit Gateway は自動でルートテーブルがプロパゲートされるようですが、2 つの Transit Gateway を相互に Peering した場合はルーティングを設定する必要があるようでした。
全てのルーティングを設定したところ、curl コマンドでバージニア北部にあるサーバーから http レスポンスが返りました。
[root@ip-172-16-0-202 ~]# curl http://10.0.1.92
<!DOCTYPE html>
<html lang="ja">
<meta charset="utf-8">
<head>
</head>
<body>
<h1>Cloud9 で開発して、EC2 にデプロイします。</h1>
<h2>見出し 2</h2>
<a href="index2.php">次のページ</a>
PHP アプリケーション</body>
</html>
[root@ip-172-16-0-202 ~]#
料金に関して
最後に Transit Gateway の料金についてまとめておきます。
Transit Gateway は料金ページにもあるとおり *3 作成するのは無料です。
アタッチメントの数に応じて時間課金され、通信量も請求されます。
そのため、短時間であれば少額で検証が可能です。(検証を終えたら速やかに削除することをお勧めします。)
今回は、2 時間検証を行いました。
数日後、料金を確認すると以下のようになっていました。
(一部、他で検証している金額を加工して省いています。)
社内検証用アカウントで発生した金額
社内検証用アカウントで発生した金額は、全部で 0.5256 USD でした。
かかったコストは、ガリガリ君 1 本分程度だったようです。
東京リージョン
Transit Gateway VPC アタッチメント: 0.07 USD * 2 時間 = 0.14 USD
通信確認で利用した Reachability Analyzer: 0.1 USD * 2 = 0.2 USD
バージニア北部
Transit Gateway ピアリングアタッチメント : 0.05 USD/時間 * 2 時間 = 0.10 USD EC2 インスタンス: 0.0428 USD/時間 * 2 時間 = 0.0856 USD
個人アカウントで発生した金額
個人アカウントで発生した金額は、0.868 USD でした。
こちらは缶コーヒー 1 本分ぐらいで試せたようです。
東京リージョン
Transit Gateway ピアリングアタッチメント: 0.07 USD * 2 時間 = 0.14 USD
バージニア北部
Transit Gateway VPC アタッチメント : 0.05 USD/時間 * 2 時間 = 0.10 USD
通信確認で利用した Reachability Analyzer: 0.1 USD * 7 = 0.7 USD
EC2 インスタンス: 0.034 USD/時間 * 2 時間 = 0.068 USD
まとめ
Transit Gateway はリージョナルサービスのため、リージョン間で接続するには Peering アタッチメントが用意でした。
また、Transit Gateway はルートテーブルをプロパゲートして自動でルート情報が伝播されますが、Peering を設定した箇所に関してはスタティック設定が必要でした。
Transit Gateway はリージョナルサービスなので、リージョンごとにデプロイすると高額になりますし、CloudWAN で構築した方がシンプルだと感じました。
最後までお読み下さり、ありがとうございました。
