オールチームで進めよう！〜AWS Transit Gatewayによるコスト削減事例〜

ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。
この記事を書いている2024/04/26（金）はドル円の為替が一時156.7円まで上昇したと思ったら155円まで下ってまた156.2円位にはねたりと乱高下を繰り返しています。
今回の記事にも関係しますがAWSのコストを見るような部門には胃が痛い日々が続きますね。
見ないほうが精神衛生上よろしいのでしょうが、仕事ではそうもいかないのが辛いところです。

今回は2024年第1Q（弊社は12月決算なので1-3月が第1Qです）に実施したdev環境のインフラ構成変更と、それによるコスト削減を紹介します。
AWSでコスト対策をしようとするとどうしても悩みのタネになるNAT Gatewayを相手取って少しでもコストを下げられないか奮闘しました。

今回はAWS Transit Gatewayというサービスを利用してNAT Gatewayの台数を減らし、時間コストを削減しました。
アプリチームへの影響やコストのトレードオフが発生する対応なので事前の慎重な検討や丁寧な進行を心がけました。

この記事を届けたい人

NAT Gatewayのコスト削減案を考えている人
円安ドル高と戦うソフトウェアエンジニア

この記事を届けたい人
「dev環境統合」プロジェクトの概要
dev環境ネットワークのBefore/After
AWS Transit Gatewayとは
dev環境統合による影響
- コスト面のトレードオフ
- アプリへの影響
dev環境統合の進め方
コスト削減効果
まとめ

「dev環境統合」プロジェクトの概要

今回の対応はCTO室で当初「dev環境統合」と呼ばれたコスト削減プロジェクトから始まっています。
「dev環境統合」とは読んで字のごとくdev環境を統合する対応です。

もう少し具体的な話をしましょう。
ENECHANGEでは多くのサービスをtoB / ToCで展開しており、各アプリは様々な論理的境界でお互いに分割されています。
ネットワークレベルだったりAWSのアカウントレベルだったり様々ですが、相互の影響を最小化するためには何らかの分割が必要です。
分割されている以上はそれぞれのサービス毎に必要なクラウドインフラサービスを利用することになり、サービスや環境の数が増えるごとにインフラコストが発生します。

ここで本番環境でも検証環境でもない環境を「dev環境」と呼ぶことにします。
一般にdev環境には個人情報やユーザーデータは存在せず、サービス間の論理的な分割のレベルを下げてもインシデントには繋がりにくいでしょう。
また本番環境とシステム構成が同じ検証環境があれば、事前検証や不具合調査に必要な環境は充足しているので、dev環境については本番環境とシステム構成が少々変わっても業務影響は少なそうです。

このため、サービス・環境をまたいで同一のクラウドインフラリソースを共用することでコストを削減できないか、というのは「dev環境統合」プロジェクトです。
今回はdev環境統合プロジェクトのネットワークに関する対応の紹介記事です。

dev環境ネットワークのBefore/After

早速ですがBefore/Afterを見ていきます。

Beforeの要点は以下のとおりです。

AWSアカウント内に複数のVPCが存在する
VPC内に複数のサブネットが存在する
サービスは複数の環境（本番/検証/dev1/dev2/...）をもつ
環境は複数のサブネットをもち、環境内にNAT Gatewayを単一または複数もつこともある

今回コスト削減の対象として考えたNAT Gatewayは別の外部サービスに接続をしたいサービスに配置されています。
外部サービスが接続元をIPアドレスで制限している場合などはどうしても必要になってきますが、御存知の通りコストが悩みのタネです。
Beforeの時点で対象候補として選定した範囲でいうと21サービス、25 NAT Gatewayが候補に上がりました。

Afterの要点は以下のとおりです。

NAT Gatewayは全体で2つ（AZ毎に1つずつ、2 AZ分）に集約
各VPCに配置した集約用のサブネットにTransit Gateway Attachmentをアタッチする
VPCをまたいでTransit Gatewayでネットワークを接続し、サービスのアプリケーションからインターネットへの通信は集約したNAT Gatewayを通過する

この対応によりAfterではNAT Gatewayの数が大きく減ります。
加えてNAT Gatewayに付与していたEIPも減っていますので、EIPのコストも削減になっています。
一方でAWS Transit Gatewayというリソースが新たに登場しており、こちらは逆にコストが増えることになります。

