Network ArchitectureによるData Transfer Cost最適化

ゴール

最終的に、

通信量
×
料金

だけではなく、

この通信は
本当にこの経路を通る必要があるか

を判断できることがゴールです。

代表的には、

VPC Endpoint
Amazon CloudFront
NAT Gateway配置
AZアフィニティ
リージョン配置
データ転送モデリング

を使って、

変更前
↓
課金される経路

変更後
↓
より少ない課金経路

を比較します。

1. 最初に「削減できる通信」を探す

データ転送コスト最適化では、

料金表を見る

より先に、

どの通信を減らせるか

を確認します。

基本的な順番は、

不要な通信をなくす
↓
有料の処理サービスを外す
↓
AZ / リージョン境界を減らす
↓
繰り返し転送をキャッシュする
↓
残った通信の料金を比較する

です。

例えば、

NAT Gateway
0.0X USD / GB

を、

もっと安いNAT料金

へ変更するより、

そもそもS3通信を
NAT Gatewayへ通さない

方が効果的な場合があります。

2. 現在の経路からコスト要因を特定する

最初に、099で作ったデータ転送モデルを使います。

例えば、

プライベートEC2
↓
別AZのNAT Gateway
↓
Amazon S3

なら、確認する料金要素は、

Inter-AZ
+
NAT Gateway データ処理

です。

同一リージョンのEC2とS3間のデータ転送自体が無料でも、

途中にNAT Gatewayがある

ことで料金が発生します。

したがって、

S3の料金を下げる

のではなく、

S3までの経路を変更する

ことが最適化になります。

3. Amazon S3 / DynamoDBではGateway VPC Endpointを最初に評価する

Amazon S3とAmazon DynamoDBには、

Gateway VPC Endpoint

があります。

Gateway Endpointには、

エンドポイント 時間料金 料金
データ処理 料金

がありません。

例えば、

Private Subnet
↓
NAT Gateway
↓
Amazon S3

を、

Private Subnet
↓
S3 Gateway Endpoint
↓
Amazon S3

へ変更すると、S3通信について、

NAT Gateway データ処理

を経路から外せます。

NAT Gatewayが別AZにあった場合は、

NATまでのInter-AZ トラフィック

も削減できる可能性があります。

4. Gateway Endpointで削減できる料金を正確に分ける

例えば、

S3通信
4 TB / 月

インターネット通信
1 TB / 月

があり、両方を同じNAT Gatewayへ通していたとします。

S3 Gateway Endpointを導入すると、

S3 4 TB
↓
NAT Gatewayを通らない

ため、

S3分の
NAT データ処理

は削減できます。

しかし、

インターネット 1 TB

のためにNAT Gatewayが残るなら、

NAT Gateway-hour

は残ります。

したがって、

Gateway Endpoint導入
=
NAT Gateway料金が全部なくなる

とは考えません。

削減額は、

実際に消える料金

だけを数えます。

5. NAT Gateway自体を削除できる場合は固定料金も削減できる

反対に、NAT Gatewayの通信が、

S3
DynamoDB
対応AWSサービス

だけだった場合、すべてを適切なVPC Endpointへ移行して、

NAT Gatewayが不要

になれば、

NAT データ処理
+
NAT Gateway-hour

の両方を削減できる可能性があります。

つまり、

トラフィックをエンドポイントへ移した

ことと、

NAT Gatewayを削除できた

ことを分けて評価します。

6. Interface VPC Endpointは無料ではない

Gateway Endpointを利用できないAWSサービスでは、

Interface VPC Endpoint

を評価できます。

Interface Endpointでは、一般に、

エンドポイント Hour
+
データ処理 / GB

が発生します。

したがって、

NAT Gateway
↓
Interface Endpoint

へ変更すれば、

必ず安くなる

わけではありません。

比較するのは、

現在
NAT Gateway-hour
+
NAT処理
+
必要なInter-AZ

vs

候補
Interface Endpoint-hour
+
エンドポイント処理
+
必要なデータ転送

です。

