はじめに
この記事はMEGAZONECLOUD Cloud Technology Center Tech Blog記事の翻訳版です。
AWS TRANSIT GATEWAY こんなに良いものをどうして使わないんですか
執筆者: ハ・スヨン
皆さんはAWSを使いながらネットワークアーキテクチャをどのように作っていますか？
AWSインフラストラクチャの拡張やセキュリティのためにどのような方法で取り組んでいますか？
今日は最初の時間としてAWSネットワークサービス接続の核心とも言えるTransit Gatewayについてお話したいと思います。
Transit Gatewayは2018年12月、ソウルリージョンにローンチしました。
かなり前にサービスができたにもかかわらず、多くの方々が以下のようなアーキテクチャでVPC Peeringを通じたフルメッシュ型ネットワークを構成しています。
もちろんこの構造に長所がないわけではありません。
最大のメリットとしては、VPC間のトラフィックコストが安いことです。
VPC PeeringサービスはEC2のトラフィックコストとして計算されるCross AZ(Availability Zones)のみが課金されます。そのためVPC間の通信トラフィックコストが相対的に安価です。
しかし、会社にAWSインフラストラクチャを管理できる人が少なくなったり、DevOpsのように複数の業務を兼職している場合にインフラストラクチャが増えれば増えるほど難しくなります。そして、もしルーティングを確認するには、複数のアカウントにある複数のVPCのルーティングテーブルをそれぞれ確認する必要があります。
実際、メッシュ型のインフラストラクチャを管理するのはとても大変なことです。
個人的に次のケースに該当する場合は、Transit Gatewayの使用をお勧めします。
・アプリケーションサービスが非常に高速に拡張され、迅速にインフラストラクチャの確保をしなければならない場合
・支社や工場などで多くのインターフェースを接続する必要がある場合
・BGPで伝播されるルーティングの経路が100を超える場合
・オペレーション、品質、開発等の環境をVPCで分け、ルーティングを細かく制御しようとする場合
・海外支社と安定したプライベートネットワークを構築したいが、MPLS、SD-WANを構成する余裕がない場合
・SAP on AWSを導入/移行する場合
・Inbound/Outboundトラフィックをモニタリングしようとする場合
・EC2環境のアプリケーションでMulticastを利用する場合
例を挙げて説明すると理解しやすいと思います。
以下はTransit Gatewayを利用する仮想会社のアーキテクチャです。
各VPCの用途は以下のとおりです。
・Services VPC : 対外サービスが存在するVPC
・Shared VPC : 社内グループウェア、セキュリティソリューションのポリシーサーバ、ソース展開サービス等が存在するVPC
・DEV VPC : 開発環境のVPCで、仮想会社の開発パートナー会社から唯一アクセスできる環境
・Playground : 内部エンジニアと開発者の能力を強化するためのAWSテスト環境
皆さんもご存知のとおり、VPCはVirtual Private Cloudの略語で独立したネットワーク環境を構成します。これらの独立したネットワーク環境にTransit Gatewayを利用して各環境を連結したり、連結できないようにすることができます。 このようなルーティング設定を容易にできるようにサポートします。
Transit Gateway（以下「TGW」と併記）サービスは5つの機能がありますが、それぞれの役割は以下のとおりです。
・Transit Gateways : Transit Gatewayを生成する機能です。
・Transit Gateway Attachments : TGWで接続を担当する機能です。 コンポーネントには、VPC、S2S VPN、Cross region Transit Gateway接続用のピアリング接続があります。
・Transit Gateway Route Tables : TGWのルーティングを担当するルーティングテーブルが集まっているところです。すべてのAttachmentは、単一のRoute Tableを使用して通信が可能です。上記のアーキテクチャのように、特定のAttachmentに基づいて、それぞれルーティングテーブルを分割して設定することもできます。
・Transit Gateway Multicast : マルチキャスト設定用のメニューです。
・Network Manager : 別途費用なしでTGWを簡単にモニタリングし、ルーティングを検証する機能です。
基本的なTGWの機能が理解できたら、サンプルアーキテクチャをConsole GUI環境に展開してみましょう。
私たちが今回テストで作る環境は以下のアーキテクチャです。
まずTGWを作ります。
この時、他のオプションは生成後に変更できますが、ASNは変更できません。
ASNは、今後Attachmentで生成するコンポーネントのうち、BGPプロトコルを利用する機器とオーバーラップすることはできませんので、BGPをご利用の方はASNを再度確認して頂ければと思います。
その後、それぞれのVPCごとにAttachmentを生成します。
以下のスクリーンショットはRed_VPCに基づいています。
Attachmentを作成すると、選択したSubnetにTGW用途のElastic Network Interface(ENI)が自動的に生成されます。
これでそれぞれのTGWのRouteTableを作成して、それぞれAssociationしています。
以下はRed Routing TableでRed_VPCをAssociationさせた画面です。
TGWで各VPCに割り当てられたRouteTableが作成されました。
ルーティングポリシーを入れるようにします。
以下のような図表の形で構成されるようにします。
RouteTypeをご覧いただくと、「Static」と明示されています。
RouteTypeには2種類があります。
・Static : 管理者が手動で入力した経路
・Propagated : RouteTableのpropagationsに登録されたAttachmentが自動的に伝播した経路
下のBlue、Greenルーティングテーブルを注意深く見ると、一部はStaticに設定されており、一部はPropagated状態です。
これは「このようにもできる」ということを示すためにテスト環境を構成したものですので、なるべくVPCはPropagationsに登録して管理することをお勧めします。
設定が完了したら、TGW「Network Manager」を通じてルーティングポリシーが正常であるかを確認してください。
上で申し上げたとおり、意図的に通信が行われないようにしたため、このような結果が出力されます。
初めてサービスを立ち上げた際は概念を理解することが難しかったのですが、他の方が理解するために役立つよう本記事を作成しました。
少しでもお役に立ちましたでしょうか？
フィードバックを残して頂ければ、次の記事で補完できるようにします。
下記のリンクはAWS公式ガイドドキュメントなので、読んでみると役立つと思います。
長文を読んでいただきありがとうございます。
MEGAZONEはAWS プレミアティア サービスパートナーとして多数のCompetencyを取得しており、大企業、ゲーム会社、スタートアップ、公共機関などさまざまな分野の5,000以上のお客様にAWSソリューションとサービスを提供しています。
Discussion