Amazon Web Services ブログ

AWS Direct Connect の定額料金で予測可能なコストを実現

本記事は、2026年10月5日にNetworking & Content Delivery で公開されたPowering predictable costs with AWS Direct Connect flat-rate pricingを翻訳したものです。

従来のオンプレミスネットワークでは、コストの予測可能性が常にネットワーク接続予算編成において中心的な要素でした。組織は専用線、Multiprotocol Label Switching (MPLS) リンク、専用クロスコネクトを利用しており、どれだけ多くのデータを転送しても請求額は変わりませんでした。クラウド上にアーキテクチャを再構築すると、従量課金制の柔軟性が得られます。初期コミットメントがないため、この柔軟性はほとんどのワークロードに適しています。一方、AWS からオンプレミスインフラストラクチャへ大量のデータを継続的に転送するワークロードでは、データ転送（送信）(DTO) 料金が送信トラフィックに応じて増加します。変動する DTO コストは、予測と予算策定が次第に難しくなります。一般的な例として、生成 AI のトレーニングと推論、医用画像、動画レンダリング、大規模データ分析があります。

予算策定を簡素化するため、AWS Direct Connect は 10 Gbps および 100 Gbps の専用接続で定額料金を提供するようになりました。この料金モデルでは固定料金が適用され、選択したティアに含まれる AWS リージョンからの DTO については GB 単位の料金が発生しません。ティアは接続範囲に応じて区分されており、トラフィックの流れに合ったティアを選べます。

※訳者注記：定額料金は接続（物理ポート/ポートペア）単位の課金で、仮想インターフェース（VIF）単位ではありません。対象となるのは、接続とその配下のすべての VIF が同一 AWS アカウントで所有されている専用接続のみです（ホスト型接続・ホスト型 VIF は対象外）。

この記事では、定額料金を使用する Direct Connect 接続の設定方法を説明します。続いて、ワークロード要件に基づくティアの選択、定額料金と従量課金制の併用、既存接続の変換について、シナリオを通じて解説します。

Direct Connect の定額料金で得られるもの

  1. 予測可能な時間あたり固定コスト: ティアの対象リージョンでは GB 単位の DTO 料金が発生せず、接続またはポートペアごとに固定料金を支払います。これにより、コストの予測、予算策定、チーム間での配分が容易になります。
  2. 標準装備の回復性: 定額料金では、デフォルトで異なるデバイスまたはロケーションに接続をポートペアとしてプロビジョニングします。回復性は追加の手順ではなく、このサービスの一部として組み込まれています。
  3. 選択肢と柔軟性: 定額料金を利用しながら従量課金制も使用でき、ワークロードに合った請求モードを選択できます。

Direct Connect の定額料金の仕組み

定額料金を使用する新しい Direct Connect 接続の作成方法を順に説明します。

ステップ 1. トポロジを選択する

接続を作成するときに、請求モードと回復性トポロジを選択します。図 1 は、定額請求モードと高い回復性トポロジを示しています。このトポロジでは、2 つの異なる Direct Connect ロケーションに 1 つずつ接続をプロビジョニングします。回復性トポロジの詳細については、Direct Connect の回復性に関する推奨事項ページをご覧ください。

図 1. 新しい Direct Connect 接続の請求モードと回復性トポロジの選択
図 1. 新しい Direct Connect 接続の請求モードと回復性トポロジの選択

ステップ 2. 接続を設定する

定額接続を設定するには、10 Gbps または 100 Gbps を選択します。次に、意図する回復性トポロジを宣言する接続の論理グループである、回復性グループを定義します。各ポートペアは、同一または異なる Direct Connect ロケーション内の別々のデバイスにある 2 つの物理ポートで構成されます。図 2 では、高い回復性トポロジ用に analytics-prod-ap という回復性グループを作成しています。シナリオ 1 で説明するように、定額接続を 1 つだけリクエストし、その接続と既存の対象接続を同じ回復性グループに追加してペアにすることもできます。

図 2. 回復性グループ、ロケーション、定額料金ティアの設定
図 2. 回復性グループ、ロケーション、定額料金ティアの設定

