オンプレミスと AWS 間のネットワーク接続

こんにちは、IT 基盤部ネットワークグループの谷崎です。

前回の私の記事で、オンプレミスと GCP 間のネットワーク接続についてご紹介させていただきました。
今回は DeNA Techcon 2020 でご紹介する予定だった、AWS とのプライベート接続についてご紹介させていただきます。

従来の構成と運用課題

AWS との内部通信は下記のような構成で運用していました。

各アカウントの VPC で Virtual Private Gateway、および Site-To-Site VPN トンネルを作成
オンプレ Firewall で各 Virtual Private Gateway と対になる IPsec VPN、および VPN トンネルを設定

しかしこの構成は下記の運用課題を抱えていました。

通信品質

IPsec VPN はインターネット通信のため通信品質が保証されない

設定管理の煩雑化・構成の複雑化

VPC と 1:1 で設定を追加する必要がある

リードタイム

ネットワークグループでの作業に 3 日程度のリードタイムを要する

今回は我々ネットワークグループがこれらの課題をどのように解決して、現在どのような構成で運用しているのかご紹介します。

「1. 通信品質」の解消

まず我々はロスの許されない大容量なデータ移行にも耐えうる通信品質を担保するため、AWS Direct Connect を採択しました。
AWS Direct Connect とは AWS との専用線接続サービスで DeNA では 10G * 2 本の Direct Connect Connections で導入しました。
この導入により、オンプレミスとの接続は下記の構成となり、通信品質は担保される状態となりました。

データセンタと AWS 間を Direct Connect 接続
- 10G x 2 Dicrect Connect Connections
Virtual Private Interface x Virtual Private Gateway 構成

これにより、「1. 通信品質」は解消されましたが、この構成も各アカウントの VPC とオンプレミス側で対になる接続設定が必要なため、 2, 3 の課題は残存しました。

通信品質

~~IPsec VPN はインターネット通信のため通信品質が保証されない~~
専用線サービス AWS Direct Connect の導入によって解消

設定管理の煩雑化・構成の複雑化

VPC と 1:1 で設定を追加する必要がある

リードタイム

ネットワークグループでの作業に 3 日程度のリードタイムを要する

「2. 設定管理の煩雑化・構成の複雑化」の解消

次に我々は AWS の利用拡大にも追従しうるシンプルかつスケーラブルな構成を求め、AWS Transit Gateway (以下、TGW) を採択しました。
TGW は VPC 間の通信をハブアンドスポーク型で実現できるマネージドなルータのサービスです。
この導入により、オンプレミス、および VPC 間の接続は下記のような構成になりました。

VPC 間の通信は TGW 折り返しでルーティング
オンプレとの通信は TGW と接続した AWS Direct Connect Gateway 経由でルーティング
オンプレミス、および各 VPC が TGW を中心としたハブアンドスポーク型の構成

これにより、「2. 設定管理の煩雑化・構成の複雑化」も解消解消されました。

通信品質

~~IPsec VPN はインターネット通信のため通信品質が保証されない~~
専用線サービス AWS Direct Connect の導入によって解消

設定管理の煩雑化・構成の複雑化

~~VPC と 1:1 で設定を追加する必要がある~~
オンプレミス、および各 VPC 間の通信をハブアンドスポーク型で可能とする AWS Transit Gateway の導入で解消

リードタイム

ネットワークグループでの作業に 3 日程度のリードタイムを要する

「3. リードタイム」の改善

先の TGW の導入により、オンプレミスとの接続が TGW での終端となったため従来のような各 VPC と対になる設定は不要となり、リードタイムに関しても大幅に改善されました。

しかし、TGW と各 VPC をアタッチする設定は必要で、設定はブラウザ上のコンソールから行なっていました。
そこで我々は TGW を含む関連リソースを全て Terraform によってコード化しました。
これにより、リードタイムの改善に付随して、コードレビューや DRY-RUN を介する事によるヒューマンエラーのリスクも減りました。