AWS Transit Gatewayとは

では今回の対応で使用したAWS Transit Gatewayというサービスについて軽く説明します。
なお、移行Transit GatewayをTGWと表記します（長いので）。

aws.amazon.com

TGWは複数のネットワーク間を相互接続するネットワークサービスです。
説明を読む限りオンプレミスのネットワークとAWSを統合するためのソリューションとしての利用が念頭にありそうですね。

AWS Transit Gateway は、Amazon Virtual Private Cloud (VPC) とオンプレミスネットワークを中央ハブで接続します。この接続により、ネットワークが簡素化され、複雑なピア接続関係がなくなります。Transit Gateway は、拡張性の高いクラウドルーターとして機能し、新しい接続は 1 回だけ行われます。

TGWはネットワークを相互に接続するためのリソースで、ネットワークとTGWを接続するリソースがTGW Attachmentです。
接続したいサブネットに対してTGW Attachmentをアタッチすることでサブネット内にENIが足を伸ばします。
ENIを意識して管理する必要はありませんが、ENIがIPを使用しますのでサブネットの範囲としては加味する必要があるでしょう。
TGW Attachment 1つに対して各AZから1つずつサブネットをアタッチできます。

ルートテーブルでアタッチメントに向き先を指定すればTGWにトラヒックが流れます。
今回の対応ではほぼ決まり切ったルートになりますが、TGWにルートテーブルを定義することで宛先ごとに異なるネットワークにルーティングができます。

TGWおよびTGW Attachmentはマネージド冗長化されています。ALBなどと同じですね。
このため可用性などは意識しなくても確保されています。

条件として接続するネットワークのIPレンジが相互に重複しない必要があります。
同一AWSアカウント内であれば問題ないでしょう。

dev環境統合による影響

本対応はアプリ/インフラ双方に影響があります。
また、もちろんコスト削減になるのですが、増加するコストもあるためトレードオフを考える必要があります。

コスト面のトレードオフ

コストは以下のように増減します。

	時間コスト	流量コスト
減少	$0.062 x 台数 / 時（NAT Gateway） $0.005 x 台数 / 時（パブリックIP）	-
増加	$0.062 x 2台 / 時（NAT Gateway） $0.070 x アタッチメント数 / 時（TGW）	$0.02 / GB （TGW）

流量コストはNAT Gatewayの分があるのですが、この対応前後でNAT Gatewayを通る流量は変わらず、集約前の個々のNAT Gatewayを通るか集約後のNAT Gatewayを通るかの差しか無いので表からは除いています。
増加側の時間コストのNAT GatewayはAZ 2つに冗長化した弊社のケースで記載しています。

ポイントは以下のとおりです。

減少幅はNAT Gatewayの台数依存
増加幅はTGW Attachmentの個数依存
時間あたりコストはリソース数が同じならTGWの高くコストは増加する
TGW Attachmentは集約先にも設置が必要なため、TGW Attachment 1つ分は必ずコスト増になる
流量コストは純増する

コストを削減するためには「新設するTGW Attachment数よりも削減するNAT Gateway数が十分上回る」ことと「流量コストの増加が時間コストの減少に対して小さい」ことが必要になります。

弊社の場合、以下のような状態だったためどちらもクリアしていました。

VPCを共用しているサービス・環境があり、個々のNAT GatewayがTGW（VPCに1つでよい）に置き換えられる
NAT Gatewayを複数AZに冗長化しているサービス・環境はTGWに置き換えられる
dev環境は流量が少なくコストが極小

もしECSをつかっていてイメージPullが多い…とか、環境ごとにVPCが分かれていてVPC内のNAT Gatewayは冗長化していない…といったような状況ではコストメリットが出ないことが考えられます。
慎重にご検討ください。

アプリへの影響

アプリへの影響は「外向け通信の送信元IPアドレスが変化する」点です。

インフラ的にはNAT GatewayにアタッチするEIPが変わっているので当然なのですが、アプリ的には小さくない影響です。
外部システムと連携するアプリではリクエスト元IPアドレスによるホワイトリスト制限が入っていることは少なくありません。
NAT Gatewayを入れて通信している以上アプリとしては「送信元IPアドレスを固定したい」という要件がある可能性も十分に考えられるため、慎重に外部接続を検討する必要があります。

