NATゲートウェイの料金を掘ったら、海底ケーブルと信頼性設計まで派生した

はじめに

AWSのNATゲートウェイ、ちょい高えだろ

という思いから始まりました。

AWSでインフラを触っていると、プライベートサブネットに置いたリソースをインターネットに接続したい！という時があります。

そこで用いられる手段の一つが、NATゲートウェイです。

やってることはプライベートサブネットからのリクエストを受けて、IPアドレスをグローバルに変換して外に出す。要は自宅のルーターと同じようなことをしてるだけとのこと。
その癖、常時稼働のEC2より高くなることがある。許せねえ。
実際の仕事と給料が見合ってねえのは許せねえよなあああ、
社会に出たらこんなことはたくさんあると思いますが、それでも僕はNATゲートウェイを許すことができません。

この疑問を掘り下げていったら、インターネットの物理構造とか、システムの健全さを測る考え方まで飛んでいって、思いがけず派生したので備忘録も兼ねて道筋を残しておきます。

Part 1：NATゲートウェイの料金の謎

なぜ高いのか（推測）

NATゲートウェイを通してインターネットに出すと、料金はこの3つが乗ってきます。

理由はざっくり2つ、

① マネージドサービスだから（稼働時間料金）

NATゲートウェイは裏側をAWSが全部見てくれます。障害が起きても自動復旧、トラフィックが増えても自動でスケール。EC2で同じことをやるならロードバランサーで複数台並べて…と手間がかかる。それを丸ごと引き受けてくれてるぶん、起動してるだけで時間料金がかかる。

② 同じデータに、データ量課金が2回乗るから

表の下2つ、NAT処理料金と送信データ転送料金は、どっちもデータ量（GB）に対する課金です。同じ1GBを外に送ると、「NATを通した分」と「外に届けた分」でデータ量課金が2回乗ります。

プライベートサブネットのEC2 → NATゲートウェイ → インターネットゲートウェイ → インターネット

実際どんぐらいか、東京リージョンで1GBをインターネットに送ってみると：

- 稼働時間料金：0.062$/時（データ0でも、起動してる限りずっとかかる）
- NAT処理料金：1GB × 0.062$ ＝ 0.062$
- 送信データ転送料金：1GB × 0.114$ ＝ 0.114$

この1GBで、処理0.062 ＋ 転送0.114 ＝ 0.176$がデータ量ぶんとして乗る
まあでも1GBでこれは全然許せます。むしろ低価格ありがとうございます。
しかし稼働時間料金は、データを1バイトも流さなくても発生します。
なので、0.062$/時 × 約730時間 となり、結果は…

月45 ドルくらい（約7245円）💸

※執筆時点のレート 1$/161.30 円の場合

置いておくだけでこんなに固定でかかる。「常時稼働のEC2より高くなることがある」の正体はこれでした。

ちなみにNATゲートウェイを使わず、パブリックサブネットから直接出すと「NAT処理料金」はかからない（送信データ転送料金は同じく発生）。だからNATゲートウェイ経由は一段割高になります💸

参考：https://aws.amazon.com/jp/vpc/pricing/

Part 2：インターネットの裏側

「データを届けるコスト」って？

じゃあ「AWSの外までデータを届けるコスト」って具体的に何なのか。

まず調べてわかったのは、インターネットという1つのネットワークが存在するわけではないということ。（?となりますが聞いてください）

実態は、無数の会社（NTT、KDDI、AWS、Googleなど）がそれぞれ自分のネットワークを持っていて、それらを物理的なケーブルで繋ぎ合わせた巨大な集合体。それが「インターネット」でした。

AWSの建物の中だけで完結する通信なら、他社にお金を払う必要がない。だからプライベートIPでの同一AZ（アベイラビリティゾーン）内通信は無料。

でもユーザーのスマホや自宅PCに届けるには、AWSのネットワークの外に出て、NTTやKDDIのネットワークを経由する必要がある。その経由に回線コストがかかるから、送信データ転送料金が発生するわけです。

イメージとしてはこんな感じ↓

[AWSのデータセンター]
   ↓ AWS自社の光ファイバー
[AWSのネットワークの出口]
   ↓ ここから先は他社のネットワーク
[NTT、KDDIなどの回線を経由]
   ↓
[ユーザーの手元]

ネットワーク同士はどこで繋がるのか

各社のネットワークが物理的に繋がる場所を**IX（Internet eXchange）**と呼びます。「データを交換する場所」です。

