SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

AWS Transit Gateway導入記

AWS

はじめに

こんにちは、オリンピックの抽選申し込みが全ハズレでテンションガタ落ち（ってほどでもないですけど）のCISO新井です。どうやら次回の抽選はさらに狭き門となるようですがまだまだ諦めないですよ。

さて、今日は最近実施したAWS Transit Gateway導入の顛末をお伝えしようかと思います。

きっかけはこんなところから

SSTでもいろいろな場面でAWS上にシステムを構築・運用させていただいています。これらのシステムにVPN経由でアクセスしていたりするのですが、少々前にこのVPN接続（AWS VPN Classic）が終了になるので新しいVPN接続（AWS VPN）に移行してね、というAWSからの通知が来ていました(ってのをしばらく見逃してました。。(T_T))。 Personal Health*1 にて確認すると、今年の9月30日までに移行を終了する必要があるという内容となっていました(ので、けっこう焦りました (>_<))。

f:id:micara:20190710185113p:plain

この通知の中で移行の手順が案内されていたのでその内容を(ソッコーで)確認します。

  • Classic VPNからSite to Site VPNへの移行
    • https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPC_VPN.html#aws-vpn-migrate

      この手順の間に、ルート伝播を無効にして古い仮想プライベートゲートウェイを VPC からデタッチするとき、現在の VPC 接続による接続は中断されます。新しい仮想プライベートゲートウェイが VPC にアタッチされ、新しい Site-to-Site VPN 接続が有効になると、接続は回復します。予期されるダウンタイムのために必ず計画を立ててください。

どうやら移行作業の過程でダウンタイムが発生するタイミングがあるようです。となると、影響する範囲にメンテナンスの案内を出して作業を実施することになるわけです。で、どうせダウンタイムが発生するのならついでに前々から気になっていたTransit Gatewayを導入する計画もいれちゃおうか、と。まあそんな経緯だったりします。

AWS Transit Gatewayとは

AWSの活用が進むと複数のアカウントにまたがる複数のVPCをピアリング接続などであちこち接続することになると思います。そしていつの間にか、ネットワークのトポロジーは理解の困難な複雑なものに。。 これに対して、Transit Gatewayをネットワークトポロジーの中心に据えることで多くのVPCを相互に接続しつつも構成をシンプルな状態に保ちやすくなります。

上図のように「AWS Transit Gateway を使用しない場合」と「AWS Transit Gateway を使用した場合」でネットワーク構成が見た目にもはっきりとシンプルになっていることが見て取れます。

Transit GatewayではいわゆるVRF(Virtual Routing and Fowarding)相当のことができるようになっているようです。複数の仮想ルータが別々のルーティングテーブルを持つことで柔軟なネットワークを組むことができるようになっています。また、各VPCから受け取った通信のルーティングはこの仮想ルータを持つTransit Gatewayに集中することになるため全体としてのコントロールをしやすくなるメリットもありそうです。

構成変更後の概略図

ではさっそくこのTransit Gatewayを導入してみます。Transit GatewayはVPCだけではなくてVPNも接続可能です。移行作業としては、これまでVPCに直接つながっていたAWS VPN Classicを廃し、新たに構築するAWS VPNと既存のVPCをTransit Gateway経由で接続することになります。図にすると、移行前と移行後でざっくりと以下のような構成の変更となります。

f:id:micara:20190711142533p:plain

今後は、VPC・VPNが増えたとしてもTransit Gatewayに接続するだけで既存のVPC・VPNと相互に通信できるようになります。将来的なVPCの増加が見込まれるような環境では、早めの段階でTransit Gatewayを中心に据えたネットワーク構成を準備しておくと良さそうに思います。

Transit Gateway導入後の展望

さて、ではこのTransit Gatewayの特性を活かし今後どう設計に反映していくかという観点でもう少し検討してみます。

先月(2019年6月)開催されたAWS Summit Tokyo 2019にて「Transit Gateway Deep Dive アーキテクチャガイド」というタイトルにて行われていたセッションをオンラインで聴講させてもらったのですが、その中で「2019.6のReference Network Architecture」として紹介されていたのが以下の構成図です。

f:id:micara:20190708200553p:plain

