同じリージョンなのになぜ料金が出るのか
一言でいうと
入ってくるトラフィックはたいてい無料で、出ていくトラフィックと、境界をまたぐトラフィックに料金が付きます。この非対称性を知らないと、請求書を説明できません。
なぜ必要なのか
マルチAZとCDNは可用性と性能を高めますが、データが境界をまたぐ回数も変えます。コンピュートの価格だけを比較すると、アプリとDBの間の繰り返しの通信や、オリジンのエグレスが生むコストを見落とすので、アーキテクチャのすべての主要なトラフィック経路を、月間の転送量に換算する必要があります。
どう動くのか
方向と境界
| 経路 | 料金 |
|---|---|
| インターネット → クラウド(イングレス) | たいてい無料 |
| クラウド → インターネット(エグレス) | 高い |
| 同じAZ内 | たいてい無料 |
| AZ間 | 双方向に課金 |
| リージョン間 | 課金 |
| VPCピアリング(同じリージョン) | AZ間の料金と同程度 |
最もよく見落とされるのがAZ間の料金です。可用性のためにマルチAZで構成したのに、アプリサーバー(AZ-a)とDB(AZ-b)がずっと通信していると、そのトラフィックのすべてが課金されます。クエリ1つ1つは小さくても、毎秒数千件なら月単位で積み上がります。
これを減らす設計
1. AZを意識して配置する 同じAZ内で処理されるように誘導します。Kubernetesなら、トポロジーアウェアルーティング(同じゾーンのエンドポイントを優先する設定)で、かなりの部分が解決します。ただし、可用性と引き換えになるので、1つのゾーンが落ちたときの動作を確認する必要があります。
2. エンドポイントを使う 前のコースで扱ったものです。S3のゲートウェイエンドポイントは料金がかからず、NATを迂回します。
3. CDNを手前に置く エグレスが大きいサービス(画像・動画・ダウンロード)では、CDNのキャッシュヒットがそのままコスト削減になります。CDNのエグレス単価がオリジンより安く、そもそもオリジンまで届きません。
4. 圧縮する APIのレスポンスをgzipで送ると、転送量が大きく減ります。ただし、ストリーミングのレスポンスは圧縮しません。チャンクがバッファーにたまり、ストリーミングがストリーミングではなくなるからです。
5. 見るべきところを見る ログやメトリクスを別のリージョンへ送っていないか、バックアップのレプリケーションが必要以上に頻繁に動いていないかを確認します。
よくある勘違い
- 「内部通信はタダ」: 同じAZ内だけの話です。
- 「圧縮すれば常に得」: CPUを使います。すでに圧縮された形式(画像・動画)には効果がなく、無駄です。
- 「CDNは高い」: エグレスが大きければ、たいていCDNのほうが安くなります。計算してみてください。
計算してみる習慣
数字を入れてみると、感覚がつかめます。
API 응답 평균 20KB, 초당 500 요청, 한 달 30일
= 20KB × 500 × 86,400 × 30
= 25,920 GB ≈ 26TB/월
이그레스 단가를 GB 당 100원으로 가정하면 약 260만 원/월
gzip 으로 5KB 까지 줄이면 약 65만 원/월 — 월 195만 원 절감
このような計算を設計会議でできれば、議論が短くなります。「圧縮するのがよさそうだ」ではなく「月195万ウォン」になるからです。
現場での姿
- マルチAZ構成にしたあとの料金の増加 → AZ間のトラフィックです。配置の戦略を調整します。
- 画像サービスの料金の大半がエグレス → CDNを導入します。
- ログを別のリージョンの収集先へ送っている → リージョン間の料金です。同じリージョンへ移します。
料金を見えるようにする
転送料金が怖い理由は、金額ではなくどこから発生したのかが見えないことです。コンピュートはインスタンスごとに名前が付いていて誰が使っているかわかりますが、転送料金は「リージョン間の転送」のような1行にまとめられて請求書に現れます。そのため、減らすにはまず見えるようにする必要があります。
フローログを有効にします。 どのアドレスからどのアドレスへどれだけ流れたかの記録が残れば、料金が大きい経路を実際に特定できます。記録そのものにもコストがかかりますが、たいてい削減額のほうがはるかに大きく、問題を見つけたあとは、サンプリング率を下げておけば済みます。
タグを付けて、その単位で見ます。 チームやサービスの単位に分けて見ると、請求書全体では見えなかった、1つのサービスの不自然な通信パターンが明らかになります。
料金ではなく転送量で管理します。 単価は変わり、割引も付きますが、「この経路で月に何テラバイト流れるか」は設計から出る値なので安定しています。設計を議論するときは、この数字で話したほうがうまくいきます。
そして、予想外の急増を捕まえる仕組みが必要です。料金のアラートは、たいてい遅すぎます。 月の予算の半分を超えたというアラートが届いたときには、すでに数日分が出ていったあとです。転送量そのものを指標にして、普段の何倍になったら通知するようにすれば、ずっと早く気づけます。特に気をつけたいのは、繰り返しの呼び出しが無限に回る事故です。2つのサービスが互いを呼び合うループができたり、リトライがリトライを呼んだりすると、転送量が数時間で普段の数十倍になります。このような事故は、機能面では何の症状もないため、請求書だけで発見されることがよくあります。そのため、サービス間の呼び出し関係を描いておき、ループができていないかを確認することは、料金の観点でも信頼性の観点でも、同じだけの価値があります。
次に見ること
いよいよ、実際に無駄を見つけ出す手順を作ります。