クラウドの通信費（Egress）入門｜データ転送量課金の仕組みと転送コストを抑える設計

「サーバー代は見積もりどおりなのに、請求書に見覚えのない項目があって合計が倍になっていた」「NATゲートウェイという聞き慣れないものが月額の上位にいる」。クラウドの請求で最も見積もりから外れやすいのが、データ転送量に応じて課金される通信費（Egress）です。インスタンスの時間単価と違い、設計次第で桁が変わります。

この記事では、クラウドの「受信は無料・送信は有料」という原則から始めて、転送の経路ごとに単価が異なる仕組み、見落とされがちなNATゲートウェイの処理料、CDNで転送量そのものを減らす設計、バックアップやログ転送の隠れたコスト、そして請求書のどこを見れば転送料を特定できるかを解説します。クラウドコスト削減の一般的な手法はクラウドコスト削減の方法で扱っているため、ここでは転送料に絞ります。なお本文中の単価は執筆時点のAWS東京リージョンの公開価格をもとにした目安で、必ず最新の料金ページで確認してください。

「入りは無料、出るときに払う」というクラウドの原則

なぜインバウンドは無料なのか

AWS・GCP・Azureのいずれも、インターネットからクラウドへ入ってくる通信（インバウンド）は原則無料で、クラウドから外へ出ていく通信（アウトバウンド＝Egress）に課金します。データを取り込むのは無料にして、取り出すときに費用がかかる構造は、利用者がデータをそのクラウドに置き続ける動機になっています。この「データの重力」を理解しておくと、後述するマルチクラウドやクラウド間バックアップでコストが膨らむ理由もわかります。

「出る」の定義は境界ごとに違う

重要なのは、課金対象の「出る」がインターネットへの送信だけではないことです。クラウド内部にも課金の境界があり、リージョンやアベイラビリティゾーン（AZ）をまたぐ通信にも単価が設定されています。

転送の経路	課金の目安（AWS東京、執筆時点）	典型的な発生源
インターネット→AWS	無料	ユーザーからのリクエスト、アップロード
同一AZ内（プライベートIP）	無料	同一AZのアプリ↔DB
AZ間	0.01 USD/GB を送信側・受信側の双方で課金	マルチAZのアプリ↔DB、レプリケーション
リージョン間	0.09 USD/GB 前後（送信側）	東京→大阪のバックアップ・DR
AWS→インターネット	月100GBまで無料、以降 0.114 USD/GB 前後（従量で逓減）	ページ・画像・APIレスポンス・動画配信
NATゲートウェイ経由	時間料金＋処理料 0.062 USD/GB（通過した全データに課金）	プライベートサブネットからの外部API・パッケージ取得

同じ1GBでも経路によって無料から0.1USD超まで開きがあり、しかもAZ間は「往復で2回」、NATゲートウェイは「経由しただけで」課金されます。構成図を描くときに、矢印ごとに「この線はどの境界を越えるか」を書き込む習慣が、転送料の見積もりの第一歩です。

NATゲートウェイ処理料の罠

プライベートサブネットからS3を読むだけで課金される

プライベートサブネットのサーバーがインターネットに出るためのNATゲートウェイは、時間課金に加えて通過したデータ量あたりの処理料がかかります。落とし穴は、同じAWS内のS3やDynamoDBへのアクセスであっても、経路がNATゲートウェイを通っていれば処理料が発生する点です。「S3からの読み出しは無料のはず」と思っていても、NATを通った分だけ課金されます。大量の画像を処理するバッチや、ECRから頻繁にイメージをpullするコンテナ環境で、NATゲートウェイの処理料がコンピュート費用を超えることは珍しくありません。

VPCエンドポイントで迂回する

S3とDynamoDBにはゲートウェイ型VPCエンドポイントがあり、無料で作成でき、これを経由すればNATゲートウェイを通らずにアクセスできます。ECR・CloudWatch Logs・SSMなどにはインターフェース型エンドポイントがあり、こちらは時間課金と処理料がかかりますが、NATゲートウェイより単価が低く設定されています。

# S3用ゲートウェイエンドポイントの作成（プライベートサブネットのルートテーブルに関連付け）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.ap-northeast-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0123456789abcdef0

# 確認：ルートテーブルにpl-xxxx（S3のプレフィックスリスト）向けの経路が追加されている
aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 \
  --query 'RouteTables[0].Routes'

VPCの構成そのものはAWS VPCのネットワーク設計入門で扱っています。設計段階で「プライベートサブネットからどこに出ていく通信があるか」を洗い出し、S3・DynamoDBはゲートウェイエンドポイント、それ以外は通信量を見てインターフェース型かNATかを判断するのが定石です。

CDNで転送量そのものを減らす

オリジンから出る量を減らすのが本質

EC2やロードバランサーからインターネットへ直接配信すると、すべてのバイトがインターネット向けEgressとして課金されます。CDNを前段に置くと、キャッシュヒットした分はCDNのエッジから配信され、オリジンからの転送は発生しません。CloudFrontのインターネット向け配信単価はEC2からの直接配信と同程度かやや安く、さらにAWSオリジン（S3・ELB・EC2）からCloudFrontへの転送は無料です。つまりCDNを挟むだけで、静的コンテンツの転送料は「エッジからの配信分だけ」に置き換わり、オリジン側の転送料が消えます。