このような前提があるためバッタン切り替えではなくロールバックも視野に入れて移行を進めるとよいでしょう。
現用しているEIPは移行完了まで保持し続けることが必要になります。

dev環境統合の進め方

今回は以下のステップで移行を進めました。

1. 影響説明と参加意向ヒアリング

新たな集約NAT GatewayやTGWの設置の前に、まず候補となるNAT Gatewayを洗い出しました。
そのうえでNAT Gatewayを利用しているアプリの担当者に概要とIPアドレスが変更になること、また移行の進め方について共有しました。
この制約を呑める（またはCTO室がサポートすることで呑めるようになった）アプリだけが移行に参加できるよう、参加意向をヒアリングします。

意向に際してはむしろアプリチームの負荷が高く、外部サービスや顧客説明、作業依頼、検証といった様々なタスクが発生します。
ここで十分に納得してもらうことが成功の必須条件でしょう。

2. 事前見積もり

参加するアプリが決まったことで初めて見積りができるようになります。

弊社は構築している環境が多かったため、アプリにヒアリングする際に「実は不要だったNAT Gateway」もそれなりの個数が見つかりました。
こうして棚卸しになったことも本プロジェクトで嬉しい効果でした。
不要なリソースの削除は恒久的なコスト削減ですので積極的にやっていきましょう。

集約可能なNAT Gatewayの数と、集約に参加するアプリが属するVPCの数がわかれば削減効果が計算できます。このコスト削減効果の規模感で実際に対応するかを判定します。

3. 集約NAT Gatewayの構築

集約NAT Gateway用のVPCやサブネット、IGW、NAT Gateway、ルートテーブルなどのネットワーク系リソースを作成します。
この時点でEIPを決めておくことでアプリ側の移行作業が行えるようになります。

4. 集約後IPへの移行

アプリチームに変更後に利用するIPアドレスを通知します。
アプリチームは顧客や外部サービスに対して「ホワイトリストに新IPアドレスを追加する」作業を行います。

弊社ではtoBのサービスもそれなりに数があり、この作業に一番時間がかかりました。
顧客からしてみると特に旨味のない作業の発生であるため、当然優先度も低くなります。
アプリ担当者の皆さんには顧客への説明や依頼など丁寧に進めて頂きとても助かりました。

5. 集約NAT Gatewayへの移行

新IPのホワイトリスト追加ができたらネットワークの経路を集約NAT Gatewayに移行します。

具体的な作業は以下のステップです。

移行するアプリのVPC内にTGW Attachment用のサブネットを作成（AZの個数分）
TGW Attachmentをアタッチし、TGWのルートテーブルに以下の定義を追加する
1. アプリVPCのCIDR範囲宛のトラヒックをアプリVPCにアタッチしたTGW Attachmentにルーティング
2. 集約NAT Gateway用VPCのCIDR範囲宛のトラヒックを集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）
3. デフォルトルートとして集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）
集約NAT Gateway用VPCのNAT Gatewayが設置されているサブネットのルートテーブルに以下を追加
1. アプリVPCのCIDR範囲宛のトラヒックをTGW Attachmentにルーティング
2. 集約NAT Gateway用VPCのCIDR範囲宛のトラヒックをlocalにルーティング（初回のみ）
3. デフォルトルートとして集約NAT Gateway用VPCのIGWにルーティング（初回のみ）
アプリVPCのアプリインスタンスが設置されているサブネットのルートテーブルのデフォルトルートをVPC内のNAT GatewayからTGW Attachmentに変更
外部サービスへの接続確認
外部サービスのホワイトリストから現用NAT Gatewayに付与しているIPアドレスを削除
現用NAT GatewayとEIPを削除

ポイントは太字の箇所です。
集約NAT Gatewayが配置されているサブネットにはリクエスト元のアプリのCIDRブロックからリクエストが到達しており、通信の戻り先もアプリのIP（アプリVPCのCIDR範囲内）です。
このためIGWが存在するサブネットには戻りのルートとして集約NAT GatewayのTGW Attachmentを明示し、そこからTGW→アプリVPCのTGW Attachmentという経路を作る必要があります。

上記の4. の手順がネットワークの切り替えタイミングですが、本プロジェクトではこのタイミングで通信断などは検知していません。