7. Interface EndpointはAZ数もコストモデルへ入れる

Interface VPC Endpointは、

可用性 ゾーン

ごとにエンドポイント用ネットワークインターフェイスを配置できます。

そのため、

1 AZ

と、

3 AZ

では固定料金の形が異なります。

例えば、

通信量
非常に少ない

エンドポイント
3 AZ

の場合、GB単位の削減額より、

エンドポイント-hour

の方が大きくなる可能性があります。

逆に、

大量のAWSサービストラフィック
↓
NAT Gateway

がある場合は、

NAT データ処理削減

によってInterface Endpointが有利になる可能性があります。

8. VPC Endpointの分散配置と中央集約も総経路で比較する

多数のVPCがある環境では、

VPC A
→ Interface Endpoint

VPC B
→ Interface Endpoint

VPC C
→ Interface Endpoint

のように各VPCへ配置すると、

エンドポイント-hour

が重複します。

そのため、

共有サービスVPC
↓
Interface Endpointを中央集約

する設計も候補になります。

しかし中央集約すると、

スポークVPC
↓
Transit Gateway / VPC Peering等
↓
共有 VPC
↓
Interface Endpoint

という経路になります。

したがって、

エンドポイント数削減

だけではなく、

Transit Gateway データ処理
Inter-AZ
VPC Peering データ転送
Interface Endpoint 処理

など、追加される経路料金も含めて比較します。

9. エンドポイント 集中化は「VPC数が多い = 必ず安い」ではない

例えば、

10 VPC
×
3 AZ
×
Interface Endpoint

の固定料金が大きい場合、中央集約によってエンドポイント数を減らせる可能性があります。

しかし、

トラフィック量

が非常に大きいと、中央ハブまでの、

データ処理
データ転送

が増えます。

したがって、

VPC数が多い
↓
中央集約

と機械的には決めません。

見るのは、

エンドポイント固定料金の削減
vs
中央経路で増える従量料金

です。

10. Zonal NAT Gatewayでは同一AZ経路を基本候補にする

Zonal NAT Gatewayは1つのAZに属します。

例えば、

AZ-A EC2
↓
AZ-A NAT Gateway

なら、EC2からNAT GatewayまでAZ境界を越えません。

一方、

AZ-B EC2
↓
AZ-A NAT Gateway

なら、

Inter-AZ

が追加される可能性があります。

そのため、高トラフィックなワークロードでは、

各AZのワークロード
↓
同じAZのNAT Gateway

という経路を評価します。

11. NAT GatewayをAZごとに置けば必ず安いわけではない

例えば2 AZで、

NAT Gateway
1台

から、

NAT Gateway
2台

へ変更すると、

Inter-AZ トラフィック

を減らせる一方、

NAT Gateway-hour

は増えます。

したがって、

追加NAT Gatewayの固定料金

と、

削減されるInter-AZ料金

を比較します。

概念的には、

追加固定料金
<
削減できるInter-AZ料金

なら、コスト面でも有力になります。

ただし、マルチAZでのNAT Gateway配置は、

可用性

にも影響するため、コストだけで1 AZへ集約してはいけません。

12. Regional NAT Gatewayも候補にする

現在は、

Regional NAT Gateway

も利用できます。

Regional NAT Gatewayは、

ワークロードが存在するAZ

に応じて、自動的にAZへ展開・縮小できます。

これにより、

AZごとに
NAT Gatewayを作成

+

Route Tableを個別管理

する運用を簡素化できます。

13. Regional NAT Gatewayは「1台分の料金」ではない

Regional NAT Gatewayは、

1つの論理 NAT Gateway

ですが、料金は、

展開されているAZ
×
NAT Gateway-hour

として考えます。

さらに、

データ処理 / GB

も発生します。

したがって、

Zonal NAT Gatewayを
3 AZへ配置

vs

Regional NAT Gatewayが
3 AZへ展開

を比較するとき、

Regionalだから
常に固定料金が3分の1

とは考えません。

Regional NAT Gatewayの主な価値は、

