[アップデート] AWS Transit Gatewayのデータ転送量課金の請求先をコントロールするメータリングポリシーが使用できるようになりました

マルチアカウントでTransit Gatewayのデータ転送料金を良い感じに按分したい場合は必須
2025.11.24
 送信元ではなく送信先に請求をしたいこんにちは、のんピ(@non____97)です。
皆さんはTransit Gatewayを使用していて、送信元ではなく送信先に請求をしたいなと思ったことはありますか? 私はあります。
Transit Gatewayはデータの転送量に対しての課金が発生します。
このデータ転送量の課金の請求先は、データの送信元となるTransit Gateway attachmentを所有しているAWSアカウントです。
ただし、この課金の仕組みだと以下のような点が気になります。
大容量のデータをPullする操作が発生した場合、Pullリクエストを行ったAWSアカウントではなく、リクエストを受けて実際に大容量データを送信するAWSアカウントに課金が発生してしまう

→ 本来は大容量データ扱いのきっかけを作った、Pullリクエストを行ったAWSアカウントに請求したい
オンプレミスからのデータ転送にかかる料金が全てDirect Connect Gatewayの所有者となってしまう

→ 本来は送信先のAWSアカウントに請求したい
AWS Network Firewallなど通信経路途中に配置するミドルボックスアタッチメントを用意する場合、ミドルボックスアタッチメントを所有するAWSアカウントに対して課金が発生してしまう

→ 本来はデータの送信元もしくは送信先のAWSアカウントに請求したい
組織内で料金を按分しようとすると、Transit Gateway Flow Logsなどから計算をする必要がありました。これは非常に労力の大きい作業です。対応が現実的ではなくAWSの仕様を受け入れざるを得ないケースもあるでしょう。
今回アップデートにより、Transit Gatewayのデータ転送量課金の請求先をコントロールするメータリングポリシーが使用できるようになりました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-transit-gateway-flexible-cost-allocation/
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/network-firewall-flexible-cost-allocation/
AWS Blogsにも投稿されています。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/introducing-flexible-cost-allocation-for-aws-transit-gateway/
これにより、ポリシーに基づいて請求先のAWSアカウントを以下から柔軟に選択できるようになりました。
データの送信元となるTransit Gateway attachmentの所有者
データの送信先となるTransit Gateway attachmentの所有者
Transit Gateway
柔軟に請求先をコントロールできることから、こちらはFlexible Cost Allocation (FCA)機能と呼ばれるようです。
実際に試してみます。
 いきなりまとめメータリングポリシーを使用することでTransit Gatewayのデータ転送量課金の請求先をコントロールすることが可能
請求先は以下かから選択
データの送信元となるTransit Gateway attachmentの所有者
データの送信先となるTransit Gateway attachmentの所有者
Transit Gateway


ミドルボックスアタッチメントをメータリングポリシーに関連付けることで、ミドルボックスアタッチメントの所有者ではなく通信の送信元/送信先に請求することが可能
マルチアカウントでTransit Gatewayのデータ転送料金を良い感じに按分したい場合は必須
 ドキュメントから仕様の確認ドキュメントから仕様をします。
以下AWS公式ドキュメントが参考になります。
https://docs.aws.amazon.com/vpc/latest/tgw/metering-policy.html
 概要メータリングポリシーはTransit Gateway単位で作成します。1:1の関係です。
メータリングポリシー内にメータリングポリシーエントリーを作成し、請求先をコントロールします。
メータリングポリシーエントリーはポリシールール番号の昇順で評価をし、請求先のAWSアカウントを決定します。ルールの条件として以下が設定可能です、
送信元Transit Gateway attachmentのタイプまたはID
送信先Transit Gateway attachmentのタイプまたはID
送信元CIDRブロック
送信先CIDRブロック
送信元ポート範囲
送信先ポート範囲
プロトコル
かなり柔軟な設定ができるのではないでしょうか。
全てのフィールドを毎回埋める必要はなく、未指定の場合はすべての値が適用されます。例えば、送信元Transit Gateway attachmentタイプのフィールドを未指定にすると、全ての送信元Transit Gateway attachmentがマッチします。
これにより、「送信元のTransit Gateway attachmentがDirect Connect Gatewayの場合は、全ての通信の課金を送信先Transit Gateway attachment所有者にする」といったことが可能になります。
イメージはAWS Blogsに投稿されていた以下図が分かりやすいです。
抜粋 : AWS Transit Gateway の柔軟なコスト配分の導入 | ネットワーキングとコンテンツ配信
また、Transit Gateway attachmentのタイプとして指定可能なものは以下のとおりです。
VPC
Site-to- Site VPN
Direct Connect Gateway
Transit Gateway ピアリング
Network Function (AWS Network Firewall)
Site-to-Site VPN Concentrator
IDではなく、タイプも指定できるということで上手に使って複雑なルールとならないように気をつけましょう。なお、メータリングポリシーエントリーの上限は50個です。
 ミドルボックスアタッチメントの課金AWS Network Firewallなど通信経路途中に配置するミドルボックスアタッチメントを用意する場合、メータリングポリシーにミドルボックスアタッチメントを関連付けることも可能です。
