AWS Transit Gateway を 使った内部ネットワークの構 成変更の話 2020/05/14 ペパボ・はてな技術大会〜@オンライン 株式会社 はてな サービス開発本部 システムプラットフォーム部 渡辺 道和 (id:nabeop) 

● id:nabeop / 渡辺 道和 ● システムプラットフォーム部 ○ はてなのサービスの共通基盤系の開発と運用部署 ● 2018年3月に中途入社 ● はてなに入るまではオンプレ中心な世界にいま した 自己紹介 

AWS Transit Gateway と私 ● Hatena Developer Blog にエントリがあります ○ AWS Transit Gateway はじめました ○ AWS Direct Connect を AWS Transit Gateway に接続した話 

AWS Transit Gateway とは? ● AWS VPN / AWS Direct Connect / AWS VPC が接続できる ● 中身は複数のルートテーブル ○ AWS VPC におけるルートテーブルと極めて似ている ○ 単一のルートテーブルのみという運用も可能 ■ 今の所、はてなにおける運用では 1つのルートテーブルのみを想定 ○ ルートテーブルでワザを使うと、非対称な経路制御ができる ● BGP による経路交換をしている ○ オンプレミス環境と接続する場合は BGP による経路交換ができるとベター ■ 静的経路のみでも接続できると思うけど、やりたくない ● コスト的には VPC Peering のほうが安い 

AWS Transit Gateway 導入前のネットワーク接続 

課題 ● 一部の AWS VPN は 2019年9月に終了予定の AWS Classic VPN を使っていて、リプ レースが必要だった ● 今後は AWS VPC の増加が見込まれており、内部ネットワークを接続する場合、VPN 方式だと管理が煩雑になることが目に見えていた ● 一部では AWS VPC 同士の接続に VPC Peering を採用していたが、全ての環境で採 用した場合、フルメッシュ構成になるので積極的に採用することは控えたい 

AWS Transit Gateway をハブにした接続 

AWS Transit Gateway の設計 ● TGW 内で複雑な経路制御をしたい場合は複数のルートテーブルを作っておく必要 がある ○ はてなにおける要件では単一のルートテーブルで十分だった ● AWS Transit Gateway は専用の AWS アカウントに作成する ○ すでに複数の AWS アカウントに AWS VPC を構築しており、その VPC を TGW に接続するとい う構成を想定していた ○ AWS Transit Gateway は AWS Resource Access Manager に対応していたので、 TGW に接続す る VPC には構築している AWS アカウントに TGW を共有リソースとして登録するようにした ● AWS Transit Gateway は自動でアソシエートとプロパゲートしないようにしておく ○ TGW との接続作業時に安全に経路制御ができる余地を残しておく 

AWS Transit Gateway におけるルートテーブル ● TGW に流れ込んできたパケットの通信先を定義する ○ TGW のルートテーブルには宛先 IP アドレスに応じた転送するべき AWS リソースが記載されてい る ○ TGW に接続している VPC は通信先に応じて TGW を経由するように VPC のルートテーブルに書 いておく必要がある 

アタッチ、アソシエート、プロパゲート ● アタッチ ○ VPC などの AWS リソースを TGW に接 続する ● アソシエート ○ AWS リソースのアタッチメントを TGW の ルートテーブルに接続する ● プロパゲート ○ TGW のルートテーブルにアタッチメントか ら経路情報が流れ込んでくる 

既存環境に AWS Transit Gateway を入れる場合 ● どの時点でアソシエートとプロパゲートを実施するか? ○ 各段階でどのような経路が全ての拠点に広報されているか、その結果、どのような通信経路になる かをあらかじめ慎重に検討しておく必要がある ■ AWS Transit Gateway はじめました の時はオンプレ環境 -> TGW -> VPC の経路を作って から、VPC のルートテーブルを切り替えた ● (複数のルートテーブルを使う場合) どのルートテーブルとアソシエートするか? ○ アソシエートできるルートテーブルは 1つだけ ● TGW のルートテーブル内での経路選択 ○ 基本的にネットワーク prefix の最長一致で選択される ○ 同一 prefix 長の場合は以下の優先順位になる ■ 静的経路 -> VPC 由来 -> Direct Connect 由来 -> VPN 由来 

内部ネットワークの経路を想像する ● オンプレミス環境内は OSPF による経路制御 ● AWS VPN とオンプレミス環境は BGP による経路交換 ○ オンプレミス環境の VPN 終端装置で OSPF と BGP で経路の再広報をしている ● ネットワークトポロジーなどを書いて、経路を想像する ○ 既存環境に TGW を追加したり、経路を TGW に向き変えたりする場合は作業の過程で 2つの経路 が作成されるタイミングがあるので、どのような経路になるか、経路がループしないかなどを慎重に 検討しておく必要がある 

AWS Transit Gateway と AWS Direct Connect ● Direct Connect は Direct Connect Gateway 経由で TGW と接続する ○ Direct Connect Gateway はオンプレミス環境からの経路を TGW のルートテーブルに伝播させる ○ Direct Connect Gateway は TGW から受け取った経路をオンプレミス環境のルーターに広報しな い ■ Direct Connect Gateway にオンプレミス環境側に広報する経路を手で書く必要がある ● TGW に接続する Direct Connect の仮想インターフェースは transit で作成する必 要がある ○ 既存の Direct Connect の仮想インターフェースを付け替えるということはできないので注意が必要 

Direct Connect Gateway ● オンプレミス環境に広報する経路は 20 prefix が上限 ○ あらかじめ集約した状態で prefix を登録する ● Direct Connect Gateway で使用する AS 番号は TGW に接続している VPN など で使用していない AS 番号を使用する ○ Direct Connect Gateway の AS 番号は作成後に変更できない ○ Direct Connect Gateway を作り直す場合は収容している仮想インターフェースの作り直しが必要 ● Direct Connect Gateway は経路フィルターが使えない ○ 例えば、オンプレミス環境から流れてくる経路のうち、特定の経路は TGW のルートテーブルに伝 播させたくないときに困る ○ はてなの場合は Direct Connect Gateway のアタッチメントはアソシエートだけして、 TGW から Direct Connect 向けの経路は静的経路として TGW のルートテーブルに作成した 

まとめ ● AWS Transit Gateway を使うことで AWS VPC や AWS 外の内部ネットワークを 接続することが可能 ● AWS Transit Gateway の導入時にはいくつか慎重に検討するべき技術的課題が ある ● とはいえ、AWS Transit Gateway は便利なので適材適所で使っていきたいですね