自動的なAZ展開
高可用性
運用簡素化

と、AZローカルな経路を作りやすくすることです。

14. Regional NAT Gatewayの展開には時間差もある

Regional NAT Gatewayは、新しいAZにワークロードを検出すると自動的に展開します。

ただし、新しいAZへの展開には、

最大60分程度

かかる場合があります。

展開完了までは、

新AZのワークロード
↓
既存AZのRegional NAT Gateway

へ通信が処理される場合があります。

そのため、

Auto Scalingで頻繁に
新しいAZへワークロードが現れる

ような構成では、定常状態だけでなく、

展開中のAZ間トラフィック

も必要に応じて考慮します。

15. AZアフィニティは「通信を同じAZへ寄せる」設計

Inter-AZ トラフィックを減らす方法は、

すべてを1 AZへ置く

ことではありません。

高可用性を維持しながら、

AZ-A
アプリ
↓
AZ-A
バックエンド

AZ-B
アプリ
↓
AZ-B
バックエンド

のように、

各AZの内部で
通信を完結させる

設計を評価できます。

これを、

AZアフィニティ

として考えます。

16. AZアフィニティとマルチAZは両立できる

例えば、

AZ-A
ウェブ → アプリ → キャッシュ

AZ-B
ウェブ → アプリ → キャッシュ

という2つのZonal Stackを持てば、

Multi-AZ

を維持しながら、通常時の大量East-West トラフィックを、

同一AZ

へ寄せられる可能性があります。

つまり、

可用性
vs
Inter-AZ コスト

を、

どちらか一方だけ選ぶ

必要はありません。

17. Network Load BalancerではAvailability Zone Affinityも評価できる

Network Load Balancerでは、

Availability Zone Affinity

を利用できます。

ただし、この機能は、

Route 53 Resolverを使用して
Network Load BalancerのDNS名を
解決するクライアント

に対して使用します。

この条件を満たすクライアントでは、

クライアント
↓
Route 53 Resolver
↓
NLB DNS Resolution

の際に、

クライアントと同じAZの
Network Load Balancer IP

へ通信を寄せることができます。

さらに、

Cross-zone Load Balancing
OFF

と組み合わせることで、

クライアント
↓
同じAZのNLB
↓
同じAZのTarget

というZonal Flowを作りやすくなります。

大量のAZ間通信があり、

Route 53 Resolverを使った
NLB DNS Resolution

を利用できるワークロードでは、Inter-AZ コスト最適化の候補になります。

一方、

任意のインターネットクライアント
↓
任意のDNS Resolver

に対して、Availability Zone Affinityが自動的に同じAZへ誘導する機能だとは考えません。

18. AZ間料金はサービス固有の例外を確認する

ただし、

Cross-zone
=
必ずInter-AZ料金

とは限りません。

例えばアプリケーション Load Balancerでは、Cross-zone Load Balancingに伴う特定のリージョン内データ転送には料金が発生しません。

そのため、

Inter-AZを見つけた
↓
必ずアーキテクチャを変更

ではなく、

実際にそのサービスで
料金が発生しているか

を確認します。

最適化対象は、

トラフィック

ではなく、

課金対象 トラフィック

です。

19. Amazon CloudFrontは繰り返し転送するデータをエッジへ寄せる

インターネット向けに、

同じ画像
同じ動画
同じソフトウェア
同じウェブ応答

を繰り返し配信する場合、毎回、

オリジン
↓
インターネット ユーザー

へ送信する必要はありません。

Amazon CloudFrontを使えば、

オリジン
↓
CloudFront
↓
ビューワー

とし、キャッシュヒット時は、

CloudFront エッジ
↓
ビューワー

だけで応答できます。

20. CloudFrontではオリジンへのデータ量を減らす

CloudFrontのコスト効果では、

リクエスト ヒット率

だけではなく、

バイトヒット率

も重要です。

例えば、

小さいオブジェクト
90% キャッシュヒット

非常に大きいオブジェクト
キャッシュミス

なら、リクエスト数ではヒット率が高くても、