2 つの接続は、アクティブ-アクティブまたはアクティブ-スタンバイ構成で使用します。実効帯域幅は 1 ポート分です。たとえば、10 Gbps のポートペアが提供する帯域幅は 20 Gbps ではなく 10 Gbps です。ワークロードで単一ポートを超えるスループットが必要な場合は、追加のポートペアをプロビジョニングします。

定額料金のティアは、接続の地理的範囲に基づきます。ティアは、AWS リージョンと Direct Connect ロケーション間のトラフィックパスを定義します。トラフィックフローに合ったティアを選択すると、その契約対象パスでは GB 単位の DTO 料金が発生しません。契約対象外の地理的範囲を経由して送信されるトラフィックには、標準の DTO 料金が適用されます。詳細については、AWS Direct Connect 料金ガイドをご覧ください。

※訳者注記：[Tierとは？] Tierは、地理的範囲の区分としてTier1(ローカル)からTier5(全AWSリージョン)まで存在し、送信元リージョンとDirect Connectロケーションが地理的に近く、狭い範囲であれば安価なTier1、より広くカバーするほど高価なTier5に寄ります。詳細はAWS DocumentのDirect Connect Flat-rate ページとDirect Connect Flat-rateの料金ページを参照ください。

ステップ 3. 確認して作成する

トポロジ、接続ロケーション、ポート速度、請求モードを確認し、[作成] を選択します（図 3）。これで Direct Connect 接続に定額料金が設定され、固定の時間料金と、ティアの対象リージョンに含まれる GB 単位の DTO が適用されます。

図 3. 作成前の定額接続注文の確認
図 3. 作成前の定額接続注文の確認

定額料金の実用例

以下のシナリオでは、シングルリージョン構成からマルチリージョンワークロード、既存接続の変換、アカウントをまたいだ請求モードの分離まで、定額料金の実際の利用方法を示します。

シナリオ 1: シングルリージョン – ローカルの Direct Connect ロケーションを介して接続する

図 4 は、us-west-2 に AWS Transit Gateway があるシングルリージョン構成を示しています。オンプレミスシステムは Seattle メトロ圏の Direct Connect ロケーションを介して AWS に接続し、施設内のユーザーはローカルアプリケーションへデータを取得します。たとえば、耐久性と一元管理のために画像検査データを AWS に保存し、医療従事者が必要に応じて閲覧する大規模な医療システムを運用しているとします。このワークロードから、2 つの要件が生じます。繁忙期に送信転送が急増して従量課金制のコストが上昇するため、年間を通じて予測可能な請求が必要です。また、ユーザーはそのデータに依存しているため、光ファイバーの切断、デバイス障害、ロケーション障害が発生してもオンライン状態を維持する必要があります。

すでに Seattle, WA の Digital Realty SEA10 に Direct Connect 接続が 1 つあります。Seattle, WA の TierPoint に 2 つ目の接続を作成し、両方を回復性グループに追加します。送信元リージョンが Direct Connect ロケーションと同じメトロ圏にあるため、ポートペアの請求モードを Tier 1 に設定します。アクティブ-スタンバイを設定し、一方の接続でトラフィックを伝送し、もう一方は障害発生時に備えて待機させます。

これらのロケーションを経由する us-west-2 からのデータ転送（送信）は、GB 単位の DTO 料金なしで時間あたり固定料金の対象になります。受信転送は、従量課金制の場合と同様に引き続き無料です。これにより、予測可能な請求と、AWS リージョンへの 2 ロケーションにまたがる回復性の高いハイブリッド接続が得られます。

図 4. 1 つのメトロ圏内の 2 つの Direct Connect ロケーションにまたがるシングルリージョンの定額料金構成
図 4. 1 つのメトロ圏内の 2 つの Direct Connect ロケーションにまたがるシングルリージョンの定額料金構成

シナリオ 2: マルチリージョン – すべてのワークロードリージョンをカバーするティアを選択する

