博士

ロボ子、今日のITニュースはNATゲートウェイについてじゃ。

ロボ子

NATゲートウェイですか。プライベートサブネットからインターネットへのアクセスを提供するものですね。

博士

そうじゃ、そうじゃ。でも、AWSのNATゲートウェイは便利だけど、結構コストがかかるのじゃ。

ロボ子

高可用性と高稼働時間を保証してくれるのはありがたいですが、コストは気になりますね。

博士

そこで、自前でNATゲートウェイを構築するという選択肢が出てくるのじゃ！

ロボ子

自前でですか？ それはどのような場合に有効なのでしょうか？

博士

例えば、Github Actionsの高速化のためにプライベートサブネットでGithub runnersをホストする場合や、統合テストを頻繁に実行する場合じゃな。NATゲートウェイのコスト削減になるぞ。

ロボ子

なるほど。専用のインスタンスを立てることで、コストを最適化できるのですね。

博士

そういうことじゃ！ 自前NATゲートウェイの選択肢としては、Fck-NATとAlterNATがあるぞ。

ロボ子

Fck-NATはAndrew GuentherさんがメンテナンスしているAWS AMIイメージですね。Terraformモジュールもあるので、セットアップが比較的簡単だと。

博士

そうじゃな。AlterNATはChimeがメンテナンスしていて、可用性ゾーンを跨いだインスタンスとLambdaによるポーリングを利用して、EC2インスタンスの障害時にAWS管理のNATゲートウェイにフェイルオーバーするらしいぞ。

ロボ子

可用性を考慮するならAlterNATが良いかもしれませんね。

博士

今回の記事では、Fck-NATの公式Terraformモジュールを使って、t4g.nanoインスタンスを2つ使用したらしいぞ。

ロボ子

t4g.nanoインスタンスですか。かなり小型ですね。

博士

開発環境で約15-30秒のダウンタイムが発生したみたいじゃが、`NATGateway-Hours`のコストを50%削減、`NATGateway-Bytes`のコストを大幅に削減できたらしいぞ。1日あたり30-40ドルのトラフィックが、最大6ドルに減少したそうじゃ。

ロボ子

それはすごいですね！ 1週間あたり800GB-900GBのトラフィックを2つのt4g.nanoインスタンスで処理できるとは。

博士

NATゲートウェイのコスト全体で約70%の削減になったらしいぞ！

ロボ子

素晴らしい成果ですね。ただし、記事にもあるように、リスクの低い環境で試すのが良さそうですね。

博士

その通りじゃ。開発環境やステージング環境などで試して、本番環境への影響を最小限に抑えるのが賢明じゃな。

ロボ子

勉強になりました！ 博士、ありがとうございました。

博士

どういたしまして。ところでロボ子、NATって何の略か知ってるか？

ロボ子

Network Address Translation、ですよね？

博士

正解！ でも、私の場合は… Naturally Always Terrible の略なのじゃ！

ロボ子

ええっ！？ それはただの自虐では…？