これにより、ミドルボックスアタッチメントを経由する通信のデータ使用量はメータリングポリシーのルールに従って請求されます。
送信元をミドルボックスアタッチメントで請求先を送信先Transit Gateway attachmentの所有者とするメータリングポリシーエントリーを追加することでも同様の対応が可能ですが、これによりルールを一つ削減することが可能です。
また、ミドルボックスアタッチメントをメータリングポリシーに関連付けることによって、送信元Transit Gateway attachmentの所有者にミドルボックスアタッチメントからTransit Gatewayに転送するデータ通信量に対しての課金も行うことが可能です。こちらはミドルボックスアタッチメントをメータリングポリシーと関連付けずに実現することはできません。
メータリングポリシーに関連付けが可能なはミドルボックスアタッチメントの上限は10個までです。11個以上使用したい場合はほぼないかと思うので十分でしょう。
ミドルボックスアタッチメントとして指定可能なTransit Gateway attachmentのタイプは以下のとおりです。
VPC
Site-to-Site VPN
Network Function (AWS Network Firewall)
また、注意点として3つあります。
1点目はミドルボックスアタッチメントのメータリングポリシーへの関連付けによる請求額のコントロールができる前提として、ミドルボックスアタッチメントに入ってくるフローと出て行くフローの5タプルが一致している必要があります。そのため、ミドルボックスアタッチメントを通ることでNATをしている場合は効力を発揮しません。
2点目はミドルボックスアタッチメント上の全ての出力専用フローは、通常の送信元/送信先のアタッチメントとして動作します。ミドルボックスとして動作していないので当然と言えば当然です。
3点目はAWS Network Firewallがパケットをドロップした場合、メータリングポリシーの設定に関係なく、全てのデータ転送量の課金が送信者アカウントに請求されます。送信先に請求することはできないので注意しましょう。
 料金メータリングポリシー自体に追加の料金は発生しません。無料で使用可能です。
なお、メータリングポリシーの変更の反映は課金時間の終了後になります。即時ではなく一時間後ぐらいを見ておくと良いでしょう。
 パフォーマンス影響レイテンシーおよび帯域幅の影響はありません。

Metering policies do not introduce any additional data-path latency.
Metering policies have no impact on maximum bandwidth per attachment.
There are no changes to transit gateway resource sharing capabilities.

 ベストプラクティスベストプラクティスとして以下が紹介されていました。
エントリー番号を慎重に計画する
将来のエントリー追加を考慮して100、200、300など間隔を空ける

より制限的なエントリーを追加する前に、最初はあまり具体的でない条件でエントリーをテストする
意図しない請求を避けるために、マッチする通信が少ないエントリーで動作確認をする
 注意点その他の注意点として以下があります。
Transit Gatewayのマルチキャストのデータ転送量には未対応
Transit Gatewayの所有者はTransit Gatewayの所有者によって構成されたコスト割り当て設定を上書きできない
Transit Gatewayに設定されたメータリングポリシーを受け入れる必要がある

 やってみた 検証環境検証環境は以下のとおりです。
AWS Network FirewallはVPC上に構築するのではなく、以下アップデートの機能を用いてTransit Gatewayに直接アタッチメントを作成しています。
https://dev.classmethod.jp/articles/aws-network-firewall-transit-gateway-native-integration/
メータリングポリシー以外の全リソースは作成済みです。
 メータリングポリシーの作成Transit Gatewayにて、メータリングポリシーの作成をします。