図 5 は、AWS Cloud WAN 上に構築されたマルチリージョンネットワークを示しています。Amazon VPC リソースは本番セグメントにアタッチされ、Direct Connect ゲートウェイはハイブリッドセグメントにアタッチされています。コアネットワークエッジは us-east-1 と ca-central-1 にあります。データセンターへの接続は、Direct Connect ゲートウェイにアタッチされたトランジット仮想インターフェイスを介して送信されます。AWS から米国とカナダの地上波送信施設へ高ビットレート動画をストリーミングするリニアチャンネル送出システムを運用しています。送出は、米国市場向けには us-east-1、カナダ市場向けには ca-central-1 で実行されます。

まず、us-east-1 用に Reston, VA の CoreSite VA1 にポートペアを、ca-central-1 用に Montreal, CAN の Cologix MTL3 に 2 つ目のポートペアを用意し、どちらにも Tier 1 の定額料金を適用します。各契約は、それぞれのリージョンから Direct Connect ロケーションへのローカルパスをカバーするため、各国内の定常時トラフィックは、GB 単位の DTO 料金なしで選択した定額料金ティアの対象になります。

両方のリージョンにまたがる最大回復性トポロジが必要です。一方のリージョンに障害が発生した場合、稼働中のリージョンから同じ Direct Connect ロケーションを介して、その市場向けのサービスを提供します。このクロスリージョンパスは Tier 1 の対象範囲を超えるため、標準の DTO 料金に戻ります。そこで、同一大陸など、同じ一般的な地理的範囲にある送信元リージョンと、それらに対応する Direct Connect ロケーションをカバーする Tier 2 にアップグレードします。これにより、いずれのロケーションを経由する us-east-1 と ca-central-1 からのトラフィックも 1 つの定額料金ティアの対象となり、通常運用時とフェイルオーバー時の両方でコストを予測できます。

他の地域へ拡張するときは、ローカルの Direct Connect ロケーションにポートペアを追加し、必要に応じて、下位ティアのリージョンを含む上位ティアへ移行します。公開されているティアを超える対象範囲については、AWS アカウントチームにお問い合わせください。

図 5. 2 つのメトロ圏にまたがる Cloud WAN とリージョナルポートペアを使用したマルチリージョンの定額料金構成
図 5. 2 つのメトロ圏にまたがる Cloud WAN とリージョナルポートペアを使用したマルチリージョンの定額料金構成

シナリオ 3: 既存接続を定額料金へ変換する

Amazon Simple Storage Service (Amazon S3) からオンプレミスインフラストラクチャへ、大量のデータを従量課金制で継続的に転送するワークロードを、高い回復性トポロジで運用しています（図 6）。回復性グループ内には、Slough, GBR の Equinix LD5 と London, GBR の Telehouse West に 100 Gbps の専用接続が 1 つずつあります。ルーティングにはアクティブ-アクティブ構成を使用しています。送信トラフィックによって、eu-west-2 からデータセンターへデータセットを転送します。データセットの増加に伴って DTO も増え続けるため、予測可能な時間あたりコストが必要です。同じトポロジを維持して請求モードだけを変更し、これらの接続を定額料金の Tier 1 に変換することを計画しています。

図 6. アクティブ-アクティブ接続を定額料金へ変換する大容量 DataSync ワークロード
図 6. アクティブ-アクティブ接続を定額料金へ変換する大容量 DataSync ワークロード

従量課金制では、各接続のポート時間料金に加えて GB 単位の DTO 料金を支払うため、送信量に応じて請求額が増加し、継続的に大量のデータを転送する場合は予測が難しくなります。定額料金では、ペアに対する単一のポート料金として時間あたり固定料金を支払い、ティアの対象リージョンからの DTO が含まれます。ティアの対象リージョン内であれば、転送量にかかわらずコストは一定です。

転送量に基づいて 2 つの選択肢を比較した後、新しい接続をリクエストする代わりに、Equinix LD5 と Telehouse West の既存接続を定額料金の Tier 1 に変換します。両方のポートは同じトポロジで同じトラフィックを引き続き伝送し、請求だけが変わるため、トラフィックには影響しません。図 7 は、コンソールの [請求モードを変更] ダイアログを示しています。UpdateConnectionsBillingMode アクションは、AWS Direct Connect API を使用して、同じ操作をプログラムで実行します。変換はロケーションレベルで適用されるため、1 つの接続を定額料金に変換すると、同じアカウントのその Direct Connect ロケーションにあるすべての接続が変換されます。