用途ごとに分けられた複数のVPCとVPNがTransit Gatewayを介して接続されています。認証などの共有サービスを提供するVPC、URLフィルタリングやNATなどを経由して外部接続を行うVPC、IDS/IPSなどが設置されたVPCなど、共通で必要となる機能をカテゴリごとにVPC内に集約して提供しているような構成となっています。新たにVPCを追加する場合でも、Transit Gatewayに接続するだけで容易にこれらの機能を利用できる状態になっていることが想像されます。Transit Gateway無しで同様のことを実施しようと思ったらなかなかたいへんなことになりそうです。同セッションでは他にも有用な内容が含まれており、今後の活用ということでは非常に参考になりました。資料などは後日公開されるようなので、また改めて確認したいところです。

外部接続の通信を集約する部分を組んで見る

実際にReference Network Architectureにある構成から外部接続の通信を集約する部分を試しに組んでみました。構成図は以下のような具合です。

f:id:micara:20190710174318p:plain

3つのVPCとTransit Gatewayで構成しています。VPC1とVPC2にはEC2を設置しています。また、VPC3にはNATゲートウェイを設置しています。 各EC2から発生する外部への通信をTransit Gatewayを経由してVPC3のNATゲートウェイに集約するような構成です。 このような通信を実現するためには、Transit Gateway内で設定するルーティングテーブルと各VPCで設定するルーティングテーブルの内容をどうするかポイントとなります。

各VPCの主な構成は以下となります。

  • VPC1(10.252.0.0/16)
    • サブネット1つ(10.252.0.0/24)
    • EC2(10.252.0.100)
  • VPC2(10.253.0.0/16)
    • サブネット1つ(10.253.0.0/24)
    • EC2(10.253.0.100)
  • VPC3(10.254.0.0/16)
    • 外部接続用のVPC
    • サブネット2つ
      • Transit Gatewayと接続するサブネット(10.254.0.0/24)
      • NATゲートウェイを配置するサブネット(10.254.1.0/24)

それぞれのVPCで定義しているルートテーブルは以下となります。

  • VPC1

    • ローカルへの通信以外はすべてTransit Gatewayに転送します。f:id:micara:20190710171931p:plain

  • VPC2

    • ローカルへの通信以外はすべてTransit Gatewayに転送します。f:id:micara:20190710172003p:plain

  • VPC3

    • Transit Gatewayと接続するサブネット
      • ローカルへの通信以外はすべてNATゲートウェイに転送します。f:id:micara:20190710173217p:plain
    • NATゲートウェイを配置しているサブネット
      • インターネットゲートウェイへの経路と、Transit Gatewayへの経路を設定します。f:id:micara:20190710172115p:plain

また、Transit Gatewayでは以下の2つのルートテーブルを定義しています。

  • ルートテーブル１

    • VPC1およびVPC2からTransit Gatewayに送信されてくる通信のルーティング
    • すべての通信をvpc-attach3で接続されているVPC3へ送信するルーティングを設定f:id:micara:20190710170743p:plain:w300

  • ルートテーブル２

    • VPC3からTransit Gatewayに送信されてくる通信のルーティング
    • VPC1およびVPC2へ送信するためのルーティングを設定f:id:micara:20190710171030p:plain:w300

では、実際に各EC2から外部へ疎通できるか確認してみます。なお、EC2のコンソールはAWS Systems Managerのセッションマネージャー*2経由で接続しています。

  • EC2(10.252.0.100)からwww.example.comへの疎通確認 f:id:micara:20190710181827p:plain

  • EC2(10.253.0.100)からwww.example.comへの疎通確認 f:id:micara:20190710182020p:plain

いずれも無事に疎通しているようです*3

今後、さらにいろいろと実験・検証を交えつつ徐々にネットワークの拡大・再構成を行っていけたらと思います。

最後に

オリンピックのチケット、次回抽選では当たりますように！

*1:https://aws.amazon.com/jp/blogs/news/aws-personal-health-dashboard/

*2:https://aws.amazon.com/jp/blogs/news/new-session-manager/

*3:今回の構成ではVPC1とVPC2の間での通信も可能な状態となっています。Reference Network ArchitectureではVPC間の通信を隔離するケースについても言及されていますが、これを実現する場合は「ルートテーブル１」にて「10.0.0.0/8」あたりをblackhole設定すれば良さそうです。