SREの林 aka もりはやです。
今回はAWSコスト削減についてです。
＊注意＊参考のスクリーンショットでパブリックなIPやリソースIDが表示されていますが、検証環境のもので既に削除済みです
TL;DR
- 不要なNAT gatewayを8台削除し、月額約$357のランニングコストを削減することができました
- これだけはお伝えしたい点として、NAT gatewayの削除にフールプルーフとしての安全仕様は現在ありません
- 削除の前に必ず"Route tables"の画面で削除対象のNAT gatewayを検索しましょう
NAT gatewayの料金は意外と高い
AWSでVPCを利用する場合、NAT gatewayは必須のリソースと考えます。 PublicとPrivateのSubnetを作成し、Private Subnet内のリソースの外部アクセスのためにNAT gatewayをデフォルトゲートウェイとして、各Availability Zone(以後AZ)ごとに作成するのが一般的な構成です。
そんな必須かつ重要なNAT gatewayですが、必要だからこそコスト削減の対象外となっていましたので改めて見直すことにしました。
ドキュメントを参照し、1台あたりのコストを確認したところ、NAT gatewayは以下の2種類のコストで構成されていました。（東京リージョンの価格）
- NAT gatewayの起動時間: $0.062/Hour
- NAT gatewayの処理データ: $0.062/GB
今回は"NAT gatewayの起動時間"について注目します。（"NAT gatewayの処理データ"についてはアプリケーションやサービスによって大きく変動するため）
以下は1台あたりのNAT gatewayの利用料金を利用時間別にまとめた表です。為替レートについては2023-08-04時点の 1ドル142円 で計算しました。
| 単位 | 料金($) | 料金(円) |
|---|---|---|
| Hourly | 0.062 | 8.804 |
| Daily | 1.488 | 211.296 |
| Monthly | 44.64 | 6338.88 |
| Yearly | 543.12 | 77123.04 |
1台のNAT gatewayが起動しているだけで月額6,000円相当のコストが発生します。（以後は簡略化のため6,000円/月/台として扱います)
当社の一般的な構成として、AWSの冗長構成を考慮しVPCは3つ以上のAZを用いており、それぞれにNAT gatewayを配置していました。
つまり基本的なVPCを作成しただけで、6,000円 x 3 = 18,000円がNAT gatewayのコストとして発生し続けます。
加えて2023-07-30に発表のあった”AWS におけるパブリック IPv4 アドレスの使用状況の特定と最適化”によると、パブリックIPv4アドレスに対しての課金が始まることがアナウンスされており、よりNAT gatewayのコスト増加が進むことになります。 aws.amazon.com
歴史的経緯で沢山のNAT gatewayが存在した
当社はすでにCloud Financial Management（CFM）プログラム支援によるコスト改善を進めており、RI/SPの見直しやストレージのgp3化などの対応はほぼ済んでいます。その中でCFMプログラムで言及されていないNAT gatewayの削減に思い至ったのは、当社のAWSの利用経緯と歴史の積み重ねがあるためです。*1 aws.amazon.com
当社のAWSのおよそ10年の歴史を持つ古いアカウントには、AWSの勉強のために作ったお試し環境、テスト環境、分析環境、個人検証環境といったさまざまな環境がSubnetとして乱立したVPCがあり、それぞれの環境のPrivate Subnetに対応したNAT gatewayがPublic Subnet上に存在する状況でした。
NAT gateway整理の流れ
こうした状況を受け、以下の方針でNAT gatewayの整理を進めることにしました。
- 未使用のPrivate Subnet・Route tableを削除する
- VPC内の同一AZのNAT gatewayを集約する
- 上記の対応で不要となったNAT gatewayを削除する
1. 未使用のPrivate Subnet・Route tableを削除する
NAT gatewayはPrivate SubnetとRoute tableがセットで利用されます。そのため不要なPrivate Subnetを特定すればそのSubnetが利用しているNAT gatewayは不要な可能性があります。
該当Subnetが不要かの判断は様々な角度から調査が必要ですが、切り分けの簡単な方法としてはSubnetを削除しようとすることです。該当Subnet内にリソースが残っている場合は以下のような警告がでるため大きな手がかりとなります。
図: リソースが残っており削除できない場合のSubnet削除画面
一方でSubnetが何も使っていなければ警告画面はでません。社内ドキュメントや古株の同僚、Slack履歴などを確認した上で削除することができました。（それでも怖いですが）
図: リソースがなく削除可能なSubnet削除画面
Subnetを整理した後は、Route tableの整理を行います。 Route tableについてSubnetと同様です。Subnetへアタッチされている利用中のものは削除できないため、削除できるものについて過去経緯を可能な限り確認してから削除しました。
2. VPC内の同一AZのNAT gatewayを集約する
同じVPC内であればNAT gatewayはどのSubnetからも利用可能です。上述したように歴史的経緯でVPC内にSubnetが乱立していたため、同一のAZのSubnetについて、一つのNAT gatewayを使うように集約しました。
作業自体は簡単ですが、NAT gatewayを変更する＝外部へのアクセスに利用する送信元のパブリックIPv4が変更になります。そのため「IP制限」を前提とした連携について事前の確認を十分に行いました。集約対象となるシステム担当者にコスト削減の目的と送信元IPが変更になる影響を説明し、テスト環境のサブネットから段階的にRoute tableの変更をして集約を行いました。
具体的には以下のようなステップを踏んで集約を行っていました。
- NAT gatewayの集約を決めたSubnet上で動作するアプリケーションについて、外部への通信時に送信元のIP(グローバルPI)の変更が影響ないことを確認します。最近では推奨されないことも多くなってきたIP制限ですがまだまだ使われているところでは使っているためです。
- Route tableを変更し、アウトバウンド 0.0.0.0 のTargetについて既存のNAT gatewayから集約先のNAT gatewayへ変更します。
- 変更後、1から3週間ほど影響がないかを見守ります。問題があった場合はRoute tableを元に戻します。
結果として以下のように各AZ内のPrivate Subnetは一つのNAT gatewayを利用する状態へ変更しました。図の”赤い矢印”はそれぞれのPrivate Subnetが”VPC a”のNAT gatewayを利用している様を表現しています。
3 . 上記の対応で不要となったNAT gatewayを削除する
こうして、後は不要となったNAT gatewayを削除するだけです。 最終確認として以下の方法でNAT gatewayが利用されていないかを確認します。
- コンソール"VPC"->”NAT gateways”の各NAT gatewayの"Monitoring"画面で、各種メトリクスが変動していないか
- コンソール"VPC"->"Route tables"の検索画面で削除対象のNAT gatewayのIDを検索し、利用しているRoute tableがないこと
NAT gatewayの"Monitoring"画面で、各種メトリクスが変動していないか
NAT gatewayの"Monitoring"のグラフを見ることで、そのNAT gatewayが直近で利用されているかを確認できます。ただし削除を行う前に後述する方法で必ずRoute tableからも未使用であることを確認してください。
使われているNAT gatewayは以下のようにメトリクスのグラフが変動します。
不要となったNAT gatewayでは以下のようにメトリクスは0を指します。ただしリソースによっては普段は停止して週に一度しか動かない機能などがあるかもしれませんのでまだ削除はできません。
仮に誤ってNAT gatewayを削除してしまうとRoute table上でStatusが”Blackhole”となり、外部への通信ができない状態となります。
削除対象のNAT gatewayがRoute tableから利用されていないか確認
本記事で一番伝えたいことがこの「削除対象のNAT gatewayがRoute tableから利用されていないか確認」することです。SubnetやRoute tableと異なり、NAT gatewayには削除時のフールプルーフが現状ありません。そのため利用中のNAT gatewayであっても削除できてしまいます。
この仕様に認識がなかった私は誤って消してはいけないNAT gatewayを削除してしまいました。（幸い影響は大きくないNAT gatewayでしたが、今思い出しても冷や汗が出ます）
それを防ぐ手段として”Route table”画面の検索で削除対象のNAT gatewayのIDを調べます。
結果としてRoute tableが表示された場合、削除対象のNAT gatewayを利用しているRoute tableが存在しているため改めて確認を行いましょう。
適切にRoute tableを整理できていれば、以下のように検索結果は0となります。
ついにNAT gateway削除！でもEIP(Elastic IP)は残るので注意
MonitoringとRoute tableで最終確認を行った後は、NAT gatewayの画面で削除を行います。上述した通りNAT gatewayの削除にフェールセーフは現在ないため、慎重に行いましょう。ただしEIPは連動して消えないため注意です。
NAT gatewayの次は、NAT gatewayに付与されていたEIPについても削除します。ただしこのEIPが最後の砦とも言えるのでEIPのコストとリスクを天秤にかけて削除のタイミングを決めてください。NAT gatewayの作成時にEIPを指定することができるため、確実に安心といえるまではリカバリのために保存しておくことをお勧めします。
終わりに
以上がNAT gatewayを整理してランニングコストを下げた話でした。振り返ってみると以下の要素がなかなか大変ではありましたが、今後永続的に発生するコストと考えると「気づいた時が最速！」のマインドでやりきってよかったなと感じています。
- 関係各所へ調整する工数
- システム側での影響確認
- システム稼働に影響がでるリスク
一方で影響は大きくはなかったものの、社内向けの一部のシステムに誤動作を起こしてしまい、同僚氏たちにフォローいただいたことはお詫びと感謝の気持ちをここでもお伝えしておきます。本記事を読んだ方が間違ってNAT gatewayを消さない一助になれば幸いです。
*1:余談ですがCFMプログラムは大変有用ですので、ぜひ担当のTAMの方に相談してみてください。