図 7. コンソールで既存接続を従量課金制から定額料金へ変換
図 7. コンソールで既存接続を従量課金制から定額料金へ変換

各ポートペアがアクティブ-アクティブモードで提供するスループットは 1 ポート分であるため、2 つの接続は合計 200 Gbps のポート容量に対して、100 Gbps の使用可能な帯域幅を提供します。単一ロケーションに障害が発生しても、稼働中のサイトには正常な接続が 1 つ残り、そのロケーションの全負荷を伝送できます。100 Gbps の実効帯域幅内に収めるため、AWS DataSync でデータを移動し、タスクの帯域幅制限を 100 Gbps に設定します。次に、Amazon CloudWatch で、両方の接続の ConnectionBpsEgress の合計に対するアラームを追加し、総ポート容量の使用率が 50% に近づいたときにトリガーされるように設定します。これにより、十分な余裕を確保し、単一ロケーションに障害が発生しても 1 ポートペアの実効帯域幅を超えないようにできます。

シナリオ 4: 同じ Direct Connect ロケーションで異なる請求モードを使用する

あるワークロードには定額料金が適していても、別のワークロードには適さない場合があります。たとえば、大量のトラフィックを継続的に送信する高ボリュームのストリーミングワークロードと、データ転送量がはるかに少ない社内イントラネットの業務アプリケーションを同時に運用しているとします。ストリーミングワークロードの継続的なトラフィックには定額料金の方が経済的である一方、イントラネットアプリケーションの少ない使用量には従量課金制が適しています。レイテンシー要件と既存のコロケーション拠点の都合で、両方のワークロードが同じ Direct Connect ロケーションを経由するため、ロケーションだけで分離することはできません。

請求モードは、アカウント内のロケーション単位で設定されます。同じロケーションで異なる請求モードを使用するには、AWS Organizations の同じ組織内にある 2 つのネットワークアカウントへ、2 つのワークロードを分離します。ストリーミング接続は、専用のネットワークアカウントで定額料金を使用してプロビジョニングします。イントラネットアプリケーションは、一元管理するネットワークアカウントで従量課金制のままにします。図 8 では、両方のワークロードが同じ Direct Connect ロケーションと物理接続を共有し、ストリーミングワークロードには定額料金、イントラネットワークロードには従量課金制を適用しています。

図 8. 同じ Direct Connect ロケーションにある 2 つのアカウントで請求モードを分離
図 8. 同じ Direct Connect ロケーションにある 2 つのアカウントで請求モードを分離

データを使用して定額料金を評価する

定額料金へ切り替える前に、まず手元にあるデータを確認します。トラフィックメトリクスと請求記録は、定額料金がワークロードに適しているかどうかを判断するのに役立ちます。以下の手順では、確認すべき CloudWatch メトリクスとコストデータを説明します。

Amazon CloudWatch で転送パターンを分析する

各 Direct Connect 接続の ConnectionBpsEgress CloudWatch メトリクスを確認します。このメトリクスは送信ビット数/秒を記録し、トラフィックの傾向を把握できます。RUNNING_SUM() CloudWatch 数式を適用して、請求期間中の累積 DTO 量を可視化できます。図 9 は、ピーク需要と増加傾向を可視化する方法を示しています。継続的な高スループット、累積転送量の月ごとの増加、予測できない急増は、定額料金が適している可能性を示す兆候です。

図 9. Amazon CloudWatch で Direct Connect のトラフィックと累積データ転送量をモニタリング
図 9. Amazon CloudWatch で Direct Connect のトラフィックと累積データ転送量をモニタリング

AWS Cost Explorer と AWS Data Exports で現在の支出を確認する

AWS Cost Explorer を使って、Direct Connect の DTO にかかっている支出を確認します。さらに詳しく見るには AWS Data Exports を使います。ここでは、Direct Connect の DTO が次の形式の使用タイプとして表示されます:

{Region}-{DirectConnectLocation}-DataXfer-Out:dc.{#}。

たとえば EUW2-THNO2-DataXfer-Out:dc.3 は、eu-west-2 から英国ロンドンの Telehouse West への DTO を表します。この内訳はロケーションごとの転送コストを示します。定額料金はそのロケーションのすべての接続に影響するため、この粒度が重要になります。図 10 は、月ごとのコストと使用量の内訳です。

図 10. AWS Cost Explorer における月次の Direct Connect コストと使用量の内訳
図 10. AWS Cost Explorer における月次の Direct Connect コストと使用量の内訳

月平均の送信支出を、対象ティアの定額料金と比較します。次に、その定額料金を GB 単位の DTO レートで割ります。転送量がそのしきい値を常に満たす (または上回る) 場合や、CloudWatch メトリクスが増加傾向にある場合は、定額料金が適している可能性があります。

考慮事項

  • 専用接続のみ対応: 定額料金はホスト接続では利用できません。
  • マルチリージョンリソース: 1 つの接続から、Direct Connect ゲートウェイ、AWS Transit Gateway、AWS Cloud WAN を介して複数リージョンのリソースに到達できます。マルチリージョンリソースをアタッチする前にティアを確認し、対象に含めたい各リージョンがカバーされているか確かめてください。
  • 新しいリージョンへの拡張: プロビジョニング後にトポロジを新しいリージョンへ広げる場合、ティアの変更が必要になることがあります。ティア対象外のリージョンからのトラフィックは、ティアを引き上げるまで標準の DTO 料金で請求されます。
  • 別途請求される料金: AWS Transit Gateway や AWS Cloud WAN でのデータ処理など、その他の AWS サービス料金は別途発生します。AWS Direct Connect SiteLink でのデータ転送はどのティアでもカバーされず、標準料金で請求されます。
  • プロバイダー料金: コロケーションプロバイダーや AWS Direct Connect パートナーによるクロスコネクト料金・コロケーション料金、およびネットワークプロバイダーによるラストマイル回線料金は、定額料金には含まれません。
  • 接続ごとの請求モード: 1 つの AWS アカウント内では、同じ Direct Connect ロケーションにあるすべての接続が同じ請求モードを使う必要があります。ただし、同じアカウントでもロケーションが異なれば別のモードを使えるため、一方のロケーションは定額料金、もう一方は従量課金制、という使い分けが可能です。
  • 回復性と SLA のカバー範囲: 回復性のためにはポートペアを推奨しますが、必須ではありません。現在接続が 1 つだけの場合は、同じロケーションにもう 1 つ接続を追加し、両方を同じ回復性グループに関連付けてポートペアを構成できます。アクティブ-アクティブとアクティブ-スタンバイのいずれかを選択します。ペアの 2 つ目の接続は追加料金なしで含まれます。回復性グループを持たない定額接続は、引き続き AWS Direct Connect サービスレベルアグリーメントの単一接続 SLA の対象となります。

まとめ

この記事では、AWS Direct Connect の定額料金によって、大容量ワークロードの変動する GB 単位 DTO 料金を、時間あたり固定料金に置き換える方法を紹介しました。設定手順を順に説明し、シングルリージョンの医用画像から、クロスリージョンフェイルオーバーを伴うマルチリージョンの動画プレイアウトまでのシナリオを取り上げました。さらに、既存接続を変換する方法や、アカウントをまたいで請求モードを使い分ける方法も示しました。CloudWatch メトリクスと Cost Explorer のデータを使えば、自社の転送量と増加傾向が切り替えに見合うかを評価できます。トラフィックの流れに合ったティアを選び、回復性グループと組み合わせることで、時間あたり固定料金・標準装備の回復性・予測可能でチーム間に配分しやすい請求が得られます。

まずは、AWS Direct Connect コンソールと、最新料金を掲載した定額料金ページをご覧ください。

ご不明な点があれば、AWS re:Post でスレッドを立てるか、AWS サポートにお問い合わせください。

この記事の翻訳はソリューションアーキテクトの長屋が担当しました。