AWS Transit Gateway を使った内部ネットワークの構成変更の話 / AWS Transit Gateway and Me

ペパボ・はてな技術大会〜@オンライン
https://pepabo.connpass.com/event/174331/

Transcript

1. AWS Transit Gateway を 使った内部ネットワークの構 成変更の話 2020/05/14 ペパボ・はてな技術大会〜@オンライン 株式会社 はてな サービス開発本部 システムプラットフォーム部 渡辺 道和 (id:nabeop)
2. • id:nabeop / 渡辺 道和 • システムプラットフォーム部 ◦ はてなのサービスの共通基盤系の開発と運用部署 • 2018年3月に中途入社 • はてなに入るまではオンプレ中心な世界にいま した 自己紹介
3. AWS Transit Gateway と私 • Hatena Developer Blog にエントリがあります ◦ AWS Transit Gateway はじめました ◦ AWS Direct Connect を AWS Transit Gateway に接続した話
4. AWS Transit Gateway とは? • AWS VPN / AWS Direct Connect / AWS VPC が接続できる • 中身は複数のルートテーブル ◦ AWS VPC におけるルートテーブルと極めて似ている ◦ 単一のルートテーブルのみという運用も可能 ▪ 今の所、はてなにおける運用では 1つのルートテーブルのみを想定 ◦ ルートテーブルでワザを使うと、非対称な経路制御ができる • BGP による経路交換をしている ◦ オンプレミス環境と接続する場合は BGP による経路交換ができるとベター ▪ 静的経路のみでも接続できると思うけど、やりたくない • コスト的には VPC Peering のほうが安い
5. AWS Transit Gateway 導入前のネットワーク接続
6. 課題 • 一部の AWS VPN は 2019年9月に終了予定の AWS Classic VPN を使っていて、リプ レースが必要だった • 今後は AWS VPC の増加が見込まれており、内部ネットワークを接続する場合、VPN 方式だと管理が煩雑になることが目に見えていた • 一部では AWS VPC 同士の接続に VPC Peering を採用していたが、全ての環境で採 用した場合、フルメッシュ構成になるので積極的に採用することは控えたい
7. AWS Transit Gateway をハブにした接続
8. 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 との接続作業時に安全に経路制御ができる余地を残しておく
9. AWS Transit Gateway におけるルートテーブル • TGW に流れ込んできたパケットの通信先を定義する ◦ TGW のルートテーブルには宛先 IP アドレスに応じた転送するべき AWS リソースが記載されてい る ◦ TGW に接続している VPC は通信先に応じて TGW を経由するように VPC のルートテーブルに書 いておく必要がある
10. アタッチ、アソシエート、プロパゲート • アタッチ ◦ VPC などの AWS リソースを TGW に接 続する • アソシエート ◦ AWS リソースのアタッチメントを TGW の ルートテーブルに接続する • プロパゲート ◦ TGW のルートテーブルにアタッチメントか ら経路情報が流れ込んでくる
11. 既存環境に AWS Transit Gateway を入れる場合 • どの時点でアソシエートとプロパゲートを実施するか? ◦ 各段階でどのような経路が全ての拠点に広報されているか、その結果、どのような通信経路になる かをあらかじめ慎重に検討しておく必要がある ▪ AWS Transit Gateway はじめました の時はオンプレ環境 -> TGW -> VPC の経路を作って から、VPC のルートテーブルを切り替えた • (複数のルートテーブルを使う場合) どのルートテーブルとアソシエートするか? ◦ アソシエートできるルートテーブルは 1つだけ • TGW のルートテーブル内での経路選択 ◦ 基本的にネットワーク prefix の最長一致で選択される ◦ 同一 prefix 長の場合は以下の優先順位になる ▪ 静的経路 -> VPC 由来 -> Direct Connect 由来 -> VPN 由来
12. 内部ネットワークの経路を想像する • オンプレミス環境内は OSPF による経路制御 • AWS VPN とオンプレミス環境は BGP による経路交換 ◦ オンプレミス環境の VPN 終端装置で OSPF と BGP で経路の再広報をしている • ネットワークトポロジーなどを書いて、経路を想像する ◦ 既存環境に TGW を追加したり、経路を TGW に向き変えたりする場合は作業の過程で 2つの経路 が作成されるタイミングがあるので、どのような経路になるか、経路がループしないかなどを慎重に 検討しておく必要がある
13. 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 の仮想インターフェースを付け替えるということはできないので注意が必要
14. 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 のルートテーブルに作成した
15. まとめ • AWS Transit Gateway を使うことで AWS VPC や AWS 外の内部ネットワークを 接続することが可能 • AWS Transit Gateway の導入時にはいくつか慎重に検討するべき技術的課題が ある • とはいえ、AWS Transit Gateway は便利なので適材適所で使っていきたいですね