AWSの構成例を見ていると、よく登場するのがNAT Gatewayというサービスです。

はて？何をするものでしょうか？

簡単に言えば、プライベートサブネットから外部へ通信するための出口です。じゃあ、外部へ出なければ使わなくてもいいじゃない？

いえいえ、そんな単純な話ではありません。

また、このNAT Gateway。
利用者がほとんどいなくても、きっちりAWSの費用としてのしかかってきます。サービス開始直後の私たちにとって、この固定費も決して無視できるものではありませんでした。

そこで考えました。
「NAT Gateway、なくせないの？」
しかし、いざ「使わない」と決めてみると、そう簡単にはいきませんでした。

今回は、Re:LinkのAWS構成からNAT Gatewayを使わないと決めてからの苦悩と、その過程で考えたことをお伝えします。

匿名チャットに必要な外部へのアクセスは？

まず、匿名チャットシステムから外部へどのような通信が発生しているのか、洗い出してみました。

OGP情報の取得、Google／LINEへの認証、決済代行サービスとの通信、生成AIへの接続……。
全くもって、外部へのアクセスを排除することはできません。

これらを無理に排除してしまえば、サービスレベルを大幅に下げることになり、本末転倒です。外部へのアクセスをなくすことはできない。

では、どうするか。

最初に考えたのは、 外部へのアクセスはLambdaに任せよう という方法でした。
Lambdaは、通常はユーザーのVPCに属さないAWS管理の実行環境で動作します。そのため、Lambda自身が外部サービスへアクセスするためだけに、こちらでNAT Gatewayを用意する必要はありません。

これならECSからLambdaをInvokeすればいいんだ！

VPC Endpoint 地獄

……ん？
LambdaをInvokeするためのエンドポイントも、Private Subnetから見ればそのままでは到達できない。 仕方ない。VPC Endpointを用意しよう。
……ん？
ECRからイメージがPullできない。 仕方ない。ここにも通信経路が必要だ。
……ん？
SQSのキューへメッセージを送れない。 またVPC Endpoint。
……ん？
SESも ？

おーい。 有料のInterface VPC Endpoint が、どんどん増えていくぞ！
NAT Gatewayの固定費をなくすために始めたはずなのに、今度はVPC Endpointの固定費が積み上がっていく。

ここで、ようやく根本的な疑問にたどり着きました。
AWSのマネージドサービスの多くは、私たちのVPC内に存在しているわけではありません。
つまり、Private SubnetにECSを配置する以上、AWSサービスとの通信であっても、何らかの「出口」を考える必要があります。

NAT Gatewayをなくすことばかり考えていたけど、そもそも――

発想の転換、プライベート空間に置く必要ある？

いっそのこと、 ECSをパブリックに置こう。 そう考えました。

ここでいう「パブリックに置く」というのは、ECSを誰でも自由にアクセスできる状態にする、という意味ではありません。ECS FargateをPublic Subnetに配置し、必要な外向き通信をそのまま行える構成にする、ということです。

そうすれば、

ECRからコンテナイメージをPullする
SQSへメッセージを送る
Lambdaはいらない
SESを利用する
外部APIへアクセスする
生成AIへ接続する

といった通信のために、NAT Gatewayや多数のInterface VPC Endpointを用意する必要がなくなります。
ここで初めて、「NAT Gatewayをどうやってなくすか」ではなく、 なぜECSをPrivate Subnetに置いているのか を考えるようになりました。

もちろん、RDSのようにVPC内のPrivate Subnetへ配置することが前提となるサービスへ接続するのであれば、ECSもPrivate Subnetに配置する構成には大きな意味があります。
しかし、Re:LinkではデータベースをDynamoDB中心へ見直したことで、その前提自体が変わっていました。

DynamoDBは、私たちのVPC内に配置するデータベースではありません。SQSも、Lambdaも、SESも、ECRも同様です。

そう考えると、「AWSサービスへアクセスするためにPrivate Subnetから外へ出る仕組みを大量に用意する」より、「必要な通信ができる場所にECSを配置する」という方が、サービス開始直後の私たちには合理的でした。それで、NAT Gatewayや多数のInterface VPC Endpointを用意する必要がなくなります。

DynamoDBは、私たちのVPC内に配置するデータベースではありません。SQSも、Lambdaも、SESも、ECRも同様です。

そう考えると、「AWSサービスへアクセスするためにPrivate Subnetから外へ出る仕組みを大量に用意する」より、「必要な通信ができる場所にECSを配置する」という方が、サービス開始直後の私たちには合理的でした。

それでセキュリティ大丈夫なの？

もちろん、Public Subnetに配置したからといって、セキュリティを考えなくてよいわけではありません。

実際の運用では、本サービスにおいて十分なセキュリティを担保できるよう、外部からのアクセス経路や権限を必要な範囲に限定しています。ただし、本記事ではサービスのセキュリティに関わるため、具体的なネットワーク構成やアクセス制御については割愛します。

今回重視したのは、

サービス開始直後の規模に対して、過剰な固定費を抱えないこと。そして、必要になったときに構成を変更できる余地を残しておくことでした。

NAT Gatewayが悪いわけではありません。

Private Subnetが悪いわけでもありません。

ただ、 「本番環境だから、とりあえずPrivate Subnet」「Private Subnetだから、とりあえずNAT Gateway」 と考える前に、「その構成、本当に今のサービスに必要なのか？」

一度立ち止まって考える価値はあると思います。

まとめ

今回、Reでは、サービス開始直後の固定費を抑えるためにNAT Gatewayを使わない構成を検討しました。

しかし、単純にNAT Gatewayをなくすだけでは、Lambda、ECR、SQS、SESなどに接続するためのVPC Endpointが次々と必要になり、別の固定費が積み上がってしまいます。

そこで私たちは、NAT Gatewayの代替手段を探すのではなく、そもそもECSをPrivate Subnetに配置する必要があるのか、という前提から見直しました。その結果、現在のReでは、必要なセキュリティ対策を講じたうえでECSをPublic Subnetに配置する構成を選択しています。

もちろん、これはすべてのサービスにとっての正解ではありません。VPC内のデータベースへ接続する場合や、通信経路を厳密に管理する必要がある場合など、NAT GatewayやPrivate Subnetが適している構成も数多くあります。

大切なのは、一般的な構成をそのまま採用するのではなく、サービスの規模、通信先、セキュリティ要件、運用負荷、そしてコストを踏まえて判断することです。

「本番環境だからPrivate Subnet」「Private SubnetだからNAT Gateway」と決める前に、その構成が今のサービスに本当に必要なのか、一度立ち止まって考えてみる。

私たちの試行錯誤が、これからAWSでサービスを立ち上げる方や、固定費に悩んでいる方にとって、構成を見直すきっかけになれば大変嬉しく思います。