オリジン転送バイト

は大きい可能性があります。

データ転送コストでは、

CloudFrontが
何リクエストを処理したか

だけではなく、

何バイトをオリジンから
再取得したか

を確認します。

21. AWSオリジンからCloudFrontへのデータ転送もコストモデルへ反映する

AWS上の対応オリジンからCloudFrontへコンテンツを配信する場合、現在のCloudFront料金体系では、

CloudFrontへの
AWSオリジン データ転送

が免除されます。

さらにキャッシュヒットが増えると、

オリジンリクエスト
オリジンコンピューティング
オリジンサービス 使用量

も減る可能性があります。

そのため、

インターネットへの直接配信

と、

CloudFront 配信

を比較するときは、

ビューワーへのCloudFront配信料金
+
CloudFront リクエスト料金
+
残るオリジンリクエスト コスト

を含めて比較します。

22. CloudFrontも必ず安くなるわけではない

例えば、

利用者ごとに
完全に異なる対応

キャッシュヒット
ほぼ0%

なら、

オリジン転送削減

は限定的です。

そのため、

CloudFrontを置けば
必ずデータ転送コストが下がる

とは判断しません。

確認するのは、

キャッシュ可能 データ量
キャッシュヒット
バイト ヒット
ビューワー トラフィック
オリジントラフィック
CloudFront 料金

です。

23. リージョン間通信は配置そのものを見直す

例えば、

リージョン A
アプリケーション

↓

毎回Inter-Region

↓

リージョン B
データ

という大量通信がある場合、

Inter-Region単価

だけを最適化するのではなく、

アプリケーションをデータへ寄せられないか

を確認します。

つまり、

コンピューティング
+
データ

を可能な範囲で同じリージョンへ配置します。

24. 「データを動かす」か「処理を動かす」かを比較する

大量データを毎回別リージョンへ送るより、

処理プログラム
数GB

をデータのリージョンへ配置して、

処理結果
数MB

だけ返した方が効率的な場合があります。

例えば、

生データ データ
10 TB

↓

別リージョンへ転送

↓

結果
100 MB

なら、

10 TBを動かす

より、

コンピューティングをデータの近くへ動かす

ことを評価します。

25. レプリケーションとInter-Region トラフィックを比較する

複数リージョンから、

同じデータ

を何度も読み取る場合は、

リージョン A
データ

↓ 毎回転送

リージョン B
コンシューマー

より、

リージョン A
データ
↓
レプリケーション
↓
リージョン B
レプリカ

リージョンB コンシューマー
↓
ローカル読み取り

が有利になる場合があります。

しかしレプリケーションには、

レプリケーション トラフィック
レプリカ ストレージ
書き込み 同期

などのコストがあります。

そのため、

レプリケーション
=
必ず安い

ではありません。

比較するのは、

継続リモート読み取り コスト
vs
レプリケーション + ストレージ コスト

です。

26. 必要なマルチリージョン アーキテクチャをコストだけで壊さない

例えば、

災害復旧
データ所在地要件
事業継続性
レイテンシ

によってマルチリージョンが必要なら、

Inter-Region料金がある

という理由だけで単一リージョンへ変更できません。

正しい順序は、

必要要件
↓
許容されるアーキテクチャ候補
↓
候補の中でデータ転送を最適化

です。

コスト最適化は、

要件を削る

ことではありません。

27. データ転送モデリングは変更前 / 変更後で行う

アーキテクチャ変更前後を、

変更前

と、

変更後

で比較します。

変更前

送信元
↓
AZ 境界
↓
NAT Gateway
↓
送信先

変更後

送信元
↓
VPC Endpoint
↓
送信先

各候補について、

トラフィック量
×
データ転送 単価

+

トラフィック量
×
データ処理 単価

+

時間料金 / 固定料金

を計算します。

28. 「消える料金」だけを削減額へ入れる

例えば、

NAT Gateway

から一部のトラフィックだけをVPC Endpointへ移しても、NAT Gatewayが残るなら、