東京だけでもJPNAP、JPIX、BBIXなど複数のIX施設があるらしく。ラックにルーターやスイッチがびっしり並んだ施設に、各社がケーブルを引き込んで物理的に接続してます。（サーバールームみたいなイメージ）

国をまたぐ通信は海底ケーブルが担っていて、これもお金がかかっていそうです😇
記事：KDDI 【国際通信150年(4)】インターネットなど国際通信の99%を担う大容量の光海底ケーブル時代へ

AWSの送信データ転送には、こういう物理インフラの維持コストもかかっているということ。
「データを届ける」のがこんなに物理的な根幹に支えられていたとは。

Part 3：運用で気づいた「システムの健全さ」の話

目先の不安を潰してただけだった

ここから話が変わります。

AWS を使用してバックエンド（インフラ込み）を構築・運用する機会があったのですが、
その中で目先のものをクリアする感覚で一個一個気にしてやってたことがあって↓

• いかに障害に強くするか

• 障害が起きた時にデータが復旧できるか

• セキュアな状況（攻撃が入り込む余地がないか）

これを後から整理してみると、信頼性やセキュリティの世界で昔から使われてる考え方に対応している部分がありました↓

可用性（= 使いたい時にちゃんと使える状態を保つ）

• EC2のディスクがログで埋まってエラーがでた → ログローテーションを設定して恒久対応

• DBのメモリが枯渇する前に気づけるようアラートを設定

• キューの処理失敗を検知するアラートを追加

全部「止まってから気づく」じゃなくて「止まる前に気づく、止まっても自動で直る」ようにする話でした。

耐久性（= データが消えずに残り続ける）

「データが飛んだら終わり」なので、どこに何をどう保存するかは一番慎重に決めてたところでした。バックアップの設計や、障害が起きた時にどの時点まで戻せるかを気にしていました。

機密性（= 権限のない人に見られない・攻撃されない）

• WAFでIP制限を設定して不正アクセスをブロック

• IAM権限を最小限に分離

「攻撃されたらどうする」じゃなくて「そもそも入り込む余地をなくす」方向で一個一個潰してました。

などなど、振り返ると世間一般的な設計パターンに自然と一致してる部分もありました。

可用性と信頼性は違う

この辺の指標を調べてて、可用性と信頼性の区別がいまいちつかなかったので整理しました。

• 信頼性 = そもそも壊れにくいかどうか（故障の「回数」に注目）

• 可用性 = トータルで使える時間がどれくらいか（故障の「影響時間」に注目）

具体例↓

Aは「滅多に壊れない」から信頼性は高いけど、壊れた時の影響が大きいから可用性は低い。
Bは「しょっちゅう壊れてる」けどすぐに直るからトータルで見るとほぼ使える状態を維持できている。

つまり**可用性を上げるには「壊れにくくする」か「壊れてもすぐ直す」かのどちらか（または両方）**で、信頼性はそのうちの片方でしかなかっただけでした。（補集合的に理解できると楽になった）

可用性と一貫性は両立が難しい話

サーバーを複数台にしてデータを複製すると、可用性は上がる（1台壊れても他で応答できるから）。でもその代わり、複製が全部揃うまでの間、ユーザーによって見えるデータが違うという状態が起きうる。

「ネットワーク分断（通信が途切れる障害）が起きたときに、一貫性と可用性のどちらを取るか迫られる」という考え方があるそうです。（CAP定理）
実務だと、扱ってるデータの性質で使い分けてる↓

新幹線の予約やクレジットカード決済が遅いのって、一貫性を優先してるからなのかな、と勝手に推測しています。座席の二重予約とか二重決済とか、シャレにならないので、多少遅くなっても全部のデータが揃うまで待っている、みたいな。
初めてのリリース怖かっただろうな（震）

感想

NATゲートウェイの請求額高えだろっていう、実務的な疑問から出発して↓

1. AWSの課金の仕組み（NATの手数料 + 転送コストで二重になる）

2. インターネットの裏側（物理インフラ）

3. システムの健全さを測る考え方（可用性、耐久性、機密性…）

4. それらのトレードオフ（可用性 vs 一貫性）

という流れで理解が繋がっていきました。

最初は「目先の不安を一個一個潰してる」だけのつもりだった作業が、後から振り返ると体系化された指標と一致している部分がありました。
実務で痛い目を見ながら身につけた判断と、体系化された理論が近い結論に収束するというのが面白かったです。
エンジニアなりたての時に基本情報の勉強してた時は？？？状態でしたが、実務から入ると全部「サービスを守る」という観点ができていたので以前より理解しやすかったです。
とはいえ分からないことは山のようにあるので気長にやっていこうと思います😇