キャッシュヒット率と圧縮で転送バイト数を削る

転送料は最終的に「バイト数×単価」なので、単価の安い経路に寄せるだけでなく、バイト数自体を減らすことが効きます。

• 画像はWebP/AVIFに変換し、表示サイズに合わせたリサイズ版を配信する
• テキスト系（HTML・CSS・JS・JSON）はgzip／brotli圧縮を有効にする（CloudFrontは設定でエッジ側圧縮が可能）
• Cache-Controlを適切に付けてブラウザキャッシュを効かせ、再訪問時の転送をゼロにする
• APIレスポンスで不要なフィールドを返さない、ページネーションを設ける

CloudFrontの具体的な設定はAWS CloudFrontでサイト高速化を参照してください。

見落とされやすい転送：バックアップ・ログ・レプリケーション

ユーザー向け以外の「裏側の通信」

請求書で驚く転送料の多くは、ユーザーに配信した分ではなく、裏側の運用通信です。

• リージョン間バックアップ・DR：東京から大阪へのS3クロスリージョンレプリケーションやRDSのクロスリージョンスナップショットは、毎回リージョン間単価がかかる
• マルチAZのDB通信：アプリとRDSのAZが異なると、全クエリの結果がAZ間転送になる。Multi-AZのレプリケーション自体は無料だが、リードレプリカを別AZに置いて読みに行く通信は課金対象
• ログとメトリクスの外部送信：Datadogなど外部SaaSへログを送ると、全量がインターネット向けEgressになる。NAT経由ならさらに処理料が乗る
• コンテナイメージのpull：Docker Hubからのpullはインターネットからの受信で無料だが、NATを通る分の処理料がかかる。ECRからのpullもエンドポイントがなければ同様
• クラウド間の移動：AWSからGCPへデータを移す、他社クラウドにバックアップを置く、といった構成は送信側のインターネット向け単価で全量課金される

「ユーザーは日本国内が数千人程度」というサービスでも、ログを毎秒送っていたり、夜間バッチが別AZのDBから数十GBを読んでいたりすれば、転送料が主要な費目になります。

請求書で転送料を見つける方法

Cost Explorerで使用量タイプ別に分解する

AWSの転送料は独立したサービスとして請求されるのではなく、EC2やS3、CloudFrontなど各サービスの中の「Usage Type（使用量タイプ）」として現れます。Cost Explorerでフィルタを「Usage Type」にし、DataTransfer を含むものに絞ると、経路別の金額が見えます。Cost Explorerの基本的な使い方を前提に、転送料に特化した見方だけ示します。

# CLIで先月の転送料をUsage Type別に集計する
aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["EC2: Data Transfer - Inter AZ","EC2: Data Transfer - Internet (Out)","EC2: Data Transfer - Region to Region (Out)","EC2: NAT Gateway - Data Processed"]}}' \
  --query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' \
  --output table

Usage Typeの名前には経路が埋め込まれています。たとえば APN1-DataTransfer-Out-Bytes はインターネット向け、APN1-DataTransfer-Regional-Bytes はAZ間、APN1-NatGateway-Bytes はNATの処理料、APN1-APN3-AWS-Out-Bytes は東京から大阪へのリージョン間転送です。どの項目が大きいかで、打つべき手（エンドポイント追加・AZ配置の見直し・CDN導入・ログ送信量の削減）がそのまま決まります。

トラブル事例：NATゲートウェイがEC2より高くなった

症状：小規模なWebアプリの請求で、NAT Gatewayの項目がEC2インスタンス代を上回っていた。トラフィックは少なく、原因が見当もつかなかった。
原因：Cost ExplorerでUsage Typeを分解すると、NatGateway-Bytesが月に数TB発生していた。プライベートサブネットのバッチサーバーが毎晩S3から全画像を読み出して再処理しており、その通信がすべてNATゲートウェイを経由していた。さらに、CloudWatch Logsへのログ送信とECRからのイメージpullもNAT経由だった。
対処：S3用ゲートウェイエンドポイントを作成してNATを迂回させ、この時点で処理料の大半が消えた。ECRとCloudWatch Logs用にインターフェース型エンドポイントを追加し、バッチも差分処理に変更して読み出し量自体を削減。翌月のNATゲートウェイ費用は時間料金のみになった。「同じAWS内の通信は無料」という思い込みが原因で、経路を確認しなかったことが根本原因でした。

まとめ

クラウドの転送料は「受信無料・送信有料」を基本に、AZ間・リージョン間・インターネット向け・NAT経由で単価が異なり、経路次第で同じデータ量でも費用が桁で変わります。設計時には矢印ごとに越える境界を確認し、S3やDynamoDBへはVPCエンドポイントを使い、ユーザー向け配信はCDNでオリジンから出る量を減らし、バックアップやログの裏側の通信も見積もりに含めてください。請求書ではUsage Typeで分解すれば、どの経路が高いかが特定できます。クラウド構成の見直しや費用の診断が必要な場合は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。