NAT Gateway-hour

は削減できません。

この場合の削減額は、

回避できる NAT処理
+
回避できる Inter-AZ

などです。

一方、

すべてのNAT トラフィックがなくなる
↓
NAT Gatewayを削除

できれば、

NAT Gateway-hour

も削減額へ入れられます。

29. 固定費と従量費を分けて損益分岐点を見る

例えばInterface Endpointへの変更では、

Interface Endpoint固定料金
+
エンドポイント処理

が増えます。

一方、

NAT処理
Inter-AZ

などが減ります。

したがって、

追加固定費
<
削減される従量費

となるトラフィック量を求めれば、

損益分岐点

を判断できます。

つまり、

通信量が少ない
↓
固定料金が支配的

通信量が多い
↓
GB単位の差が支配的

になる場合があります。

30. データ転送最適化の比較表

31. 代表的なアンチパターン

32. SAP-C02での判断フロー

現在のトラフィックフローを作る
        ↓

どこにコストがある？
        ↓
インターネット
Inter-AZ
Inter-Region
データ処理
時間料金

        ↓

トラフィック自体を減らせる？
        │
        ├─ 繰り返し配信
        │      ↓
        │   CloudFront
        │
        └─ 不要通信
               ↓
             削除

        ↓

NAT Gatewayを通る
AWSサービストラフィックか？
        │
        ├─ S3 / DynamoDB
        │      ↓
        │   Gateway Endpoint
        │
        └─ その他の対応サービス
               ↓
          Interface Endpoint
          との総額比較

        ↓

Zonal NATを
別AZから利用している？
        ↓
同一AZ NAT
またはRegional NAT
を比較

        ↓

大量Inter-AZ トラフィック？
        ↓
AZアフィニティを評価
ただし可用性を維持

        ↓

大量Inter-Region トラフィック？
        ↓
コンピューティング / データの
リージョン配置を見直す

        ↓

反復 リモート読み取り？
        ↓
レプリケーションとの
総額比較

        ↓

変更前 / 変更後の
データ転送モデルを作る

        ↓

実際に消える料金だけを
削減額へ入れる

        ↓

要件を満たす候補の中から
総ネットワークコストが低い
アーキテクチャを選択

まとめ

ネットワークアーキテクチャによるデータ転送コスト最適化では、

料金が発生している

と確認するだけでは不十分です。

まず、

そのトラフィックは
本当にその経路を
通る必要があるか

を確認します。

Amazon S3 / DynamoDBへの通信では、

Gateway VPC Endpoint

によってNAT Gatewayを経路から外せる場合があります。

その他の対応AWSサービスでは、

Interface VPC Endpoint

と、

NAT Gateway

の、

時間料金
+
データ処理
+
データ転送

を比較します。

NAT Gatewayでは、

同一AZのZonal NAT

または

Regional NAT Gateway

を使ってAZ間トラフィックを減らせないか確認します。

大量の東西 トラフィックでは、

AZアフィニティ

を使い、高可用性を維持しながら同一AZへ通信を寄せます。

インターネットへ同じデータを繰り返し配信する場合は、

Amazon CloudFront

によってオリジントラフィックを減らします。

Inter-Region トラフィックでは、

データを動かす

だけではなく、

コンピューティングをデータへ寄せる

ことも検討します。

最後に、

変更前 コスト
vs
変更後 コスト

を比較し、

実際に消えるコスト

だけを削減額として計算します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• AWS Well-Architected Framework — COST08-BP01 Perform data transfer modeling
• AWS Well-Architected Framework — COST08-BP02 Select components to optimize data transfer cost
• AWS Well-Architected Framework — COST08-BP03 Implement services to reduce data transfer costs
• Amazon VPC — Gateway endpoints
• Amazon VPC — AWS PrivateLink pricing
• Amazon VPC — NAT Gateway pricing
• Amazon VPC — Regional NAT gateways
• Amazon CloudFront — Pricing
• Elastic Load Balancing — Availability Zone Affinity / Cross-zone Load Balancing