Transit Gatewayを確認すると、メータリングポリシーIDのフィールドがありました。アクション-Create metering policyをクリックします。
タグや関連付けるTransit GatewayのID、ミドルボックスアタッチメントの指定が可能です。Nameタグとミドルボックスアタッチメントとして、AWS Network FirewallのTransit Gateway attachmentを選択します。
ミドルボックスアタッチメントとしては他にVPCも選択可能でした。
また、ミドルボックスアタッチメント - オプション横の情報をクリックすると以下説明が表示されました。分かりやすいですね。
ミドルボックスアタッチメントは、送信元と送信先の間のトラフィックを処理するファイアウォールやロードバランサーなどの中間ネットワークサービスです。デフォルトでは、データ使用量はミドルボックスの所有者に課金されます。このリストにアタッチメントを追加すると、ミドルボックスの所有者ではなく、ポリシーエントリに基づいて実際の送信元または送信先に対するトラフィックが計測されます。
メータリングポリシーが作成されたことを確認します。
作成完了は一瞬でした。
メータリングポリシーエントリーとして、送信元に請求先するデフォルトのエントリーが登録されていました。このエントリーは削除も優先度も変更できないようです。そのため、デフォルトの挙動を変更したい場合は32767未満のルール番号でルール条件全未指定で請求先AWSアカウントを送信先やTransit Gateway所有者に変更する必要があります。
ミドルウェアボックスアタッチメント一覧も確認できます。リソースIDとしてAWS Network Firewallに設定した名前が表示されているので分かりやすいですね。
AWS CLIで確認する場合は以下のとおりです。
> aws ec2 describe-transit-gateway-metering-policies --transit-gateway-metering-policy-ids tgw-mp-076fcd5d54dc2c728
{
    "TransitGatewayMeteringPolicies": [
        {
            "TransitGatewayMeteringPolicyId": "tgw-mp-076fcd5d54dc2c728",
            "TransitGatewayId": "tgw-070ff0538aa32b8dd",
            "MiddleboxAttachmentIds": [
                "tgw-attach-0b54392b8c596de41"
            ],
            "State": "available",
            "UpdateEffectiveAt": "2025-11-24T03:00:00+00:00",
            "Tags": [
                {
                    "Key": "Name",
                    "Value": "egress-tgw"
                }
            ]
        }
    ]
}

 メータリングポリシーエントリーの追加メータリングポリシーエントリーの追加をします。
ポリシールール番号や請求先のAWSアカウント、ルールの条件を指定できます。
従量制アカウントで請求先のAWSアカウントを選択可能です。
送信元Transit Gateway attachmentのタイプまたはIDや、送信先Transit Gateway attachmentのタイプまたはIDでは以下のようにプルダウンで選択が可能です。
エントリーの追加をすると以下のようになりました。
AWS CLIと確認すると以下のとおりです。
> aws ec2 get-transit-gateway-metering-policy-entries --transit-gateway-metering-policy-id tgw-mp-076fcd5d54dc2c728
{
    "TransitGatewayMeteringPolicyEntries": [
        {
            "PolicyRuleNumber": "100",
            "MeteredAccount": "destination-attachment-owner",
            "State": "available",
            "UpdateEffectiveAt": "2025-11-24T03:00:00+00:00",
            "MeteringPolicyRule": {
                "SourceTransitGatewayAttachmentId": "tgw-attach-0d4d02b657dcc0ca6",
                "DestinationTransitGatewayAttachmentId": "tgw-attach-06f7680c56f8c19f5"
            }
        },
        {
            "PolicyRuleNumber": "32767",
            "MeteredAccount": "source-attachment-owner",
            "State": "available",
            "UpdateEffectiveAt": "2025-11-24T03:00:00+00:00",
            "MeteringPolicyRule": {}
        }
    ]
}
 個人的に設定するであろう設定およびエントリー個人的に設定するであろう設定およびエントリーは以下のとおりです。
AWS Network Firewallやファイアウォール製品の仮想アプライアンスが動作しているVPCのミドルボックスアタッチメントとメータリングポリシーの関連付けの実施

→ ミドルボックスアタッチメントの所有者に請求するのではなく、送信元もしくは送信先に請求するため

Egress VPCを送信元とする通信において、請求先を送信先とする

→ インターネットへのアウトバウンド通信のリクエストを行ったAWSアカウントへ請求するため

データレイクやファイルサーバーなどが動作しているVPCを送信元とする通信において、請求先を送信先とする

→ 大容量のデータ通信のリクエストを行ったAWSアカウントへ請求するため

要するに課金のきっかけを作ったものに対して請求をしたいです。
 マルチアカウントでTransit Gatewayのデータ転送料金を良い感じに按分したい場合は必須AWS Transit Gatewayのデータ転送量課金の請求先をコントロールするメータリングポリシーが使用できるようになりました。
マルチアカウントでTransit Gatewayのデータ転送料金を良い感じに按分したい場合は必須ですね。
今まで多大な工数をかけて人力で対応していた、もしくは受容するしかなかった状況であった場合はぜひ検討してみてください。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!