Transit Gateway で AWS を社内ネットワークの延長として使う - Cybozu Inside Out

こんにちは、生産性向上チームの @miyajan です！

この記事は、Cybozu Advent Calendar 2022 の七日目です。今回は、AWS 上から Transit Gateway 経由で社内ネットワークからしかアクセスできないシステムにアクセスできるようにしたお話です。

背景

サイボウズでは、社内の開発者が手軽に AWS アカウントを利用できるようにしています。AWS のアカウントは利用するチームや用途ごとに分けてマルチアカウントで運用しています。（関連記事）

サイボウズでは、AWS を本番環境としてサービスを世の中へ公開する用途以外にも、開発チームが普段の開発を改善する用途としても活用しています。しかし、サイボウズの開発で利用している一部のオンプレシステム（例えば、GitHub Enterprise Server など）は社内のオンプレネットワークからしかアクセスできないようになっており、AWS 上からではこれらのシステムとの通信ができませんでした。これにより、オンプレシステムに依存している開発チームは AWS を開発基盤として活用しづらいという問題がありました。

このため、AWS と社内ネットワーク間で VPN 接続したいと考えました。ただし、オンプレシステムに VPN 経由でアクセスしたい VPC は複数の AWS アカウントで存在し、AWS の活用が進むにつれて今後も増えていくので、新しく VPC を社内ネットワークに接続するための作業はできるだけ簡単にしたいです。特に、社内ネットワーク側の機材の設定変更は影響範囲が大きくなりがちなので、VPC が増えても対応が必要ないようにしたいです。

この問題を解決するため、生産性向上チームと社内のネットワークチームで協力して、AWS VPC と社内ネットワークを VPN 接続する仕組みを Transit Gateway を活用して作りました。

Transit Gateway とは

Transit Gateway は、VPC とオンプレミスネットワークを相互接続するために使用される、ネットワークの中継ハブとなるマネージドサービスです。

Transit Gateway はクラウドルーターとして機能し、VPN 接続と複数の VPC のハブとなります。これにより、VPN 接続したい VPC が増えても、設定変更は Transit Gateway 側と新しい VPC 側だけで完結するようになり、オンプレネットワーク側に影響を与えません。

Transit Gateway の構築

全体の構成としては以下の図のようになりました。

Transit Gateway の構成図

VPC と社内ネットワークは双方向で通信可能です。

注意点として、Transit Gateway で社内ネットワークとつながっている VPC に侵入されると、社内ネットワークにも侵入されることになってしまいます。このため、VPC にはパブリックインターネットからのインバウンドアクセスは許可しないルールで運用しています。

社内ネットワーク側の設定

社内ネットワーク側の設定は、AWS マネージドコンソールからネットワーク機材のベンダー、プラットフォーム、ソフトウェアを選択することで、サンプルの設定をダウンロード可能です。

ただし、あくまでサンプルなので、自社のネットワーク要件に合わせて設定ファイルを変更する必要があります。また、設定ファイルに VPN 接続の共有キーも含まれるので、設定ファイルの共有には注意が必要です。

Transit Gateway の設定の Terraform 化

我々は、Terraform を使って Transit Gateway などの AWS の設定を管理しています。

これにより設定は宣言的に管理されるようになり、バージョン管理やプルリクエストによる差分レビューといったプラクティスを適用できるようになります。

Resource Access Manager で Transit Gateway をマルチアカウントで共有する

VPC から社内ネットワークに通信するには、VPC 側のルートテーブルで社内ネットワークの CIDR を Transit Gateway にルーティングするように設定する必要があります。Transit Gateway が存在する AWS アカウントと社内ネットワークに接続する VPC は異なる AWS アカウントに存在します。このため、VPC 側のアカウントで Transit Gateway を参照できるように、AWS の Resource Access Manager (RAM) を利用して Transit Gateway を各アカウントに共有する必要があります。

プレフィックスリストで社内ネットワークにルーティングする CIDR を管理する

上で書いたとおり、VPC 側のルートテーブルで Transit Gateway にルーティングする CIDR を設定する必要があります。¹

最初は VPC から社内ネットワークにルーティングさせる CIDR を一つずつルート設定していました。しかし、これだと後からルートが増えるたびに、Transit Gateway に接続しているすべての VPC のルートテーブルで設定を変更する必要がありました。これだと CIDR の追加が厳しいため、社内ネットワークにルーティングする CIDR のリストをプレフィックスリストで管理するようにしました。

ここでプレフィックスリストは AWS のカスタマーマネージドプレフィックスリストのことです。プレフィックスリストは、ユーザーが定義できる CIDR のリストで、RAM によって複数の AWS アカウントで共有できます。

プレフィックスリストはルートテーブルの送信先として指定できます。なので、VPC のルートテーブル側で送信先としてこのプレフィックスリストを指定してもらえば、新しく CIDR をルートとして追加したいときにプレフィックスリスト側を修正するだけになり、VPC 側では特に設定変更が必要なくなりました。

VPC フローログと Amazon Athena でトラフィックを分析する

運用開始後に、Transit Gateway に接続している VPC で VPN 経由のネットワークが遅延する問題が発生しました。社内のネットワークチームに確認してもらったところ、社内側のネットワーク機材で帯域が逼迫しており、社内 → AWS 方向で大量の通信が発生しているのが原因ということがわかりました。

転送量が多いトラフィックを分析するために、VPC フローログと Amazon Athena を使いました。VPC フローログを有効にすると、VPC 内のすべてのネットワークインターフェースのトラフィックがキャプチャして S3 に保存できます。そして、Amazon Athena を使うことで、S3 に保存されたフローログをクエリで分析できるようになります。

VPC フローログを Athena で分析

Athena でフローログを分析できるようにするためのテーブル作成などのセットアップ方法は公式ドキュメントにあるので省略しますが、最終的には以下のようなクエリでどの IP アドレスからのトラフィック転送量が多いかを分析しました。

SELECT
  SUM(bytes) AS bytecount,
  srcaddr,
  srcport
FROM vpc_flow_logs
WHERE date = DATE('2022-12-08')
GROUP BY srcaddr,srcport
ORDER BY bytecount DESC
LIMIT 10;

結果
      bytecount       srcaddr          srcport
1     803098477846    192.0.2.123      443
2     286904891745    192.0.2.45       22
（省略）

これで、どこからのトラフィック転送量が多いかまでわかるようになりました。あとは、対象のサービスのログを分析するなどして大量の通信が発生している原因を分析し、改善を行いました。

まとめ

弊社で運用している AWS と社内ネットワークを Transit Gateway で接続する仕組みと、その運用についてご紹介しました。この仕組みは、運用を開始してから三年以上経っており、社内の多くのチームから活用されています。

この仕組みにより、社内の開発チームは AWS の豊富なリソースやマネージドサービスを活用しやすくなりました。例えば、CI で一時的にスペックの高いインスタンスを利用してテストを実行したり、Lambda で並列にビルドを実行したりといった活用がされています。運用もだいぶ安定しており、社内ネットワークに接続する VPC を増やしたり減らしたりするのも簡単に行えています。

最後になりますが、生産性向上チームではこういった課題を解決することが好きな方を募集しています。興味がありましたら、ぜひ生産性向上チームの紹介記事もご覧ください。We're hiring!

note.com