ペパボ・はてな技術大会〜@オンライン https://pepabo.connpass.com/event/174331/
AWS Transit Gateway を使った内部ネットワークの構成変更の話2020/05/14 ペパボ・はてな技術大会〜@オンライン株式会社 はてなサービス開発本部 システムプラットフォーム部渡辺 道和 (id:nabeop)
View Slide
● 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 は便利なので適材適所で使っていきたいですね
nabeo
culvert
cimadai
k1low
yutoy
coconala_engineer
cybozuinsideout
nagix
kosui
okamototakuyasr2
yuj1osm
neonankiti
inureyes
dotmariusz
brianwarren
jacobian
kastner
jrom
keithpitt
marcduiker
kneath
keathley
afnizarnur
geoffreycrofte
addyosmani