JP6679673B2 - 分散システムにおける顧客志向ネットワークの限界 - Google Patents
分散システムにおける顧客志向ネットワークの限界 Download PDFInfo
- Publication number
- JP6679673B2 JP6679673B2 JP2018146686A JP2018146686A JP6679673B2 JP 6679673 B2 JP6679673 B2 JP 6679673B2 JP 2018146686 A JP2018146686 A JP 2018146686A JP 2018146686 A JP2018146686 A JP 2018146686A JP 6679673 B2 JP6679673 B2 JP 6679673B2
- Authority
- JP
- Japan
- Prior art keywords
- network
- node
- traffic
- client
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 claims description 88
- 238000003860 storage Methods 0.000 claims description 55
- 238000012800 visualization Methods 0.000 description 55
- 235000019580 granularity Nutrition 0.000 description 51
- 230000004044 response Effects 0.000 description 46
- 238000007726 management method Methods 0.000 description 38
- 230000005540 biological transmission Effects 0.000 description 27
- 230000009467 reduction Effects 0.000 description 19
- 230000009471 action Effects 0.000 description 13
- 230000008859 change Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 10
- 238000012546 transfer Methods 0.000 description 10
- 238000004891 communication Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 239000008186 active pharmaceutical agent Substances 0.000 description 7
- 230000008520 organization Effects 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 230000001419 dependent effect Effects 0.000 description 6
- 238000001514 detection method Methods 0.000 description 6
- 230000036541 health Effects 0.000 description 6
- 238000005259 measurement Methods 0.000 description 6
- 238000007493 shaping process Methods 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 125000001810 isothiocyanato group Chemical group *N=C=S 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 3
- 238000013467 fragmentation Methods 0.000 description 3
- 238000006062 fragmentation reaction Methods 0.000 description 3
- 239000000543 intermediate Substances 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 239000003086 colorant Substances 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000003862 health status Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000007334 memory performance Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000002040 relaxant effect Effects 0.000 description 1
- 230000002459 sustained effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002194 synthesizing effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000002747 voluntary effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
- H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
- H04L43/0882—Utilisation of link capacity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5029—Service quality level-based billing, e.g. dependent on measured service level customer is charged more or less
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Mining & Analysis (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Description
多くの企業や他の組織は、コンピューティング・システムが同一の場所に配置される（
例えば、ローカル・ネットワークの一部として）、或いは、多数の別個の地理的場所に配
置される（例えば、一つ以上の私的或いは公的中間ネットワークを介して接続された）と
して、多数のコンピューティング・システムを相互接続するコンピュータ・ネットワーク
を動作させて、それぞれの動作をサポートする。例えば、単一の組織により且つその代わ
りに動作される私的データ・センター、および、顧客にコンピューティング資源を提供す
るようビジネスとしてエンティティによって動作される公的データ・センター等、著しい
数の相互接続されたコンピューティング・システムを収容するデータ・センターは一般的
になってきている。幾つかの公的データ・センターのオペレーターは、様々な顧客によっ
て所有されるハードウェアについてネットワーク・アクセス、電力、および、安全な設置
施設を提供し、他の公的データ・センターのオペレーターは、その顧客によって使用され
るよう利用可能にされたハードウェア資源を含む「フルサービス」施設を提供する。しか
しながら、典型的なデータ・センターの規模や範囲が増大されると、物理的なコンピュー
ティング資源を提供し、運営し、管理する作業も益々複雑になってくる。
例えば、ローカル・ネットワークの一部として）、或いは、多数の別個の地理的場所に配
置される（例えば、一つ以上の私的或いは公的中間ネットワークを介して接続された）と
して、多数のコンピューティング・システムを相互接続するコンピュータ・ネットワーク
を動作させて、それぞれの動作をサポートする。例えば、単一の組織により且つその代わ
りに動作される私的データ・センター、および、顧客にコンピューティング資源を提供す
るようビジネスとしてエンティティによって動作される公的データ・センター等、著しい
数の相互接続されたコンピューティング・システムを収容するデータ・センターは一般的
になってきている。幾つかの公的データ・センターのオペレーターは、様々な顧客によっ
て所有されるハードウェアについてネットワーク・アクセス、電力、および、安全な設置
施設を提供し、他の公的データ・センターのオペレーターは、その顧客によって使用され
るよう利用可能にされたハードウェア資源を含む「フルサービス」施設を提供する。しか
しながら、典型的なデータ・センターの規模や範囲が増大されると、物理的なコンピュー
ティング資源を提供し、運営し、管理する作業も益々複雑になってくる。
商品ハードウェアに対する仮想化技術の出現は、様々なニーズを持つ多数の顧客に対し
て大規模なコンピューティング資源を管理することに関して利益をもたらすため、様々な
コンピューティング資源が多数の顧客によって効率的に且つ安全に共有されることが可能
となる。例えば、仮想化技術によると、単一の物理的なコンピューティング・マシンによ
ってホストされる一つ以上のバーチャル・マシンを各ユーザに提供することで、該単一の
物理的なコンピューティング・マシンは多数のユーザ間で共有されることができる。各バ
ーチャル・マシンは、ユーザに所与のハードウェア・コンピューティング資源の唯一のオ
ペレーターであり管理者であるといった錯覚を与える一方で、様々なバーチャル・マシン
間でアプリケーション隔離やセキュリティを提供する、別個の論理的コンピューティング
・システムとして作用するソフトウェア・シミュレーションとして考えられる。更に、幾
つかの仮想化技術は、多数の別個の物理的なコンピューティング・システムにわたる多数
の仮想プロセッサを含む単一のバーチャル・マシン等、二つ以上の物理的資源にわたる仮
想資源を提供することができる。
て大規模なコンピューティング資源を管理することに関して利益をもたらすため、様々な
コンピューティング資源が多数の顧客によって効率的に且つ安全に共有されることが可能
となる。例えば、仮想化技術によると、単一の物理的なコンピューティング・マシンによ
ってホストされる一つ以上のバーチャル・マシンを各ユーザに提供することで、該単一の
物理的なコンピューティング・マシンは多数のユーザ間で共有されることができる。各バ
ーチャル・マシンは、ユーザに所与のハードウェア・コンピューティング資源の唯一のオ
ペレーターであり管理者であるといった錯覚を与える一方で、様々なバーチャル・マシン
間でアプリケーション隔離やセキュリティを提供する、別個の論理的コンピューティング
・システムとして作用するソフトウェア・シミュレーションとして考えられる。更に、幾
つかの仮想化技術は、多数の別個の物理的なコンピューティング・システムにわたる多数
の仮想プロセッサを含む単一のバーチャル・マシン等、二つ以上の物理的資源にわたる仮
想資源を提供することができる。
仮想化計算、ストレージ、および、ネットワーク資源のプロバイダによってサポートさ
れる機能性や特徴が増大され、大規模なプロバイダによって使用されるハードウェア・プ
ラットホームの隊が増大されると、ネットワーク・トラフィックの流れを管理する等、プ
ラットホームに対する運営管理制御動作の実施自体が比較的複雑になる。多くの場合、こ
のようなプラットホームで実行されるアプリケーションの機能性や有用性は、プロバイダ
・ネットワークの他の部分および／またはクライアント、第三者等の外部エンティティと
のネットワーク通信に広く依存し得る。分散システムのオペレーターは、所望のアプリケ
ーション性能レベルを実現しようと典型的にセットアップされた高帯域幅ネットワーク・
インフラストラクチャを有してもよい。しかしながら、高帯域幅ネットワーク装置および
リンクが提供されたとしても、特に、多くのタイプの展開されたアプリケーションに対し
て時間的に変化し、場所に依存する帯域幅要件を考慮するとネットワーク帯域幅は、多く
の場合、障害資源となり得る。単一のハードウェア・プラットホーム上で実施される様々
なバーチャル・マシンがプラットホームの共有ネットワークの構成要素を用いて満たされ
なくてはならない幅広く変化するネットワーク要件を有し、所与のハードウェア・プラッ
トホームでインスタンス化されるアプリケーションやバーチャル・マシンのセットが時間
と共に変化し得るため、仮想化はネットワーク帯域幅（並びに、待ち時間や他のネットワ
ーク特徴）の管理を益々難しい問題にしている。
れる機能性や特徴が増大され、大規模なプロバイダによって使用されるハードウェア・プ
ラットホームの隊が増大されると、ネットワーク・トラフィックの流れを管理する等、プ
ラットホームに対する運営管理制御動作の実施自体が比較的複雑になる。多くの場合、こ
のようなプラットホームで実行されるアプリケーションの機能性や有用性は、プロバイダ
・ネットワークの他の部分および／またはクライアント、第三者等の外部エンティティと
のネットワーク通信に広く依存し得る。分散システムのオペレーターは、所望のアプリケ
ーション性能レベルを実現しようと典型的にセットアップされた高帯域幅ネットワーク・
インフラストラクチャを有してもよい。しかしながら、高帯域幅ネットワーク装置および
リンクが提供されたとしても、特に、多くのタイプの展開されたアプリケーションに対し
て時間的に変化し、場所に依存する帯域幅要件を考慮するとネットワーク帯域幅は、多く
の場合、障害資源となり得る。単一のハードウェア・プラットホーム上で実施される様々
なバーチャル・マシンがプラットホームの共有ネットワークの構成要素を用いて満たされ
なくてはならない幅広く変化するネットワーク要件を有し、所与のハードウェア・プラッ
トホームでインスタンス化されるアプリケーションやバーチャル・マシンのセットが時間
と共に変化し得るため、仮想化はネットワーク帯域幅（並びに、待ち時間や他のネットワ
ーク特徴）の管理を益々難しい問題にしている。
本願では、幾つかの実施形態に対する実施例および例示的図面を用いて実施形態が説明
されるが、当業者には、実施形態が記載する実施形態または図面に制限されないことが分
かるであろう。図面およびそれに伴う詳細な説明は、実施形態を開示する特定の形態に制
限することを意図せず、反対に、添付の特許請求の範囲によって定められる精神および範
囲内の全ての変更態様、等価物、および、代替物を網羅することが意図されることは理解
されるであろう。本願で使用される見出しは、整理目的のためのみに提供され、明細書ま
たは特許請求の範囲の範囲を制限するために使用されることは意図されていない。本願を
通じて使用されるように、「得る」といった言い方は、強制的な意味合い（即ち、必須の
意味）よりもむしろ、許容的な意味合い（即ち、可能性があるといった意味）で用いられ
る。同様にして、「含む」、「含んでいる」、および、「含み」といった用語は、含むこ
とを意味しているが、これに制限されない。
されるが、当業者には、実施形態が記載する実施形態または図面に制限されないことが分
かるであろう。図面およびそれに伴う詳細な説明は、実施形態を開示する特定の形態に制
限することを意図せず、反対に、添付の特許請求の範囲によって定められる精神および範
囲内の全ての変更態様、等価物、および、代替物を網羅することが意図されることは理解
されるであろう。本願で使用される見出しは、整理目的のためのみに提供され、明細書ま
たは特許請求の範囲の範囲を制限するために使用されることは意図されていない。本願を
通じて使用されるように、「得る」といった言い方は、強制的な意味合い（即ち、必須の
意味）よりもむしろ、許容的な意味合い（即ち、可能性があるといった意味）で用いられ
る。同様にして、「含む」、「含んでいる」、および、「含み」といった用語は、含むこ
とを意味しているが、これに制限されない。
プロバイダ・ネットワーク等の大規模な分散システムにおいてネットワーク動作を構成
する方法および装置の様々な実施形態を説明する。幾つかの実施形態では、中央化ネット
ワーク構成管理スキームが実施され、それによると、分散システムの帯域幅限界、待ち時
間の管理、および、多数のノード（ホストおよびネットワーク装置等）に対する他のトラ
フィック・シェーピング・パラメータに関する様々なタイプの決定が、一つ以上のネット
ワーク構成サーバー（ＮＣＳ）でなされる。（幾つかの実施形態では、サーバーの主な責
任が様々なトラフィック・カテゴリーに対してそれぞれの帯域幅限界を課すことで分散シ
ステムの構成要素で帯域幅の使用を管理することであるため、ネットワーク構成サーバー
は「帯域幅仲裁サーバー」と称されてもよい）。例えば、トラフィック分類手順またはル
ール、および、トラフィックの様々なカテゴリーに対するネットワーク構成オプションを
含む決定を実施するために使用されるべきメタデータは、ＮＣＳから分散システムのノー
ドへポータブルで解析しやすいフォーマットで送信され得る。分散システムのノードでは
、受信されたメタデータが、例えば、仮想化管理ソフトウェア内のネットワーク管理モジ
ュールによって解釈されることで、ネットワーク・トラフィック・スケジュールのパケッ
トまたは他の単位が生成された或いは受信されたままの状態で分類され、ＢＡＳでなされ
た決定が適用されることでトラフィックの送信がスケジューリングされるおよび／または
制限される。そのため、トラフィック・シェーピングのために使用されるべき論理を生成
する責任（少なくとも幾つかの場合では、様々なソースから取得された重要な入力データ
・セットの分析を必要とする）は、中央化ネットワーク構成サーバーによって扱われても
よく、論理は比較的簡単な制御モジュールによって様々なノードで適用されてもよい。少
なくとも幾つかの実施形態では、所与のノードに送信されるメタデータは、ノードから収
集されるメトリックス、当該ノードで行われるアプリケーションの性質等に基づき、当該
ノード専用にカスタマイズされてもよい。ネットワーク構成管理技術は、幾つかの実施形
態において、分散システムのクライアントが関心のある資源のネットワーク関連のステー
タスの統一或いは統合見解を得ることを可能にする、プログラマチック・インターフェイ
スに対するサポートを含んでもよい。少なくとも幾つかの実施形態では、資源使用インジ
ケータ（例えば、適用可能な帯域幅限界に対する測定された帯域幅の比等）は、ヒートマ
ップまたは他の可視化ツールを用いて表示されてもよい。プログラマチック・インターフ
ェイスは、少なくとも幾つかの実施形態において、クライアントおよび／または管理者が
中央化ネットワーク構成システムに様々なタイプの構成リクエストを要請できるよう実施
されてもよく、その結果、例えば、ＮＣＳで確定され様々なノードに広められた分類関連
のルールおよび／またはネットワーク設定が変化される。少なくとも幾つかの実施形態で
は、クライアントは、サービス・インスタンス等、様々な資源について帯域幅限界（また
は他のタイプの資源使用限界）の軽減をリクエストすることができる。少なくとも幾つか
の実施では、ネットワーク構成スキームの一部或いは全部がウェブサービスとして実施さ
れてもよく、例えば、一つ以上のウェブサービス・プログラマチック・インターフェイス
がネットワーク構成サーバーとの様々なタイプの相互作用についてサポートされ得る。
する方法および装置の様々な実施形態を説明する。幾つかの実施形態では、中央化ネット
ワーク構成管理スキームが実施され、それによると、分散システムの帯域幅限界、待ち時
間の管理、および、多数のノード（ホストおよびネットワーク装置等）に対する他のトラ
フィック・シェーピング・パラメータに関する様々なタイプの決定が、一つ以上のネット
ワーク構成サーバー（ＮＣＳ）でなされる。（幾つかの実施形態では、サーバーの主な責
任が様々なトラフィック・カテゴリーに対してそれぞれの帯域幅限界を課すことで分散シ
ステムの構成要素で帯域幅の使用を管理することであるため、ネットワーク構成サーバー
は「帯域幅仲裁サーバー」と称されてもよい）。例えば、トラフィック分類手順またはル
ール、および、トラフィックの様々なカテゴリーに対するネットワーク構成オプションを
含む決定を実施するために使用されるべきメタデータは、ＮＣＳから分散システムのノー
ドへポータブルで解析しやすいフォーマットで送信され得る。分散システムのノードでは
、受信されたメタデータが、例えば、仮想化管理ソフトウェア内のネットワーク管理モジ
ュールによって解釈されることで、ネットワーク・トラフィック・スケジュールのパケッ
トまたは他の単位が生成された或いは受信されたままの状態で分類され、ＢＡＳでなされ
た決定が適用されることでトラフィックの送信がスケジューリングされるおよび／または
制限される。そのため、トラフィック・シェーピングのために使用されるべき論理を生成
する責任（少なくとも幾つかの場合では、様々なソースから取得された重要な入力データ
・セットの分析を必要とする）は、中央化ネットワーク構成サーバーによって扱われても
よく、論理は比較的簡単な制御モジュールによって様々なノードで適用されてもよい。少
なくとも幾つかの実施形態では、所与のノードに送信されるメタデータは、ノードから収
集されるメトリックス、当該ノードで行われるアプリケーションの性質等に基づき、当該
ノード専用にカスタマイズされてもよい。ネットワーク構成管理技術は、幾つかの実施形
態において、分散システムのクライアントが関心のある資源のネットワーク関連のステー
タスの統一或いは統合見解を得ることを可能にする、プログラマチック・インターフェイ
スに対するサポートを含んでもよい。少なくとも幾つかの実施形態では、資源使用インジ
ケータ（例えば、適用可能な帯域幅限界に対する測定された帯域幅の比等）は、ヒートマ
ップまたは他の可視化ツールを用いて表示されてもよい。プログラマチック・インターフ
ェイスは、少なくとも幾つかの実施形態において、クライアントおよび／または管理者が
中央化ネットワーク構成システムに様々なタイプの構成リクエストを要請できるよう実施
されてもよく、その結果、例えば、ＮＣＳで確定され様々なノードに広められた分類関連
のルールおよび／またはネットワーク設定が変化される。少なくとも幾つかの実施形態で
は、クライアントは、サービス・インスタンス等、様々な資源について帯域幅限界（また
は他のタイプの資源使用限界）の軽減をリクエストすることができる。少なくとも幾つか
の実施では、ネットワーク構成スキームの一部或いは全部がウェブサービスとして実施さ
れてもよく、例えば、一つ以上のウェブサービス・プログラマチック・インターフェイス
がネットワーク構成サーバーとの様々なタイプの相互作用についてサポートされ得る。
以下の説明の大半では、中央化ネットワーク構成技術が実施され得る分散システムの実
施例として、プロバイダ・ネットワークが使用される。クライアントの分散されたセット
にインターネットおよび／または他のネットワークを介してアクセス可能な一つ以上のネ
ットワーク・アクセス可能サービス（例えば、様々なタイプのクラウドベースのデータベ
ース、コンピューティングまたはストレージ・サービス）を提供するよう企業または公共
部門組織等のエンティティによってセットアップされたネットワークは、本願ではプロバ
イダ・ネットワークと称されてもよい。少なくとも幾つかのサービスは、「インスタンス
」と呼ばれるサービス単位でクライアント使用のためにパッケージ化されてもよい。例え
ば、仮想化されたコンピューティング・サービスによってインスタンス化されるバーチャ
ル・マシンは「計算インスタンス」を表し、ストレージ・サービスによってインスタンス
化されるブロックレベルの容積等のストレージ装置は「ストレージ・インスタンス」と呼
ばれる。幾つかの実施形態では、より高いレベルのサービスのインスタンスが計算インス
タンスおよび／またはストレージ・インスタンスを用いてパッケージ化されてもよく、例
えば、幾つかの実施形態では、計算およびストレージ・インスタンスの組み合わせを用い
てデータベース・インスタンスが構築されてもよい。プロバイダ・ネットワークの様々な
ネットワーク・アクセス可能サービスのこのような単位が実施されるサーバーおよび／ま
たはストレージ装置等のコンピューティング装置は、本願では「インスタンス・ホスト」
と呼ばれ、より簡単に「ホスト」と呼ばれる。本文書の残りでは、所与の通信のソース或
いは宛先として使用される場合、「クライアント」といった用語は、プロバイダ・ネット
ワークの少なくとも一つのネットワーク・アクセス可能サービスにアクセスし利用するこ
とができるエンティティ（例えば、組織、多数のユーザを含むグループ、または、単一の
ユーザ）に所有され、管理され、或いは、割り付けられる全てのコンピューティング装置
、プロセス、ハードウェア・モジュール、または、ソフトウェア・モジュールのいずれか
を示す。
施例として、プロバイダ・ネットワークが使用される。クライアントの分散されたセット
にインターネットおよび／または他のネットワークを介してアクセス可能な一つ以上のネ
ットワーク・アクセス可能サービス（例えば、様々なタイプのクラウドベースのデータベ
ース、コンピューティングまたはストレージ・サービス）を提供するよう企業または公共
部門組織等のエンティティによってセットアップされたネットワークは、本願ではプロバ
イダ・ネットワークと称されてもよい。少なくとも幾つかのサービスは、「インスタンス
」と呼ばれるサービス単位でクライアント使用のためにパッケージ化されてもよい。例え
ば、仮想化されたコンピューティング・サービスによってインスタンス化されるバーチャ
ル・マシンは「計算インスタンス」を表し、ストレージ・サービスによってインスタンス
化されるブロックレベルの容積等のストレージ装置は「ストレージ・インスタンス」と呼
ばれる。幾つかの実施形態では、より高いレベルのサービスのインスタンスが計算インス
タンスおよび／またはストレージ・インスタンスを用いてパッケージ化されてもよく、例
えば、幾つかの実施形態では、計算およびストレージ・インスタンスの組み合わせを用い
てデータベース・インスタンスが構築されてもよい。プロバイダ・ネットワークの様々な
ネットワーク・アクセス可能サービスのこのような単位が実施されるサーバーおよび／ま
たはストレージ装置等のコンピューティング装置は、本願では「インスタンス・ホスト」
と呼ばれ、より簡単に「ホスト」と呼ばれる。本文書の残りでは、所与の通信のソース或
いは宛先として使用される場合、「クライアント」といった用語は、プロバイダ・ネット
ワークの少なくとも一つのネットワーク・アクセス可能サービスにアクセスし利用するこ
とができるエンティティ（例えば、組織、多数のユーザを含むグループ、または、単一の
ユーザ）に所有され、管理され、或いは、割り付けられる全てのコンピューティング装置
、プロセス、ハードウェア・モジュール、または、ソフトウェア・モジュールのいずれか
を示す。
所与のプロバイダ・ネットワークは、プロバイダによって提供されるインフラストラク
チャおよびサービスを実施し、構成し、分散するのに必要な物理的および／または仮想化
されたコンピュータ・サーバー、それぞれが一つ以上のストレージ装置を含むストレージ
・サーバー、ネットワーク機器等の集まりを含む様々な資源プールをホストする多数のデ
ータ・センター（異なる地理的領域にわたって分散され得る）を含み得る。幾つかの異な
るハードウェアおよび／またはソフトウェア・コンポーネントは、その幾つかが異なるデ
ータ・センターにおいて、または、異なる地理的領域においてインスタンス化される或い
は実行され、様々な実施形態において各サービスを実施するために集合的に使用されても
よい。クライアントは、クライアント所有の或いはクライアント管理の土地に位置する装
置、または、プロバイダ・ネットワーク外にあるデータ・センターから、および／または
、プロバイダ・ネットワーク内の装置から、プロバイダ・ネットワークで資源およびサー
ビスと相互に作用してもよい。少なくとも幾つかの実施形態では、様々なタイプの計算イ
ンスタンスを提供する仮想化されたコンピューティング・サービスは、プロバイダ・ネッ
トワーク内で実施されてもよく、このような計算インスタンスはクライアントに割り付け
られてもよい。プロバイダ・ネットワークの他のサービスは、このような計算インスタン
スから、並びに、外部の場所からアクセスされ得る。プロバイダ・ネットワークは、本願
記載の帯域幅管理技術の多くが実施され得る一つの模範的な状況として機能するが、これ
らの技術は、例えば、アプリケーションの異なるコンポーネントが時間的に変化する帯域
幅のニーズを持つ大規模な分散アプリケーション環境等、プロバイダ・ネットワークより
も他のタイプの分散システムに適用されてもよいことに注意する。
チャおよびサービスを実施し、構成し、分散するのに必要な物理的および／または仮想化
されたコンピュータ・サーバー、それぞれが一つ以上のストレージ装置を含むストレージ
・サーバー、ネットワーク機器等の集まりを含む様々な資源プールをホストする多数のデ
ータ・センター（異なる地理的領域にわたって分散され得る）を含み得る。幾つかの異な
るハードウェアおよび／またはソフトウェア・コンポーネントは、その幾つかが異なるデ
ータ・センターにおいて、または、異なる地理的領域においてインスタンス化される或い
は実行され、様々な実施形態において各サービスを実施するために集合的に使用されても
よい。クライアントは、クライアント所有の或いはクライアント管理の土地に位置する装
置、または、プロバイダ・ネットワーク外にあるデータ・センターから、および／または
、プロバイダ・ネットワーク内の装置から、プロバイダ・ネットワークで資源およびサー
ビスと相互に作用してもよい。少なくとも幾つかの実施形態では、様々なタイプの計算イ
ンスタンスを提供する仮想化されたコンピューティング・サービスは、プロバイダ・ネッ
トワーク内で実施されてもよく、このような計算インスタンスはクライアントに割り付け
られてもよい。プロバイダ・ネットワークの他のサービスは、このような計算インスタン
スから、並びに、外部の場所からアクセスされ得る。プロバイダ・ネットワークは、本願
記載の帯域幅管理技術の多くが実施され得る一つの模範的な状況として機能するが、これ
らの技術は、例えば、アプリケーションの異なるコンポーネントが時間的に変化する帯域
幅のニーズを持つ大規模な分散アプリケーション環境等、プロバイダ・ネットワークより
も他のタイプの分散システムに適用されてもよいことに注意する。
少なくとも一つの実施形態によると、幾つかのＮＣＳは、プロバイダ・ネットワーク内
の様々な場所でインスタンス化されてもよく、このとき、ＮＣＳの数および分散は、例え
ば、以下に説明する性能および／または利用可能性基準に基づいて確定される。ＮＣＳは
、帯域幅管理の決定を補助するよう、プロバイダ・ネットワークの様々なノードから、例
えば、プロバイダ・ネットワークにおいて実施される様々なタイプのサービスのインスタ
ンス・ホストから、および／または、様々なタイプのネットワーク装置（スイッチ、ルー
ター、ゲートウェイ等）からネットワーク関連のメトリックスを取得するよう構成され得
る。例えば、時間間隔中の所与のホストにおける実際の入来する／出発するネットワーク
・トラフィックに関する情報、時間間隔中にドロップされたパケットの数、現在の帯域幅
限界の実施により送信が遅延されたパケットの数、パケットのサイズ、トラフィックを所
与のノードに或いは所与のノードから生じさせたアプリケーション、トラフィックを開始
させたクライアント、および／または、様々な送信に伴われるエンドポイントのＩＰアド
レスが、様々な実施形態において収集されてもよい。幾つかの実施形態では、他のソース
からの入力が帯域幅管理の決定を行う際に使用されてもよい。例えば、分散型サービス妨
害攻撃（ＤＤＯＳ）等のネットワーク侵入または攻撃を特定するようセキュリティ・サー
ビスが幾つかのプロバイダ・ネットワークで実施されてもよく、潜在的な攻撃に関する警
報は帯域幅限界の変化またはトラフィック・カテゴリーの定義に影響を及ぼし得る。少な
くとも一つの実施形態では、プロバイダ・ネットワークは、例えば、管理および／または
請求目的のために、ＩＰアドレス毎にまたはクライアント毎にネットワーク・トラフィッ
ク・メトリックスを集めるサービスを含んでもよく、このような集める側はＮＣＳに入力
を供給してもよい。幾つかの実施形態では、プロバイダ・ネットワークの一つ以上のネッ
トワーク・アクセス可能サービスのクライアントおよび／または管理者は、例えば、特定
されたインスタンス・ホストまたはネットワーク装置に対する一つ以上の帯域幅管理パラ
メータを無効にするよう、ＮＣＳに帯域幅関連リクエストまたは他の構成リクエストを要
請してもよく、このようなリクエストはＮＣＳで行われる決定にも寄与し得る。
の様々な場所でインスタンス化されてもよく、このとき、ＮＣＳの数および分散は、例え
ば、以下に説明する性能および／または利用可能性基準に基づいて確定される。ＮＣＳは
、帯域幅管理の決定を補助するよう、プロバイダ・ネットワークの様々なノードから、例
えば、プロバイダ・ネットワークにおいて実施される様々なタイプのサービスのインスタ
ンス・ホストから、および／または、様々なタイプのネットワーク装置（スイッチ、ルー
ター、ゲートウェイ等）からネットワーク関連のメトリックスを取得するよう構成され得
る。例えば、時間間隔中の所与のホストにおける実際の入来する／出発するネットワーク
・トラフィックに関する情報、時間間隔中にドロップされたパケットの数、現在の帯域幅
限界の実施により送信が遅延されたパケットの数、パケットのサイズ、トラフィックを所
与のノードに或いは所与のノードから生じさせたアプリケーション、トラフィックを開始
させたクライアント、および／または、様々な送信に伴われるエンドポイントのＩＰアド
レスが、様々な実施形態において収集されてもよい。幾つかの実施形態では、他のソース
からの入力が帯域幅管理の決定を行う際に使用されてもよい。例えば、分散型サービス妨
害攻撃（ＤＤＯＳ）等のネットワーク侵入または攻撃を特定するようセキュリティ・サー
ビスが幾つかのプロバイダ・ネットワークで実施されてもよく、潜在的な攻撃に関する警
報は帯域幅限界の変化またはトラフィック・カテゴリーの定義に影響を及ぼし得る。少な
くとも一つの実施形態では、プロバイダ・ネットワークは、例えば、管理および／または
請求目的のために、ＩＰアドレス毎にまたはクライアント毎にネットワーク・トラフィッ
ク・メトリックスを集めるサービスを含んでもよく、このような集める側はＮＣＳに入力
を供給してもよい。幾つかの実施形態では、プロバイダ・ネットワークの一つ以上のネッ
トワーク・アクセス可能サービスのクライアントおよび／または管理者は、例えば、特定
されたインスタンス・ホストまたはネットワーク装置に対する一つ以上の帯域幅管理パラ
メータを無効にするよう、ＮＣＳに帯域幅関連リクエストまたは他の構成リクエストを要
請してもよく、このようなリクエストはＮＣＳで行われる決定にも寄与し得る。
このような入力に少なくとも部分的に基づき、所与のＮＣＳは、プロバイダ・ネットワ
ークの所与のノードで使用されるべき様々なネットワーク構成オプションおよび／または
手順を確定してもよい。幾つかの場合では、パラメータを確定する際、一つ以上のグロー
バルおよび／またはローカル・ネットワーク管理ポリシーも考慮され得る。一実施形態で
は、カテゴリーそれぞれについて、帯域幅限界、待ち時間の目標または制約等の様々なネ
ットワーク構成オプションと共に、トラフィック・カテゴリーのセットまたは階層が確定
されてもよい。幾つかの実施では、フラットな分類（一つのレベルのみを有する階層に等
しい）が使用されてもよく、他の実施では、異なるレベルのノード間で親子関係を有する
多レベルの階層が使用されてもよい。後続する説明では、本願で使用する「階層」といっ
た用語は、単一レベルのまたはフラットな分類と、親子関係を示す多レベルの分類との両
方を網羅することを意図している。階層に加えて、任意の所与のネットワーク・パケット
（または、データ転送の全ての適当な単位）をカテゴリーの一つに分類するために使用さ
れる手順（例えば、適用されるべき決定ステップまたはルールのシーケンス）が確定され
てもよい。トラフィック・カテゴリーに関する情報、および、トラフィック単位をカテゴ
リーにマッピングするために使用される論理またはルールは、本願では合わせて「トラフ
ィック分類メタデータ」または「分類メタデータ」と呼ばれる。少なくとも幾つかの実施
形態において、所与のホストが別のホストとは異なる組み合わせのサービス・インスタン
スを有し得、所与のホストのサービス・インスタンスで実施されるアプリケーションのネ
ットワーク要件が他のアプリケーション（同じホストにある、または、他のホストにある
）のネットワーク要件と異なり得るため、異なるセットのネットワーク構成パラメータが
異なるホストに適当となり得る。したがって、少なくとも幾つかの実施形態では、分類メ
タデータは少なくとも幾つかのノードについてカスタマイズされてもよく、例えば、イン
スタンス・ホストＩＨ１等、プロバイダ・ネットワークの一つのノードについて生成され
た分類メタデータは、インスタンス・ホストＩＨ２等の異なるノードについて生成された
分類メタデータと異なってもよい。異なるセットのトラフィック・カテゴリーが異なるノ
ードに対して定められてもよく、例えば、異なる帯域幅限界または待ち時間要件が同じト
ラフィック・カテゴリーについて設定されてもよく、或いは、トラフィック単位分類手順
の少なくとも幾つかのステップが異なってもよい。少なくとも幾つかの実施では、スイッ
チ、ルーター、ゲートウェイ、または、ロード・バランサ等の様々なネットワーク装置に
ついて、または、ネットワーク接続ストレージ装置について確定されるネットワーク構成
パラメータは、装置と関連付けられるまたは影響を及ぼされる一組のホストの帯域幅管理
パラメータから少なくとも部分的に導出され、例えば、特定のスイッチが八個のホストへ
の入来／出発トラフィックに使用される場合、トラフィックのあるカテゴリーに対するス
イッチの帯域幅限界は八個のホストの帯域幅限界から導出され得る。
ークの所与のノードで使用されるべき様々なネットワーク構成オプションおよび／または
手順を確定してもよい。幾つかの場合では、パラメータを確定する際、一つ以上のグロー
バルおよび／またはローカル・ネットワーク管理ポリシーも考慮され得る。一実施形態で
は、カテゴリーそれぞれについて、帯域幅限界、待ち時間の目標または制約等の様々なネ
ットワーク構成オプションと共に、トラフィック・カテゴリーのセットまたは階層が確定
されてもよい。幾つかの実施では、フラットな分類（一つのレベルのみを有する階層に等
しい）が使用されてもよく、他の実施では、異なるレベルのノード間で親子関係を有する
多レベルの階層が使用されてもよい。後続する説明では、本願で使用する「階層」といっ
た用語は、単一レベルのまたはフラットな分類と、親子関係を示す多レベルの分類との両
方を網羅することを意図している。階層に加えて、任意の所与のネットワーク・パケット
（または、データ転送の全ての適当な単位）をカテゴリーの一つに分類するために使用さ
れる手順（例えば、適用されるべき決定ステップまたはルールのシーケンス）が確定され
てもよい。トラフィック・カテゴリーに関する情報、および、トラフィック単位をカテゴ
リーにマッピングするために使用される論理またはルールは、本願では合わせて「トラフ
ィック分類メタデータ」または「分類メタデータ」と呼ばれる。少なくとも幾つかの実施
形態において、所与のホストが別のホストとは異なる組み合わせのサービス・インスタン
スを有し得、所与のホストのサービス・インスタンスで実施されるアプリケーションのネ
ットワーク要件が他のアプリケーション（同じホストにある、または、他のホストにある
）のネットワーク要件と異なり得るため、異なるセットのネットワーク構成パラメータが
異なるホストに適当となり得る。したがって、少なくとも幾つかの実施形態では、分類メ
タデータは少なくとも幾つかのノードについてカスタマイズされてもよく、例えば、イン
スタンス・ホストＩＨ１等、プロバイダ・ネットワークの一つのノードについて生成され
た分類メタデータは、インスタンス・ホストＩＨ２等の異なるノードについて生成された
分類メタデータと異なってもよい。異なるセットのトラフィック・カテゴリーが異なるノ
ードに対して定められてもよく、例えば、異なる帯域幅限界または待ち時間要件が同じト
ラフィック・カテゴリーについて設定されてもよく、或いは、トラフィック単位分類手順
の少なくとも幾つかのステップが異なってもよい。少なくとも幾つかの実施では、スイッ
チ、ルーター、ゲートウェイ、または、ロード・バランサ等の様々なネットワーク装置に
ついて、または、ネットワーク接続ストレージ装置について確定されるネットワーク構成
パラメータは、装置と関連付けられるまたは影響を及ぼされる一組のホストの帯域幅管理
パラメータから少なくとも部分的に導出され、例えば、特定のスイッチが八個のホストへ
の入来／出発トラフィックに使用される場合、トラフィックのあるカテゴリーに対するス
イッチの帯域幅限界は八個のホストの帯域幅限界から導出され得る。
所与のノードに対してＮＣＳによって定められるトラフィック・カテゴリーは、異なる
実施形態において様々な特性について互いと異なってもよい。一実施形態では、異なるセ
ットのネットワーク・エンドポイントについて異なるカテゴリーが作成されてもよく、例
えば、トラフィックの宛先（またはソース）のＩＰ（インターネット・プロトコル）アド
レスがトラフィックをカテゴリー化するために使用されてもよい。別の実施形態では、ト
ラフィックが流れる原因となるアプリケーションの種類がトラフィックのカテゴリー化の
ために使用されてもよく、例えば、データベース関連のトラフィックが一つのカテゴリー
に配置され、高性能計算に関連するトラフィックが別のカテゴリーに配置されてもよい。
幾つかの実施形態では、トラフィックが生成される原因となるクライアント、および／ま
たは、クライアントの予算或いはクライアントが到達した契約上の合意の面がトラフィッ
ク・カテゴリーを定めるために使用されてもよい。複数のネットワーク・アクセス可能サ
ービスが分散システムで実施される幾つかの実施形態では、トラフィック・カテゴリーは
サービスに基づいて定められてもよく、該サービスによりトラフィックの特定の単位が生
成される。サービスベースの分類が使用され、所与のパケットが二つ以上のサービスと関
連付けられる場合、例えば、データのパケットがデータベース・サービスのデータベース
・インスタンスの代わりにストレージ・サービスから転送される場合、パケットは様々な
実施形態においてソース・サービス（即ち、送信側）または宛先サービス（受信側）に属
するとして分類されてもよい。少なくとも一つの実施形態では、クライアントは、トラフ
ィック単位を分類するようネットワーク構成サービスによって使用され得る一つ以上の特
性の表示を提供してもよく、例えば、クライアントは、幾つかのセットの計算インスタン
スが少なくとも一時的に最優先インスタンスと識別されるようリクエストを出してもよく
、これらのインスタンスへの或いはこれらのインスタンスからのトラフィックは高帯域幅
限界を有する最優先トラフィックとして相応じて分類されてもよい。
実施形態において様々な特性について互いと異なってもよい。一実施形態では、異なるセ
ットのネットワーク・エンドポイントについて異なるカテゴリーが作成されてもよく、例
えば、トラフィックの宛先（またはソース）のＩＰ（インターネット・プロトコル）アド
レスがトラフィックをカテゴリー化するために使用されてもよい。別の実施形態では、ト
ラフィックが流れる原因となるアプリケーションの種類がトラフィックのカテゴリー化の
ために使用されてもよく、例えば、データベース関連のトラフィックが一つのカテゴリー
に配置され、高性能計算に関連するトラフィックが別のカテゴリーに配置されてもよい。
幾つかの実施形態では、トラフィックが生成される原因となるクライアント、および／ま
たは、クライアントの予算或いはクライアントが到達した契約上の合意の面がトラフィッ
ク・カテゴリーを定めるために使用されてもよい。複数のネットワーク・アクセス可能サ
ービスが分散システムで実施される幾つかの実施形態では、トラフィック・カテゴリーは
サービスに基づいて定められてもよく、該サービスによりトラフィックの特定の単位が生
成される。サービスベースの分類が使用され、所与のパケットが二つ以上のサービスと関
連付けられる場合、例えば、データのパケットがデータベース・サービスのデータベース
・インスタンスの代わりにストレージ・サービスから転送される場合、パケットは様々な
実施形態においてソース・サービス（即ち、送信側）または宛先サービス（受信側）に属
するとして分類されてもよい。少なくとも一つの実施形態では、クライアントは、トラフ
ィック単位を分類するようネットワーク構成サービスによって使用され得る一つ以上の特
性の表示を提供してもよく、例えば、クライアントは、幾つかのセットの計算インスタン
スが少なくとも一時的に最優先インスタンスと識別されるようリクエストを出してもよく
、これらのインスタンスへの或いはこれらのインスタンスからのトラフィックは高帯域幅
限界を有する最優先トラフィックとして相応じて分類されてもよい。
幾つかの実施形態では、ＮＣＳは所与のプロバイダ・ネットワークのノードについてト
ラフィック・カテゴリーをモデル化する或いは表すようツリーまたは同様の階層型データ
構造を使用してもよく、このとき、それぞれの帯域幅限界および／または他のネットワー
ク構成オプションはツリーの各ノードに割り当てられる。少なくとも幾つかの実施では、
帯域幅総和ポリシーが分類ツリーに適用されてもよい。このようなポリシーによると、ツ
リーにおける子ノードＣ１、Ｃ２、．．．Ｃｋを有する所与の親ノードＰがＸビット／秒
の帯域幅限界を有する場合、所与の時間期間中に子ノードＣ１、Ｃ２、．．．Ｃｋと関連
付けられる実際のトラフィックの総和は親の帯域幅限界を超えてはならない。Ｐの帯域幅
限界が出発トラフィックについて１Ｇビット／秒に設定され、Ｐが二つの子ノードＣ１お
よびＣ２を有する実施例を考慮すると、その帯域幅限界それぞれも出発トラフィックにつ
いて１Ｇビット／秒に設定される。所与の１秒にわたって、Ｃ１トラフィックとして分類
される０．６Ｇビットのトラフィックがあるインスタンスから流れると、Ｃ２に対して定
められる個々の限界はより高いが、Ｃ２トラフィックとして分類されるわずか０．４Ｇビ
ットのトラフィックだけが許可される。親子関係に基づく総和ポリシーは、当然のことな
がら、待ち時間の制約または目標、サービス品質の目標、パケット・フラグメンテーショ
ン設定、または、パケット・サイズについて少なくとも部分的に確定される設定等、ＮＣ
Ｓによって確定される幾つかのタイプのネットワーク構成オプションに対しては、様々な
実施形態において、関連がない或いは有用でない。
ラフィック・カテゴリーをモデル化する或いは表すようツリーまたは同様の階層型データ
構造を使用してもよく、このとき、それぞれの帯域幅限界および／または他のネットワー
ク構成オプションはツリーの各ノードに割り当てられる。少なくとも幾つかの実施では、
帯域幅総和ポリシーが分類ツリーに適用されてもよい。このようなポリシーによると、ツ
リーにおける子ノードＣ１、Ｃ２、．．．Ｃｋを有する所与の親ノードＰがＸビット／秒
の帯域幅限界を有する場合、所与の時間期間中に子ノードＣ１、Ｃ２、．．．Ｃｋと関連
付けられる実際のトラフィックの総和は親の帯域幅限界を超えてはならない。Ｐの帯域幅
限界が出発トラフィックについて１Ｇビット／秒に設定され、Ｐが二つの子ノードＣ１お
よびＣ２を有する実施例を考慮すると、その帯域幅限界それぞれも出発トラフィックにつ
いて１Ｇビット／秒に設定される。所与の１秒にわたって、Ｃ１トラフィックとして分類
される０．６Ｇビットのトラフィックがあるインスタンスから流れると、Ｃ２に対して定
められる個々の限界はより高いが、Ｃ２トラフィックとして分類されるわずか０．４Ｇビ
ットのトラフィックだけが許可される。親子関係に基づく総和ポリシーは、当然のことな
がら、待ち時間の制約または目標、サービス品質の目標、パケット・フラグメンテーショ
ン設定、または、パケット・サイズについて少なくとも部分的に確定される設定等、ＮＣ
Ｓによって確定される幾つかのタイプのネットワーク構成オプションに対しては、様々な
実施形態において、関連がない或いは有用でない。
トラフィック・カテゴリーのセットを表すためにツリーまたはツリーのような構造を用
いることに加えて、幾つかの実施形態では、ＮＣＳは第二のデータ構造を生成してトラフ
ィック単位をカテゴリーに分類するために使用されるべき手順をモデル化してもよい。分
類手順グラフとも呼ばれる第二のデータ構造は、幾つかの実施では決定ノードのシーケン
スを一つ以上含んでもよく、所与のシーケンスの連続するノードそれぞれはトラフィック
単位をより狭いカテゴリーに分類するために使用されるべき一つ以上の基準を示す。少な
くとも一つの実施では、分類手順グラフのうちの幾つかの決定ノードは、多数のカテゴリ
ーの選択肢の中から一つのカテゴリーを選択するために使用され得るルックアップ・テー
ブル（例えば、ハッシュ・テーブル）を含んでもよい。ルックアップ・テーブルのエント
リーは、分類されるべきネットワーク・トラフィック単位の一つ以上の特性に基づいてイ
ンデックスを付けられてもよく、例えば、宛先またはソースＩＰアドレスの一部または全
部がインデックス付けに使用されてもよく、或いは、別のパケットのヘッダ・フィールド
の一部分またはパケットのボディのコンテンツさえもがテーブル中の特定のエントリーを
調べるために使用されてもよい。少なくとも幾つかの実施形態では、ルックアップ・テー
ブルのエントリーは、別の分類手順グラフまたはサブグラフをもたらす。そのため、この
ような実施では、パケットの所与の特性が、最初に、幾つかの可能なルックアップ・テー
ブルのエントリーの中からのルックアップ・テーブルのエントリーの選択を生じ、続いて
、選択されたルックアップ・テーブルのエントリーの処理が別のセットの決定ノード（こ
れらノード自体が他のルックアップ・テーブルを含む）のトラバースをもたらし、最終的
に、パケットのカテゴリーが識別される。様々な実施形態においてこのような手順のステ
ップを用いて、比較的詳細な細かいカテゴリー・マッピングがネットワーク・パケットお
よび／または他のトラフィック単位に対して定められ得、それにより、高度なトラフィッ
ク・シェーピングが可能となる。少なくとも幾つかの実施において、異なる分類階層およ
び／または手順が入来するおよび出発するトラフィックに対して生成されてもよい。
いることに加えて、幾つかの実施形態では、ＮＣＳは第二のデータ構造を生成してトラフ
ィック単位をカテゴリーに分類するために使用されるべき手順をモデル化してもよい。分
類手順グラフとも呼ばれる第二のデータ構造は、幾つかの実施では決定ノードのシーケン
スを一つ以上含んでもよく、所与のシーケンスの連続するノードそれぞれはトラフィック
単位をより狭いカテゴリーに分類するために使用されるべき一つ以上の基準を示す。少な
くとも一つの実施では、分類手順グラフのうちの幾つかの決定ノードは、多数のカテゴリ
ーの選択肢の中から一つのカテゴリーを選択するために使用され得るルックアップ・テー
ブル（例えば、ハッシュ・テーブル）を含んでもよい。ルックアップ・テーブルのエント
リーは、分類されるべきネットワーク・トラフィック単位の一つ以上の特性に基づいてイ
ンデックスを付けられてもよく、例えば、宛先またはソースＩＰアドレスの一部または全
部がインデックス付けに使用されてもよく、或いは、別のパケットのヘッダ・フィールド
の一部分またはパケットのボディのコンテンツさえもがテーブル中の特定のエントリーを
調べるために使用されてもよい。少なくとも幾つかの実施形態では、ルックアップ・テー
ブルのエントリーは、別の分類手順グラフまたはサブグラフをもたらす。そのため、この
ような実施では、パケットの所与の特性が、最初に、幾つかの可能なルックアップ・テー
ブルのエントリーの中からのルックアップ・テーブルのエントリーの選択を生じ、続いて
、選択されたルックアップ・テーブルのエントリーの処理が別のセットの決定ノード（こ
れらノード自体が他のルックアップ・テーブルを含む）のトラバースをもたらし、最終的
に、パケットのカテゴリーが識別される。様々な実施形態においてこのような手順のステ
ップを用いて、比較的詳細な細かいカテゴリー・マッピングがネットワーク・パケットお
よび／または他のトラフィック単位に対して定められ得、それにより、高度なトラフィッ
ク・シェーピングが可能となる。少なくとも幾つかの実施において、異なる分類階層およ
び／または手順が入来するおよび出発するトラフィックに対して生成されてもよい。
関連するネットワーク構成オプションを含むトラフィック・カテゴリーのセットと、ネ
ットワーク・トラフィック単位をカテゴリーにマッピングするための論理を有するメタデ
ータを生成した後、幾つかの実施形態では、ＮＣＳはメタデータが適用されるべきノード
への送信のためにメタデータのポータブル表現を生成してもよい。例えば、様々な実施で
は、メタデータの一つの或いは両方のコンポーネントがＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ
（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ），ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍ
ａｒｋｕｐ Ｌａｎｇｕａｇｅ），ＹＡＭＬ（頭字語が“Ｙｅｔ Ａｎｏｔｈｅｒ Ｍａ
ｒｋｕｐ Ｌａｎｇｕａｇｅ”または“ＹＡＭＬ Ａｉｎ’ｔ Ｍａｒｋｕｐ Ｌａｎｇ
ｕａｇｅ”等の幾つかの可能な拡張子を有するシリアル化フォーマット）等の業界標準プ
ロトコルまたは言語に従って符号化されてもよい。他の実施では、独占的符号化技術また
はプロトコルを使用してデータ構造のポータブル・バージョンを生成してもよい。
ットワーク・トラフィック単位をカテゴリーにマッピングするための論理を有するメタデ
ータを生成した後、幾つかの実施形態では、ＮＣＳはメタデータが適用されるべきノード
への送信のためにメタデータのポータブル表現を生成してもよい。例えば、様々な実施で
は、メタデータの一つの或いは両方のコンポーネントがＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ
（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ），ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍ
ａｒｋｕｐ Ｌａｎｇｕａｇｅ），ＹＡＭＬ（頭字語が“Ｙｅｔ Ａｎｏｔｈｅｒ Ｍａ
ｒｋｕｐ Ｌａｎｇｕａｇｅ”または“ＹＡＭＬ Ａｉｎ’ｔ Ｍａｒｋｕｐ Ｌａｎｇ
ｕａｇｅ”等の幾つかの可能な拡張子を有するシリアル化フォーマット）等の業界標準プ
ロトコルまたは言語に従って符号化されてもよい。他の実施では、独占的符号化技術また
はプロトコルを使用してデータ構造のポータブル・バージョンを生成してもよい。
ポータブル表現は、プロバイダ・ネットワークまたは分散システムのターゲット・ノー
ド、例えば、表現を解析して手順グラフによって示される手順を実施する、ネットワーク
管理モジュールのような制御／管理モジュールに送信されてもよい。受信したメタデータ
を用いて、その後様々なトラフィック単位がターゲット・ノードで適当なカテゴリーに分
類され、様々なネットワーク送信はそれぞれのトラフィック・カテゴリーについて示され
る帯域幅限界または待ち時間要件等のネットワーク構成オプションに応じてスケジューリ
ングされるおよび／または制限されるまたは遅延されてもよい。このような送信中に収集
されるメトリックスはＮＣＳにフィードバックされ、その後の時間期間にわたるメタデー
タの改善を可能にする。そのため、ＮＣＳと、ＮＣＳで成される決定が最終的に実施され
るノードとの間でフィードバック・ループが確立されてもよく、それにより、時間をかけ
てネットワーク管理パラメータを動態的調整することが可能となる。このようなカスタマ
イズ可能なトラフィック分類および構成技術を用いることで、様々な実施形態において、
中央化ネットワーク構成システムはプロバイダ・ネットワークの様々な部分におけるトラ
フィックを任意の所望のレベルの粒度に制御しシェーピングすることが可能となる。
ド、例えば、表現を解析して手順グラフによって示される手順を実施する、ネットワーク
管理モジュールのような制御／管理モジュールに送信されてもよい。受信したメタデータ
を用いて、その後様々なトラフィック単位がターゲット・ノードで適当なカテゴリーに分
類され、様々なネットワーク送信はそれぞれのトラフィック・カテゴリーについて示され
る帯域幅限界または待ち時間要件等のネットワーク構成オプションに応じてスケジューリ
ングされるおよび／または制限されるまたは遅延されてもよい。このような送信中に収集
されるメトリックスはＮＣＳにフィードバックされ、その後の時間期間にわたるメタデー
タの改善を可能にする。そのため、ＮＣＳと、ＮＣＳで成される決定が最終的に実施され
るノードとの間でフィードバック・ループが確立されてもよく、それにより、時間をかけ
てネットワーク管理パラメータを動態的調整することが可能となる。このようなカスタマ
イズ可能なトラフィック分類および構成技術を用いることで、様々な実施形態において、
中央化ネットワーク構成システムはプロバイダ・ネットワークの様々な部分におけるトラ
フィックを任意の所望のレベルの粒度に制御しシェーピングすることが可能となる。
異なる実施形態において、様々なアプローチ法がターゲット・ノードへの分類メタデー
タの分散に使用されてもよい。例えば、一実施形態では、ＮＣＳは、ＮＣＳが割り当てら
れたホストおよび／またはネットワーク装置それぞれに分類メタデータを周期的に（例え
ば、少なくともＸ分に一回）「プッシュ」するよう構成されてもよい。幾つかの実施形態
において、様々なタイプのトリガとなるイベント（潜在的なネットワーク侵入または攻撃
の検出等）は、新しい分類メタデータの普及につながる。例えば、以下により詳細に説明
するように、攻撃の影響を緩和または制限する試みとして、幾つかのセットのノードにお
ける帯域幅限界が低下されるか、低帯域幅限界を有する新しいカテゴリーが定められても
よい。別の実施形態では、例えば、ＮＣＳにメタデータ・リクエストを送信し、それに応
答してメタデータを受信することで、プロバイダ・ネットワークの少なくとも幾つかのノ
ードは、割り当てられたＮＣＳからトラフィック分類メタデータを「プル」してもよい。
幾つかの実施形態では、スケジュール化されたプッシュ技術、メタデータのトリガとなる
イベントに基づく分散、および／または、ノードで開始されるプル技術の組み合わせが使
用されてもよい。
タの分散に使用されてもよい。例えば、一実施形態では、ＮＣＳは、ＮＣＳが割り当てら
れたホストおよび／またはネットワーク装置それぞれに分類メタデータを周期的に（例え
ば、少なくともＸ分に一回）「プッシュ」するよう構成されてもよい。幾つかの実施形態
において、様々なタイプのトリガとなるイベント（潜在的なネットワーク侵入または攻撃
の検出等）は、新しい分類メタデータの普及につながる。例えば、以下により詳細に説明
するように、攻撃の影響を緩和または制限する試みとして、幾つかのセットのノードにお
ける帯域幅限界が低下されるか、低帯域幅限界を有する新しいカテゴリーが定められても
よい。別の実施形態では、例えば、ＮＣＳにメタデータ・リクエストを送信し、それに応
答してメタデータを受信することで、プロバイダ・ネットワークの少なくとも幾つかのノ
ードは、割り当てられたＮＣＳからトラフィック分類メタデータを「プル」してもよい。
幾つかの実施形態では、スケジュール化されたプッシュ技術、メタデータのトリガとなる
イベントに基づく分散、および／または、ノードで開始されるプル技術の組み合わせが使
用されてもよい。
幾つかの実施形態では、プロバイダ・ネットワークまたは他の分散システムは、複数の
地理的領域に整理されてもよく、各領域は、本願では「利用可能ゾーン」とも称される一
つ以上の利用可能コンテナを含んでもよい。利用可能コンテナは、所与の利用可能コンテ
ナにおける資源が他の利用可能コンテナにおける故障と隔離されるように操作される一つ
以上の別個の場所またはデータ・センターを有してもよい。つまり、一つの利用可能コン
テナにおける故障は、任意の他の利用可能コンテナにおける故障と時間的に或いは因果的
に相互に関係することが予想されないため、資源インスタンスまたは制御サーバーの利用
可能プロフィールは異なる利用可能コンテナにおける資源インスタンスまたは制御サーバ
ーの利用可能プロフィールと独立していることが意図される。クライアントは、それぞれ
の利用可能コンテナにおいて多数のアプリケーション・インスタンスを立ち上げることで
単一の場所で故障からそれぞれのアプリケーションを保護することができる。同時に、幾
つかの実施では、同じ地理的領域内にある資源インスタンス間に安価で低待ち時間のネッ
トワーク接続が提供される（同じ利用可能コンテナの資源間のネットワーク送信はより速
くなる）。ネットワーク構成システムについて所望のレベルの利用可能性および／または
性能を実現するために、幾つかの実施形態では、少なくとも一つのネットワーク構成サー
バーが各利用可能ゾーンでセットアップされてもよい。幾つかの実施形態では、少なくと
も一つのＮＣＳが各データ・センター内に確立されてもよい。幾つかの実施形態では、所
与の領域、利用可能コンテナ、または、データ・センター内にセットアップされるべきＮ
ＣＳの数は、性能要件に少なくとも部分的に基づいて確定されてもよく、例えば、変更さ
れた帯域幅限界を生成し、変更された限界を適当なセットのノードで適用することで、ネ
ットワーク構成システムがどれだけ早くネットワーク攻撃または他のトリガとなるイベン
トに反応することができるかに基づいて確定されてもよい。
地理的領域に整理されてもよく、各領域は、本願では「利用可能ゾーン」とも称される一
つ以上の利用可能コンテナを含んでもよい。利用可能コンテナは、所与の利用可能コンテ
ナにおける資源が他の利用可能コンテナにおける故障と隔離されるように操作される一つ
以上の別個の場所またはデータ・センターを有してもよい。つまり、一つの利用可能コン
テナにおける故障は、任意の他の利用可能コンテナにおける故障と時間的に或いは因果的
に相互に関係することが予想されないため、資源インスタンスまたは制御サーバーの利用
可能プロフィールは異なる利用可能コンテナにおける資源インスタンスまたは制御サーバ
ーの利用可能プロフィールと独立していることが意図される。クライアントは、それぞれ
の利用可能コンテナにおいて多数のアプリケーション・インスタンスを立ち上げることで
単一の場所で故障からそれぞれのアプリケーションを保護することができる。同時に、幾
つかの実施では、同じ地理的領域内にある資源インスタンス間に安価で低待ち時間のネッ
トワーク接続が提供される（同じ利用可能コンテナの資源間のネットワーク送信はより速
くなる）。ネットワーク構成システムについて所望のレベルの利用可能性および／または
性能を実現するために、幾つかの実施形態では、少なくとも一つのネットワーク構成サー
バーが各利用可能ゾーンでセットアップされてもよい。幾つかの実施形態では、少なくと
も一つのＮＣＳが各データ・センター内に確立されてもよい。幾つかの実施形態では、所
与の領域、利用可能コンテナ、または、データ・センター内にセットアップされるべきＮ
ＣＳの数は、性能要件に少なくとも部分的に基づいて確定されてもよく、例えば、変更さ
れた帯域幅限界を生成し、変更された限界を適当なセットのノードで適用することで、ネ
ットワーク構成システムがどれだけ早くネットワーク攻撃または他のトリガとなるイベン
トに反応することができるかに基づいて確定されてもよい。
一実施形態によると、一つ以上のプログラマチック・インターフェイス（例えば、ＡＰ
Ｉ（アプリケーション・プログラミング・インターフェイス）、ウェブページ、コマンド
・ライン・ツール、グラフィカル・ユーザ・インターフェイス等）は、プロバイダ・ネッ
トワークのクライアントおよび／または他のサービスによる使用のためにネットワーク構
成システムによって実施されてもよい。このような実施形態の一つでは、前述の通り、様
々なサービスのクライアントまたは管理者は、特定のサービス・インスタンスまたはホス
トについてネットワーク構成オプションを設定または変更するよう帯域幅無効リクエスト
等の構成リクエストを要請してもよい。幾つかのクライアントは、例えば、少なくとも幾
らかの時間間隔にわたって少なくとも幾つかのアプリケーションについて帯域幅限界を増
加（または低減）させることを望む場合がある。幾つかの実施形態では、多数のサービス
・インスタンス（数百または数千の計算インスタンス、ストレージ・インスタンス、デー
タベース・インスタンス等）が所与のクライアントに割り付けられ、クライアントがその
サービス・インスタンスのサブセットのネットワーク・ステータス（適用可能な帯域幅限
界、待ち時間設定等を含む）の最新の統合ビューを得ることを望む場合がある。幾つかの
実施形態では、例えば、プロバイダ・ネットワークのコンソール・サービスによって、或
いは、幾つかの他の統合ネットワーク・ビュー生成部によって統一されたビューを提供す
るために、ネットワーク構成サービスのプログラマチック・インターフェイスが使用され
てもよい。プログラマチック・インターフェイスは、幾つかの実施形態では、新しいサー
ビス・インスタンスが立ち上げられるインスタンス・ホストを識別する責任を担うインス
タンス配置サービス等の他のサービスによって使用されてもよい。特定のインスタンス・
ホストを新しいサービス・インスタンスに対する候補として考えた場合、配置サービスは
、候補における最近の帯域幅使用傾向、ネットワーク送信が最近制限された数、および／
または、当該インスタンス・ホストに対する現在確立されているネットワーク帯域幅限界
または待ち時間設定等、プログラマチック・インターフェイス上で用いるネットワーク構
成サービスから情報を取得し、この情報を用いて新しいサービス・インスタンスの配置を
確定してもよい。
模範的なシステム環境
Ｉ（アプリケーション・プログラミング・インターフェイス）、ウェブページ、コマンド
・ライン・ツール、グラフィカル・ユーザ・インターフェイス等）は、プロバイダ・ネッ
トワークのクライアントおよび／または他のサービスによる使用のためにネットワーク構
成システムによって実施されてもよい。このような実施形態の一つでは、前述の通り、様
々なサービスのクライアントまたは管理者は、特定のサービス・インスタンスまたはホス
トについてネットワーク構成オプションを設定または変更するよう帯域幅無効リクエスト
等の構成リクエストを要請してもよい。幾つかのクライアントは、例えば、少なくとも幾
らかの時間間隔にわたって少なくとも幾つかのアプリケーションについて帯域幅限界を増
加（または低減）させることを望む場合がある。幾つかの実施形態では、多数のサービス
・インスタンス（数百または数千の計算インスタンス、ストレージ・インスタンス、デー
タベース・インスタンス等）が所与のクライアントに割り付けられ、クライアントがその
サービス・インスタンスのサブセットのネットワーク・ステータス（適用可能な帯域幅限
界、待ち時間設定等を含む）の最新の統合ビューを得ることを望む場合がある。幾つかの
実施形態では、例えば、プロバイダ・ネットワークのコンソール・サービスによって、或
いは、幾つかの他の統合ネットワーク・ビュー生成部によって統一されたビューを提供す
るために、ネットワーク構成サービスのプログラマチック・インターフェイスが使用され
てもよい。プログラマチック・インターフェイスは、幾つかの実施形態では、新しいサー
ビス・インスタンスが立ち上げられるインスタンス・ホストを識別する責任を担うインス
タンス配置サービス等の他のサービスによって使用されてもよい。特定のインスタンス・
ホストを新しいサービス・インスタンスに対する候補として考えた場合、配置サービスは
、候補における最近の帯域幅使用傾向、ネットワーク送信が最近制限された数、および／
または、当該インスタンス・ホストに対する現在確立されているネットワーク帯域幅限界
または待ち時間設定等、プログラマチック・インターフェイス上で用いるネットワーク構
成サービスから情報を取得し、この情報を用いて新しいサービス・インスタンスの配置を
確定してもよい。
模範的なシステム環境
図１は、少なくとも幾つかの実施形態による、中央化ネットワーク構成サービスが分散
コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理する
よう実施されるシステム１００の実施例を例示する。図示するように、ＮＣＳ１８０Ａや
ＮＣＳ１８０Ｂのようなネットワーク構成サーバー１８０のプール１８２が確立されても
よい。幾つかの実施形態において、図２に例示し、以下に説明するように、ＮＣＳ１８０
は、コンピューティング環境の様々なデータ・センターの間で分散されてもよい。所与の
ＮＣＳ１８０は、例えば、異なる実施形態において一つ以上のソフトウェアおよび／また
はハードウェア・モジュールを有し、幾つかのケースでは自身が複数のコンピューティン
グ装置を用いて実施されてもよい。ＮＣＳ１８０は、幾つかの異なるタイプのソースから
入力を受信するよう構成され得る。分散コンピューティング環境の様々な要素において適
用されるべき帯域幅限界等のカスタマイズ可能なトラフィック分類論理やネットワーク構
成オプションは、図示する実施形態において、入力に基づいておよび／またはグローバル
・ネットワーク管理ポリシー１２２を考慮してＮＣＳによって確定されてもよい。ネット
ワーク構成サービスの視点からすると、分散コンピューティング環境の要素は、測定関連
コンポーネント１０７、決定コンポーネント１０８、および、実施コンポーネント１０９
といった三つの高レベルなカテゴリーに分類されてもよい。測定関連コンポーネント１０
７はＮＣＳに対する様々な入力ソースを有し、決定コンポーネント１０８はＮＣＳ自体を
有し、実施コンポーネント１０９はネットワーク・トラフィックをシェーピングするため
に決定が実行される、または、決定コンポーネントによって生成された出力が他の目的の
ために利用されるエンティティを表す。古典的な制御システム・フィードバック・ループ
のようなフィードバック・ループは、実施コンポーネント（例えば、サービス・インスタ
ンス・ホスト１４４および／またはネットワーク装置１４５）の幾つかから測定結果を得
て、これらのメトリックスを用いてＮＣＳ１８０による後続の決定を確定することで確立
されてもよく、ＮＣＳは実施されると将来的な決定に影響を与える追加的な測定につなが
る。
コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理する
よう実施されるシステム１００の実施例を例示する。図示するように、ＮＣＳ１８０Ａや
ＮＣＳ１８０Ｂのようなネットワーク構成サーバー１８０のプール１８２が確立されても
よい。幾つかの実施形態において、図２に例示し、以下に説明するように、ＮＣＳ１８０
は、コンピューティング環境の様々なデータ・センターの間で分散されてもよい。所与の
ＮＣＳ１８０は、例えば、異なる実施形態において一つ以上のソフトウェアおよび／また
はハードウェア・モジュールを有し、幾つかのケースでは自身が複数のコンピューティン
グ装置を用いて実施されてもよい。ＮＣＳ１８０は、幾つかの異なるタイプのソースから
入力を受信するよう構成され得る。分散コンピューティング環境の様々な要素において適
用されるべき帯域幅限界等のカスタマイズ可能なトラフィック分類論理やネットワーク構
成オプションは、図示する実施形態において、入力に基づいておよび／またはグローバル
・ネットワーク管理ポリシー１２２を考慮してＮＣＳによって確定されてもよい。ネット
ワーク構成サービスの視点からすると、分散コンピューティング環境の要素は、測定関連
コンポーネント１０７、決定コンポーネント１０８、および、実施コンポーネント１０９
といった三つの高レベルなカテゴリーに分類されてもよい。測定関連コンポーネント１０
７はＮＣＳに対する様々な入力ソースを有し、決定コンポーネント１０８はＮＣＳ自体を
有し、実施コンポーネント１０９はネットワーク・トラフィックをシェーピングするため
に決定が実行される、または、決定コンポーネントによって生成された出力が他の目的の
ために利用されるエンティティを表す。古典的な制御システム・フィードバック・ループ
のようなフィードバック・ループは、実施コンポーネント（例えば、サービス・インスタ
ンス・ホスト１４４および／またはネットワーク装置１４５）の幾つかから測定結果を得
て、これらのメトリックスを用いてＮＣＳ１８０による後続の決定を確定することで確立
されてもよく、ＮＣＳは実施されると将来的な決定に影響を与える追加的な測定につなが
る。
幾つかのタイプのネットワーク関連のメトリックスは、例えば、メトリックス・コレク
タ１２５によってインスタンス・ホスト１４４および／またはネットワーク装置１４５か
ら集められ、図示する実施形態において、ＮＣＳ１８０によってアクセス可能なメトリッ
クス・データベース１９０に配置されてもよい。例えば、このようなメトリックスは、時
間間隔（例えば、バイトまたはパケットで表現される）中の所与のホストにおける入来す
る／出発するネットワーク・トラフィック率、ＴＣＰ（通信制御プロトコル）またはＵＤ
Ｐ（ユーザ・データグラム・プロトコル）のような様々なプロトコルに対応するネットワ
ーク接続の数、時間間隔中にドロップされたパケットの数やパケットがドロップされた原
因、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズの
分散、所与のノードに或いは所与のノードからトラフィックを生じさせたアプリケーショ
ン、トラフィックを開始させたクライアント、パケット・デリバリーと関連付けられる待
ち時間、および／または、様々な送信に伴われるエンドポントのＩＰアドレスを含んでも
よい。データベース１９０に記憶されるメトリックスに加えて、ＮＣＳは、セキュリティ
・サービス１１１またはトラフィック・メトリック集合部１１２のようなシステム１００
の追加的な入力データ・ソース１１０から入力を受信してもよい。セキュリティ・サービ
ス１１１は、ネットワーク侵入または攻撃（その幾つかはシステム１００の外部で生ずる
、例えば、公衆インターネットの様々な場所から生じ、他は幾つかのインスタンス・ホス
ト１４４自体で生ずる）を検出するよう、システム１００の様々な部分でトラフィック・
パターンを監視するよう構成されてもよい。不審なトラフィック・パターンが検出された
場合、例えば、所与のネットワーク・アドレスに方向付けられた高トラフィックの急激且
つ持続したバーストがあると、セキュリティ・サービス１１１はＮＣＳ１８０に通知する
。これは緩和作用を伴い得る。例えば、ＮＣＳ１８０は、新しいネットワーク・カテゴリ
ーおよび適用されるべき対応する帯域幅限界を生成する、または、既存のカテゴリーの帯
域幅限界を変更し、新しく変更されたまたは生成された分類メタデータを適当なホストに
送信して潜在的なセキュリティ・イベントの影響を制限してもよい。トラフィック・メト
リック集合部１１２は、コレクタ１２５から送信されるメトリックスをバケット、例えば
、ＩＰアドレス毎のバケットまたはクライアント毎のバケットに組み合わせてもよく、バ
ケットの表現はネットワーク構成の決定を行う際に考慮されるようＮＣＳに利用され得る
。
タ１２５によってインスタンス・ホスト１４４および／またはネットワーク装置１４５か
ら集められ、図示する実施形態において、ＮＣＳ１８０によってアクセス可能なメトリッ
クス・データベース１９０に配置されてもよい。例えば、このようなメトリックスは、時
間間隔（例えば、バイトまたはパケットで表現される）中の所与のホストにおける入来す
る／出発するネットワーク・トラフィック率、ＴＣＰ（通信制御プロトコル）またはＵＤ
Ｐ（ユーザ・データグラム・プロトコル）のような様々なプロトコルに対応するネットワ
ーク接続の数、時間間隔中にドロップされたパケットの数やパケットがドロップされた原
因、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズの
分散、所与のノードに或いは所与のノードからトラフィックを生じさせたアプリケーショ
ン、トラフィックを開始させたクライアント、パケット・デリバリーと関連付けられる待
ち時間、および／または、様々な送信に伴われるエンドポントのＩＰアドレスを含んでも
よい。データベース１９０に記憶されるメトリックスに加えて、ＮＣＳは、セキュリティ
・サービス１１１またはトラフィック・メトリック集合部１１２のようなシステム１００
の追加的な入力データ・ソース１１０から入力を受信してもよい。セキュリティ・サービ
ス１１１は、ネットワーク侵入または攻撃（その幾つかはシステム１００の外部で生ずる
、例えば、公衆インターネットの様々な場所から生じ、他は幾つかのインスタンス・ホス
ト１４４自体で生ずる）を検出するよう、システム１００の様々な部分でトラフィック・
パターンを監視するよう構成されてもよい。不審なトラフィック・パターンが検出された
場合、例えば、所与のネットワーク・アドレスに方向付けられた高トラフィックの急激且
つ持続したバーストがあると、セキュリティ・サービス１１１はＮＣＳ１８０に通知する
。これは緩和作用を伴い得る。例えば、ＮＣＳ１８０は、新しいネットワーク・カテゴリ
ーおよび適用されるべき対応する帯域幅限界を生成する、または、既存のカテゴリーの帯
域幅限界を変更し、新しく変更されたまたは生成された分類メタデータを適当なホストに
送信して潜在的なセキュリティ・イベントの影響を制限してもよい。トラフィック・メト
リック集合部１１２は、コレクタ１２５から送信されるメトリックスをバケット、例えば
、ＩＰアドレス毎のバケットまたはクライアント毎のバケットに組み合わせてもよく、バ
ケットの表現はネットワーク構成の決定を行う際に考慮されるようＮＣＳに利用され得る
。
図１に示す実施形態では、クライアント無効リクエスト１３０および／または管理者無
効リクエスト１３１もＮＣＳ１８０による決定において役割を担う。例えば、ＮＣＳ１８
０は、グローバル・ポリシー１２２および他のメトリックスに基づき、インスタンス・ホ
スト１４４におけるトラフィックの所与のカテゴリーＣ１に対する帯域幅限界が考慮され
る次の時間間隔について２Ｇビット／秒に設定されるべきと確定し得る。しかしながら、
計算インスタンスがたまたま当該インスタンス・ホストにおいてインスタンス化されるク
ライアントは、当該計算インスタンスに対して５Ｇビット／秒の帯域幅をリクエストする
、または、当該インスタンス・ホストにおいて実施されるサービスの管理者は１Ｇビット
／秒に帯域幅を制限するようリクエストする。このようなリクエストは、図示する実施形
態において他の要因を無効にするためにＮＣＳによって使用されてもよい。クライアント
が、発生したトラフィックの量に比例してネットワーク・トラフィックに対する金額が請
求される実施形態では、幾つかのクライアントはコストを制御するために帯域幅使用に上
限を課すことを望む場合がある。このような上限も無効リクエスト１３０の実施例を表し
得る。
効リクエスト１３１もＮＣＳ１８０による決定において役割を担う。例えば、ＮＣＳ１８
０は、グローバル・ポリシー１２２および他のメトリックスに基づき、インスタンス・ホ
スト１４４におけるトラフィックの所与のカテゴリーＣ１に対する帯域幅限界が考慮され
る次の時間間隔について２Ｇビット／秒に設定されるべきと確定し得る。しかしながら、
計算インスタンスがたまたま当該インスタンス・ホストにおいてインスタンス化されるク
ライアントは、当該計算インスタンスに対して５Ｇビット／秒の帯域幅をリクエストする
、または、当該インスタンス・ホストにおいて実施されるサービスの管理者は１Ｇビット
／秒に帯域幅を制限するようリクエストする。このようなリクエストは、図示する実施形
態において他の要因を無効にするためにＮＣＳによって使用されてもよい。クライアント
が、発生したトラフィックの量に比例してネットワーク・トラフィックに対する金額が請
求される実施形態では、幾つかのクライアントはコストを制御するために帯域幅使用に上
限を課すことを望む場合がある。このような上限も無効リクエスト１３０の実施例を表し
得る。
幾つかの実施形態によると、所与のＮＣＳ１８０は、ＮＣＳが割り当てられた一つ以上
のインスタンス・ホスト１４４および／またはネットワーク装置１４５に対してトラフィ
ック分類メタデータを生成してもよい。少なくとも幾つかの実施形態では、分類メタデー
タはネットワーク接続ストレージ（ＮＡＳ）装置等のストレージ装置に対しても生成され
得る。メタデータは、例えば、ツリー・データ構造として表されてもよい一つ以上のレベ
ルのトラフィック・カテゴリーの階層を有してもよく、このとき、ツリーの各ノードはそ
れぞれのトラフィック・カテゴリーを表し、ネットワーク構成オプションまたは設定（例
えば、帯域幅限界または待ち時間要件）の関連するセットを有する。幾つかの実施形態で
は、トラフィック総和ポリシーは、図５を参照して以下に説明するように、分類ツリーに
適用されてもよい。図５によると、親ノードの子ノードとして表されるトラフィック・カ
テゴリーに対する実際のトラフィック率は親ノードの帯域幅限界を超えてはならない。そ
れぞれの分類ツリーが各インスタンス・ホスト１４４に対して生成される幾つかの実施形
態によると、図６を参照して以下に説明するように、ホスト・レベルの分類ツリーは、Ｎ
ＣＳ１８０によってラックレベルのツリーまたはデータ・センター・レベルの分類ツリー
にさえも合わされ得る。このような高レベルのツリーは、例えば、ネットワーク・トラフ
ィックの流れに対するより広い視点を得る、および／または、インスタンス・ホスト毎ま
たはネットワーク装置毎に行われるよりも高レベルの決定を行うために使用されてもよい
。
のインスタンス・ホスト１４４および／またはネットワーク装置１４５に対してトラフィ
ック分類メタデータを生成してもよい。少なくとも幾つかの実施形態では、分類メタデー
タはネットワーク接続ストレージ（ＮＡＳ）装置等のストレージ装置に対しても生成され
得る。メタデータは、例えば、ツリー・データ構造として表されてもよい一つ以上のレベ
ルのトラフィック・カテゴリーの階層を有してもよく、このとき、ツリーの各ノードはそ
れぞれのトラフィック・カテゴリーを表し、ネットワーク構成オプションまたは設定（例
えば、帯域幅限界または待ち時間要件）の関連するセットを有する。幾つかの実施形態で
は、トラフィック総和ポリシーは、図５を参照して以下に説明するように、分類ツリーに
適用されてもよい。図５によると、親ノードの子ノードとして表されるトラフィック・カ
テゴリーに対する実際のトラフィック率は親ノードの帯域幅限界を超えてはならない。そ
れぞれの分類ツリーが各インスタンス・ホスト１４４に対して生成される幾つかの実施形
態によると、図６を参照して以下に説明するように、ホスト・レベルの分類ツリーは、Ｎ
ＣＳ１８０によってラックレベルのツリーまたはデータ・センター・レベルの分類ツリー
にさえも合わされ得る。このような高レベルのツリーは、例えば、ネットワーク・トラフ
ィックの流れに対するより広い視点を得る、および／または、インスタンス・ホスト毎ま
たはネットワーク装置毎に行われるよりも高レベルの決定を行うために使用されてもよい
。
分類ツリーに加え、トラフィック分類メタデータは、図示する実施形態においてパケッ
ト等のネットワーク・トラフィック単位を分類ツリーに定められる様々なカテゴリーにマ
ッピングするために使用されるべき手順も含み得る。手順のステップは、例えば、手順グ
ラフの決定ノードとして表されてもよい。所与の手順グラフは、幾つかの実施において一
つ以上の決定ノードのシーケンスを有してもよく、このとき、連続するノードは、ネット
ワーク・トラフィック単位を連続して狭くなるトラフィック・カテゴリーに一致させるた
めに使用されるべき基準の表示を含む。少なくとも一つの実施において、幾つかの決定ノ
ードはハッシュ・テーブルのようなルックアップ・テーブルを含んでもよい。このような
ルックアップ・テーブル・ノードを用いると、所与のパケットまたはトラフィック単位が
単一のグラフ・ノードを用いて多数の異なるカテゴリーのうちの一つにマッピングされ、
それにより、手順グラフのサイズや複雑性が減少される。幾つかのケースでは、ルックア
ップ・テーブル・ノードのエントリーは他の手順グラフまたはサブグラフへのポインタと
して機能してもよく、それにより、非常に細かい分類論理または基準の使用が可能になる
。手順グラフやルックアップ・テーブルを組み込む決定ノードの実施例は図６および図７
に示され、以下により詳細に説明される。少なくとも幾つかの実施形態では、分類メタデ
ータは、適当なインスタンス・ホスト１４４および／またはネットワーク装置１４５に分
散されることに加えて、分類データベース１９２に記憶されてもよい。
ト等のネットワーク・トラフィック単位を分類ツリーに定められる様々なカテゴリーにマ
ッピングするために使用されるべき手順も含み得る。手順のステップは、例えば、手順グ
ラフの決定ノードとして表されてもよい。所与の手順グラフは、幾つかの実施において一
つ以上の決定ノードのシーケンスを有してもよく、このとき、連続するノードは、ネット
ワーク・トラフィック単位を連続して狭くなるトラフィック・カテゴリーに一致させるた
めに使用されるべき基準の表示を含む。少なくとも一つの実施において、幾つかの決定ノ
ードはハッシュ・テーブルのようなルックアップ・テーブルを含んでもよい。このような
ルックアップ・テーブル・ノードを用いると、所与のパケットまたはトラフィック単位が
単一のグラフ・ノードを用いて多数の異なるカテゴリーのうちの一つにマッピングされ、
それにより、手順グラフのサイズや複雑性が減少される。幾つかのケースでは、ルックア
ップ・テーブル・ノードのエントリーは他の手順グラフまたはサブグラフへのポインタと
して機能してもよく、それにより、非常に細かい分類論理または基準の使用が可能になる
。手順グラフやルックアップ・テーブルを組み込む決定ノードの実施例は図６および図７
に示され、以下により詳細に説明される。少なくとも幾つかの実施形態では、分類メタデ
ータは、適当なインスタンス・ホスト１４４および／またはネットワーク装置１４５に分
散されることに加えて、分類データベース１９２に記憶されてもよい。
幾つかの実施形態によると、ＮＣＳ１８０において生成されるメタデータは、分散シス
テム１２７を介してその意図する宛先に送信されてもよい。分散システム１２７は、それ
自体、ルーティング情報および／またはアクセス制御リスト等、他のタイプのメタデータ
をシステム１００の様々なノードに分散するために使用され得る複数の中間ノードを幾つ
かの実施において有してもよい。データベース１９２が生成されたメタデータの保存場所
として使用される実施形態では、分散システム１２７のノードは、例えば、データベース
１９２が更新された場合に（例えば、通知メカニズムに申し込むことで）通知されてもよ
く、また、相応じて新しいメタデータを適当な宛先に転送してもよい。幾つかの実施形態
では、メタデータのポータブル表現（例えば、分類ツリーおよび手順）は、ＪＳＯＮ、Ｘ
ＭＬ、ＹＡＭＬ、または、独自の技術または言語等のプロトコルを用いて、ＮＣＳ自体に
よって、或いは、分散システム１２７によって生成されてもよい。一つの実施では、ポー
タブル表現がデータベース１９２に記憶されてもよい。図３に例示され以下に更に詳細に
説明されるように、宛先では、受信したメタデータの表現が、例えば、インスタンス・ホ
スト１４４の場合には仮想化管理ソフトウェア・スタックのネットワーク管理モジュール
によって解析されてもよい。
テム１２７を介してその意図する宛先に送信されてもよい。分散システム１２７は、それ
自体、ルーティング情報および／またはアクセス制御リスト等、他のタイプのメタデータ
をシステム１００の様々なノードに分散するために使用され得る複数の中間ノードを幾つ
かの実施において有してもよい。データベース１９２が生成されたメタデータの保存場所
として使用される実施形態では、分散システム１２７のノードは、例えば、データベース
１９２が更新された場合に（例えば、通知メカニズムに申し込むことで）通知されてもよ
く、また、相応じて新しいメタデータを適当な宛先に転送してもよい。幾つかの実施形態
では、メタデータのポータブル表現（例えば、分類ツリーおよび手順）は、ＪＳＯＮ、Ｘ
ＭＬ、ＹＡＭＬ、または、独自の技術または言語等のプロトコルを用いて、ＮＣＳ自体に
よって、或いは、分散システム１２７によって生成されてもよい。一つの実施では、ポー
タブル表現がデータベース１９２に記憶されてもよい。図３に例示され以下に更に詳細に
説明されるように、宛先では、受信したメタデータの表現が、例えば、インスタンス・ホ
スト１４４の場合には仮想化管理ソフトウェア・スタックのネットワーク管理モジュール
によって解析されてもよい。
一実施形態では、実施サブシステム１０９の他の出力宛先１５０からＮＣＳ１８０に向
けられたリクエストを扱うために一つ以上のＡＰＩサーバー１７０がセットアップされ得
る。例えば、一つ以上のサーバーは、分散環境の選択された部分のネットワーク・ステー
タスの統一ビューをクライアントに提供するために、統合ネットワーク・ビュー生成部１
５２として構成されてもよい。ある一つの実施では、例えば、クライアントは、様々なイ
ンスタンス・ホストにおいて数百または数千のサービス・インスタンスが割り当てられ、
ビュー生成部１５２によって実施されるコンソールを介してそれぞれのインスタンスに対
する様々なタイプのメトリックス（例えば、最近の入来／出発トラフィック率、ドロップ
されたパケット率、適用可能な帯域幅限界等）を見ることができる。少なくとも一つの実
施形態では、配置サービス１５１もＡＰＩサーバー１７０を介してＮＣＳからのネットワ
ーク帯域幅限界および他のメトリックスにアクセスすることができ、これは、立ち上げら
れるべき新しいサービス・インスタンスに使用されるインスタンス・ホストに関して決定
を行う際、或いは、既存のサービス・インスタンスを帯域幅の競合がより少ないインスタ
ンス・ホストに移動する際に有用となる。
けられたリクエストを扱うために一つ以上のＡＰＩサーバー１７０がセットアップされ得
る。例えば、一つ以上のサーバーは、分散環境の選択された部分のネットワーク・ステー
タスの統一ビューをクライアントに提供するために、統合ネットワーク・ビュー生成部１
５２として構成されてもよい。ある一つの実施では、例えば、クライアントは、様々なイ
ンスタンス・ホストにおいて数百または数千のサービス・インスタンスが割り当てられ、
ビュー生成部１５２によって実施されるコンソールを介してそれぞれのインスタンスに対
する様々なタイプのメトリックス（例えば、最近の入来／出発トラフィック率、ドロップ
されたパケット率、適用可能な帯域幅限界等）を見ることができる。少なくとも一つの実
施形態では、配置サービス１５１もＡＰＩサーバー１７０を介してＮＣＳからのネットワ
ーク帯域幅限界および他のメトリックスにアクセスすることができ、これは、立ち上げら
れるべき新しいサービス・インスタンスに使用されるインスタンス・ホストに関して決定
を行う際、或いは、既存のサービス・インスタンスを帯域幅の競合がより少ないインスタ
ンス・ホストに移動する際に有用となる。
図２は、少なくとも幾つかの実施形態による、それぞれのネットワーク構成サーバーが
幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例
を例示する。図示するように、プロバイダ・ネットワーク２０２は、図示する実施形態に
おいて幾つかの利用可能コンテナ２０３、例えば、２０３Ａ、２０３Ｂ、および、２０３
Ｃを有してもよい。各利用可能コンテナは一つ以上のデータ・センター２０５を有しても
よく、例えば、利用可能コンテナ２０３Ａにはデータ・センター２０５Ａおよび２０５Ｂ
が設けられ、利用可能コンテナ２０３Ｂにはデータ・センター２０５Ｃが設けられ、利用
可能コンテナ２０３Ｃにはデータ・センター２０５Ｄが設けられる。前述の通り、各利用
可能コンテナ２０３は、任意の所与の利用可能コンテナにおける様々なタイプの故障イベ
ントの影響が当該利用可能コンテナに典型的には制限されるよう（例えば、電力源等のそ
れぞれ独立したインフラストラクチャ素子を有して、且つ、異なる利用可能コンテナ間の
幾らかの地理的距離を有して）設計され操作され得る。そのため、故障および／またはエ
ラーは、利用可能コンテナの境界を越えて典型的には広がらず、異なる利用可能コンテナ
は独立した故障プロフィールまたは独立した利用可能プロフィールを有すると考えられる
。例えば、所与の利用可能コンテナが自然災害を受けた場合でも、他の利用可能コンテナ
は動作可能なままであると予期される。
幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例
を例示する。図示するように、プロバイダ・ネットワーク２０２は、図示する実施形態に
おいて幾つかの利用可能コンテナ２０３、例えば、２０３Ａ、２０３Ｂ、および、２０３
Ｃを有してもよい。各利用可能コンテナは一つ以上のデータ・センター２０５を有しても
よく、例えば、利用可能コンテナ２０３Ａにはデータ・センター２０５Ａおよび２０５Ｂ
が設けられ、利用可能コンテナ２０３Ｂにはデータ・センター２０５Ｃが設けられ、利用
可能コンテナ２０３Ｃにはデータ・センター２０５Ｄが設けられる。前述の通り、各利用
可能コンテナ２０３は、任意の所与の利用可能コンテナにおける様々なタイプの故障イベ
ントの影響が当該利用可能コンテナに典型的には制限されるよう（例えば、電力源等のそ
れぞれ独立したインフラストラクチャ素子を有して、且つ、異なる利用可能コンテナ間の
幾らかの地理的距離を有して）設計され操作され得る。そのため、故障および／またはエ
ラーは、利用可能コンテナの境界を越えて典型的には広がらず、異なる利用可能コンテナ
は独立した故障プロフィールまたは独立した利用可能プロフィールを有すると考えられる
。例えば、所与の利用可能コンテナが自然災害を受けた場合でも、他の利用可能コンテナ
は動作可能なままであると予期される。
利用可能コンテナ間依存性を回避或いは低減するといった設計の目標を実現すべく、図
示する実施形態において少なくとも一つのＮＣＳ１８０が各利用可能コンテナ２０３に確
立されてもよい。例えば、ＮＣＳ１８０Ａおよび１８０Ｂは利用可能コンテナ２０３Ａの
データ・センター２０５Ａおよび２０５Ｂにそれぞれセットアップされ、ＮＣＳ１８０Ｃ
は利用可能コンテナ２０３Ｂのデータ・センター２０５Ｃに確立され、ＮＣＳ１８０Ｄは
利用可能コンテナ２０３Ｃのデータ・センター２０５Ｄに位置される。ＮＣＳ１８０Ａは
、データ・センター２０５Ａにおいて実施されている一つ以上のネットワーク・アクセス
可能サービス（例えば、仮想化されたコンピューティング・サービスまたはストレージ・
サービス）のインスタンス・ホスト１４４Ａ、および、データ・センター２０５Ａに位置
するネットワーク装置１４５Ａに対して分類メタデータを生成するよう構成されてもよい
。同様にして、ＮＣＳ１８０Ｂには、インスタンス・ホスト１４４Ｂおよびネットワーク
装置１４５Ｂに対して分類メタデータを生成するタスクが割り当てられ、ＮＣＳ１８０Ｃ
はインスタンス・ホスト１４４Ｃおよびネットワーク装置１４５Ｃに対して分類メタデー
タを生成する責任を担い、ＮＣＳ１８０Ｄはインスタンス・ホスト１４４Ｄおよびネット
ワーク装置１４５Ｄに対して分類メタデータを生成するよう構成されてもよい。図２に示
す実施形態では、単一のＮＣＳが各データ・センター２０５に示されているが、少なくと
も幾つかの実施形態では、複数のＮＣＳが（例えば、性能要件および／またはデータ・セ
ンターにおいてメタデータが生成されるべきノードの数に依存して）所与のデータ・セン
ター２０５にセットアップされてもよい。一実施形態では、利用可能コンテナ（例えば、
２０３Ａ）がＮ個のデータ・センターを有し、帯域幅管理に対する性能要件がＮ個未満の
ＮＣＳで満たされる場合、幾つかのデータ・センターはどの構成されたＮＣＳも有する必
要がなく、代わりに、単一のＮＣＳが二つ以上のデータ・センターに十分となり得る。他
の実施形態では、所与のＮＣＳ１８０は、二つ以上の利用可能コンテナにおいてノードに
対するメタデータを生成するよう構成され得る。
示する実施形態において少なくとも一つのＮＣＳ１８０が各利用可能コンテナ２０３に確
立されてもよい。例えば、ＮＣＳ１８０Ａおよび１８０Ｂは利用可能コンテナ２０３Ａの
データ・センター２０５Ａおよび２０５Ｂにそれぞれセットアップされ、ＮＣＳ１８０Ｃ
は利用可能コンテナ２０３Ｂのデータ・センター２０５Ｃに確立され、ＮＣＳ１８０Ｄは
利用可能コンテナ２０３Ｃのデータ・センター２０５Ｄに位置される。ＮＣＳ１８０Ａは
、データ・センター２０５Ａにおいて実施されている一つ以上のネットワーク・アクセス
可能サービス（例えば、仮想化されたコンピューティング・サービスまたはストレージ・
サービス）のインスタンス・ホスト１４４Ａ、および、データ・センター２０５Ａに位置
するネットワーク装置１４５Ａに対して分類メタデータを生成するよう構成されてもよい
。同様にして、ＮＣＳ１８０Ｂには、インスタンス・ホスト１４４Ｂおよびネットワーク
装置１４５Ｂに対して分類メタデータを生成するタスクが割り当てられ、ＮＣＳ１８０Ｃ
はインスタンス・ホスト１４４Ｃおよびネットワーク装置１４５Ｃに対して分類メタデー
タを生成する責任を担い、ＮＣＳ１８０Ｄはインスタンス・ホスト１４４Ｄおよびネット
ワーク装置１４５Ｄに対して分類メタデータを生成するよう構成されてもよい。図２に示
す実施形態では、単一のＮＣＳが各データ・センター２０５に示されているが、少なくと
も幾つかの実施形態では、複数のＮＣＳが（例えば、性能要件および／またはデータ・セ
ンターにおいてメタデータが生成されるべきノードの数に依存して）所与のデータ・セン
ター２０５にセットアップされてもよい。一実施形態では、利用可能コンテナ（例えば、
２０３Ａ）がＮ個のデータ・センターを有し、帯域幅管理に対する性能要件がＮ個未満の
ＮＣＳで満たされる場合、幾つかのデータ・センターはどの構成されたＮＣＳも有する必
要がなく、代わりに、単一のＮＣＳが二つ以上のデータ・センターに十分となり得る。他
の実施形態では、所与のＮＣＳ１８０は、二つ以上の利用可能コンテナにおいてノードに
対するメタデータを生成するよう構成され得る。
ＮＣＳ１８０の数および配置は、図示する実施形態においてネットワーク構成サービス
・マネージャ２２２によって確定されてもよい。ＮＣＳマネージャ２２２自体は、幾つか
の実施において複数のハードウェアおよび／またはソフトウェア・コンポーネントを有し
、その幾つかは様々な利用可能ゾーン２０３のデータ・センター２０５にわたって分散さ
れてもよい。ＮＣＳ１８０に対する構成の変化は、図示する実施形態において、必要に応
じてＮＣＳマネージャによって開始されてもよく、例えば、ＮＣＳによって使用されるソ
フトウェア・モジュールの新バージョンが展開されるべき場合、その展開がＮＣＳマネー
ジャによって調整されてもよい。
・マネージャ２２２によって確定されてもよい。ＮＣＳマネージャ２２２自体は、幾つか
の実施において複数のハードウェアおよび／またはソフトウェア・コンポーネントを有し
、その幾つかは様々な利用可能ゾーン２０３のデータ・センター２０５にわたって分散さ
れてもよい。ＮＣＳ１８０に対する構成の変化は、図示する実施形態において、必要に応
じてＮＣＳマネージャによって開始されてもよく、例えば、ＮＣＳによって使用されるソ
フトウェア・モジュールの新バージョンが展開されるべき場合、その展開がＮＣＳマネー
ジャによって調整されてもよい。
プロバイダ・ネットワークの幾つかの他のサービスは、図示する実施形態において、ネ
ットワーク構成システムと相互に作用してもよい。例えば、統一コンソール・サービス２
７８が一つ以上のプログラマチック・インターフェイス２４０（例えば、ウェブページ、
ＡＰＩ、ＧＵＩ、および／または、コマンド・ライン・ツール）を実施することで、クラ
イアント２６５は関心のある資源のネットワーク・ステータスに関するクエリーを出すか
、リクエストした情報をプログラムで受信することが可能となる。統一コンソール・サー
ビス２７８は、図１の統合ネットワーク・ビュー生成部１５２の一実施例を表してもよい
。プログラマチック・インターフェイス２４０は、クライアントが構成リクエストを要請
する、例えば、特定された時間期間にわたって様々なサービス・インスタンスまたはイン
スタンス・ホストに対する現在適用可能な帯域幅限界を上げるか下げることを可能にする
。
ットワーク構成システムと相互に作用してもよい。例えば、統一コンソール・サービス２
７８が一つ以上のプログラマチック・インターフェイス２４０（例えば、ウェブページ、
ＡＰＩ、ＧＵＩ、および／または、コマンド・ライン・ツール）を実施することで、クラ
イアント２６５は関心のある資源のネットワーク・ステータスに関するクエリーを出すか
、リクエストした情報をプログラムで受信することが可能となる。統一コンソール・サー
ビス２７８は、図１の統合ネットワーク・ビュー生成部１５２の一実施例を表してもよい
。プログラマチック・インターフェイス２４０は、クライアントが構成リクエストを要請
する、例えば、特定された時間期間にわたって様々なサービス・インスタンスまたはイン
スタンス・ホストに対する現在適用可能な帯域幅限界を上げるか下げることを可能にする
。
装置健康管理サービス２７６は、幾つかの実施形態において、様々なインスタンス・ホ
ストおよびネットワーク装置から応答情報を（例えば、心拍メカニズムを用いて）収集す
るよう、プロバイダ・ネットワーク２０２で実施される。図示する実施形態では、健康管
理サービス２７６は、例えば、健康ステータス・メッセージにネットワーク・メトリック
スをピギーバックさせることで、ＮＣＳ１８０によって入力として使用されるべきネット
ワーク関連のメトリックスの収集に使用されてもよい。そのため、健康管理サービス２７
６のノードは、図１に示すメトリックス・コレクタ１２５の実施例として考えられてもよ
い。健康管理サービスは、幾つかの実施形態においてメタデータ分散システム１２７とし
て使用されてもよく、例えば、様々なインスタンス・ホストに送られる心拍メッセージは
ピギーバックされた分類メタデータを含んでもよい。ＤＤＯＳ検出サービス２７４は、例
えば、所与のセットのＩＰアドレスへの或いは所与のセットのＩＰアドレスからの異常に
重いトラフィック・パターンを検出することで、プロバイダ・ネットワーク内のターゲッ
トにおけるサービス攻撃の拒絶および／または外部ターゲットにおけるプロバイダ・ネッ
トワーク２０２内から開始され得たサービス攻撃の拒絶を検出するよう構成されてもよい
。潜在的なＤＯＳ攻撃が識別されると、ＤＤＯＳ検出サービス２７４は、潜在的なネット
ワーク攻撃または侵入に関して適当なＮＣＳ１８０に入力を供給してもよく、これにより
、ＮＣＳ１８０は、潜在的な攻撃の影響を緩和させるよう幾つかのインスタンス・ホスト
またはネットワーク装置について少なくとも一時的に帯域幅限界を狭めるか他のネットワ
ーク構成オプションを変える。インスタンス配置サービス２７２は、ＮＣＳ１８０から最
近の利用可能なネットワーク関連メトリックスおよび構成設定を取得して、新しいインス
タンスを立ち上げるに利用可能な十分な余分帯域幅を有するインスタンス・ホストを選択
する、または、ネットワーク・トラフィック状態を変えることを考慮して既存のインスタ
ンスを移動すべきインスタンス・ホストを選択する。
インスタンス・ホストにおける分類メタデータの使用
ストおよびネットワーク装置から応答情報を（例えば、心拍メカニズムを用いて）収集す
るよう、プロバイダ・ネットワーク２０２で実施される。図示する実施形態では、健康管
理サービス２７６は、例えば、健康ステータス・メッセージにネットワーク・メトリック
スをピギーバックさせることで、ＮＣＳ１８０によって入力として使用されるべきネット
ワーク関連のメトリックスの収集に使用されてもよい。そのため、健康管理サービス２７
６のノードは、図１に示すメトリックス・コレクタ１２５の実施例として考えられてもよ
い。健康管理サービスは、幾つかの実施形態においてメタデータ分散システム１２７とし
て使用されてもよく、例えば、様々なインスタンス・ホストに送られる心拍メッセージは
ピギーバックされた分類メタデータを含んでもよい。ＤＤＯＳ検出サービス２７４は、例
えば、所与のセットのＩＰアドレスへの或いは所与のセットのＩＰアドレスからの異常に
重いトラフィック・パターンを検出することで、プロバイダ・ネットワーク内のターゲッ
トにおけるサービス攻撃の拒絶および／または外部ターゲットにおけるプロバイダ・ネッ
トワーク２０２内から開始され得たサービス攻撃の拒絶を検出するよう構成されてもよい
。潜在的なＤＯＳ攻撃が識別されると、ＤＤＯＳ検出サービス２７４は、潜在的なネット
ワーク攻撃または侵入に関して適当なＮＣＳ１８０に入力を供給してもよく、これにより
、ＮＣＳ１８０は、潜在的な攻撃の影響を緩和させるよう幾つかのインスタンス・ホスト
またはネットワーク装置について少なくとも一時的に帯域幅限界を狭めるか他のネットワ
ーク構成オプションを変える。インスタンス配置サービス２７２は、ＮＣＳ１８０から最
近の利用可能なネットワーク関連メトリックスおよび構成設定を取得して、新しいインス
タンスを立ち上げるに利用可能な十分な余分帯域幅を有するインスタンス・ホストを選択
する、または、ネットワーク・トラフィック状態を変えることを考慮して既存のインスタ
ンスを移動すべきインスタンス・ホストを選択する。
インスタンス・ホストにおける分類メタデータの使用
前述の通り、異なる実施形態において、ネットワーク構成サーバーは、様々なネットワ
ーク・アクセス可能サービスのインスタンス・ホストにトラフィック分類メタデータの表
現を送信してもよい。図３は、少なくとも幾つかの実施形態による、仮想化されたコンピ
ューティング・サービスのインスタンス・ホスト１４４においてトラフィック分類メタデ
ータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する
。インスタンス・ホスト１４４は、幾つかの異なるクライアント・アクセス可能バーチャ
ル・マシンまたは計算インスタンス３５０、例えば、計算インスタンス３５０Ａおよび３
５０Ｂをインスタンス化し管理することができる仮想化管理ソフトウェア・スタック（Ｖ
ＭＳＳ）３１０を含んでもよい。ＶＭＳＳ３１０は、例えば、ハイパーバイザー３１７、
および、幾つかの実施において「ドメインゼロ」または「ドム０」と呼ばれるオペレーテ
ィング・システム３１５の管理インスタンスを有してもよい。ドム０オペレーティング・
システムは、計算インスタンス３５０を実行しているクライアントによってアクセスする
ことができないが、計算インスタンス３５０への或いは計算インスタンス３５０からのネ
ットワーク・トラフィックを扱うことを含む、仮想化されたオペレーティング・システム
の様々な管理または制御面の動作に対して責任を担う。
ーク・アクセス可能サービスのインスタンス・ホストにトラフィック分類メタデータの表
現を送信してもよい。図３は、少なくとも幾つかの実施形態による、仮想化されたコンピ
ューティング・サービスのインスタンス・ホスト１４４においてトラフィック分類メタデ
ータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する
。インスタンス・ホスト１４４は、幾つかの異なるクライアント・アクセス可能バーチャ
ル・マシンまたは計算インスタンス３５０、例えば、計算インスタンス３５０Ａおよび３
５０Ｂをインスタンス化し管理することができる仮想化管理ソフトウェア・スタック（Ｖ
ＭＳＳ）３１０を含んでもよい。ＶＭＳＳ３１０は、例えば、ハイパーバイザー３１７、
および、幾つかの実施において「ドメインゼロ」または「ドム０」と呼ばれるオペレーテ
ィング・システム３１５の管理インスタンスを有してもよい。ドム０オペレーティング・
システムは、計算インスタンス３５０を実行しているクライアントによってアクセスする
ことができないが、計算インスタンス３５０への或いは計算インスタンス３５０からのネ
ットワーク・トラフィックを扱うことを含む、仮想化されたオペレーティング・システム
の様々な管理または制御面の動作に対して責任を担う。
図示する実施形態では、ドム０オペレーティング・システム３１５は、ネットワーク・
マネージャ・コンポーネント３５７を含む様々な制御モジュールを含み、ネットワーク・
マネージャ・コンポーネント３５７は分類メタデータ解釈部３５９を有する。ネットワー
ク・マネージャ・コンポーネントは、例えば、上述の分類ツリーおよび／または分類手順
の表示を含む、インスタンス・ホスト１４４についてＮＣＳ１８０によって生成された分
類メタデータを受信してもよい。解釈部３５９は、メタデータを解析し、様々な計算イン
スタンス３５０に或いは計算インスタンス３５０から方向付けられるトラフィックのパケ
ットにメタデータに示される手順を適用し得る。例えば、様々なトラフィック・カテゴリ
ーに対して帯域幅限界を実施するために、一つ以上のインスタンス・パケット・キュー（
ＩＰＱ）３１９（例えば、ＩＰＱ３１９Ａおよび３１９Ｂ）が構成されてもよい。特定の
インスタンス３５０における特定のカテゴリーの入来または出発トラフィック率が所与の
時間間隔中に当該カテゴリーに対する帯域幅限界を超えると、入来または出発パケットの
幾つかは当該特定のインスタンスに対するＩＰＱ３１９の待ち行列に入れられてもよい。
幾つかの実施では、二つ以上のパケット・キューが所与の計算インスタンスに対してイン
スタンス化されてもよく、例えば、一つのトラフィック・カテゴリー当たり一つのパケッ
ト・キューがセットアップされてもよい。他の実施では、多数のインスタンス３５０と関
連付けられるパケットを待ち行列に入れるには単一のパケット・キューで十分である。Ｉ
ＰＱまたは他の同様の構成は、様々な実施形態において、待ち時間要件、他のサービス品
質の目標（例えば、異なるトラフィック・カテゴリーに対するネットワーク送信の相対的
優先順位）、パケット・フラグメンテーション設定、または、パケット・サイズに依存す
る設定等の他のネットワーク構成オプションをＮＣＳから受信したメタデータに応じて実
施するために使用されてもよい。
マネージャ・コンポーネント３５７を含む様々な制御モジュールを含み、ネットワーク・
マネージャ・コンポーネント３５７は分類メタデータ解釈部３５９を有する。ネットワー
ク・マネージャ・コンポーネントは、例えば、上述の分類ツリーおよび／または分類手順
の表示を含む、インスタンス・ホスト１４４についてＮＣＳ１８０によって生成された分
類メタデータを受信してもよい。解釈部３５９は、メタデータを解析し、様々な計算イン
スタンス３５０に或いは計算インスタンス３５０から方向付けられるトラフィックのパケ
ットにメタデータに示される手順を適用し得る。例えば、様々なトラフィック・カテゴリ
ーに対して帯域幅限界を実施するために、一つ以上のインスタンス・パケット・キュー（
ＩＰＱ）３１９（例えば、ＩＰＱ３１９Ａおよび３１９Ｂ）が構成されてもよい。特定の
インスタンス３５０における特定のカテゴリーの入来または出発トラフィック率が所与の
時間間隔中に当該カテゴリーに対する帯域幅限界を超えると、入来または出発パケットの
幾つかは当該特定のインスタンスに対するＩＰＱ３１９の待ち行列に入れられてもよい。
幾つかの実施では、二つ以上のパケット・キューが所与の計算インスタンスに対してイン
スタンス化されてもよく、例えば、一つのトラフィック・カテゴリー当たり一つのパケッ
ト・キューがセットアップされてもよい。他の実施では、多数のインスタンス３５０と関
連付けられるパケットを待ち行列に入れるには単一のパケット・キューで十分である。Ｉ
ＰＱまたは他の同様の構成は、様々な実施形態において、待ち時間要件、他のサービス品
質の目標（例えば、異なるトラフィック・カテゴリーに対するネットワーク送信の相対的
優先順位）、パケット・フラグメンテーション設定、または、パケット・サイズに依存す
る設定等の他のネットワーク構成オプションをＮＣＳから受信したメタデータに応じて実
施するために使用されてもよい。
図示するように、各計算インスタンス３５０は、図示する実施形態において対応するク
ライアント・アクセス可能オペレーティング・システム３７０、例えば、計算インスタン
ス３５０ＡのＯＳ３７０Ａや計算インスタンス３５０ＢのＯＳ３７０Ｂを有してもよい。
オペレーティング・システム３７０は、入来および出発トラフィックに対してインスタン
ス・ホスト１４４のハードウェア・ネットワーク・インターフェイスを使用するようネッ
トワーク・マネージャ３５７と通信し得る、独自のネットワーク・スタック３７２（例え
ば、インスタンス３５０Ａのネットワーク・スタック３７２Ａおよびインスタンス３５０
Ｂのネットワーク・スタック３７２Ｂ）をそれぞれ有してもよい。計算インスタンス３５
０を実施するクライアントの視点からすると、各インスタンスは完全に機能的なサーバー
に見え、クライアントは使用されているネットワーク構成技術の実施の詳細（例えば、Ｉ
ＰＱでパケットを待ち行列に入れる）を知らない場合もある。図３に示すのと同様の分類
メタデータを解釈し使用する技術が、異なる実施形態において、様々なタイプのストレー
ジ・サービスまたはデータベース・サービス等、他のタイプのネットワーク・アクセス可
能な仮想化サービスのインスタンス・ホストにも使用されてもよいことに注意する。更に
、幾つかの実施形態において、分類メタデータがＶＭＳＳ３１０のネットワーク・マネー
ジャ３５７の代わりに、或いは、それに加えて、インスタンス３５０のネットワーク・ス
タック３７２で少なくとも部分的に解釈および／または使用されてもよいことに注意する
。
メタデータ送信モード
ライアント・アクセス可能オペレーティング・システム３７０、例えば、計算インスタン
ス３５０ＡのＯＳ３７０Ａや計算インスタンス３５０ＢのＯＳ３７０Ｂを有してもよい。
オペレーティング・システム３７０は、入来および出発トラフィックに対してインスタン
ス・ホスト１４４のハードウェア・ネットワーク・インターフェイスを使用するようネッ
トワーク・マネージャ３５７と通信し得る、独自のネットワーク・スタック３７２（例え
ば、インスタンス３５０Ａのネットワーク・スタック３７２Ａおよびインスタンス３５０
Ｂのネットワーク・スタック３７２Ｂ）をそれぞれ有してもよい。計算インスタンス３５
０を実施するクライアントの視点からすると、各インスタンスは完全に機能的なサーバー
に見え、クライアントは使用されているネットワーク構成技術の実施の詳細（例えば、Ｉ
ＰＱでパケットを待ち行列に入れる）を知らない場合もある。図３に示すのと同様の分類
メタデータを解釈し使用する技術が、異なる実施形態において、様々なタイプのストレー
ジ・サービスまたはデータベース・サービス等、他のタイプのネットワーク・アクセス可
能な仮想化サービスのインスタンス・ホストにも使用されてもよいことに注意する。更に
、幾つかの実施形態において、分類メタデータがＶＭＳＳ３１０のネットワーク・マネー
ジャ３５７の代わりに、或いは、それに加えて、インスタンス３５０のネットワーク・ス
タック３７２で少なくとも部分的に解釈および／または使用されてもよいことに注意する
。
メタデータ送信モード
ＮＣＳ１８０によって生成されたメタデータの表現は、異なる実施形態における異なる
プロトコルまたは転送モードに応じて、インスタンス・ホスト１４４またはネットワーク
装置１４５等のターゲットに供給されてもよい。図４ａ〜図４ｃは、少なくとも幾つかの
実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために
使用され得るプロトコルの実施例をそれぞれ示す。一つ以上のプログラマチック・インタ
ーフェイスは、異なる実施形態においてインスタンス・ホストまたは分散システムの他の
ノードにメタデータを供給するために使用されてもよく、このときＮＣＳまたはメタデー
タの受信部のいずれかは、使用されるプロトコルに応じてインターフェイスを呼び出す。
プロトコルまたは転送モードに応じて、インスタンス・ホスト１４４またはネットワーク
装置１４５等のターゲットに供給されてもよい。図４ａ〜図４ｃは、少なくとも幾つかの
実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために
使用され得るプロトコルの実施例をそれぞれ示す。一つ以上のプログラマチック・インタ
ーフェイスは、異なる実施形態においてインスタンス・ホストまたは分散システムの他の
ノードにメタデータを供給するために使用されてもよく、このときＮＣＳまたはメタデー
タの受信部のいずれかは、使用されるプロトコルに応じてインターフェイスを呼び出す。
図４ａに示す実施形態では、分類メタデータは、ＮＣＳ１８０によって開始されたスケ
ジューリングされた「プッシュ」動作４０１を介してインスタンス・ホスト１４４に（ま
たは、ネットワーク装置１４５またはストレージ装置に）送られてもよい。例えば、各Ｎ
ＣＳはそれぞれスケジュールを有して構成されてもよく、ＮＣＳは該スケジュールに応じ
て所与のメタデータ・ターゲットに（例えば、一分間に一回、または、五分間に一回）メ
タデータを送る。幾つかの実施において所与のＮＣＳから異なるターゲットにメタデータ
が送られる実時間は、メタデータ転送自体によって生ずるネットワークの混雑を回避する
ようずらされる。例えば、メタデータが所与のＮＣＳから六つのインスタンス・ホストに
一分間に一回プッシュされるべき場合、各インスタンス・ホストへのメタデータ送信は十
秒間隔でスケジューリングされ得る。
ジューリングされた「プッシュ」動作４０１を介してインスタンス・ホスト１４４に（ま
たは、ネットワーク装置１４５またはストレージ装置に）送られてもよい。例えば、各Ｎ
ＣＳはそれぞれスケジュールを有して構成されてもよく、ＮＣＳは該スケジュールに応じ
て所与のメタデータ・ターゲットに（例えば、一分間に一回、または、五分間に一回）メ
タデータを送る。幾つかの実施において所与のＮＣＳから異なるターゲットにメタデータ
が送られる実時間は、メタデータ転送自体によって生ずるネットワークの混雑を回避する
ようずらされる。例えば、メタデータが所与のＮＣＳから六つのインスタンス・ホストに
一分間に一回プッシュされるべき場合、各インスタンス・ホストへのメタデータ送信は十
秒間隔でスケジューリングされ得る。
図４ｂに示す実施形態では、トリガとなるイベントはメタデータの送信につながり得る
。例えば、イベント検出部４２１が潜在的なＤＤＯＳ検出等のイベントが検出されたこと
をＮＣＳに通知し、ＮＣＳがイベントの影響を緩和するよう適当なメタデータを生成して
もよい。あるタイプのイベントについては、イベントになるべく早く対応するよう、幾つ
かの実施形態では、メタデータが生成されるとすぐに、生成されたメタデータのトリガさ
れたプッシュ４０２が高い優先順位で開始されてもよい。他のタイプのトリガとなるイベ
ントに対して、例えば、管理者が先に生成されたメタデータを無効にするリクエストを出
した場合、メタデータはすぐに或いは高い優先順位でプッシュされる必要がない。
。例えば、イベント検出部４２１が潜在的なＤＤＯＳ検出等のイベントが検出されたこと
をＮＣＳに通知し、ＮＣＳがイベントの影響を緩和するよう適当なメタデータを生成して
もよい。あるタイプのイベントについては、イベントになるべく早く対応するよう、幾つ
かの実施形態では、メタデータが生成されるとすぐに、生成されたメタデータのトリガさ
れたプッシュ４０２が高い優先順位で開始されてもよい。他のタイプのトリガとなるイベ
ントに対して、例えば、管理者が先に生成されたメタデータを無効にするリクエストを出
した場合、メタデータはすぐに或いは高い優先順位でプッシュされる必要がない。
図４ｃに示す実施形態では、インスタンス・ホスト１４４は、最近の分類メタデータに
ついてＢＡ１８０にプル・リクエスト４０３を出し、メタデータは相応じて応答４０４で
インスタンス・ホストに送られてもよい。様々な実施形態では、図４ａ乃至図４ｃに示す
三つのアプローチ法のいずれかの組み合わせが、インスタンス・ホスト１４４に対して、
ネットワーク装置１４５に対して、または、ストレージ装置に対して使用されてもよい。
少なくとも一実施形態では、メタデータを送信する際に差分アプローチが使用されてもよ
く、つまり、現在のメタデータと最近供給されたメタデータとの間の差だけの表現がイン
スタンス・ホスト、ネットワーク装置、または、ストレージ装置に送られてもよい。他の
実施形態では、メタデータ全体が各転送において送信されてもよい。
分類ツリー
ついてＢＡ１８０にプル・リクエスト４０３を出し、メタデータは相応じて応答４０４で
インスタンス・ホストに送られてもよい。様々な実施形態では、図４ａ乃至図４ｃに示す
三つのアプローチ法のいずれかの組み合わせが、インスタンス・ホスト１４４に対して、
ネットワーク装置１４５に対して、または、ストレージ装置に対して使用されてもよい。
少なくとも一実施形態では、メタデータを送信する際に差分アプローチが使用されてもよ
く、つまり、現在のメタデータと最近供給されたメタデータとの間の差だけの表現がイン
スタンス・ホスト、ネットワーク装置、または、ストレージ装置に送られてもよい。他の
実施形態では、メタデータ全体が各転送において送信されてもよい。
分類ツリー
図５は、少なくとも幾つかの実施形態による、分散システムの装置においてネットワー
ク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類
ツリー・データ構造５０１の実施例を例示する。ツリー５０１の各ノードは、ノードによ
って表されるカテゴリーについて、図５における各ノードに対して例示されるそれぞれの
帯域幅限界等のネットワーク構成オプションまたは設定の関連するセットを有してもよい
。各ノードに適用され得るネットワーク構成オプションの他の実施例は、パケット待ち時
間要件または目標、異なるトラフィック・カテゴリーの相対的優先順位等の他のサービス
品質の目標、パケット・フラグメンテーション／再組立設定、または、パケット・サイズ
に依存する構成の設定を含み得る。トラフィック・カテゴリーは、異なる実施形態におい
て様々な特性における差に基づいて定められ、例えば、トラフィックと関連付けられるア
プリケーションのカテゴリー、コンポーネントが送信側または受信側にあるサービス、関
連するエンドポイント（幾つかのケースでは、それ自体がアプリケーションのタイプを示
す）のネットワーク・アドレス、転送のサイズ、トラフィックを生成したクライアント、
互いに対するエンドポイントの場所（例えば、プロバイダ・ネットワーク・ノードからの
出発パケットについては、宛先がローカル・データ・センター内、ローカル利用可能コン
テナ、ローカル領域、プロバイダ・ネットワークの別の領域、またはプロバイダ・ネット
ワークの外部か否か）等に基づいて定められる。例示する分類ツリー５０１において、例
えば、ノード５０４はアプリケーション（高性能計算）の一つのクラスに対するトラフィ
ックを表し、ノード５２０はデータベース・トラフィックを表し、ノード５０６は高性能
ブロック・ストレージ・トラフィック（即ち、高入力／出力速度を支持するよう構成され
るブロック・ストレージ装置と関連付けられるトラフィック）を表す。ノード５２０によ
って表されるデータベース・カテゴリー内では、場所に基づくサブカテゴリーに対して三
つのノード、即ち、データ・センター間トラフィックに対するノード５２２、領域間トラ
フィックに対するノード５２４、および、余剰領域トラフィックに対するノード５２６が
定められる。
ク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類
ツリー・データ構造５０１の実施例を例示する。ツリー５０１の各ノードは、ノードによ
って表されるカテゴリーについて、図５における各ノードに対して例示されるそれぞれの
帯域幅限界等のネットワーク構成オプションまたは設定の関連するセットを有してもよい
。各ノードに適用され得るネットワーク構成オプションの他の実施例は、パケット待ち時
間要件または目標、異なるトラフィック・カテゴリーの相対的優先順位等の他のサービス
品質の目標、パケット・フラグメンテーション／再組立設定、または、パケット・サイズ
に依存する構成の設定を含み得る。トラフィック・カテゴリーは、異なる実施形態におい
て様々な特性における差に基づいて定められ、例えば、トラフィックと関連付けられるア
プリケーションのカテゴリー、コンポーネントが送信側または受信側にあるサービス、関
連するエンドポイント（幾つかのケースでは、それ自体がアプリケーションのタイプを示
す）のネットワーク・アドレス、転送のサイズ、トラフィックを生成したクライアント、
互いに対するエンドポイントの場所（例えば、プロバイダ・ネットワーク・ノードからの
出発パケットについては、宛先がローカル・データ・センター内、ローカル利用可能コン
テナ、ローカル領域、プロバイダ・ネットワークの別の領域、またはプロバイダ・ネット
ワークの外部か否か）等に基づいて定められる。例示する分類ツリー５０１において、例
えば、ノード５０４はアプリケーション（高性能計算）の一つのクラスに対するトラフィ
ックを表し、ノード５２０はデータベース・トラフィックを表し、ノード５０６は高性能
ブロック・ストレージ・トラフィック（即ち、高入力／出力速度を支持するよう構成され
るブロック・ストレージ装置と関連付けられるトラフィック）を表す。ノード５２０によ
って表されるデータベース・カテゴリー内では、場所に基づくサブカテゴリーに対して三
つのノード、即ち、データ・センター間トラフィックに対するノード５２２、領域間トラ
フィックに対するノード５２４、および、余剰領域トラフィックに対するノード５２６が
定められる。
様々なカテゴリーに対して定められるネットワーク構成オプションが帯域幅限界を含む
実施形態では、様々な種類のトラフィック総和ポリシーまたはルールが分類ツリーに適用
され得、それにより、親ノードに対する子ノードの帯域幅限界の間の関係に影響が与えら
れる。例示する実施例では、以下のルールが当てはめられる：（ａ）ツリーにおけるどの
子ノードもその親の帯域幅限界を超える帯域幅限界を有さない、および、（ｂ）親ノード
の子ノードの帯域幅限界の総和が親の帯域幅限界を超えたとしても、子ノードによって表
されるカテゴリーに対する実際のトラフィック率の総和はどの所与の時間期間中にも親の
帯域幅限界を超えてはならない。
実施形態では、様々な種類のトラフィック総和ポリシーまたはルールが分類ツリーに適用
され得、それにより、親ノードに対する子ノードの帯域幅限界の間の関係に影響が与えら
れる。例示する実施例では、以下のルールが当てはめられる：（ａ）ツリーにおけるどの
子ノードもその親の帯域幅限界を超える帯域幅限界を有さない、および、（ｂ）親ノード
の子ノードの帯域幅限界の総和が親の帯域幅限界を超えたとしても、子ノードによって表
されるカテゴリーに対する実際のトラフィック率の総和はどの所与の時間期間中にも親の
帯域幅限界を超えてはならない。
これらのルールによると、ルート・ノード（分類グラフが生成されるインスタンス・ホ
ストまたはネットワーク装置に対して定められた全てのトラフィック・カテゴリーを総称
的に表す）がＫ Ｇビット／秒の帯域幅限界を有するため、ルート・ノードのどの子ノー
ドもＫ Ｇビット／秒よりも大きい帯域幅限界を有さず、Ａ＜Ｋ、Ｂ＜Ｋ、Ｃ＜Ｋ、およ
び、Ｄ＜Ｋとなる。ノード５２０の場合、子ノード（ノード５２２、５２５、および、５
２６）の帯域幅限界は、総和が親ノードの帯域幅限界となるよう割り当てられるため、上
述の両方のルールが満たされる。Ｄ Ｇビット／秒の帯域幅限界を有する包括的な「他の
」トラフィック・カテゴリーを表すノード５３０の場合、子ノード５３２（他のブロック
・ストレージ・トラフィック）、５３４（インターネット・トラフィック）、５３６（イ
ントラサービス・トラフィック）、および、５３８（どの他のリーフ・ノードによっても
表されない雑または未分類トラフィック）それぞれもＤ Ｇビット／秒の帯域幅限界を有
する。子ノードに対する公称帯域幅限界の総和が（この場合４Ｄ Ｇビット／秒）が親ノ
ード（Ｄ Ｇビット／秒）の帯域幅限界を超えるこのようなシナリオは、上述の第二のル
ールに応じて以下のように解釈され得る。原則としては、子ノードのカテゴリーそれぞれ
がＤ Ｇビット／秒までのトラフィック率を有することができるが、実際には、どの所与
の一秒（または他の適当な時間単位）中にも、全ての子ノードの実際のトラフィック・フ
ローの総和はＤ Ｇビット／秒を超えてはならない。そのため、特定の一秒中「他のブロ
ック・ストレージ・トラフィック」（ノード５３２）といったカテゴリーに対するトラフ
ィック率が０．６Ｄ Ｇビット／秒の場合、ノード５３４、５３６、および、５３８に対
するトラフィック率は合わせて０．４Ｄを超えてはならない。
ストまたはネットワーク装置に対して定められた全てのトラフィック・カテゴリーを総称
的に表す）がＫ Ｇビット／秒の帯域幅限界を有するため、ルート・ノードのどの子ノー
ドもＫ Ｇビット／秒よりも大きい帯域幅限界を有さず、Ａ＜Ｋ、Ｂ＜Ｋ、Ｃ＜Ｋ、およ
び、Ｄ＜Ｋとなる。ノード５２０の場合、子ノード（ノード５２２、５２５、および、５
２６）の帯域幅限界は、総和が親ノードの帯域幅限界となるよう割り当てられるため、上
述の両方のルールが満たされる。Ｄ Ｇビット／秒の帯域幅限界を有する包括的な「他の
」トラフィック・カテゴリーを表すノード５３０の場合、子ノード５３２（他のブロック
・ストレージ・トラフィック）、５３４（インターネット・トラフィック）、５３６（イ
ントラサービス・トラフィック）、および、５３８（どの他のリーフ・ノードによっても
表されない雑または未分類トラフィック）それぞれもＤ Ｇビット／秒の帯域幅限界を有
する。子ノードに対する公称帯域幅限界の総和が（この場合４Ｄ Ｇビット／秒）が親ノ
ード（Ｄ Ｇビット／秒）の帯域幅限界を超えるこのようなシナリオは、上述の第二のル
ールに応じて以下のように解釈され得る。原則としては、子ノードのカテゴリーそれぞれ
がＤ Ｇビット／秒までのトラフィック率を有することができるが、実際には、どの所与
の一秒（または他の適当な時間単位）中にも、全ての子ノードの実際のトラフィック・フ
ローの総和はＤ Ｇビット／秒を超えてはならない。そのため、特定の一秒中「他のブロ
ック・ストレージ・トラフィック」（ノード５３２）といったカテゴリーに対するトラフ
ィック率が０．６Ｄ Ｇビット／秒の場合、ノード５３４、５３６、および、５３８に対
するトラフィック率は合わせて０．４Ｄを超えてはならない。
幾つかの実施形態では、それぞれのツリーは所与のインスタンス・ホストまたはネット
ワーク装置において入来および出発トラフィックに対してＮＣＳ１８０によって生成され
てもよく、ネットワーク構成オプションおよび／またはカテゴリーにおいて入来トラフィ
ックに対するツリーは出発トラフィックに対するツリーと異なってもよい。幾つかの実施
形態では、分類ツリーの幾つかの或いは全てのノードに関して、持続的帯域幅（例えば、
Ｔ秒を超える時間期間にわたって平均的帯域幅使用に適用される）、および、バースト帯
域幅（例えば、所与のインスタンス・ホストに対して持続的帯域幅限界が１Ｇビット／秒
に設定されているが４Ｇビット／秒の短期間バースト・トラフィック率が当該インスタン
ス・ホストに対して二秒まで許される）に対して異なる限界が定められてもよい。前述の
通り、幾つかの実施では、所与のインスタンス・ホスト、ネットワーク装置、またはスト
レージ装置に対するトラフィック分類階層は、多数の層を有する代わりに平坦でもよい。
ワーク装置において入来および出発トラフィックに対してＮＣＳ１８０によって生成され
てもよく、ネットワーク構成オプションおよび／またはカテゴリーにおいて入来トラフィ
ックに対するツリーは出発トラフィックに対するツリーと異なってもよい。幾つかの実施
形態では、分類ツリーの幾つかの或いは全てのノードに関して、持続的帯域幅（例えば、
Ｔ秒を超える時間期間にわたって平均的帯域幅使用に適用される）、および、バースト帯
域幅（例えば、所与のインスタンス・ホストに対して持続的帯域幅限界が１Ｇビット／秒
に設定されているが４Ｇビット／秒の短期間バースト・トラフィック率が当該インスタン
ス・ホストに対して二秒まで許される）に対して異なる限界が定められてもよい。前述の
通り、幾つかの実施では、所与のインスタンス・ホスト、ネットワーク装置、またはスト
レージ装置に対するトラフィック分類階層は、多数の層を有する代わりに平坦でもよい。
幾つかのシナリオでは、分散システムの異なるエンティティの分類ツリーを高次ツリー
に組み合わせることが管理的視点から有用となり得る。図６は、少なくとも幾つかの実施
形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・ト
ラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造６０１の
実施例を例示する。図示するように、Ｃツリー６０１Ａ、６０１Ｂ、６０１Ｍ、および、
６０１Ｎ等、それぞれの分類ツリー（Ｃツリー）が多数のインスタンス・ホストに対して
データ・センターにおいて生成され得る。データ・センターは、図示する実施形態におい
て幾つかの異なるルームに配置される複数のサーバー・ラックを有する。ＮＣＳは、所与
のラックに組み込まれるインスタンス・ホストのＣツリーを統合して６０３Ａおよび６０
３Ｂ等のラックレベルのＣツリーを形成する。統合の次のレベルでは、データ・センター
の所与のルームまたはサブセットにおける全てのラックに対するラックレベルＣツリー６
０３が例えば、ルームレベルＣツリー６０５Ａまたは６０５Ｂの形態で組み合わされても
よい。幾つかの実施形態では、ルームレベルのツリーを組み合わせることで、全体として
単一の合成ツリー６０７がデータ・センターに対して形成されてもよい。全体として利用
可能コンテナ、地理的領域、または、プロバイダ・ネットワークのレベルにおける等、よ
り高レベルのツリー階層が幾つかの実施形態で構成され得る。
に組み合わせることが管理的視点から有用となり得る。図６は、少なくとも幾つかの実施
形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・ト
ラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造６０１の
実施例を例示する。図示するように、Ｃツリー６０１Ａ、６０１Ｂ、６０１Ｍ、および、
６０１Ｎ等、それぞれの分類ツリー（Ｃツリー）が多数のインスタンス・ホストに対して
データ・センターにおいて生成され得る。データ・センターは、図示する実施形態におい
て幾つかの異なるルームに配置される複数のサーバー・ラックを有する。ＮＣＳは、所与
のラックに組み込まれるインスタンス・ホストのＣツリーを統合して６０３Ａおよび６０
３Ｂ等のラックレベルのＣツリーを形成する。統合の次のレベルでは、データ・センター
の所与のルームまたはサブセットにおける全てのラックに対するラックレベルＣツリー６
０３が例えば、ルームレベルＣツリー６０５Ａまたは６０５Ｂの形態で組み合わされても
よい。幾つかの実施形態では、ルームレベルのツリーを組み合わせることで、全体として
単一の合成ツリー６０７がデータ・センターに対して形成されてもよい。全体として利用
可能コンテナ、地理的領域、または、プロバイダ・ネットワークのレベルにおける等、よ
り高レベルのツリー階層が幾つかの実施形態で構成され得る。
このような合成ツリー階層は、幾つかの方法で、特に、階層のカスマタイズ可能な視覚
表示がプログラムで（例えば、統一コンソール・サービスを介して）利用可能にされた実
施においてネットワーク構成システムやプロバイダ・ネットワークの管理者を補助する。
データ・センターまたはプロバイダ・ネットワークの異なる部分における帯域幅使用の均
一性または不均一性の概要は、このような階層を用いて得られ、これは、構成または配置
の変化につながってネットワーク利用レベルを改善するまたはバランスを取る。トラフィ
ックの異なるカテゴリー間の利用可能な帯域幅の分散もより高レベルの階層を検査するこ
とでより明確になり、これは、プロバイダ・ネットワークの収益の改善を補助する価格変
化を行う際に助けとなる（例えば、より普及しているカテゴリーに関連するトラフィック
の価格上昇）。配置サービスも、例えば、新しいサービス・インスタンスに対して適当な
インスタンス・ホストを選択する際に助けとなるラックレベルの帯域幅使用を確定するこ
とで、高レベルのツリー階層から恩恵を受ける。
分類手順グラフ
表示がプログラムで（例えば、統一コンソール・サービスを介して）利用可能にされた実
施においてネットワーク構成システムやプロバイダ・ネットワークの管理者を補助する。
データ・センターまたはプロバイダ・ネットワークの異なる部分における帯域幅使用の均
一性または不均一性の概要は、このような階層を用いて得られ、これは、構成または配置
の変化につながってネットワーク利用レベルを改善するまたはバランスを取る。トラフィ
ックの異なるカテゴリー間の利用可能な帯域幅の分散もより高レベルの階層を検査するこ
とでより明確になり、これは、プロバイダ・ネットワークの収益の改善を補助する価格変
化を行う際に助けとなる（例えば、より普及しているカテゴリーに関連するトラフィック
の価格上昇）。配置サービスも、例えば、新しいサービス・インスタンスに対して適当な
インスタンス・ホストを選択する際に助けとなるラックレベルの帯域幅使用を確定するこ
とで、高レベルのツリー階層から恩恵を受ける。
分類手順グラフ
上述の通り、少なくとも幾つかの実施形態では、ネットワーク構成サーバーは、所与の
インスタンス・ホストまたはネットワーク装置に対して定められたカテゴリーにパケット
等のネットワーク・トラフィック単位を分類するために使用され得る手順のステップまた
はルールを確定してもよい。図７は、少なくとも幾つかの実施形態による、ネットワーク
・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るト
ラフィック手順グラフ７５０の実施例を例示する。グラフ７５０は、複数の決定ノードを
有し、各ノードにおいてネットワーク・トラフィックに対する分類基準のそれぞれのセッ
トが示される。少なくとも幾つかの実施形態では、少なくとも決定ノードのサブセットが
シーケンスに配置されてもよく、該シーケンスの連続するノードは連続して狭くなるカテ
ゴリーに対応する。例えば、ノード７０１、７０２、および、７０３のシーケンスでは、
ノード７０１に示される基準と一致するトラフィックのサブセットはノード７０２に示さ
れる基準と一致してもよく、ノード７０２に示される基準と一致するトラフィックのサブ
セットはノード７０３に示される基準と一致してもよい。ネットワーク・トラフィックの
所与の単位がシーケンスの最後のノードの基準に一致しない場合、当該トラフィック単位
は異なるシーケンスを用いて評価され得る。例えば、パケットがノード７０１および７０
２の基準に一致する（ノード７０１および７０２に対して「はい」の結果によって示され
る）が、ノード７０３に示される基準と一致しない（ノード７０３に対して「いいえ」の
結果によって示される）場合、パケットはノード７０４および７０５のシーケンスを用い
て評価される必要がある。
インスタンス・ホストまたはネットワーク装置に対して定められたカテゴリーにパケット
等のネットワーク・トラフィック単位を分類するために使用され得る手順のステップまた
はルールを確定してもよい。図７は、少なくとも幾つかの実施形態による、ネットワーク
・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るト
ラフィック手順グラフ７５０の実施例を例示する。グラフ７５０は、複数の決定ノードを
有し、各ノードにおいてネットワーク・トラフィックに対する分類基準のそれぞれのセッ
トが示される。少なくとも幾つかの実施形態では、少なくとも決定ノードのサブセットが
シーケンスに配置されてもよく、該シーケンスの連続するノードは連続して狭くなるカテ
ゴリーに対応する。例えば、ノード７０１、７０２、および、７０３のシーケンスでは、
ノード７０１に示される基準と一致するトラフィックのサブセットはノード７０２に示さ
れる基準と一致してもよく、ノード７０２に示される基準と一致するトラフィックのサブ
セットはノード７０３に示される基準と一致してもよい。ネットワーク・トラフィックの
所与の単位がシーケンスの最後のノードの基準に一致しない場合、当該トラフィック単位
は異なるシーケンスを用いて評価され得る。例えば、パケットがノード７０１および７０
２の基準に一致する（ノード７０１および７０２に対して「はい」の結果によって示され
る）が、ノード７０３に示される基準と一致しない（ノード７０３に対して「いいえ」の
結果によって示される）場合、パケットはノード７０４および７０５のシーケンスを用い
て評価される必要がある。
一般的に、所与のトラフィック単位がノードの所与のシーケンスの基準全てと一致する
場合、そのカテゴリーが確定され得る、例えば、ノード７０１、７０２、および、７０３
の基準が満たされる場合にはカテゴリーＣ１パケットとして分類され、ノード７０７およ
び７０８の基準が満たされる場合にはカテゴリーＣ６パケットとして分類され、ノード７
０６の基準が満たされる場合にはカテゴリーＣ５パケットとして分類され、または、ノー
ド７０９の基準が満たされる場合にはカテゴリーＣ７パケットとして分類される。所与の
ノードにおいて示される基準は、異なる実施形態においてネットワーク・トラフィック単
位の様々な特性に関して表されてもよい。例えば、ソースまたは宛先ＩＰアドレス、ポー
ト番号、または、使用されるネットワーク・プロトコル等のパケットの一つ以上のヘッダ
のコンテンツがそのカテゴリーを確定するために使用されてもよく、またはボディのコン
テンツが使用されてもよい。所与のトラフィック単位が手順を用いて分類されるカテゴリ
ーそれぞれは、図示する実施形態においてＮＣＳによって生成される分類ツリーの対応す
るノードに対応してもよい。
場合、そのカテゴリーが確定され得る、例えば、ノード７０１、７０２、および、７０３
の基準が満たされる場合にはカテゴリーＣ１パケットとして分類され、ノード７０７およ
び７０８の基準が満たされる場合にはカテゴリーＣ６パケットとして分類され、ノード７
０６の基準が満たされる場合にはカテゴリーＣ５パケットとして分類され、または、ノー
ド７０９の基準が満たされる場合にはカテゴリーＣ７パケットとして分類される。所与の
ノードにおいて示される基準は、異なる実施形態においてネットワーク・トラフィック単
位の様々な特性に関して表されてもよい。例えば、ソースまたは宛先ＩＰアドレス、ポー
ト番号、または、使用されるネットワーク・プロトコル等のパケットの一つ以上のヘッダ
のコンテンツがそのカテゴリーを確定するために使用されてもよく、またはボディのコン
テンツが使用されてもよい。所与のトラフィック単位が手順を用いて分類されるカテゴリ
ーそれぞれは、図示する実施形態においてＮＣＳによって生成される分類ツリーの対応す
るノードに対応してもよい。
少なくとも原則としては、少なくとも幾つかの実施形態ではパケット分類のために任意
に細かい基準が使用されてもよく、決定ノードの任意に長いシーケンスが生成されてもよ
い。例えば、分類基準は、パケット・ボディの非常に特定的なコンテンツ（パケットのオ
フセットＯ１で特定のバイトレンジ「０ｘｆｆ」が生じるか）、または、パケットまたは
ヘッダ・コンテンツの任意の組み合わせ等に基づいてもよい。分類手順グラフ７５０のサ
イズおよび複雑性を減少させるために、多数の可能な結果を有する決定ノードが幾つかの
実施形態において使用されてもよい。例えば、手順グラフ７５０では、ルックアップ・テ
ーブル７７０を有するノード７０５が含まれる。このようなルックアップ・テーブルそれ
ぞれは、複数の行を有し、その中から所与のトラフィック単位（例えば、パケットの宛先
ＩＰアドレス）の特性に基づいて一行がインデックス付けされるまたは選択されて、分類
の決定が達せられる。ノード７０５の実施例では、分類の決定とは、パケットがカテゴリ
ーＣ２、Ｃ３、または、Ｃ４に属するか否かである。他の場合では、分類の決定は、決定
ノードの追加的なシーケンスを用いてパケットを評価することであり、例えば、ルックア
ップ・テーブル・エントリーが他の分類グラフまたはサブグラフへのポインタとして機能
してもよい。
に細かい基準が使用されてもよく、決定ノードの任意に長いシーケンスが生成されてもよ
い。例えば、分類基準は、パケット・ボディの非常に特定的なコンテンツ（パケットのオ
フセットＯ１で特定のバイトレンジ「０ｘｆｆ」が生じるか）、または、パケットまたは
ヘッダ・コンテンツの任意の組み合わせ等に基づいてもよい。分類手順グラフ７５０のサ
イズおよび複雑性を減少させるために、多数の可能な結果を有する決定ノードが幾つかの
実施形態において使用されてもよい。例えば、手順グラフ７５０では、ルックアップ・テ
ーブル７７０を有するノード７０５が含まれる。このようなルックアップ・テーブルそれ
ぞれは、複数の行を有し、その中から所与のトラフィック単位（例えば、パケットの宛先
ＩＰアドレス）の特性に基づいて一行がインデックス付けされるまたは選択されて、分類
の決定が達せられる。ノード７０５の実施例では、分類の決定とは、パケットがカテゴリ
ーＣ２、Ｃ３、または、Ｃ４に属するか否かである。他の場合では、分類の決定は、決定
ノードの追加的なシーケンスを用いてパケットを評価することであり、例えば、ルックア
ップ・テーブル・エントリーが他の分類グラフまたはサブグラフへのポインタとして機能
してもよい。
図８は、少なくとも幾つかの実施形態による、トラフィック分類手順グラフのルックア
ップ・テーブル・ノード８０５の使用の実施例を例示する。図示する実施形態では、パケ
ットをカテゴリー化するために使用されるべきノード８０５のルックアップ・テーブル７
７０Ａのエントリーを識別するよう、ネットワーク・パケット８１０の一部分にハッシュ
関数８５０が適用されてもよい。ルックアップ・テーブル８０５は、幾つかの場合では、
それ自体が手順の他の決定ノードの評価後に到達され得、即ち、少なくとも幾らかのレベ
ルのカテゴリー化がハッシュ関数８５０の適用前にパケット８１０に対して既に行われて
いてもよい。図示する実施例におけるパケットは宛先ＩＰアドレス「Ｐ．Ｑ．Ｒ．Ｓ」８
０１を有するアウトバウンド・パケットであり、宛先ＩＰアドレスの四つの要素のうちの
第三の要素「Ｒ」がハッシュ関数８５０への入力として使用されて、パケット８１０に対
応するルックアップ・テーブルのエントリーが確定される。例えば、宛先ＩＰアドレスま
たはソースＩＰアドレスの他の部分の値、他のヘッダ・フィールド８０２の値、または、
パケットのボディ８０３のコンテンツさえも含む、パケット８１０の幾つかの特性のいず
れもが、様々な実施形態においてハッシュ関数への入力として使用され得る。ルックアッ
プ・テーブルのエントリーを選択するためにパケットのどの特性が使用されるべきかに関
するルール、および、特性に適用されるべき関数（例えば、ハッシュ関数８５０）は、幾
つかの実施形態において、インスタンス・ホストまたはネットワーク装置等のターゲット
装置における制御モジュールにＮＣＳ１８０による分類メタデータと一緒に供給されても
よい。
ップ・テーブル・ノード８０５の使用の実施例を例示する。図示する実施形態では、パケ
ットをカテゴリー化するために使用されるべきノード８０５のルックアップ・テーブル７
７０Ａのエントリーを識別するよう、ネットワーク・パケット８１０の一部分にハッシュ
関数８５０が適用されてもよい。ルックアップ・テーブル８０５は、幾つかの場合では、
それ自体が手順の他の決定ノードの評価後に到達され得、即ち、少なくとも幾らかのレベ
ルのカテゴリー化がハッシュ関数８５０の適用前にパケット８１０に対して既に行われて
いてもよい。図示する実施例におけるパケットは宛先ＩＰアドレス「Ｐ．Ｑ．Ｒ．Ｓ」８
０１を有するアウトバウンド・パケットであり、宛先ＩＰアドレスの四つの要素のうちの
第三の要素「Ｒ」がハッシュ関数８５０への入力として使用されて、パケット８１０に対
応するルックアップ・テーブルのエントリーが確定される。例えば、宛先ＩＰアドレスま
たはソースＩＰアドレスの他の部分の値、他のヘッダ・フィールド８０２の値、または、
パケットのボディ８０３のコンテンツさえも含む、パケット８１０の幾つかの特性のいず
れもが、様々な実施形態においてハッシュ関数への入力として使用され得る。ルックアッ
プ・テーブルのエントリーを選択するためにパケットのどの特性が使用されるべきかに関
するルール、および、特性に適用されるべき関数（例えば、ハッシュ関数８５０）は、幾
つかの実施形態において、インスタンス・ホストまたはネットワーク装置等のターゲット
装置における制御モジュールにＮＣＳ１８０による分類メタデータと一緒に供給されても
よい。
幾つかのケースでは、（例えば、宛先ＩＰアドレス要素のハッシュ法の結果として）選
択されたルックアップ・テーブルのエントリーが対応するパケットのトラフィック・カテ
ゴリーを直接示してもよい。例えば、ルックアップ・テーブル７７０Ａの要素のうちの一
つを選択することは、図８におけるカテゴリーＡにつながる。ルックアップ・テーブルの
他のエントリー自体も図８のグラフ８８０Ａおよび８８０Ｂのような追加的な手順グラフ
へのポインタとして機能し、その決定ノードはパケット８１０のカテゴリーを確定するた
めにナビゲートされなくてはならない。異なるグラフのノードから評価される基準の結果
として到達される追加的な手順グラフは、本願ではサブグラフとも呼ばれる。図示する実
施例では、決定ノード８５１、８５２（それ自体ルックアップ・テーブル７７０Ｂを有す
るノード）および／または８５３によって示される基準はハッシュ関数８５０が７７０Ａ
の一つのエントリーにつながる場合には評価される必要があり、決定ノード８５４、８５
５、および／または、８５６によって示される基準はハッシュ関数８５０がルックアップ
・テーブル７７０Ａの異なるエントリーの選択を結果とする場合には評価される必要があ
る。手順グラフ８８０Ｂが到達され、要素８５４および８５５に示される基準が満たされ
ると、例えば、パケット８１０は図８の実施例においてトラフィック・カテゴリーＬに属
すると考えられる。分類手順グラフ７５０の様々なノードにルックアップ・テーブル７７
０を組み込むことで、複雑で細かい論理が分類に使用されたとしてもトラフィック分類の
論理の比較的コンパクトな表現が可能となる。
トリガとなるイベントへのネットワーク構成システムの応答
択されたルックアップ・テーブルのエントリーが対応するパケットのトラフィック・カテ
ゴリーを直接示してもよい。例えば、ルックアップ・テーブル７７０Ａの要素のうちの一
つを選択することは、図８におけるカテゴリーＡにつながる。ルックアップ・テーブルの
他のエントリー自体も図８のグラフ８８０Ａおよび８８０Ｂのような追加的な手順グラフ
へのポインタとして機能し、その決定ノードはパケット８１０のカテゴリーを確定するた
めにナビゲートされなくてはならない。異なるグラフのノードから評価される基準の結果
として到達される追加的な手順グラフは、本願ではサブグラフとも呼ばれる。図示する実
施例では、決定ノード８５１、８５２（それ自体ルックアップ・テーブル７７０Ｂを有す
るノード）および／または８５３によって示される基準はハッシュ関数８５０が７７０Ａ
の一つのエントリーにつながる場合には評価される必要があり、決定ノード８５４、８５
５、および／または、８５６によって示される基準はハッシュ関数８５０がルックアップ
・テーブル７７０Ａの異なるエントリーの選択を結果とする場合には評価される必要があ
る。手順グラフ８８０Ｂが到達され、要素８５４および８５５に示される基準が満たされ
ると、例えば、パケット８１０は図８の実施例においてトラフィック・カテゴリーＬに属
すると考えられる。分類手順グラフ７５０の様々なノードにルックアップ・テーブル７７
０を組み込むことで、複雑で細かい論理が分類に使用されたとしてもトラフィック分類の
論理の比較的コンパクトな表現が可能となる。
トリガとなるイベントへのネットワーク構成システムの応答
幾つかの実施形態では、前述の通り、ネットワーク攻撃や侵入等の潜在的に損害を与え
るイベントの検出等のイベントに応答して、帯域幅管理の決定がなされてもよい。ネット
ワーク構成システムを構成する際、例えば、分散システムの特定のサブセットに幾つのＮ
ＣＳがセットアップされるべきかを決定する際、または、どのタイプの計算能力およびメ
タデータ分散能力がネットワーク構成システムに必要かを決定する際に考慮され得る要素
の一つがこのようなイベントへの所望の応答となり得る。図９は、少なくとも幾つかの実
施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定する
ために利用され得る応答メトリックの実施例を例示する。
るイベントの検出等のイベントに応答して、帯域幅管理の決定がなされてもよい。ネット
ワーク構成システムを構成する際、例えば、分散システムの特定のサブセットに幾つのＮ
ＣＳがセットアップされるべきかを決定する際、または、どのタイプの計算能力およびメ
タデータ分散能力がネットワーク構成システムに必要かを決定する際に考慮され得る要素
の一つがこのようなイベントへの所望の応答となり得る。図９は、少なくとも幾つかの実
施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定する
ために利用され得る応答メトリックの実施例を例示する。
時間値が左から右に増加する、模範的な時系列が図９に示される。ブロック９０２に示
されるように、時間Ｔ１において、中央化ネットワーク構成が実施される分散システムの
セキュリティ・サービスがＤＤＯＳ攻撃等の潜在的なネットワーク攻撃が検出される。起
こり得る攻撃は、例えば、分散システムの一つ以上のノードにまたは一つ以上のノードか
ら方向付けられるトラフィック率における急な増加に基づいて識別されてもよい。このよ
うな攻撃は、分散システム内（例えば、プロバイダ・ネットワークの計算インスタンスの
セットを用いて実施されている電子ビジネスのウェブサイト）、または、分散システムの
外部（例えば、繰り返されるリクエストがプロバイダ・ネットワークの計算インスタンス
のセットから外部のウェブサイトに高い率で送られてもよい）の一つ以上のターゲットに
おいて方向付けられてもよい。幾つかのケースでは、トラフィックの増加は、ウェブサイ
ト上でのセール商品に対する急な関心といった正当な理由によるものの場合もあるが、多
くの実施形態では、セキュリティ・サービスがこのような誤判定の確率を低減させるよう
高度な分析技術を使用してもよい。
されるように、時間Ｔ１において、中央化ネットワーク構成が実施される分散システムの
セキュリティ・サービスがＤＤＯＳ攻撃等の潜在的なネットワーク攻撃が検出される。起
こり得る攻撃は、例えば、分散システムの一つ以上のノードにまたは一つ以上のノードか
ら方向付けられるトラフィック率における急な増加に基づいて識別されてもよい。このよ
うな攻撃は、分散システム内（例えば、プロバイダ・ネットワークの計算インスタンスの
セットを用いて実施されている電子ビジネスのウェブサイト）、または、分散システムの
外部（例えば、繰り返されるリクエストがプロバイダ・ネットワークの計算インスタンス
のセットから外部のウェブサイトに高い率で送られてもよい）の一つ以上のターゲットに
おいて方向付けられてもよい。幾つかのケースでは、トラフィックの増加は、ウェブサイ
ト上でのセール商品に対する急な関心といった正当な理由によるものの場合もあるが、多
くの実施形態では、セキュリティ・サービスがこのような誤判定の確率を低減させるよう
高度な分析技術を使用してもよい。
潜在的な攻撃が本当に攻撃か否かに関わらず、ネットワーク構成システムは、図示する
実施形態において、例えば、分散システムの適当なノードに対する帯域幅限界等、新しい
分類メタデータおよび／または新しい構成オプションを生成し、新しいメタデータをなる
べく早く適用することで、応答するよう構成され得る。ブロック９０４によって示される
ように、図示する時系列の時間Ｔ２において、ノードのセットに対する変更されたメタデ
ータが生成されてもよい。例えば、ＩＰアドレスＫ．Ｌ．Ｍ．Ｎから発生されＩＰアドレ
スＥ．Ｆ．Ｇ．Ｈで方向付けられるアウトバウンドＤＤＯＳ攻撃を表すトラフィックが検
出されると、これらのＩＰアドレスに対して帯域幅限界を適用する責任を担うＮＣＳは新
しいメタデータを生成してもよい。例えば、新しいメタデータは、Ｋ．Ｌ．Ｍ．Ｎから発
生されるまたはＥ．Ｆ．Ｇ．Ｈで受信される全てのトラフィックに対して単に新しい帯域
幅限界を（少なくとも一時的に）課してもよい。代替的には、一つ以上の新しいトラフィ
ック・カテゴリーが、具体的には、Ｋ．Ｌ．Ｍ．ＮからＥ．Ｆ．Ｇ．Ｈに流れるトラフィ
ックに対して定められてもよく、これら特定のカテゴリーに対する帯域幅限界が生成され
広められてもよい。
実施形態において、例えば、分散システムの適当なノードに対する帯域幅限界等、新しい
分類メタデータおよび／または新しい構成オプションを生成し、新しいメタデータをなる
べく早く適用することで、応答するよう構成され得る。ブロック９０４によって示される
ように、図示する時系列の時間Ｔ２において、ノードのセットに対する変更されたメタデ
ータが生成されてもよい。例えば、ＩＰアドレスＫ．Ｌ．Ｍ．Ｎから発生されＩＰアドレ
スＥ．Ｆ．Ｇ．Ｈで方向付けられるアウトバウンドＤＤＯＳ攻撃を表すトラフィックが検
出されると、これらのＩＰアドレスに対して帯域幅限界を適用する責任を担うＮＣＳは新
しいメタデータを生成してもよい。例えば、新しいメタデータは、Ｋ．Ｌ．Ｍ．Ｎから発
生されるまたはＥ．Ｆ．Ｇ．Ｈで受信される全てのトラフィックに対して単に新しい帯域
幅限界を（少なくとも一時的に）課してもよい。代替的には、一つ以上の新しいトラフィ
ック・カテゴリーが、具体的には、Ｋ．Ｌ．Ｍ．ＮからＥ．Ｆ．Ｇ．Ｈに流れるトラフィ
ックに対して定められてもよく、これら特定のカテゴリーに対する帯域幅限界が生成され
広められてもよい。
ブロック９０６によって示されるように、図９の模範的な時系列における時間Ｔ３にお
いて、変更された分類メタデータは、適当なインスタンス・ホストまたは他のノードに分
散され、実施されてもよい（幾らかの時間の後、例えば、ネットワーク攻撃が終了した場
合か攻撃を示したトラフィックが正当と分かった場合、分類メタデータは再び変更されて
もよい）。例えば、間隔（Ｔ３乃至Ｔ１）によって示されるように、トリガとなるイベン
トへのネットワーク構成サービスの応答は、例えば、ネットワーク構成サービス・マネー
ジャ２２２によって時間とともに追跡され、使用されるＮＣＳの数またはメタデータの分
散システムの様々な特性を調節するために使用されてもよい。
中央化ネットワーク構成サービスを実施する方法
いて、変更された分類メタデータは、適当なインスタンス・ホストまたは他のノードに分
散され、実施されてもよい（幾らかの時間の後、例えば、ネットワーク攻撃が終了した場
合か攻撃を示したトラフィックが正当と分かった場合、分類メタデータは再び変更されて
もよい）。例えば、間隔（Ｔ３乃至Ｔ１）によって示されるように、トリガとなるイベン
トへのネットワーク構成サービスの応答は、例えば、ネットワーク構成サービス・マネー
ジャ２２２によって時間とともに追跡され、使用されるＮＣＳの数またはメタデータの分
散システムの様々な特性を調節するために使用されてもよい。
中央化ネットワーク構成サービスを実施する方法
図１０は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのコンポー
ネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。要素１
００１に示されるように、サービスの様々な初期またはデフォルトのパラメータが、例え
ば、グローバル帯域幅管理ポリシー、ネットワーク構成が実施されるサービスの利用可能
性および／または性能要件を考慮して、確定されてもよい。このようなパラメータは、例
えば、各利用可能コンテナまたは各データ・センターに構成されるべきＮＣＳ１８０の数
、メタデータ搬送スケジュールおよびプロトコル（例えば、ＮＣＳがメタデータ転送を開
始するプッシュ・プロトコルがデフォルトとして使用されるべきか否か、または、インス
タンス・ホストが必要に応じて分類メタデータをリクエストするプル・プロトコルが使用
されるべきか）、メタデータ転送をもたらす追加的なトリガとなるイベントのタイプ、Ｎ
ＣＳへの入力ソースおよび／またはＮＣＳの決定の結果が供給される出力の宛先を含んで
もよい。
ネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。要素１
００１に示されるように、サービスの様々な初期またはデフォルトのパラメータが、例え
ば、グローバル帯域幅管理ポリシー、ネットワーク構成が実施されるサービスの利用可能
性および／または性能要件を考慮して、確定されてもよい。このようなパラメータは、例
えば、各利用可能コンテナまたは各データ・センターに構成されるべきＮＣＳ１８０の数
、メタデータ搬送スケジュールおよびプロトコル（例えば、ＮＣＳがメタデータ転送を開
始するプッシュ・プロトコルがデフォルトとして使用されるべきか否か、または、インス
タンス・ホストが必要に応じて分類メタデータをリクエストするプル・プロトコルが使用
されるべきか）、メタデータ転送をもたらす追加的なトリガとなるイベントのタイプ、Ｎ
ＣＳへの入力ソースおよび／またはＮＣＳの決定の結果が供給される出力の宛先を含んで
もよい。
少なくとも幾つかの実施形態では、プログラマチック・インターフェイスのセットが実
施されてもよく（要素１００４）、それによりクライアントおよび／または管理者はＮＣ
Ｓの決定を選択的に無効にすることができる。例えば、一実施形態では、幾らかのクライ
アントは、（例えば、アプリケーション・ワークロード・レベルにおける予想増加に基づ
いて）ＮＣＳによって選択される帯域幅限界を超えて様々な帯域幅限界を増加させるリク
エストを出す、または、（例えば、トラフィック関連の請求金額を下げるよう）ＮＣＳが
確定する帯域幅限界より下となるようトラフィックのあるカテゴリーに対する帯域幅限界
を制限するリクエストを出すことができる。様々な他のタイプのオプションに対するクラ
イアントおよび／または管理者からの構成リクエストも、待ち時間関連の設定、サービス
品質の設定等のためにサポートされてもよい。
施されてもよく（要素１００４）、それによりクライアントおよび／または管理者はＮＣ
Ｓの決定を選択的に無効にすることができる。例えば、一実施形態では、幾らかのクライ
アントは、（例えば、アプリケーション・ワークロード・レベルにおける予想増加に基づ
いて）ＮＣＳによって選択される帯域幅限界を超えて様々な帯域幅限界を増加させるリク
エストを出す、または、（例えば、トラフィック関連の請求金額を下げるよう）ＮＣＳが
確定する帯域幅限界より下となるようトラフィックのあるカテゴリーに対する帯域幅限界
を制限するリクエストを出すことができる。様々な他のタイプのオプションに対するクラ
イアントおよび／または管理者からの構成リクエストも、待ち時間関連の設定、サービス
品質の設定等のためにサポートされてもよい。
要素１００１に対応する動作において確定されるパラメータに応じて、適当な数のＮＣ
Ｓ１８０が選択された場所でインスタンス化されてもよい（要素１００７）。ネットワー
ク接続はＮＣＳと分散システムまたはプロバイダ・ネットワークの様々な他の要素との間
に確立されてもよく（要素１０１０）、例えば、ＮＣＳとＮＣＳによる決定が実施される
インスタンス・ホスト１４４および他のネットワーク装置１４５との間、ＮＣＳとＮＣＳ
の決定に影響を及ぼす入力データ・ソースとの間、および、ＮＣＳと継続的にＮＣＳから
ネットワーク情報を取得することに関心のある全ての出力宛先との間で確立される。少な
くとも幾つかの実施形態では、ＴＬＳ（トランスポート層セキュリティ）やＳＳＬ（セキ
ュア・ソケット層）等の安全なネットワーク・プロトコルがＮＣＳと分散システムの少な
くとも幾つかの他の要素との間のネットワーク接続のために使用されてもよい。
Ｓ１８０が選択された場所でインスタンス化されてもよい（要素１００７）。ネットワー
ク接続はＮＣＳと分散システムまたはプロバイダ・ネットワークの様々な他の要素との間
に確立されてもよく（要素１０１０）、例えば、ＮＣＳとＮＣＳによる決定が実施される
インスタンス・ホスト１４４および他のネットワーク装置１４５との間、ＮＣＳとＮＣＳ
の決定に影響を及ぼす入力データ・ソースとの間、および、ＮＣＳと継続的にＮＣＳから
ネットワーク情報を取得することに関心のある全ての出力宛先との間で確立される。少な
くとも幾つかの実施形態では、ＴＬＳ（トランスポート層セキュリティ）やＳＳＬ（セキ
ュア・ソケット層）等の安全なネットワーク・プロトコルがＮＣＳと分散システムの少な
くとも幾つかの他の要素との間のネットワーク接続のために使用されてもよい。
図１１は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのトラフィ
ック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図
である。図示する実施形態では、ＮＣＳは反復アプローチを用いてもよく、各反復中、入
力のセットがターゲット・ノード（例えば、インスタンス・ホスト）のセットに分散され
適用されるネットワーク管理パラメータを確定するために使用され、メトリックスがター
ゲット・ノードや他のソースから収集され次の反復に対するパラメータに影響を与えるま
たはパラメータを確定するよう入力としてフィードバックされる。要素１１０１に示され
るように、所与の時間間隔中、所与のＮＣＳは、インスタンス・ホストおよび／またはス
イッチ、ルーター、ゲートウェイ等のネットワーク装置を含む分散システムの様々なノー
ドから取得されるネットワーク関連メトリックスのセットを受信してもよい。例えば、測
定された入来／出発トラフィック率、パケット損失率、パケット制限率等を含み得るこの
ようなメトリックスは、ＮＣＳによるトラフィック分類メタデータの次の反復を生成する
ために使用され得る。幾つかのケースでは、メトリックスは、例えば、健康管理サービス
のノードのようなメトリックス収集システムのノードを介してＮＣＳに供給されてもよい
。更に、ＮＣＳは、図示する実施形態において、セキュリティ関連のサービス、ＩＰアド
レス毎のトラフィック集合部、クライアント毎のトラフィック集合部等を含む他の入力ソ
ースから様々な入力を取得してもよい。クライアントおよび／または管理者は、ＮＣＳに
よって一つ以上のトラフィック・カテゴリーに先に適用された帯域幅限界を増加または低
減させるためのリクエスト等の構成リクエストをＮＣＳに要請してもよく、このような構
成リクエストはトラフィック分類メタデータの次の反復を確定する際に入力として使用さ
れてもよい。
ック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図
である。図示する実施形態では、ＮＣＳは反復アプローチを用いてもよく、各反復中、入
力のセットがターゲット・ノード（例えば、インスタンス・ホスト）のセットに分散され
適用されるネットワーク管理パラメータを確定するために使用され、メトリックスがター
ゲット・ノードや他のソースから収集され次の反復に対するパラメータに影響を与えるま
たはパラメータを確定するよう入力としてフィードバックされる。要素１１０１に示され
るように、所与の時間間隔中、所与のＮＣＳは、インスタンス・ホストおよび／またはス
イッチ、ルーター、ゲートウェイ等のネットワーク装置を含む分散システムの様々なノー
ドから取得されるネットワーク関連メトリックスのセットを受信してもよい。例えば、測
定された入来／出発トラフィック率、パケット損失率、パケット制限率等を含み得るこの
ようなメトリックスは、ＮＣＳによるトラフィック分類メタデータの次の反復を生成する
ために使用され得る。幾つかのケースでは、メトリックスは、例えば、健康管理サービス
のノードのようなメトリックス収集システムのノードを介してＮＣＳに供給されてもよい
。更に、ＮＣＳは、図示する実施形態において、セキュリティ関連のサービス、ＩＰアド
レス毎のトラフィック集合部、クライアント毎のトラフィック集合部等を含む他の入力ソ
ースから様々な入力を取得してもよい。クライアントおよび／または管理者は、ＮＣＳに
よって一つ以上のトラフィック・カテゴリーに先に適用された帯域幅限界を増加または低
減させるためのリクエスト等の構成リクエストをＮＣＳに要請してもよく、このような構
成リクエストはトラフィック分類メタデータの次の反復を確定する際に入力として使用さ
れてもよい。
ＮＣＳにおいて、メトリックスや受信した入力は、例えば、グローバルおよび／または
ローカル・ネットワーク管理ポリシーを考慮して、図示する実施形態においてトラフィッ
ク分類メタデータを確定するために使用されてもよい（要素１１０４）。グローバル・ポ
リシーは、例えば、ネットワーク・インフラストラクチャの様々な部分のターゲット利用
限界、同様のレベルのサービスに登録した異なるクライアントからのトラフィックを扱う
ための公平要件、実施される異なるネットワーク・アクセス可能サービスに対してネット
ワーク・トラフィックに与えられるべき相対的優先順位等を示してもよい。ローカル・ポ
リシーは、例えば、ネットワーク・インフラストラクチャや能力が他の利用可能コンテナ
またはデータ・センターのネットワーク・インフラストラクチャや能力と異なる、所与の
利用可能コンテナまたは所与のデータ・センターで適用されるルールを示してもよい。分
散システムの所与のターゲット・ノードに対して生成された分類メタデータは、ターゲッ
ト・ノードで使用されるべきトラフィック分類階層（例えば、図５に示す構造と同様のツ
リー・データ構造において表される階層）、および、階層において定められるカテゴリー
にネットワーク・トラフィックの単位を分類するために使用されるべき手順またはルール
のセット（例えば、図７に示すグラフと同様のグラフを用いて表すことができる手順）を
含んでもよい。階層において定められる各トラフィック・カテゴリーに対して、例えば、
平均的トラフィックに対して定められる帯域幅限界および短期間バーストに対して定めら
れる異なる帯域幅限界、待ち時間要件、パケット・サイズに依存する要件、または、優先
順位設定を含む帯域幅限界等の対応するネットワーク構成オプションが一つ以上確定され
てもよい。幾つかのケースでは、カテゴリーおよび／またはオプションのそれぞれのセッ
トが入来／出発トラフィックに対して定められてもよい。少なくとも幾つかの実施形態で
は、分類階層および／または手順は、異なるインスタンス・ホストおよび／またはネット
ワーク装置に対してカスタマイズされてもよく、例えば、一つのセットのクライアント・
アプリケーションに対して使用される所与のホストＨ１は、異なるセットのクライアント
・アプリケーションが実施される別のホストＨ２とは定められるトラフィック・カテゴリ
ーが異なり、当該カテゴリーに課せられる帯域幅限界が異なる。
ローカル・ネットワーク管理ポリシーを考慮して、図示する実施形態においてトラフィッ
ク分類メタデータを確定するために使用されてもよい（要素１１０４）。グローバル・ポ
リシーは、例えば、ネットワーク・インフラストラクチャの様々な部分のターゲット利用
限界、同様のレベルのサービスに登録した異なるクライアントからのトラフィックを扱う
ための公平要件、実施される異なるネットワーク・アクセス可能サービスに対してネット
ワーク・トラフィックに与えられるべき相対的優先順位等を示してもよい。ローカル・ポ
リシーは、例えば、ネットワーク・インフラストラクチャや能力が他の利用可能コンテナ
またはデータ・センターのネットワーク・インフラストラクチャや能力と異なる、所与の
利用可能コンテナまたは所与のデータ・センターで適用されるルールを示してもよい。分
散システムの所与のターゲット・ノードに対して生成された分類メタデータは、ターゲッ
ト・ノードで使用されるべきトラフィック分類階層（例えば、図５に示す構造と同様のツ
リー・データ構造において表される階層）、および、階層において定められるカテゴリー
にネットワーク・トラフィックの単位を分類するために使用されるべき手順またはルール
のセット（例えば、図７に示すグラフと同様のグラフを用いて表すことができる手順）を
含んでもよい。階層において定められる各トラフィック・カテゴリーに対して、例えば、
平均的トラフィックに対して定められる帯域幅限界および短期間バーストに対して定めら
れる異なる帯域幅限界、待ち時間要件、パケット・サイズに依存する要件、または、優先
順位設定を含む帯域幅限界等の対応するネットワーク構成オプションが一つ以上確定され
てもよい。幾つかのケースでは、カテゴリーおよび／またはオプションのそれぞれのセッ
トが入来／出発トラフィックに対して定められてもよい。少なくとも幾つかの実施形態で
は、分類階層および／または手順は、異なるインスタンス・ホストおよび／またはネット
ワーク装置に対してカスタマイズされてもよく、例えば、一つのセットのクライアント・
アプリケーションに対して使用される所与のホストＨ１は、異なるセットのクライアント
・アプリケーションが実施される別のホストＨ２とは定められるトラフィック・カテゴリ
ーが異なり、当該カテゴリーに課せられる帯域幅限界が異なる。
トラフィック分類階層および分類手順のそれぞれのポータブルな表現または符号化は、
図示する実施形態では、ターゲット・ノードへの送信のためにＮＣＳにおいて生成され得
る（要素１１０７）。ＪＳＯＮ、ＸＭＬ、ＹＡＭＬ等の業界標準プロトコルまたは言語が
幾つかの実施において使用され、独自の符号化スキームが他の実施において使用されても
よい。ポータブルな表現は、メタデータが適用されるか使用されるべきターゲットに送信
される（要素１１１０）。少なくとも一つの実施において、単一のまたは組み合わされた
符号化が分類カテゴリーおよび手順の両方に対して使用され、他の実施において、分類カ
テゴリーおよび手順のそれぞれの別個の表現が使用されてもよい。幾つかの実施形態では
、例えば、先の反復から変更されたメタデータの部分だけがターゲットに送信される差分
メタデータ送信技術が使用され得る。他の実施形態では、メタデータ全体が各反復におい
て送信される完全送信アプローチ法が使用され得る。様々な実施形態では、スケジューリ
ングされたプッシュ送信（メタデータがターゲットにＮＣＳ主導でプッシュされる）、プ
ル送信（ＮＣＳがターゲットからのリクエストに応じて分類メタデータを送信する）、お
よび、イベントにトリガされたメタデータ送信（あるタイプのイベントを検出すると、Ｎ
ＣＳがメタデータを生成しおよび／または送信する）の組み合わせが使用されてもよい。
所与の反復に対するメタデータが適当なターゲットに送られた後、ＮＣＳは、例えば、要
素１１０１以降に対応する動作を繰り返すことで次の反復を開始する。
図示する実施形態では、ターゲット・ノードへの送信のためにＮＣＳにおいて生成され得
る（要素１１０７）。ＪＳＯＮ、ＸＭＬ、ＹＡＭＬ等の業界標準プロトコルまたは言語が
幾つかの実施において使用され、独自の符号化スキームが他の実施において使用されても
よい。ポータブルな表現は、メタデータが適用されるか使用されるべきターゲットに送信
される（要素１１１０）。少なくとも一つの実施において、単一のまたは組み合わされた
符号化が分類カテゴリーおよび手順の両方に対して使用され、他の実施において、分類カ
テゴリーおよび手順のそれぞれの別個の表現が使用されてもよい。幾つかの実施形態では
、例えば、先の反復から変更されたメタデータの部分だけがターゲットに送信される差分
メタデータ送信技術が使用され得る。他の実施形態では、メタデータ全体が各反復におい
て送信される完全送信アプローチ法が使用され得る。様々な実施形態では、スケジューリ
ングされたプッシュ送信（メタデータがターゲットにＮＣＳ主導でプッシュされる）、プ
ル送信（ＮＣＳがターゲットからのリクエストに応じて分類メタデータを送信する）、お
よび、イベントにトリガされたメタデータ送信（あるタイプのイベントを検出すると、Ｎ
ＣＳがメタデータを生成しおよび／または送信する）の組み合わせが使用されてもよい。
所与の反復に対するメタデータが適当なターゲットに送られた後、ＮＣＳは、例えば、要
素１１０１以降に対応する動作を繰り返すことで次の反復を開始する。
分散システムのターゲット・ノードでは、制御モジュール（例えば、図３に示すネット
ワーク・マネージャ３５７等）はメタデータ表現を受信し解釈するよう構成され得る。メ
タデータは、パケット等のネットワーク・トラフィックの単位を分類し、対応する帯域幅
限界を適用してトラフィック単位の送信をスケジューリングするおよび／または制限する
ために使用され得る（要素１１１３）。幾つかの実施では、ノードで既に利用可能な「ｔ
ｃ」等のオペレーティング・システム・ユーティリティまたはツールがＮＣＳによって生
成された論理を実施するために使用されてもよい。他の実施では、カスタム・ツールまた
はユーティリティが使用されてもよい。メトリックスは、例えば、様々な性能ツール等を
用いてターゲット・ノードから収集され、ＮＣＳへの入力として使用されてもよい。
ワーク・マネージャ３５７等）はメタデータ表現を受信し解釈するよう構成され得る。メ
タデータは、パケット等のネットワーク・トラフィックの単位を分類し、対応する帯域幅
限界を適用してトラフィック単位の送信をスケジューリングするおよび／または制限する
ために使用され得る（要素１１１３）。幾つかの実施では、ノードで既に利用可能な「ｔ
ｃ」等のオペレーティング・システム・ユーティリティまたはツールがＮＣＳによって生
成された論理を実施するために使用されてもよい。他の実施では、カスタム・ツールまた
はユーティリティが使用されてもよい。メトリックスは、例えば、様々な性能ツール等を
用いてターゲット・ノードから収集され、ＮＣＳへの入力として使用されてもよい。
図１２は、少なくとも幾つかの実施形態による、トリガとなるイベントに応答してネッ
トワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図であ
る。要素１２０１に示されるように、潜在的なＤＤＯＳ攻撃等、トラフィック分類メタデ
ータに対する変更を結果としてもたらすイベントが検出され得る。幾つかの実施形態では
、プロバイダ・ネットワークは一つ以上のセキュリティ・サービスを確立して様々な種類
の起こり得る攻撃を示す疑いのあるトラフィック・パターンを識別してもよい。このよう
なサービスはネットワーク構成システムと通信されてもよい。攻撃によって影響を与えら
れるまたは攻撃に寄与する分散システムの特定のノード（例えば、インスタンス・ホスト
および／またはスイッチ、ルーター等のネットワーク装置）は、図示する実施形態では、
例えば、セキュリティ・サービス、ＮＣＳ、または、セキュリティ・サービスとＮＣＳの
組み合わせのいずれかにより識別される（要素１２０４）。
トワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図であ
る。要素１２０１に示されるように、潜在的なＤＤＯＳ攻撃等、トラフィック分類メタデ
ータに対する変更を結果としてもたらすイベントが検出され得る。幾つかの実施形態では
、プロバイダ・ネットワークは一つ以上のセキュリティ・サービスを確立して様々な種類
の起こり得る攻撃を示す疑いのあるトラフィック・パターンを識別してもよい。このよう
なサービスはネットワーク構成システムと通信されてもよい。攻撃によって影響を与えら
れるまたは攻撃に寄与する分散システムの特定のノード（例えば、インスタンス・ホスト
および／またはスイッチ、ルーター等のネットワーク装置）は、図示する実施形態では、
例えば、セキュリティ・サービス、ＮＣＳ、または、セキュリティ・サービスとＮＣＳの
組み合わせのいずれかにより識別される（要素１２０４）。
トラフィック分類メタデータの変更されたセットは、攻撃の影響を緩和するようＮＣＳ
で生成される（要素１２０７）。変更は、例えば、（例えば、疑いのあるトラフィックを
送信するおよび／または受信することに関わる特定のノードのアドレスに基づいて）定め
られるトラフィックの新しいカテゴリー、および／または、適用されるべき新しい帯域幅
限界または他のネットワーク構成オプションを含み得る。続いて、新しいメタデータは、
幾つかの実施形態において、攻撃に関連するまたはターゲットとされる特定のノードおよ
び／または他のノード（例えば、疑いのあるトラフィックが通る路に沿った中間物である
ネットワーク装置）を含み得る、分散システムのノードの選択されたセットに送信されて
もよい。
で生成される（要素１２０７）。変更は、例えば、（例えば、疑いのあるトラフィックを
送信するおよび／または受信することに関わる特定のノードのアドレスに基づいて）定め
られるトラフィックの新しいカテゴリー、および／または、適用されるべき新しい帯域幅
限界または他のネットワーク構成オプションを含み得る。続いて、新しいメタデータは、
幾つかの実施形態において、攻撃に関連するまたはターゲットとされる特定のノードおよ
び／または他のノード（例えば、疑いのあるトラフィックが通る路に沿った中間物である
ネットワーク装置）を含み得る、分散システムのノードの選択されたセットに送信されて
もよい。
トリガとなる状態に応答するのにかかる時間、例えば、状態の検出と新しいメタデータ
の適用との間の間隔が測定され、記録される（要素１２１０）。このようなトリガとなる
イベントへのネットワーク構成システムの応答における傾向および／またはネットワーク
構成システムがとる動作の有効性が、時間とともに分析され、構成を変化させる必要があ
るか否かが確定される（要素１２１３）。応答が不十分とされた場合、例えば、任意の数
の構成変化が行われる。例えば、検出されたイベントにより有効的に応答するよう、ＮＣ
Ｓの数が増加される、イベント検出部とＮＣＳとの間の接続性が改善される、メタデータ
分散システムが向上される、および／または、ＮＣＳまたはターゲット・ノードでの論理
が変更される。
の適用との間の間隔が測定され、記録される（要素１２１０）。このようなトリガとなる
イベントへのネットワーク構成システムの応答における傾向および／またはネットワーク
構成システムがとる動作の有効性が、時間とともに分析され、構成を変化させる必要があ
るか否かが確定される（要素１２１３）。応答が不十分とされた場合、例えば、任意の数
の構成変化が行われる。例えば、検出されたイベントにより有効的に応答するよう、ＮＣ
Ｓの数が増加される、イベント検出部とＮＣＳとの間の接続性が改善される、メタデータ
分散システムが向上される、および／または、ＮＣＳまたはターゲット・ノードでの論理
が変更される。
図１３は、少なくとも幾つかの実施形態による、分散システムのクライアントにネット
ワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示す
るフロー図である。要素１３０１に示されるように、一つ以上のプログラマチック・イン
ターフェイス（例えば、ウェブページまたはコンソール、ＡＰＩ、ＧＵＩ、または、コマ
ンド・ライン・ツール）は、関心のある様々な分散システム資源のネットワーク・ステー
タスの統一されたカスタマイズ可能なビューをクライアントに提供するよう確立されても
よい。例えば、クライアントは、仮想化されたコンピューティング・サービスの多数の計
算インスタンスが割り当てられてもよく、最後の１５分間でどの特定のインスタンスが帯
域幅の制限に影響されたかを知りたいと望む場合がある。プログラマチック・インターフ
ェイスにより、クライアントは様々なフィルタを使用して表示されるべきネットワーク特
性および／または特性が表示されるべき資源のセットを特定し得る。
ワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示す
るフロー図である。要素１３０１に示されるように、一つ以上のプログラマチック・イン
ターフェイス（例えば、ウェブページまたはコンソール、ＡＰＩ、ＧＵＩ、または、コマ
ンド・ライン・ツール）は、関心のある様々な分散システム資源のネットワーク・ステー
タスの統一されたカスタマイズ可能なビューをクライアントに提供するよう確立されても
よい。例えば、クライアントは、仮想化されたコンピューティング・サービスの多数の計
算インスタンスが割り当てられてもよく、最後の１５分間でどの特定のインスタンスが帯
域幅の制限に影響されたかを知りたいと望む場合がある。プログラマチック・インターフ
ェイスにより、クライアントは様々なフィルタを使用して表示されるべきネットワーク特
性および／または特性が表示されるべき資源のセットを特定し得る。
ネットワーク・ステータス・リクエストがインターフェイスを介して受信され、関心の
あるメトリックスおよび資源が示される（要素１３０４）。ネットワーク構成システムは
、例えば、メトリックス・データベース１９０（要素１３０７）から、または、ＮＣＳに
おけるキャッシュからリクエストされたメトリックスを引き出してもよい。幾つかの実施
形態では、リクエストに応答する際に有用となり得る適用可能な分類メタデータも分類デ
ータベース１９２（要素１３１０）またはＮＣＳにおけるメタデータ・キャッシュから引
き出されてもよい。収集された情報を用いて、ネットワーク・ステータス・リクエストに
対する応答が生成され、プログラマチック・インターフェイスを介してリクエスタに供給
される（要素１３１３）。
ネットワーク・トポロジーに対する資源使用の可視化ツール
あるメトリックスおよび資源が示される（要素１３０４）。ネットワーク構成システムは
、例えば、メトリックス・データベース１９０（要素１３０７）から、または、ＮＣＳに
おけるキャッシュからリクエストされたメトリックスを引き出してもよい。幾つかの実施
形態では、リクエストに応答する際に有用となり得る適用可能な分類メタデータも分類デ
ータベース１９２（要素１３１０）またはＮＣＳにおけるメタデータ・キャッシュから引
き出されてもよい。収集された情報を用いて、ネットワーク・ステータス・リクエストに
対する応答が生成され、プログラマチック・インターフェイスを介してリクエスタに供給
される（要素１３１３）。
ネットワーク・トポロジーに対する資源使用の可視化ツール
上述した通り、ネットワーク構成サービスはプロバイダ・ネットワークのような分散シ
ステムの様々なコンポーネントから様々なメトリックスを収集し、これらのメトリックス
を用い、少なくとも幾つかのノードに対して帯域幅限界等の設定を確定する。少なくとも
一つの実施形態では、性能インジケータまたは資源使用インジケータ（例えば、様々なノ
ードでのそれぞれの測定されたネットワーク・トラフィック率とこれらのノードに対して
設定されたそれぞれの帯域幅限界との間の比の色分けされた表現またはヒートマップ）を
表示することができる一つ以上の可視化ツールが実施されてもよい。一実施形態によると
、資源ヒートマップおよび／または他のタイプの可視化を提供するよう構成されるネット
ワーク・トポロジー可視化サーバーは、ネットワーク構成サーバー１８０のサブコンポー
ネントとして実施されてもよい。他の実施形態では、ネットワーク・トポロジー可視化ツ
ールは、ネットワーク構成サーバー１８０とは独立して実施されてもよく、例えば、分散
システムの別の中央化サービスとして、または、単独型エンティティとして実施されても
よく、ＮＣＳ１８０と相互に作用する或いはＮＣＳ１８０によって収集されたデータを消
費し得る。少なくとも幾つかの実施では、統合ネットワーク・ビュー生成部１５２（図１
に示す）は、その特徴の一つとしてトポロジー可視化インターフェイスを含み得る。
ステムの様々なコンポーネントから様々なメトリックスを収集し、これらのメトリックス
を用い、少なくとも幾つかのノードに対して帯域幅限界等の設定を確定する。少なくとも
一つの実施形態では、性能インジケータまたは資源使用インジケータ（例えば、様々なノ
ードでのそれぞれの測定されたネットワーク・トラフィック率とこれらのノードに対して
設定されたそれぞれの帯域幅限界との間の比の色分けされた表現またはヒートマップ）を
表示することができる一つ以上の可視化ツールが実施されてもよい。一実施形態によると
、資源ヒートマップおよび／または他のタイプの可視化を提供するよう構成されるネット
ワーク・トポロジー可視化サーバーは、ネットワーク構成サーバー１８０のサブコンポー
ネントとして実施されてもよい。他の実施形態では、ネットワーク・トポロジー可視化ツ
ールは、ネットワーク構成サーバー１８０とは独立して実施されてもよく、例えば、分散
システムの別の中央化サービスとして、または、単独型エンティティとして実施されても
よく、ＮＣＳ１８０と相互に作用する或いはＮＣＳ１８０によって収集されたデータを消
費し得る。少なくとも幾つかの実施では、統合ネットワーク・ビュー生成部１５２（図１
に示す）は、その特徴の一つとしてトポロジー可視化インターフェイスを含み得る。
中央化トポロジー可視化サーバー（ＴＶＳ）は、少なくとも幾つかの実施形態において
分散システムの様々なノード間の論理的および／または物理的関係を確定するよう構成さ
れてもよい。例えば、仮想コンピューティング・サービスが実施される実施形態では、Ｔ
ＶＳは、インスタンス・ホストのセットで様々な計算インスタンスが割り当てられるクラ
イアント・アカウントを確定し、アカウント情報を使用して特定のクライアント・アカウ
ントまたはクライアント・アカウントの選択されたセットに割り当てられた計算インスタ
ンスだけを含むトポロジーを生成してもよい。当該クライアント・アカウント（またはア
カウントのセット）と関係するクライアントからの可視化リクエストに応答して、当該ト
ポロジーのインスタンスに対する性能インジケータを示すヒートマップが提供されてもよ
い。一つ以上のデータ・センターで実施されるネットワーク・アクセス可能サービスの管
理者に対して、様々なインスタンス、ホストおよび／またはスイッチ、ルーター等のネッ
トワーク装置間の物理的または論理的ネットワーク・リンクを示し得る、より詳細なトポ
ロジーが生成され、サービスの非管理クライアントには典型的にはアクセス可能でない情
報を用いて対応するヒートマップが生成され得る。各ケースにおいて、クライアントまた
は管理者には、生成されたヒートマップを用いて、様々なタイプの資源の使用統計の理解
しやすい視覚表示が提供されてもよい。続いて、使用統計が使用されて、例えば、潜在的
な障害または他のタイプの問題が積極的に特定されて、応答作用が行われる。ヒートマッ
プに表示される色の範囲、および、色間の遷移境界は、示されるメトリックのレベルを示
すために選択可能である。例えば、一実施では、最近測定されたトラフィック率が当該ノ
ードに対する帯域幅限界に非常に近いことを示すようネットワーク・トポロジーの所与の
ノードに対して赤色が表示され、測定されたトラフィックが限界をはるかに下回ることを
示すよう緑色が使用され、赤から緑への遷移色がトラフィックの中間レベルに対して使用
されてもよい。
分散システムの様々なノード間の論理的および／または物理的関係を確定するよう構成さ
れてもよい。例えば、仮想コンピューティング・サービスが実施される実施形態では、Ｔ
ＶＳは、インスタンス・ホストのセットで様々な計算インスタンスが割り当てられるクラ
イアント・アカウントを確定し、アカウント情報を使用して特定のクライアント・アカウ
ントまたはクライアント・アカウントの選択されたセットに割り当てられた計算インスタ
ンスだけを含むトポロジーを生成してもよい。当該クライアント・アカウント（またはア
カウントのセット）と関係するクライアントからの可視化リクエストに応答して、当該ト
ポロジーのインスタンスに対する性能インジケータを示すヒートマップが提供されてもよ
い。一つ以上のデータ・センターで実施されるネットワーク・アクセス可能サービスの管
理者に対して、様々なインスタンス、ホストおよび／またはスイッチ、ルーター等のネッ
トワーク装置間の物理的または論理的ネットワーク・リンクを示し得る、より詳細なトポ
ロジーが生成され、サービスの非管理クライアントには典型的にはアクセス可能でない情
報を用いて対応するヒートマップが生成され得る。各ケースにおいて、クライアントまた
は管理者には、生成されたヒートマップを用いて、様々なタイプの資源の使用統計の理解
しやすい視覚表示が提供されてもよい。続いて、使用統計が使用されて、例えば、潜在的
な障害または他のタイプの問題が積極的に特定されて、応答作用が行われる。ヒートマッ
プに表示される色の範囲、および、色間の遷移境界は、示されるメトリックのレベルを示
すために選択可能である。例えば、一実施では、最近測定されたトラフィック率が当該ノ
ードに対する帯域幅限界に非常に近いことを示すようネットワーク・トポロジーの所与の
ノードに対して赤色が表示され、測定されたトラフィックが限界をはるかに下回ることを
示すよう緑色が使用され、赤から緑への遷移色がトラフィックの中間レベルに対して使用
されてもよい。
幾つかの実施形態によると、ＴＶＳは、分散システムにおける様々なソースからメトリ
ックスの集まりを取得し、分散システムの様々なコンポーネントについて関係情報を取得
し、収集されたメトリックスおよび関係情報に基づいて様々なタイプのネットワーク・ト
ポリジーについて性能インジケータ（例えば、個別性能メトリックス、または、適用可能
な限界へのメトリックスの比）を確定する責任を担う。クライアントまたは管理者が資源
性能インジケータのカスタマイズされたまたはフィルタリングされた可視化をリクエスト
することを可能にするプログラマチック可視化インターフェイスが実施されてもよく、Ｔ
ＶＳはデータ・セットの適当なサブセットを用いて性能インジケータのヒートマップおよ
び／または他のグラフィカル表現を合成することで可視化リクエストに応えてもよい。幾
つかの実施では、一つ以上のこれらタスクは、以下により詳細に説明するように、分散シ
ステムの他のコンポーネントまたはサービスとの相互作用を伴い得る。
ックスの集まりを取得し、分散システムの様々なコンポーネントについて関係情報を取得
し、収集されたメトリックスおよび関係情報に基づいて様々なタイプのネットワーク・ト
ポリジーについて性能インジケータ（例えば、個別性能メトリックス、または、適用可能
な限界へのメトリックスの比）を確定する責任を担う。クライアントまたは管理者が資源
性能インジケータのカスタマイズされたまたはフィルタリングされた可視化をリクエスト
することを可能にするプログラマチック可視化インターフェイスが実施されてもよく、Ｔ
ＶＳはデータ・セットの適当なサブセットを用いて性能インジケータのヒートマップおよ
び／または他のグラフィカル表現を合成することで可視化リクエストに応えてもよい。幾
つかの実施では、一つ以上のこれらタスクは、以下により詳細に説明するように、分散シ
ステムの他のコンポーネントまたはサービスとの相互作用を伴い得る。
図１４は、少なくとも幾つかの実施形態による、分散システムの少なくともノードのサ
ブセットについてトポロジー可視化サーバー（ＴＶＳ）１４１０によって生成され得るカ
スタマイズ可能なヒートマップ１４５０の実施例を例示する。図示する実施形態では、Ｔ
ＶＳはネットワーク構成サーバー１８０の構成要素として実施される。他の実施形態では
、ＴＶＳ１４１０は、ＮＣＳとは独立した或いはＮＣＳの外部の一つ以上のハードウェア
またはソフトウェア・コンポーネントを用いて実施されてもよく、例えば、中央化可視化
サービスは幾つかのこのような実施形態ではＮＣＳが不在の状態で実施されてもよい。Ｔ
ＶＳ１４１０は、アカウント管理サービス１４２０、配置サービス１５１、在庫サービス
１４３０、並びに、メトリックス・コレクタ１２５を含み、図１４に示す実施形態におけ
る幾つかのタイプのデータ・ソースからの入力を取得してもよい。
ブセットについてトポロジー可視化サーバー（ＴＶＳ）１４１０によって生成され得るカ
スタマイズ可能なヒートマップ１４５０の実施例を例示する。図示する実施形態では、Ｔ
ＶＳはネットワーク構成サーバー１８０の構成要素として実施される。他の実施形態では
、ＴＶＳ１４１０は、ＮＣＳとは独立した或いはＮＣＳの外部の一つ以上のハードウェア
またはソフトウェア・コンポーネントを用いて実施されてもよく、例えば、中央化可視化
サービスは幾つかのこのような実施形態ではＮＣＳが不在の状態で実施されてもよい。Ｔ
ＶＳ１４１０は、アカウント管理サービス１４２０、配置サービス１５１、在庫サービス
１４３０、並びに、メトリックス・コレクタ１２５を含み、図１４に示す実施形態におけ
る幾つかのタイプのデータ・ソースからの入力を取得してもよい。
アカウント管理サービス１４２０は、一つ以上のマルチテナントまたはシングルテナン
ト・サービス・インスタンス（例えば、仮想化されたコンピューティング・サービス、ス
トレージ装置、または、データベース・サービス）の様々なサービス・インスタンスが割
り当てられるクライアント・アカウント（および／または関係するユーザまたはグループ
・アカウント）に関する情報をＴＶＳ１４１０に供給してもよい。前述の通り、配置サー
ビス１５１は、様々なサービス・インスタンスが立ち上げられるインスタンス・ホストを
特定する責任を担うため、ネットワーク・トポロジーを生成する上で有用となるインスタ
ンス−ホスト・マッピングを少なくとも幾つかの実施形態において提供することができる
。在庫サービス１４３０は、一つ以上のデータ・センター内のどこに様々なインスタンス
・ホスト、スイッチ、ルーター、および、分散システムの他の機器部品が物理的に位置し
ているかを記録するデータベースを管理してもよい。図１の文脈で前述した通り、メトリ
ックス・コレクタ１２５は、分散システム内の様々なサービス・インスタンス、ホスト、
ネットワーク装置等からネットワーク関連および／または他の資源のメトリックスを集め
てもよい。例えば、ネットワーク関連のメトリックスについて、ソースは中でも（ａ）ネ
ットワーク・インターフェイス・カード、（ｂ）仮想化ホストにインストールされる仮想
化ソフトウェア・スタックのネットワーク・コンポーネント、（ｃ）計算インスタンスの
ネットワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（
ｆ）ルーター、（ｇ）ゲートウェイ、または（ｈ）ロード・バランサを含んでもよい。幾
つかの実施形態において、図１４に示される様々なタイプのデータ・ソースの全てがＴＶ
Ｓ１４１０によって使用されないことに注意する。例えば、幾つかの実施では、配置サー
ビスは様々なノードに関する物理的な場所情報を供給することができるため、在庫管理サ
ービスとの相互作用はこのような実施では必要とされない。
ト・サービス・インスタンス（例えば、仮想化されたコンピューティング・サービス、ス
トレージ装置、または、データベース・サービス）の様々なサービス・インスタンスが割
り当てられるクライアント・アカウント（および／または関係するユーザまたはグループ
・アカウント）に関する情報をＴＶＳ１４１０に供給してもよい。前述の通り、配置サー
ビス１５１は、様々なサービス・インスタンスが立ち上げられるインスタンス・ホストを
特定する責任を担うため、ネットワーク・トポロジーを生成する上で有用となるインスタ
ンス−ホスト・マッピングを少なくとも幾つかの実施形態において提供することができる
。在庫サービス１４３０は、一つ以上のデータ・センター内のどこに様々なインスタンス
・ホスト、スイッチ、ルーター、および、分散システムの他の機器部品が物理的に位置し
ているかを記録するデータベースを管理してもよい。図１の文脈で前述した通り、メトリ
ックス・コレクタ１２５は、分散システム内の様々なサービス・インスタンス、ホスト、
ネットワーク装置等からネットワーク関連および／または他の資源のメトリックスを集め
てもよい。例えば、ネットワーク関連のメトリックスについて、ソースは中でも（ａ）ネ
ットワーク・インターフェイス・カード、（ｂ）仮想化ホストにインストールされる仮想
化ソフトウェア・スタックのネットワーク・コンポーネント、（ｃ）計算インスタンスの
ネットワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（
ｆ）ルーター、（ｇ）ゲートウェイ、または（ｈ）ロード・バランサを含んでもよい。幾
つかの実施形態において、図１４に示される様々なタイプのデータ・ソースの全てがＴＶ
Ｓ１４１０によって使用されないことに注意する。例えば、幾つかの実施では、配置サー
ビスは様々なノードに関する物理的な場所情報を供給することができるため、在庫管理サ
ービスとの相互作用はこのような実施では必要とされない。
これら様々なソースから収集されたデータは、ＴＶＳ１４１０によって合成され、可視
化リクエストに応答して模範的なヒートマップ１４５０等の様々なカスタマイズ可能なヒ
ートマップが生成される。ヒートマップ１４５０は、クライアント・アカウントＣＡ１に
割り当てられた五つの計算インスタンス（ＣＩ）、例えば、利用可能コンテナ２０３Ａに
おけるＣＩ１４４０Ａ、１４４０Ｂ、および、１４４０Ｃ、および利用可能コンテナ２０
３ＢにおけるＣＩ１４４０Ｄおよび１４４０Ｅを有するネットワーク・トポロジー１４６
０を示す。幾つかのケースでは、ＴＶＳ１４１０によって生成されたトポロジーは、様々
な実施形態において、データ・センター境界、利用可能コンテナ境界（図１４に示すよう
な）、または、他の組織的或いは物理的境界をわたる。トポロジー１４６０における各計
算インスタンス１４４０について、それぞれの色点けされた性能インジケータ（ＰＩ）１
４７０が表示され、例えば、ＣＩ１４４０Ａ、１４４０Ｂ、１４４０Ｃ、１４４０Ｄ、お
よび、１４４０Ｅに対してＰＩ１４７０Ａ、１４７０Ｂ、１４７０Ｃ、１４７０Ｄ、およ
び、１４７０Ｅが示される。ＰＩ１４７０は、異なる実施形態において様々な異なるタイ
プのメトリックスまたはメトリックスと関連付けられる比を示し、符号化された性能情報
のタイプは少なくとも幾つかの実施においてカスタマイズ可能である。例えば、入来およ
び／または出発トラフィックに対する、現在構成されている帯域幅限界に対する測定され
たトラフィック率の比が表示されてもよい。このような模範的なシナリオでは、赤色ＰＩ
は測定されたトラフィックが帯域幅限界に近い（例えば、その７５％より大きい）ことを
示し、緑色ＰＩは比が３０％より下であることを示し、黄色ＰＩは比が３０％乃至７５％
の間であることを示している。幾つかの実施では、数値またはテキストメッセージが各ノ
ードに対して示されてもよい（例えば、比の値がパーセンテージとして表示されてもよい
）。異なる実施形態において、ネットワーク帯域幅関連インジケータ、待ち時間関連イン
ジケータ（例えば、最近測定された待ち時間がパケット待ち時間に対して要求される上界
にどれだけ近いか、或いは、測定された平均的パケット転送待ち時間と待ち時間に対する
ターゲット上界との間の比）、閾値に対するＣＰＵ利用レベル、ストレージ装置利用レベ
ル、メモリ利用レベル等を含む、幾つかの異なるタイプの性能インジケータがＴＶＳによ
って表示されてもよい。幾つかの実施形態では、ヒートマップに比が示されることに加え
て或いはその代わりに（例えば、何らかの定義された閾値に対する測定された値の比）、
絶対値が示されてもよい。少なくとも幾つかの実施において、ヒートマップは可視化サー
ビスによって提供された情報に基づいてクライアント側のコンポーネント（例えば、ウェ
ブブラウザまたはＧＵＩツール）によって表示されてもよい。そのため、上述のような実
施において、可視化サービスは、メトリックスを取得し、トポロジーや性能インジケータ
を確定し、クライアント側のコンポーネントに何らかの適当なフォーマットでヒートマッ
トに含まれるようデータの選択されたセットを供給することについて、責任を担っている
。クライアント側のコンポーネントは、可視化サービスによって提供されるデータを用い
てヒートマップを表示する。少なくとも幾つかの実施形態では、可視化サービスは、バッ
クエンド・コンポーネントとフロントエンド・コンポーネントの両方を有し、バックエン
ド・コンポーネントはヒートマップの形態で提示され得る基礎データの生成に関与し、フ
ロントエンド・コンポーネントはヒートマップの実際の表示に関与する。
化リクエストに応答して模範的なヒートマップ１４５０等の様々なカスタマイズ可能なヒ
ートマップが生成される。ヒートマップ１４５０は、クライアント・アカウントＣＡ１に
割り当てられた五つの計算インスタンス（ＣＩ）、例えば、利用可能コンテナ２０３Ａに
おけるＣＩ１４４０Ａ、１４４０Ｂ、および、１４４０Ｃ、および利用可能コンテナ２０
３ＢにおけるＣＩ１４４０Ｄおよび１４４０Ｅを有するネットワーク・トポロジー１４６
０を示す。幾つかのケースでは、ＴＶＳ１４１０によって生成されたトポロジーは、様々
な実施形態において、データ・センター境界、利用可能コンテナ境界（図１４に示すよう
な）、または、他の組織的或いは物理的境界をわたる。トポロジー１４６０における各計
算インスタンス１４４０について、それぞれの色点けされた性能インジケータ（ＰＩ）１
４７０が表示され、例えば、ＣＩ１４４０Ａ、１４４０Ｂ、１４４０Ｃ、１４４０Ｄ、お
よび、１４４０Ｅに対してＰＩ１４７０Ａ、１４７０Ｂ、１４７０Ｃ、１４７０Ｄ、およ
び、１４７０Ｅが示される。ＰＩ１４７０は、異なる実施形態において様々な異なるタイ
プのメトリックスまたはメトリックスと関連付けられる比を示し、符号化された性能情報
のタイプは少なくとも幾つかの実施においてカスタマイズ可能である。例えば、入来およ
び／または出発トラフィックに対する、現在構成されている帯域幅限界に対する測定され
たトラフィック率の比が表示されてもよい。このような模範的なシナリオでは、赤色ＰＩ
は測定されたトラフィックが帯域幅限界に近い（例えば、その７５％より大きい）ことを
示し、緑色ＰＩは比が３０％より下であることを示し、黄色ＰＩは比が３０％乃至７５％
の間であることを示している。幾つかの実施では、数値またはテキストメッセージが各ノ
ードに対して示されてもよい（例えば、比の値がパーセンテージとして表示されてもよい
）。異なる実施形態において、ネットワーク帯域幅関連インジケータ、待ち時間関連イン
ジケータ（例えば、最近測定された待ち時間がパケット待ち時間に対して要求される上界
にどれだけ近いか、或いは、測定された平均的パケット転送待ち時間と待ち時間に対する
ターゲット上界との間の比）、閾値に対するＣＰＵ利用レベル、ストレージ装置利用レベ
ル、メモリ利用レベル等を含む、幾つかの異なるタイプの性能インジケータがＴＶＳによ
って表示されてもよい。幾つかの実施形態では、ヒートマップに比が示されることに加え
て或いはその代わりに（例えば、何らかの定義された閾値に対する測定された値の比）、
絶対値が示されてもよい。少なくとも幾つかの実施において、ヒートマップは可視化サー
ビスによって提供された情報に基づいてクライアント側のコンポーネント（例えば、ウェ
ブブラウザまたはＧＵＩツール）によって表示されてもよい。そのため、上述のような実
施において、可視化サービスは、メトリックスを取得し、トポロジーや性能インジケータ
を確定し、クライアント側のコンポーネントに何らかの適当なフォーマットでヒートマッ
トに含まれるようデータの選択されたセットを供給することについて、責任を担っている
。クライアント側のコンポーネントは、可視化サービスによって提供されるデータを用い
てヒートマップを表示する。少なくとも幾つかの実施形態では、可視化サービスは、バッ
クエンド・コンポーネントとフロントエンド・コンポーネントの両方を有し、バックエン
ド・コンポーネントはヒートマップの形態で提示され得る基礎データの生成に関与し、フ
ロントエンド・コンポーネントはヒートマップの実際の表示に関与する。
幾つかの実施形態によると、ＴＶＳ１４１０のユーザは、可視化において表示される情
報の粒度を調節することができる。例えば、一実施では、ネットワーク関連の性能インジ
ケータに関して、クライアントは次の粒度のいずれかに対して好みを示し得る：（ａ）ポ
ートレベルの粒度（例えば、ＴＣＰまたはＵＤＰポートのレベルでの情報が好ましい）、
（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レ
ベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・
センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用
可能コンテナレベルの粒度、または（ｉ）地理的領域レベルの粒度。粒度の選択肢は、様
々な実施形態において、ストレージ関連のメトリックス等、性能インジケータが表示され
得る他のタイプの資源またはメトリックスに対して選択されてもよい。ＴＶＳ１４１０は
、要求された粒度で収集されたメトリックスを統合して、可視化または表示に含まれるよ
う性能インジケータを確定してもよい。表示されるネットワーク関連情報の粒度をカスタ
マイズ化することに加えて、少なくとも一実施形態では、表示が様々なトラフィック・カ
テゴリーについてカスタマイズ化されてもよい。例えば、分散システムの所与のノードへ
のまたは所与のノードからのネットワーク・トラフィックはエンドポイントＩＰアドレス
に基づいて（例えば、トラフィックがプロバイダ・ネットワーク内の二つのインスタンス
間を、または、プロバイダ・ネットワーク外にある公衆インターネット・アドレスに流れ
ているか）、トラフィックのエンドポイントが割り当てられるクライアント・アカウント
に基づいて、または、トラフィックが生成されるアプリケーションまたはアプリケーショ
ン・タイプ（例えば、データベース関連のトラフィック特有のヒートマップが要求される
、または、高性能計算特有のヒートマップが要求される）に基づいて分類されてもよい。
図５に例示するようなトラフィック分類は、表示される情報をフィルタリングするために
幾つかの実施形態において使用されてもよい。少なくとも幾つかの実施において、ＴＶＳ
のクライアントは、性能インジケータを表示したいトラフィック・カテゴリーをプログラ
ムで定めてもよい。例えば、クライアントは、その割り当てられた計算インスタンスの一
つのセットをソースセットとして指定し、インスタンスの別のセットまたは他のエンドポ
イント（例えば、特定のデータベース・インスタンス）を宛先として指定し、指定された
セットに基づいてトラフィック・カテゴリーを定めてもよい。
報の粒度を調節することができる。例えば、一実施では、ネットワーク関連の性能インジ
ケータに関して、クライアントは次の粒度のいずれかに対して好みを示し得る：（ａ）ポ
ートレベルの粒度（例えば、ＴＣＰまたはＵＤＰポートのレベルでの情報が好ましい）、
（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レ
ベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・
センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用
可能コンテナレベルの粒度、または（ｉ）地理的領域レベルの粒度。粒度の選択肢は、様
々な実施形態において、ストレージ関連のメトリックス等、性能インジケータが表示され
得る他のタイプの資源またはメトリックスに対して選択されてもよい。ＴＶＳ１４１０は
、要求された粒度で収集されたメトリックスを統合して、可視化または表示に含まれるよ
う性能インジケータを確定してもよい。表示されるネットワーク関連情報の粒度をカスタ
マイズ化することに加えて、少なくとも一実施形態では、表示が様々なトラフィック・カ
テゴリーについてカスタマイズ化されてもよい。例えば、分散システムの所与のノードへ
のまたは所与のノードからのネットワーク・トラフィックはエンドポイントＩＰアドレス
に基づいて（例えば、トラフィックがプロバイダ・ネットワーク内の二つのインスタンス
間を、または、プロバイダ・ネットワーク外にある公衆インターネット・アドレスに流れ
ているか）、トラフィックのエンドポイントが割り当てられるクライアント・アカウント
に基づいて、または、トラフィックが生成されるアプリケーションまたはアプリケーショ
ン・タイプ（例えば、データベース関連のトラフィック特有のヒートマップが要求される
、または、高性能計算特有のヒートマップが要求される）に基づいて分類されてもよい。
図５に例示するようなトラフィック分類は、表示される情報をフィルタリングするために
幾つかの実施形態において使用されてもよい。少なくとも幾つかの実施において、ＴＶＳ
のクライアントは、性能インジケータを表示したいトラフィック・カテゴリーをプログラ
ムで定めてもよい。例えば、クライアントは、その割り当てられた計算インスタンスの一
つのセットをソースセットとして指定し、インスタンスの別のセットまたは他のエンドポ
イント（例えば、特定のデータベース・インスタンス）を宛先として指定し、指定された
セットに基づいてトラフィック・カテゴリーを定めてもよい。
一実施形態では、可視化リクエストは、時間的コンポーネントを含み得、例えば、リク
エストは、特定されたタイプのメトリックについて、表示される性能インジケータを生成
するためにメトリックスが収集される時間期間を示す。幾つかの実施形態では、クライア
ントは、例えば、特定された時間期間にわたる所与の性能インジケータの値における変動
が示される、動的可視化をリクエストすることができる。可視化のリクエスタに割り当て
られる許可能力または役割（例えば、リクエスタがサービスに対して管理的アクセス許可
を有するか、非管理的アクセス許可を有するか）は、様々な実施形態において表示され得
る情報の種類を制御する暗黙のフィルタとしても機能する。幾つかの実施形態では、中央
化可視化サービスは、二つ以上のネットワーク・アクセス可能サービスに関連する資源メ
トリックスまたは性能インジケータを見ることに有用であり、可視化の消費者は性能イン
ジケータが表示されるサービスを示すことができる。例えば、プロバイダ・ネットワーク
の所与のクライアント・アカウントは、プロバイダ・ネットワークによって実施される関
係型データベース・サービスおよび非関係型データベース・サービスの両方を使用しても
よく、別個のヒートマップが二つの異なるタイプのデータベース・サービスに対してそれ
ぞれのトポロジーおよび関連ネットワーク性能インジケータについて生成されてもよい。
エストは、特定されたタイプのメトリックについて、表示される性能インジケータを生成
するためにメトリックスが収集される時間期間を示す。幾つかの実施形態では、クライア
ントは、例えば、特定された時間期間にわたる所与の性能インジケータの値における変動
が示される、動的可視化をリクエストすることができる。可視化のリクエスタに割り当て
られる許可能力または役割（例えば、リクエスタがサービスに対して管理的アクセス許可
を有するか、非管理的アクセス許可を有するか）は、様々な実施形態において表示され得
る情報の種類を制御する暗黙のフィルタとしても機能する。幾つかの実施形態では、中央
化可視化サービスは、二つ以上のネットワーク・アクセス可能サービスに関連する資源メ
トリックスまたは性能インジケータを見ることに有用であり、可視化の消費者は性能イン
ジケータが表示されるサービスを示すことができる。例えば、プロバイダ・ネットワーク
の所与のクライアント・アカウントは、プロバイダ・ネットワークによって実施される関
係型データベース・サービスおよび非関係型データベース・サービスの両方を使用しても
よく、別個のヒートマップが二つの異なるタイプのデータベース・サービスに対してそれ
ぞれのトポロジーおよび関連ネットワーク性能インジケータについて生成されてもよい。
トポロジー可視化サーバーの異なる消費者は、収集されたメトリックスの異なるサブセ
ットにアクセスする許可が与えられるため、幾つかの実施形態では異なるレベルの詳細で
可視化が提供される。図１５は、少なくとも幾つかの実施形態による、サービス管理者お
よびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る
収集されたメトリックスの異なるサブセットの実施例を例示する。図示するように、管理
者アクセス可能メトリックス１５１０は、図示する実施形態において非管理クライアント
によってアクセス可能なメトリックスのスーパーセットでもよい。例えば、仮想コンピュ
ーティング・サービスおよび一つ以上の仮想化されたストレージ・サービス等の様々な仮
想化されたマルチテナント・サービスが実施されるプロバイダ・ネットワークでは、仮想
化を実施するために使用される物理的資源に関する情報（例えば、使用されるインスタン
ス・ホスト、使用されるネットワーク装置、様々なデータ・センター内の物理的資源の配
置）が幾つかの理由により秘密と考えられている。使用されるハードウェア・プロセッサ
および装置のタイプ等の詳細をサービス・クライアントに提供することは、ハードウェア
の詳細を考慮することなく様々なサービス特徴を絶えず利用するといったクライアントの
能力等、仮想化されたサービスを実施する主な目標の一つに反する。しかしながら、仮想
化されたサービスの管理者は、例えば、ハードウェア・サーバー、ラック、ネットワーク
装置等の適当な数やタイプを提供するために、使用されるハードウェアに関する少なくと
も幾らかの詳細を知る必要がある。したがって、管理者は、図示する実施形態において非
管理クラアイントに提供されるよりもＴＶＳ１４１０によって生成されるより詳細なヒー
トマップを見ることができる。
ットにアクセスする許可が与えられるため、幾つかの実施形態では異なるレベルの詳細で
可視化が提供される。図１５は、少なくとも幾つかの実施形態による、サービス管理者お
よびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る
収集されたメトリックスの異なるサブセットの実施例を例示する。図示するように、管理
者アクセス可能メトリックス１５１０は、図示する実施形態において非管理クライアント
によってアクセス可能なメトリックスのスーパーセットでもよい。例えば、仮想コンピュ
ーティング・サービスおよび一つ以上の仮想化されたストレージ・サービス等の様々な仮
想化されたマルチテナント・サービスが実施されるプロバイダ・ネットワークでは、仮想
化を実施するために使用される物理的資源に関する情報（例えば、使用されるインスタン
ス・ホスト、使用されるネットワーク装置、様々なデータ・センター内の物理的資源の配
置）が幾つかの理由により秘密と考えられている。使用されるハードウェア・プロセッサ
および装置のタイプ等の詳細をサービス・クライアントに提供することは、ハードウェア
の詳細を考慮することなく様々なサービス特徴を絶えず利用するといったクライアントの
能力等、仮想化されたサービスを実施する主な目標の一つに反する。しかしながら、仮想
化されたサービスの管理者は、例えば、ハードウェア・サーバー、ラック、ネットワーク
装置等の適当な数やタイプを提供するために、使用されるハードウェアに関する少なくと
も幾らかの詳細を知る必要がある。したがって、管理者は、図示する実施形態において非
管理クラアイントに提供されるよりもＴＶＳ１４１０によって生成されるより詳細なヒー
トマップを見ることができる。
幾つかの実施形態では、非管理クライアントに曝された情報のタイプは、所与のクライ
アント・アカウントまたはリンク付けされたクライアント・アカウントのセットに割り当
てられたインスタンスについて帯域幅限界に対する測定されたネットワーク・トラフィッ
クの比等、サービス・インスタンス・レベルの性能インジケータを含んでもよい。幾つか
の実施形態では、クライアント・アカウントは私的部門または公的部門エンティティ、或
いは、このようなエンティティ内の部門を含む組織の代わりにプロバイダ・ネットワーク
の一つ以上のネットワーク・アクセス可能サービスで確立されてもよい。各クライアント
・アカウントは、幾つかの実施において幾つかの異なるユーザ・アカウントまたはグルー
プ・アカウントを包含してもよい。少なくとも幾つかの実施形態では、例えば、それぞれ
クライアント・アカウントが確立された大企業の二つの異なる部門に対する総請求のため
に、異なるクライアント・アカウントがリンク付けされてもよい。クライアントＣ２にア
クセス可能なインスタンス関連メトリックス１５１５Ｂ等、ＴＶＳによって収集されたメ
トリックスの幾つかは、一つのクライアント・アカウント（例えば、該アカウントに対し
て定められたユーザ／グループ）にだけ可視である。クライアントＣ１およびＣ２に可視
なインスタンス関連メトリックス１５１５Ａ等、他のメトリックスは複数のリンク付けさ
れたクライアント・アカウントと関係するユーザ／グループに可視である。
アント・アカウントまたはリンク付けされたクライアント・アカウントのセットに割り当
てられたインスタンスについて帯域幅限界に対する測定されたネットワーク・トラフィッ
クの比等、サービス・インスタンス・レベルの性能インジケータを含んでもよい。幾つか
の実施形態では、クライアント・アカウントは私的部門または公的部門エンティティ、或
いは、このようなエンティティ内の部門を含む組織の代わりにプロバイダ・ネットワーク
の一つ以上のネットワーク・アクセス可能サービスで確立されてもよい。各クライアント
・アカウントは、幾つかの実施において幾つかの異なるユーザ・アカウントまたはグルー
プ・アカウントを包含してもよい。少なくとも幾つかの実施形態では、例えば、それぞれ
クライアント・アカウントが確立された大企業の二つの異なる部門に対する総請求のため
に、異なるクライアント・アカウントがリンク付けされてもよい。クライアントＣ２にア
クセス可能なインスタンス関連メトリックス１５１５Ｂ等、ＴＶＳによって収集されたメ
トリックスの幾つかは、一つのクライアント・アカウント（例えば、該アカウントに対し
て定められたユーザ／グループ）にだけ可視である。クライアントＣ１およびＣ２に可視
なインスタンス関連メトリックス１５１５Ａ等、他のメトリックスは複数のリンク付けさ
れたクライアント・アカウントと関係するユーザ／グループに可視である。
様々な実施形態において、幾つかのメトリックスのタイプは、非管理ユーザにアクセス
可能でない。例えば、スイッチ、ルーター、ゲートウェイ等の特定のネットワーク装置と
関連付けられるメトリックス１５５０は、典型的には、非管理者に曝されない。同様にし
て、インスタンス・ホスト（複数のクライアントに対してサービス・インスタンスを潜在
的に実施するハードウェア・コンピューティング装置）について収集されたメトリックス
も管理者によってのみアクセスされ得る。図示する実施形態では、データ・センターに関
するメトリックス（例えば、特定のデータ・センターに流入し、流出するトラフィック量
）も管理的使用にのみ制限されてもよい。
可能でない。例えば、スイッチ、ルーター、ゲートウェイ等の特定のネットワーク装置と
関連付けられるメトリックス１５５０は、典型的には、非管理者に曝されない。同様にし
て、インスタンス・ホスト（複数のクライアントに対してサービス・インスタンスを潜在
的に実施するハードウェア・コンピューティング装置）について収集されたメトリックス
も管理者によってのみアクセスされ得る。図示する実施形態では、データ・センターに関
するメトリックス（例えば、特定のデータ・センターに流入し、流出するトラフィック量
）も管理的使用にのみ制限されてもよい。
したがって、ＴＶＳ１４１０によって異なる消費者カテゴリーについて生成されたヒー
トマップのタイプは異なる。図示する実施形態において、クライアントＣ１にはメトリッ
クス１５１５Ａから導出された比較的制限されたヒートマップ１４５０Ａが提供され、ク
ライアントＣ２はソース・メトリックスが１５１５Ａおよび１５１５Ｂの両方を含むヒー
トマップ１４５０Ｂを見ることができる。管理ユーザは、より大きいメトリックスの集ま
り１５１０から導出されたヒートマップ１４５０Ｃを見ることができる。所与の可視化リ
クエストに応答するよう使用されるべきメトリックスのサブセットについての決定は、例
えば、許可設定の確定、リクエスタの能力または役割に基づいて、少なくとも幾つかの実
施形態では、ランタイムでＴＶＳによってなされてもよい。
可視化のためのプログラマチック・インターフェイス
トマップのタイプは異なる。図示する実施形態において、クライアントＣ１にはメトリッ
クス１５１５Ａから導出された比較的制限されたヒートマップ１４５０Ａが提供され、ク
ライアントＣ２はソース・メトリックスが１５１５Ａおよび１５１５Ｂの両方を含むヒー
トマップ１４５０Ｂを見ることができる。管理ユーザは、より大きいメトリックスの集ま
り１５１０から導出されたヒートマップ１４５０Ｃを見ることができる。所与の可視化リ
クエストに応答するよう使用されるべきメトリックスのサブセットについての決定は、例
えば、許可設定の確定、リクエスタの能力または役割に基づいて、少なくとも幾つかの実
施形態では、ランタイムでＴＶＳによってなされてもよい。
可視化のためのプログラマチック・インターフェイス
幾つかの異なるタイプのプログラマチック・インターフェイスが、異なる実施形態にお
いて、可視化リクエストを受信し応答するために使用されてもよい。図１６は、少なくと
も幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示する
ために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示
する。図示するように、ウェブベースのインターフェイスは、ネットワーク・トポロジー
のノード１６１０Ａ、１６１０Ｂ、および、１６１０Ｃが性能インジケータ１６２０Ａ、
１６２０Ｂ、および、１６２０Ｃのそれぞれのセットと一緒に表示される、ウェブページ
１６０２を有する。
いて、可視化リクエストを受信し応答するために使用されてもよい。図１６は、少なくと
も幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示する
ために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示
する。図示するように、ウェブベースのインターフェイスは、ネットワーク・トポロジー
のノード１６１０Ａ、１６１０Ｂ、および、１６１０Ｃが性能インジケータ１６２０Ａ、
１６２０Ｂ、および、１６２０Ｃのそれぞれのセットと一緒に表示される、ウェブページ
１６０２を有する。
性能インジケータ１６２０は、ネットワーク帯域幅（図１６においてラベル「ＢＷ」に
よって示される）、ＣＰＵ、ディスク、および、メモリ（ラベル「Ｍｅｍ」によって示さ
れる）等、図示する実施例においてノードそれぞれについて複数の資源タイプに対する色
付けされたエントリーを示す。ヒートマップを変更するまたはカスタマイズ化する幾つか
のウェブベースの制御が図１６に例示される。例えば、ズーム制御１６５０は、トポロジ
ーの異なる部分にズームインする、または、ズームアウトするためにビューアによって使
用されてもよい。資源セレクタ１６５２は、可視化から幾つかのタイプの資源をフィルタ
で除去する、または、資源タイプを追加するために使用されてもよい。同様のセレクタが
、表示のための時間期間（即ち、性能インジケータに対するメトリックスの使用の集まり
に対応する時間の期間）、ネットワーク・トラフィック・カテゴリー、アプリケーション
・タイプ等を選択するためにも有用である。図示する実施形態では、ビューアは、可視化
に使用する閾値１６５４を特定することも可能であり、例えば、ビューアは、帯域幅限界
の８０％（またはそれより高い）の測定された転送速度が赤色ＢＷ性能インジケータによ
って示され、３０％未満の値が緑色ＢＷ性能インジケータによって示される等と示しても
よい。
よって示される）、ＣＰＵ、ディスク、および、メモリ（ラベル「Ｍｅｍ」によって示さ
れる）等、図示する実施例においてノードそれぞれについて複数の資源タイプに対する色
付けされたエントリーを示す。ヒートマップを変更するまたはカスタマイズ化する幾つか
のウェブベースの制御が図１６に例示される。例えば、ズーム制御１６５０は、トポロジ
ーの異なる部分にズームインする、または、ズームアウトするためにビューアによって使
用されてもよい。資源セレクタ１６５２は、可視化から幾つかのタイプの資源をフィルタ
で除去する、または、資源タイプを追加するために使用されてもよい。同様のセレクタが
、表示のための時間期間（即ち、性能インジケータに対するメトリックスの使用の集まり
に対応する時間の期間）、ネットワーク・トラフィック・カテゴリー、アプリケーション
・タイプ等を選択するためにも有用である。図示する実施形態では、ビューアは、可視化
に使用する閾値１６５４を特定することも可能であり、例えば、ビューアは、帯域幅限界
の８０％（またはそれより高い）の測定された転送速度が赤色ＢＷ性能インジケータによ
って示され、３０％未満の値が緑色ＢＷ性能インジケータによって示される等と示しても
よい。
図１７は、少なくとも幾つかの実施形態による、プログラマチック・インターフェイス
１７７０を介してトポロジー可視化サーバー１４１０によって受信され得る可視化リクエ
スト１７２０の模範的な要素を例示する。このようなリクエストは、例えば、クラアイン
トまたは管理者１７１０による制御１６５０、１６５２、または、１６５４と同様の一つ
以上の制御の選択に応答して、幾つかの実施形態において、図１６に示すようなウェブペ
ージを介して行われてもよい。他の実施形態では、このようなリクエストは異なるＧＵＩ
、ＡＰＩ呼び出しを介してまたはコマンド・ライン・ツールから要請されてもよい。
１７７０を介してトポロジー可視化サーバー１４１０によって受信され得る可視化リクエ
スト１７２０の模範的な要素を例示する。このようなリクエストは、例えば、クラアイン
トまたは管理者１７１０による制御１６５０、１６５２、または、１６５４と同様の一つ
以上の制御の選択に応答して、幾つかの実施形態において、図１６に示すようなウェブペ
ージを介して行われてもよい。他の実施形態では、このようなリクエストは異なるＧＵＩ
、ＡＰＩ呼び出しを介してまたはコマンド・ライン・ツールから要請されてもよい。
図示するように、リクエスト１７２０は、可視化に含まれるべきサービス・ノードのセ
ットを示すターゲット・サービス・ノード・リスト１７２５を有してもよい。幾つかの実
施形態では、特定のセットのノードの表示がリクエスタによって提供されない場合、サー
ビス・ノードのセットに対するデフォルト設定がＴＶＳ１４１０によって使用されてもよ
い。例えば、デフォルトで、クライアント・アカウントに割り当てられた全ての計算イン
スタンスが可視化のために選択される、または、管理者がリクエストを要請するデータ・
センター内の全てのインスタンス・ホストが可視化に含まれ得る候補として考えられる。
ノードのセットは、幾つかの実施形態において明確に示されてもよい（例えば、計算イン
スタンス識別子等のノード識別子のリストを提供することで）、または、ノードを検索す
るために使用され得るフィルタリング基準を示すことで（例えば、クライアントは特定さ
れた利用可能コンテナにおける計算インスタンスがセットに含まれるべきと示してもよい
）。可視化に含まれるべきネットワーク・トラフィックのカテゴリーおよび／または資源
も要素１７２８を用いてトポロジー可視化リクエストに示されてもよい。前述した通り、
トラフィック・カテゴリーは、幾つかの実施形態において、クライアントによって定めら
れてもよい。他の実施形態では、クライアントまたは管理者１７１０が、クライアントが
定めたカテゴリーの代わりに或いはそれに加えて、複数の所定のトラフィック・カテゴリ
ーの中から選択してもよい。幾つかの実施形態では、例えば、計算インスタンスだけを示
すヒートマップが提供されるべきか、または、ストレージ・ノードが含まれるべきか等、
資源の異なるカテゴリーも選択可能である。
ットを示すターゲット・サービス・ノード・リスト１７２５を有してもよい。幾つかの実
施形態では、特定のセットのノードの表示がリクエスタによって提供されない場合、サー
ビス・ノードのセットに対するデフォルト設定がＴＶＳ１４１０によって使用されてもよ
い。例えば、デフォルトで、クライアント・アカウントに割り当てられた全ての計算イン
スタンスが可視化のために選択される、または、管理者がリクエストを要請するデータ・
センター内の全てのインスタンス・ホストが可視化に含まれ得る候補として考えられる。
ノードのセットは、幾つかの実施形態において明確に示されてもよい（例えば、計算イン
スタンス識別子等のノード識別子のリストを提供することで）、または、ノードを検索す
るために使用され得るフィルタリング基準を示すことで（例えば、クライアントは特定さ
れた利用可能コンテナにおける計算インスタンスがセットに含まれるべきと示してもよい
）。可視化に含まれるべきネットワーク・トラフィックのカテゴリーおよび／または資源
も要素１７２８を用いてトポロジー可視化リクエストに示されてもよい。前述した通り、
トラフィック・カテゴリーは、幾つかの実施形態において、クライアントによって定めら
れてもよい。他の実施形態では、クライアントまたは管理者１７１０が、クライアントが
定めたカテゴリーの代わりに或いはそれに加えて、複数の所定のトラフィック・カテゴリ
ーの中から選択してもよい。幾つかの実施形態では、例えば、計算インスタンスだけを示
すヒートマップが提供されるべきか、または、ストレージ・ノードが含まれるべきか等、
資源の異なるカテゴリーも選択可能である。
可視化の粒度１７３１は、例えば（ネットワーク・トラフィックに対して）ホスト・レ
ベルのビューが望ましいか、インスタンスレベルのビューが望ましいか等、幾つかの実施
形態において、リクエスト１７２０に示されてもよい。可視化を生成するために使用され
るべき様々なソースからのメトリックスの集まりの時間範囲は要素１７３４を介して示さ
れてもよい。幾つかの実施では、クライアントは動的可視化をリクエストすることができ
、例えば、選択された時間期間にわたる性能インジケータの値の変化が要素１７３７を介
して示されるクライアントの好みに応じて表示されてもよい。少なくとも幾つかの実施形
態において、リクエスト１７２０の要素に対して利用可能な選択肢のセットがユーザ間で
変わり得ることに注意する。例えば、管理者は、可視化機能性の非管理ユーザよりもより
広い範囲の好みを特定することができる。少なくとも一実施形態において、管理者には非
管理ユーザに提供されものとは異なるセットのプログラマチック・インターフェイス１７
７０がＴＶＳ１４１０によって提供されてもよい（例えば、より広範囲のセットのＡＰＩ
が他のユーザよりも管理資格を有するユーザに利用可能である）。図示する実施形態では
、リクエスト１７２０に応答して、ＴＶＳ１４１０はデータの適当なセットを引き出し、
ヒートマップ１４５０の形態で対応する表示を提供してもよい。
ネットワーク・トポロジーの可視化のための方法
ベルのビューが望ましいか、インスタンスレベルのビューが望ましいか等、幾つかの実施
形態において、リクエスト１７２０に示されてもよい。可視化を生成するために使用され
るべき様々なソースからのメトリックスの集まりの時間範囲は要素１７３４を介して示さ
れてもよい。幾つかの実施では、クライアントは動的可視化をリクエストすることができ
、例えば、選択された時間期間にわたる性能インジケータの値の変化が要素１７３７を介
して示されるクライアントの好みに応じて表示されてもよい。少なくとも幾つかの実施形
態において、リクエスト１７２０の要素に対して利用可能な選択肢のセットがユーザ間で
変わり得ることに注意する。例えば、管理者は、可視化機能性の非管理ユーザよりもより
広い範囲の好みを特定することができる。少なくとも一実施形態において、管理者には非
管理ユーザに提供されものとは異なるセットのプログラマチック・インターフェイス１７
７０がＴＶＳ１４１０によって提供されてもよい（例えば、より広範囲のセットのＡＰＩ
が他のユーザよりも管理資格を有するユーザに利用可能である）。図示する実施形態では
、リクエスト１７２０に応答して、ＴＶＳ１４１０はデータの適当なセットを引き出し、
ヒートマップ１４５０の形態で対応する表示を提供してもよい。
ネットワーク・トポロジーの可視化のための方法
図１８は、少なくとも幾つかの実施形態による、分散システムの様々なノードの性能イ
ンジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する
。要素１８０１に示されるように、幾つかのメトリックスが、プロバイダ・ネットワーク
において実施される様々なネットワーク・アクセス可能サービスのサービス・インスタン
ス、ルーター、スイッチ、ゲートウェイ等のネットワーク装置、並びに、分散システムの
インスタンス・ホスト或いは他のタイプのハードウェアまたはソフトウェア・コンポーネ
ント等、様々なデータ・ソースからＴＶＳ１４１０によって収集されてもよい。収集され
たメトリックスは、例えば、ネットワーク関連メトリックス（インバウンドまたはアウト
バウンド・トラフィック率、現在適用可能な帯域幅限界、測定されたおよびターゲット化
された待ち時間、ネットワーク・エラー・カウント、パケット・サイズ分散、または、ド
ロップされたパケット・カウント等）、プロセッサ関連メトリックス（全体的なＣＰＵ利
用、ターゲット閾値ＣＰＵ利用レベル、カーネル対ユーザ利用スプリット、アクティブ処
理／スレッド・カウント等）、メモリ関連メトリックス（例えば、利用可能なフリーメモ
リの量、ページング速度等）、および、ストレージ関連メトリックス（ディスクまたは他
のストレージ装置利用、平均的応答待ち時間、キュー長さ等）を含んでもよい。一実施形
態において、現在適用されている限界（例えば、帯域幅限界）または性能ターゲット（例
えば、待ち時間ターゲット）に関するメトリックスは、ＮＣＳ１８０から取得されてもよ
い。幾つかの実施形態では、幾つかのまたは全てのメトリックスは、ＮＣＳ１８０によっ
て例えば、様々な資源の間で帯域幅分散を確定する等、他の目的のために既に収集されて
いてもよく、ＴＶＳはＮＣＳの他のコンポーネントまたはメトリックス・データベース１
９０からメトリックスを取得してもよい。一実施形態では、メトリックスは、様々なデー
タ・ソースによって他のタイプのメッセージにピギーバックされてもよく、例えば、前述
の通り、心拍メッセージが健康管理プロトコルに応じて送られる。
ンジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する
。要素１８０１に示されるように、幾つかのメトリックスが、プロバイダ・ネットワーク
において実施される様々なネットワーク・アクセス可能サービスのサービス・インスタン
ス、ルーター、スイッチ、ゲートウェイ等のネットワーク装置、並びに、分散システムの
インスタンス・ホスト或いは他のタイプのハードウェアまたはソフトウェア・コンポーネ
ント等、様々なデータ・ソースからＴＶＳ１４１０によって収集されてもよい。収集され
たメトリックスは、例えば、ネットワーク関連メトリックス（インバウンドまたはアウト
バウンド・トラフィック率、現在適用可能な帯域幅限界、測定されたおよびターゲット化
された待ち時間、ネットワーク・エラー・カウント、パケット・サイズ分散、または、ド
ロップされたパケット・カウント等）、プロセッサ関連メトリックス（全体的なＣＰＵ利
用、ターゲット閾値ＣＰＵ利用レベル、カーネル対ユーザ利用スプリット、アクティブ処
理／スレッド・カウント等）、メモリ関連メトリックス（例えば、利用可能なフリーメモ
リの量、ページング速度等）、および、ストレージ関連メトリックス（ディスクまたは他
のストレージ装置利用、平均的応答待ち時間、キュー長さ等）を含んでもよい。一実施形
態において、現在適用されている限界（例えば、帯域幅限界）または性能ターゲット（例
えば、待ち時間ターゲット）に関するメトリックスは、ＮＣＳ１８０から取得されてもよ
い。幾つかの実施形態では、幾つかのまたは全てのメトリックスは、ＮＣＳ１８０によっ
て例えば、様々な資源の間で帯域幅分散を確定する等、他の目的のために既に収集されて
いてもよく、ＴＶＳはＮＣＳの他のコンポーネントまたはメトリックス・データベース１
９０からメトリックスを取得してもよい。一実施形態では、メトリックスは、様々なデー
タ・ソースによって他のタイプのメッセージにピギーバックされてもよく、例えば、前述
の通り、心拍メッセージが健康管理プロトコルに応じて送られる。
ＴＶＳ１４１０は、例えば、プロバイダ・ネットワークのアカウント管理サービス１４
２０から、または、アイデンティティ管理サービスから、分散システムにおいて実施され
ている様々なサービスに対するクライアント・アカウント情報（図１８の要素１８０４）
も取得してもよい。アカウント情報は、異なるクライアント・アカウント間（例えば、幾
つかのクライアント・アカウントは統合請求のために他のアカウントとリンク付けされて
もよい）、並びに、クライアント・アカウントとユーザ・アカウントまたはグループ・ア
カウント間等の関係を含んでもよい。少なくとも幾つかの実施において、ＴＶＳはサービ
ス・ノードまたはインスタンス間およびクライアント・アカウント間のマッピング、例え
ば、所与の計算インスタンスを代わりに立ち上げたクライアント・アカウントを示す情報
を取得してもよい。少なくとも幾つかの実施形態において、データ・センターの異なるラ
ックやルームにおけるインスタンス・ホストの配置、分散システムの異なるノードとスイ
ッチやルーター等の様々なネットワーク装置との間のネットワーク・リンクまたは路とい
った物理的なレイアウト情報が取得されてもよい（要素１８０７）。物理的なレイアウト
情報は、例えば、在庫サービスまたは他のデータ・センター管理ツールから取得されても
よい。
２０から、または、アイデンティティ管理サービスから、分散システムにおいて実施され
ている様々なサービスに対するクライアント・アカウント情報（図１８の要素１８０４）
も取得してもよい。アカウント情報は、異なるクライアント・アカウント間（例えば、幾
つかのクライアント・アカウントは統合請求のために他のアカウントとリンク付けされて
もよい）、並びに、クライアント・アカウントとユーザ・アカウントまたはグループ・ア
カウント間等の関係を含んでもよい。少なくとも幾つかの実施において、ＴＶＳはサービ
ス・ノードまたはインスタンス間およびクライアント・アカウント間のマッピング、例え
ば、所与の計算インスタンスを代わりに立ち上げたクライアント・アカウントを示す情報
を取得してもよい。少なくとも幾つかの実施形態において、データ・センターの異なるラ
ックやルームにおけるインスタンス・ホストの配置、分散システムの異なるノードとスイ
ッチやルーター等の様々なネットワーク装置との間のネットワーク・リンクまたは路とい
った物理的なレイアウト情報が取得されてもよい（要素１８０７）。物理的なレイアウト
情報は、例えば、在庫サービスまたは他のデータ・センター管理ツールから取得されても
よい。
一つ以上のネットワーク・トポロジーは、例えば、アカウント情報を物理的なレイアウ
ト情報と合成して、関連するノードまたは資源について確定されてもよい（要素１８１０
）。分散システムのサイズやそのユーザ・ベースに依存して、総合的なネットワーク・ト
ポロジーを生成するおよび／または記憶することは、幾つかの実施形態において相当な計
算、メモリ、および／または、ストレージ資源を必要とし得る。したがって、例えば、各
データ・センターに対して一つ、或いは、各地理的領域に対して一つ等、幾つかの実施形
態において幾つかの異なるネットワーク・トポロジーが生成されてもよい。性能インジケ
ータのデータ・セットは、収集されたメトリックスを用いて単一のトポロジーまたは複数
のトポロジーに対応して作成されてもよい（要素１８１３）。最近の時間間隔中に測定さ
れたトラフィック率および該間隔中に適用された帯域幅限界の比、ターゲット最大待ち時
間に対する時間間隔中に観察されるピーク待ち時間の比、ターゲットとされた最大または
最小レベルに対して測定されたＣＰＵ利用等、任意の数の性能インジケータがトポロジー
の様々なノードに対して確定されるまたは導出されてもよい。
ト情報と合成して、関連するノードまたは資源について確定されてもよい（要素１８１０
）。分散システムのサイズやそのユーザ・ベースに依存して、総合的なネットワーク・ト
ポロジーを生成するおよび／または記憶することは、幾つかの実施形態において相当な計
算、メモリ、および／または、ストレージ資源を必要とし得る。したがって、例えば、各
データ・センターに対して一つ、或いは、各地理的領域に対して一つ等、幾つかの実施形
態において幾つかの異なるネットワーク・トポロジーが生成されてもよい。性能インジケ
ータのデータ・セットは、収集されたメトリックスを用いて単一のトポロジーまたは複数
のトポロジーに対応して作成されてもよい（要素１８１３）。最近の時間間隔中に測定さ
れたトラフィック率および該間隔中に適用された帯域幅限界の比、ターゲット最大待ち時
間に対する時間間隔中に観察されるピーク待ち時間の比、ターゲットとされた最大または
最小レベルに対して測定されたＣＰＵ利用等、任意の数の性能インジケータがトポロジー
の様々なノードに対して確定されるまたは導出されてもよい。
少なくとも性能インジケータのサブセットに対する可視化リクエストが受信されてもよ
い（要素１８１６）。リクエスタの許可設定が確定され、リクエストおよび許可設定に対
応する性能インジケータのデータ・セットの適当なサブセットが取得される（要素１８１
９）。静的または動的ヒートマップの形態の色付けされた可視化が表示されてもよい（要
素１８２２）。ブラウザ、ブラウザ・プラグイン、またはＧＵＩ等のクライアント側のコ
ンポーネントは、バックエンドＴＶＳ１４１０によって提供されるデータに基づいてヒー
トマップを表示するために使用されてもよい。幾つかの実施形態では、性能インジケータ
のヒストグラム、円グラフ等他のタイプの可視化がＴＶＳ１４１０を用いてリクエストに
応じて提供されてもよい。幾つかの実施形態では、トポロジーがオンデマンドで、例えば
、可視化リクエストが受信された後、リクエストされた特定のタイプの性能インジケータ
に基づいて生成されてもよいことに注意する。
クライアント・リクエストされた資源使用限界の低減
い（要素１８１６）。リクエスタの許可設定が確定され、リクエストおよび許可設定に対
応する性能インジケータのデータ・セットの適当なサブセットが取得される（要素１８１
９）。静的または動的ヒートマップの形態の色付けされた可視化が表示されてもよい（要
素１８２２）。ブラウザ、ブラウザ・プラグイン、またはＧＵＩ等のクライアント側のコ
ンポーネントは、バックエンドＴＶＳ１４１０によって提供されるデータに基づいてヒー
トマップを表示するために使用されてもよい。幾つかの実施形態では、性能インジケータ
のヒストグラム、円グラフ等他のタイプの可視化がＴＶＳ１４１０を用いてリクエストに
応じて提供されてもよい。幾つかの実施形態では、トポロジーがオンデマンドで、例えば
、可視化リクエストが受信された後、リクエストされた特定のタイプの性能インジケータ
に基づいて生成されてもよいことに注意する。
クライアント・リクエストされた資源使用限界の低減
幾つかの分散システムでは、様々なサービスに対してクライアントが支払わなくてはな
らない金額は、クライアントの代わりにサービス・インスタンスで生成されたネットワー
ク・トラフィックに依存し得る。幾つかのシナリオでは、サービスは、一サービス・イン
スタンス当たり転送され得るデータの量（または、データ転送の速度）に対して上界を定
め、トラフィックに比例する料金がこの上界より低く適用されてもよい。したがって、ク
ライアントは、予算に合うよう、少なくとも一時的にこのような環境においてネットワー
ク使用を減少させるインセンティブを有する。幾つかのタイプのサービスに対して、幾つ
かの異なる標準化されたサービス・インスタンス・タイプがクライアントに利用可能であ
り、このとき、異なるネットワーク限界および／または速度が各インスタンス・タイプに
適用可能である。図１９は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界
およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定され
た、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイ
プのセットの実施例を例示する。仮想コンピューティング・サービスによって定められる
、四つの異なる計算インスタンス・タイプ１９０２（「小」、「中」、「大」、「特大」
計算インスタンス）に対するネットワーク関連設定を含む表が示される。インスタンス・
タイプは、ネットワーク能力および帯域幅関連価格決定における差に加えて、計算力、ス
トレージ・サイズ限界、メモリ・サイズ、または、全体的な価格決定等、様々な特性にお
いて異なり得る。
らない金額は、クライアントの代わりにサービス・インスタンスで生成されたネットワー
ク・トラフィックに依存し得る。幾つかのシナリオでは、サービスは、一サービス・イン
スタンス当たり転送され得るデータの量（または、データ転送の速度）に対して上界を定
め、トラフィックに比例する料金がこの上界より低く適用されてもよい。したがって、ク
ライアントは、予算に合うよう、少なくとも一時的にこのような環境においてネットワー
ク使用を減少させるインセンティブを有する。幾つかのタイプのサービスに対して、幾つ
かの異なる標準化されたサービス・インスタンス・タイプがクライアントに利用可能であ
り、このとき、異なるネットワーク限界および／または速度が各インスタンス・タイプに
適用可能である。図１９は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界
およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定され
た、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイ
プのセットの実施例を例示する。仮想コンピューティング・サービスによって定められる
、四つの異なる計算インスタンス・タイプ１９０２（「小」、「中」、「大」、「特大」
計算インスタンス）に対するネットワーク関連設定を含む表が示される。インスタンス・
タイプは、ネットワーク能力および帯域幅関連価格決定における差に加えて、計算力、ス
トレージ・サイズ限界、メモリ・サイズ、または、全体的な価格決定等、様々な特性にお
いて異なり得る。
図示する実施形態では、二つの異なるトラフィック・カテゴリー（カテゴリー「Ａ」と
「Ｂ」とそれぞれラベル付けされる）のそれぞれについて、アウトバウンド・トラフィッ
ク（列１９０４）およびインバウンド・トラフィック（列１９０８）に対して別個の帯域
幅限界が定められてもよい。カテゴリーは、関係するエンドポイントがプロバイダ・ネッ
トワーク内にあるか否か、例えば、トラフィックが公衆インターネットに方向付けられて
いるか否かに関して互いと異なってもよい。異なるインスタンス・タイプに対する帯域幅
限界に加えて、図１９は、二つのトラフィック・カテゴリーそれぞれについて別個に特定
され得る、アウトバウンドおよびインバウンドの帯域幅価格決定（それぞれ列１９０６お
よび１９１０）も示す。実際には、幾つかの実施形態においてプロバイダ・ネットワーク
・オペレーターによって幾つかの価格がゼロに設定されてもよく、例えば、同じデータ・
センター内でたまたまインスタンス化された異なる計算インスタンス間のトラフィックが
「フリー」でもよいことに注意する。図１９に例示される情報は、仮想コンピューティン
グ・サービスの潜在的クライアントによってアクセスされ得、各タイプのインスタンスを
どれだけ取得すべきかを決定する際にクライアントによって（クライアントのアプリケー
ションの計算性能要件、帯域幅使用に関連しない価格決定ポリシー等の他の要素とともに
）考慮されてもよい。幾つかのクライアントは、例えば、図１９に提供される情報の種類
を用いてネットワーク関連のコストのための予算を取っておいてもよい。クライアントの
アプリケーションのニーズにより、少なくとも幾らかの時間期間中、所与のクライアント
はそのインスタンス・タイプをサポートした最大帯域幅よりもはるかに小さい帯域幅を利
用する必要があり、そのため、より低い限界を課すことをリクエストすることでより効果
的にコストを管理することができる場合がある。例えば、所与のネットワーク・アクセス
可能サービスにアクセスする権限が与えられた多数の個人ユーザを所与のビジネス組織が
含む環境では、低帯域幅限界を適用することは、個別ユーザにそれぞれの帯域幅使用を自
主的に制御することを単にリクエストするよりも、ネットワーク関連のコストを低減させ
るより信頼できる方法である。
「Ｂ」とそれぞれラベル付けされる）のそれぞれについて、アウトバウンド・トラフィッ
ク（列１９０４）およびインバウンド・トラフィック（列１９０８）に対して別個の帯域
幅限界が定められてもよい。カテゴリーは、関係するエンドポイントがプロバイダ・ネッ
トワーク内にあるか否か、例えば、トラフィックが公衆インターネットに方向付けられて
いるか否かに関して互いと異なってもよい。異なるインスタンス・タイプに対する帯域幅
限界に加えて、図１９は、二つのトラフィック・カテゴリーそれぞれについて別個に特定
され得る、アウトバウンドおよびインバウンドの帯域幅価格決定（それぞれ列１９０６お
よび１９１０）も示す。実際には、幾つかの実施形態においてプロバイダ・ネットワーク
・オペレーターによって幾つかの価格がゼロに設定されてもよく、例えば、同じデータ・
センター内でたまたまインスタンス化された異なる計算インスタンス間のトラフィックが
「フリー」でもよいことに注意する。図１９に例示される情報は、仮想コンピューティン
グ・サービスの潜在的クライアントによってアクセスされ得、各タイプのインスタンスを
どれだけ取得すべきかを決定する際にクライアントによって（クライアントのアプリケー
ションの計算性能要件、帯域幅使用に関連しない価格決定ポリシー等の他の要素とともに
）考慮されてもよい。幾つかのクライアントは、例えば、図１９に提供される情報の種類
を用いてネットワーク関連のコストのための予算を取っておいてもよい。クライアントの
アプリケーションのニーズにより、少なくとも幾らかの時間期間中、所与のクライアント
はそのインスタンス・タイプをサポートした最大帯域幅よりもはるかに小さい帯域幅を利
用する必要があり、そのため、より低い限界を課すことをリクエストすることでより効果
的にコストを管理することができる場合がある。例えば、所与のネットワーク・アクセス
可能サービスにアクセスする権限が与えられた多数の個人ユーザを所与のビジネス組織が
含む環境では、低帯域幅限界を適用することは、個別ユーザにそれぞれの帯域幅使用を自
主的に制御することを単にリクエストするよりも、ネットワーク関連のコストを低減させ
るより信頼できる方法である。
少なくとも幾つかの実施形態では、図１に例示するのと同様の中央化ネットワーク構成
サービスは、顧客リクエストされた帯域幅限界および／または他のタイプの資源使用減少
限界を実施するために使用されてもよい。幾つかのタイプのネットワーク関連限界のいず
れかが様々な実施形態ではクライアント・リクエストに応答して適用されてもよく、例え
ば、（ａ）幾らかの時間の期間にわたって超えられてはならない平均的トラフィック送信
速度、（ｂ）短い時間の期間にわたってさえも超えられてはならないピーク・トラフィッ
ク送信速度、（ｃ）転送されたデータの合計バイト数に対する上限、または、（ｄ）転送
されたネットワーク・メッセージの数に対する上限が適用されてもよい。平均的限界およ
び／またはピーク限界が適用される時間の期間は、幾つかの実施形態においてクライアン
トによって示されてもよい。図２０は、少なくとも幾つかの実施形態による、ネットワー
ク構成サーバー１８０によって受信され得る資源使用限界低減リクエスト２０２０の模範
的な要素を例示する。幾つかの実施形態では、前述の通り、所与の請求可能な顧客アカウ
ントは、それと関連付けられる幾つかのユーザ・アカウントを有し、異なる資源使用限界
が異なるユーザ・アカウントに適用されてもよい。図示するように、プログラマチック・
インターフェイス２０７０を介して要請されるリクエスト２０２０は、リクエストされた
低減が適用されるべき一つ以上のユーザ・アカウントを示す要素２０２３を含んでもよい
。幾つかの実施形態ではグループ・アカウントも示され得る。一実施形態では、幾つかの
異なる計算インスタンスまたは他の資源が割り付けられたクライアント２０１０は、これ
ら資源の幾つかのサブセットにより低い資源使用限界を適用することを望む場合がある。
ターゲットとされた特定ノードまたは資源の識別子は、限界低減リクエスト２０２０の別
の要素２０２６を介して示されてもよい。幾つかのセットのサービス・インスタンスに対
する組み合わされた資源使用限界は、幾つかの実施においてクライアントによってリクエ
ストされてもよい。例えば、クライアントは、インスタンスＩ１、Ｉ２、および、Ｉ３に
Ｘ ＧＢ／秒の帯域幅限界が集合的に適用されることをリクエストしてもよく、限界はイ
ンスタンスの帯域幅使用の合計が特定の時間期間中にＸ ＧＢ／秒を超える場合に満たさ
れたと考えられる。
サービスは、顧客リクエストされた帯域幅限界および／または他のタイプの資源使用減少
限界を実施するために使用されてもよい。幾つかのタイプのネットワーク関連限界のいず
れかが様々な実施形態ではクライアント・リクエストに応答して適用されてもよく、例え
ば、（ａ）幾らかの時間の期間にわたって超えられてはならない平均的トラフィック送信
速度、（ｂ）短い時間の期間にわたってさえも超えられてはならないピーク・トラフィッ
ク送信速度、（ｃ）転送されたデータの合計バイト数に対する上限、または、（ｄ）転送
されたネットワーク・メッセージの数に対する上限が適用されてもよい。平均的限界およ
び／またはピーク限界が適用される時間の期間は、幾つかの実施形態においてクライアン
トによって示されてもよい。図２０は、少なくとも幾つかの実施形態による、ネットワー
ク構成サーバー１８０によって受信され得る資源使用限界低減リクエスト２０２０の模範
的な要素を例示する。幾つかの実施形態では、前述の通り、所与の請求可能な顧客アカウ
ントは、それと関連付けられる幾つかのユーザ・アカウントを有し、異なる資源使用限界
が異なるユーザ・アカウントに適用されてもよい。図示するように、プログラマチック・
インターフェイス２０７０を介して要請されるリクエスト２０２０は、リクエストされた
低減が適用されるべき一つ以上のユーザ・アカウントを示す要素２０２３を含んでもよい
。幾つかの実施形態ではグループ・アカウントも示され得る。一実施形態では、幾つかの
異なる計算インスタンスまたは他の資源が割り付けられたクライアント２０１０は、これ
ら資源の幾つかのサブセットにより低い資源使用限界を適用することを望む場合がある。
ターゲットとされた特定ノードまたは資源の識別子は、限界低減リクエスト２０２０の別
の要素２０２６を介して示されてもよい。幾つかのセットのサービス・インスタンスに対
する組み合わされた資源使用限界は、幾つかの実施においてクライアントによってリクエ
ストされてもよい。例えば、クライアントは、インスタンスＩ１、Ｉ２、および、Ｉ３に
Ｘ ＧＢ／秒の帯域幅限界が集合的に適用されることをリクエストしてもよく、限界はイ
ンスタンスの帯域幅使用の合計が特定の時間期間中にＸ ＧＢ／秒を超える場合に満たさ
れたと考えられる。
それぞれの使用限界は、幾つかの実施形態において異なるネットワーク・トラフィック
・カテゴリーに適用されてもよい。上述した通り、幾つかの実施形態では、ネットワーク
・アクセス可能サービスは、例えば、エンドポイントのネットワーク・アドレスの範囲に
基づいて、および、エンドポイントの地理的場所に基づいて、ネットワーク・トラフィッ
クの様々なカテゴリーを定めてもよい。幾つかの実施形態では、例えば、それぞれの限界
は、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ
）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）プロバ
イダ・ネットワークによって定められる所与の地理的領域内の二つのプロバイダ・ネット
ワーク・データ・センター間を流れるトラフィック、（ｄ）プロバイダ・ネットワークに
よって定められる二つの異なる地理的領域における二つのプロバイダ・ネットワーク・デ
ータ・センター間を流れるトラフィック、または、（ｅ）特定のサービス・インスタンス
とプロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィ
ック、に適用されてもよい。図２０に示す実施形態では、使用の低減をターゲットとした
トラフィック・カテゴリーまたは複数のカテゴリーは、要素２０２９を介して示されても
よい。
・カテゴリーに適用されてもよい。上述した通り、幾つかの実施形態では、ネットワーク
・アクセス可能サービスは、例えば、エンドポイントのネットワーク・アドレスの範囲に
基づいて、および、エンドポイントの地理的場所に基づいて、ネットワーク・トラフィッ
クの様々なカテゴリーを定めてもよい。幾つかの実施形態では、例えば、それぞれの限界
は、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ
）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）プロバ
イダ・ネットワークによって定められる所与の地理的領域内の二つのプロバイダ・ネット
ワーク・データ・センター間を流れるトラフィック、（ｄ）プロバイダ・ネットワークに
よって定められる二つの異なる地理的領域における二つのプロバイダ・ネットワーク・デ
ータ・センター間を流れるトラフィック、または、（ｅ）特定のサービス・インスタンス
とプロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィ
ック、に適用されてもよい。図２０に示す実施形態では、使用の低減をターゲットとした
トラフィック・カテゴリーまたは複数のカテゴリーは、要素２０２９を介して示されても
よい。
ネットワーク・トラフィックに対する限界に関して、流れ方向（低減された限界がイン
バウンド・トラフィック、アウトバウンド・トラフィック、または、両方に適用されるべ
きか）が要素２０３２を介して示されてもよい。新しい限界が適用されるべき時間範囲（
例えば、開始時間、終了時間、または、両方）は要素２０３５を介して示されてもよい。
リクエストされた限界値（または、現在の限界が低減されるべき程度）は、図示する実施
形態では要素２０３８を介して示されてもよい。例えば、要素２０３８は、新しい限界に
対して絶対値を特定する代わりに、現在の帯域幅限界が２５％だけ低減されるべきと示し
てもよい。幾つかの実施では、新しい限界を示す場合、クライアントは使用されるべき測
定アプローチの態様を示してもよく、例えば、平均的帯域幅限界への変化がリクエストさ
れる場合、平均が計算されるべき時間期間が特定され、より低いピーク帯域幅がリクエス
トされた場合、ピーク帯域幅が定量化されるべき時間期間が特定されてもよい。少なくと
も幾つかの実施形態では、低減された限界を特定することに加えて、クライアント２０１
０はそれぞれの作用がネットワーク構成サーバー１８０によって行われる、要素２０４１
を介して限界に対して一つ以上の閾値を定めてもよい。例えば、クライアント２０１０は
、計算インスタンスへのまたはからの測定されたトライフィック率がクライアント・リク
エストされた帯域幅限界の８０％を超えた場合に通知されることを望む。幾つかの実施で
は、リクエストは、閾値に到達したときに通知が提供されるべき一つ以上の宛先（例えば
、電子メールアカウント）の表示を含んでもよい。それぞれの作用が行われる幾つかの異
なる閾値が幾つかの実施において示されてもよい。例えば、帯域幅の８０％では通知が生
成され、１００％ではサービスがパケットをドロップするか破棄し始めることが許可され
る。幾つかのパケットを送信する代わりに一時的に待ち行列に入れる、限界を一時的に緩
和するおよび／または増加する等、他の応答作用が、幾つかの実施形態において、クライ
アントの明確なリクエストに応じて、または、サービス主導で行われ得る。
バウンド・トラフィック、アウトバウンド・トラフィック、または、両方に適用されるべ
きか）が要素２０３２を介して示されてもよい。新しい限界が適用されるべき時間範囲（
例えば、開始時間、終了時間、または、両方）は要素２０３５を介して示されてもよい。
リクエストされた限界値（または、現在の限界が低減されるべき程度）は、図示する実施
形態では要素２０３８を介して示されてもよい。例えば、要素２０３８は、新しい限界に
対して絶対値を特定する代わりに、現在の帯域幅限界が２５％だけ低減されるべきと示し
てもよい。幾つかの実施では、新しい限界を示す場合、クライアントは使用されるべき測
定アプローチの態様を示してもよく、例えば、平均的帯域幅限界への変化がリクエストさ
れる場合、平均が計算されるべき時間期間が特定され、より低いピーク帯域幅がリクエス
トされた場合、ピーク帯域幅が定量化されるべき時間期間が特定されてもよい。少なくと
も幾つかの実施形態では、低減された限界を特定することに加えて、クライアント２０１
０はそれぞれの作用がネットワーク構成サーバー１８０によって行われる、要素２０４１
を介して限界に対して一つ以上の閾値を定めてもよい。例えば、クライアント２０１０は
、計算インスタンスへのまたはからの測定されたトライフィック率がクライアント・リク
エストされた帯域幅限界の８０％を超えた場合に通知されることを望む。幾つかの実施で
は、リクエストは、閾値に到達したときに通知が提供されるべき一つ以上の宛先（例えば
、電子メールアカウント）の表示を含んでもよい。それぞれの作用が行われる幾つかの異
なる閾値が幾つかの実施において示されてもよい。例えば、帯域幅の８０％では通知が生
成され、１００％ではサービスがパケットをドロップするか破棄し始めることが許可され
る。幾つかのパケットを送信する代わりに一時的に待ち行列に入れる、限界を一時的に緩
和するおよび／または増加する等、他の応答作用が、幾つかの実施形態において、クライ
アントの明確なリクエストに応じて、または、サービス主導で行われ得る。
リクエスト２０２０を受信することに応答して、ＮＣＳ１８０は、リクエストするクラ
イアントに変化の承認２０５０を提供し、リクエストされた限界を適用するよう適当な構
成の変化を開始する。例えば、低減された帯域幅限界がインスタンス・ホストで実施され
た計算インスタンスに適用されるべきシナリオでは、ＮＣＳ１８０はインスタンス・ホス
トにおいて図３に例示されるスタック３１０と同様の仮想化管理ソフトウェア・スタック
のコンポーネントに新しい限界を送信してもよい。幾つかの実施形態では、ＮＣＳ１８０
は、承認２０５０を送る前に、構成の変化が約束されるまで待ってもよい。
イアントに変化の承認２０５０を提供し、リクエストされた限界を適用するよう適当な構
成の変化を開始する。例えば、低減された帯域幅限界がインスタンス・ホストで実施され
た計算インスタンスに適用されるべきシナリオでは、ＮＣＳ１８０はインスタンス・ホス
トにおいて図３に例示されるスタック３１０と同様の仮想化管理ソフトウェア・スタック
のコンポーネントに新しい限界を送信してもよい。幾つかの実施形態では、ＮＣＳ１８０
は、承認２０５０を送る前に、構成の変化が約束されるまで待ってもよい。
資源使用限界の低減は、仮想コンピューティング・サービス、様々なタイプのストレー
ジ・サービス、データベース・サービス等、幾つかの実施形態において複数のネットワー
ク・アクセス可能サービスのいずれかのインスタンスに対してリクエストされてもよい。
幾つかの実施形態では、低減された資源使用限界値を直接示す代わりに、クライアントは
ある示された時間期間中に満たされるべき資源予算限界を示してもよい。それに応答して
、ネットワーク構成サービスは、クライアントのサービス・インスタンスの資源使用を監
視し、対応する請求金額を（例えば、関連するサービスの請求管理コンポーネントと通信
することで）確定してもよい。予算限界に近い閾値（または予算限界自体）が到達される
と、クライアントは通知されてもよくおよび／または一つ以上の応答作用が行われてもよ
い。そのため、資源予算限界は、少なくとも幾つかの実施形態において資源使用限界と類
似して処理されてもよい（またはそれに置換されてもよい）。少なくとも幾つかの実施形
態において、資源使用限界におけるクライアント・リクエストされた低減をサポートする
構成サーバーは、図１のＮＣＳ１８０に関して前述した機能の少なくとも幾つかを実施す
る必要がないことに注意する。例えば、使用減少リクエスト２０２０に応答する構成サー
バーは、図７と同様の手順グラフや図５と同様の分類ツリーを必ずしも生成する必要がな
い。
ジ・サービス、データベース・サービス等、幾つかの実施形態において複数のネットワー
ク・アクセス可能サービスのいずれかのインスタンスに対してリクエストされてもよい。
幾つかの実施形態では、低減された資源使用限界値を直接示す代わりに、クライアントは
ある示された時間期間中に満たされるべき資源予算限界を示してもよい。それに応答して
、ネットワーク構成サービスは、クライアントのサービス・インスタンスの資源使用を監
視し、対応する請求金額を（例えば、関連するサービスの請求管理コンポーネントと通信
することで）確定してもよい。予算限界に近い閾値（または予算限界自体）が到達される
と、クライアントは通知されてもよくおよび／または一つ以上の応答作用が行われてもよ
い。そのため、資源予算限界は、少なくとも幾つかの実施形態において資源使用限界と類
似して処理されてもよい（またはそれに置換されてもよい）。少なくとも幾つかの実施形
態において、資源使用限界におけるクライアント・リクエストされた低減をサポートする
構成サーバーは、図１のＮＣＳ１８０に関して前述した機能の少なくとも幾つかを実施す
る必要がないことに注意する。例えば、使用減少リクエスト２０２０に応答する構成サー
バーは、図７と同様の手順グラフや図５と同様の分類ツリーを必ずしも生成する必要がな
い。
上述したように、少なくとも幾つかの実施形態では、所与の請求可能なクライアント・
アカウント、例えば、社員がプロバイダ・ネットワークの一つ以上のネットワーク・アク
セス可能サービスを使用する組織またはエンティティのために確立されたアカウントは、
それと関連する幾つかの異なるユーザ・アカウントまたはグループ・アカウントを有して
もよい。このような実施形態では、別個の資源使用限界が異なるユーザまたはグループに
対して設定されてもよい。図２１は、少なくとも幾つかの実施形態による、ネットワーク
・アクセス可能サービスのクライアント・アカウント２１０４Ａに対する全体的な資源使
用限界設定２１１０の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付
けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。図示
するように、クライアント・アカウント２１０４Ａは、ユーザ・グループ２１２０Ａおよ
び２１２０Ｂ等の、一つ以上の関係するグループ・アカウント２１２０が定められている
。各グループは、グループ２１２０Ｂのユーザ・アカウント２１２３Ｋおよび２１２３Ｌ
等、複数のユーザ・アカウント２１２３を有してもよい。幾つかのユーザ・アカウント、
例えば、２１２３Ａ、２１２３Ｂ、および、２１２３Ｃはどのユーザ・グループに属さな
くてもよい。
アカウント、例えば、社員がプロバイダ・ネットワークの一つ以上のネットワーク・アク
セス可能サービスを使用する組織またはエンティティのために確立されたアカウントは、
それと関連する幾つかの異なるユーザ・アカウントまたはグループ・アカウントを有して
もよい。このような実施形態では、別個の資源使用限界が異なるユーザまたはグループに
対して設定されてもよい。図２１は、少なくとも幾つかの実施形態による、ネットワーク
・アクセス可能サービスのクライアント・アカウント２１０４Ａに対する全体的な資源使
用限界設定２１１０の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付
けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。図示
するように、クライアント・アカウント２１０４Ａは、ユーザ・グループ２１２０Ａおよ
び２１２０Ｂ等の、一つ以上の関係するグループ・アカウント２１２０が定められている
。各グループは、グループ２１２０Ｂのユーザ・アカウント２１２３Ｋおよび２１２３Ｌ
等、複数のユーザ・アカウント２１２３を有してもよい。幾つかのユーザ・アカウント、
例えば、２１２３Ａ、２１２３Ｂ、および、２１２３Ｃはどのユーザ・グループに属さな
くてもよい。
図示する実施形態では、全体的な資源使用限界２１１０（例えば、帯域幅限界）は、様
々なグループ・アカウント２１２０およびユーザ・アカウント２１２３等、クライアント
・アカウント２１０４Ａと関係するアカウント全てに対して確定されてもよい。アカウン
ト２１０４Ｂ等の一つ以上の追加的なクライアント・アカウントは、例えば、総合請求ま
たは他の目的のためにクライアント・アカウント２１０４Ａとリンク付けされてもよい。
一つの模範的なシナリオでは、クライアント・アカウント２１０４Ａはプロバイダ・ネッ
トワーク資源を用いて特定のアプリケーションを実施する組織Ｏ１に対してセットアップ
される一方で、クライアント・アカウント２１０４ＢはＯ１とパートナーとなる或いはＯ
１によって実施されるアプリケーションを利用する異なる組織Ｏ２に対してセットアップ
され得る。二つのクライアント・アカウントがセットアップされるエンティティの好みに
より、全体的な資源使用限界２１１０もリンク付けされたユーザ・アカウントに適用され
得る。少なくとも幾つかの実施形態では、所与の時間期間にわたる全てのユーザ、グルー
プ、および、リンク付けされたアカウントの測定された資源使用は、例えば、使用限界総
和ポリシー２１９０に応じて、当該期間中、親クライアント・アカウント２１０４Ａに適
用される全体的な資源使用限界を超えてはならない。
々なグループ・アカウント２１２０およびユーザ・アカウント２１２３等、クライアント
・アカウント２１０４Ａと関係するアカウント全てに対して確定されてもよい。アカウン
ト２１０４Ｂ等の一つ以上の追加的なクライアント・アカウントは、例えば、総合請求ま
たは他の目的のためにクライアント・アカウント２１０４Ａとリンク付けされてもよい。
一つの模範的なシナリオでは、クライアント・アカウント２１０４Ａはプロバイダ・ネッ
トワーク資源を用いて特定のアプリケーションを実施する組織Ｏ１に対してセットアップ
される一方で、クライアント・アカウント２１０４ＢはＯ１とパートナーとなる或いはＯ
１によって実施されるアプリケーションを利用する異なる組織Ｏ２に対してセットアップ
され得る。二つのクライアント・アカウントがセットアップされるエンティティの好みに
より、全体的な資源使用限界２１１０もリンク付けされたユーザ・アカウントに適用され
得る。少なくとも幾つかの実施形態では、所与の時間期間にわたる全てのユーザ、グルー
プ、および、リンク付けされたアカウントの測定された資源使用は、例えば、使用限界総
和ポリシー２１９０に応じて、当該期間中、親クライアント・アカウント２１０４Ａに適
用される全体的な資源使用限界を超えてはならない。
幾つかの実施形態では、異なるユーザ、グループ、または、リンク付けされたアカウン
トに対して明確な資源使用限界がリクエストされてもよい。例えば、グループ２１２０Ａ
および２１２０Ｂには、それぞれの限界２１５０Ａおよび２１５０Ｂが割り当てられ、ユ
ーザ２１２３Ａ、２１２３Ｂ、２１２３Ｋ、および、２１２３Ｌには、それぞれの限界２
１６０Ａ、２１６０Ｂ，２１６０Ｋ、および、２１６０Ｌが割り当てられる。何人かのユ
ーザ（例えば、２１２３Ｃ）および／またはグループはそれぞれの限界が定められていな
い場合があり、その場合、その親グループの限界および／またはクライアント・アカウン
トの限界が適用され得る。リンク付けされたアカウント２１０４Ｂには、独自の資源使用
限界２１７０は定められ、これはリンク付けされたアカウント内で定められるユーザおよ
び／またはグループにも適用され得る。図２１に例示される資源使用限界に関して、クラ
イアント・アカウント２１０４Ａは「親」エンティティと考えられ、グループ、ユーザ、
および、リンク付けされたアカウントは「子孫」エンティティと考えられる。図２１に示
される異なる粒度またはレベルのいずれかで適用される資源使用限界における低減は、例
えば、図２０のリクエスト２０２０と同様のリクエストを介して、少なくとも幾つかの実
施形態において要請されてもよい。リクエストされた低減が親エンティティ（例えば、ク
ライアント・アカウント２１０４Ａ）に適用される場合、子孫エンティティに課せられる
限界に対する低減の影響は使用限界総和ポリシー２１９０に示され得る。例えば、一実施
形態では、全体として帯域幅における１０％の低減がクライアント・アカウントにリクエ
ストされた場合、クライアント・アカウントから由来する各ユーザまたはグループに適用
されるべき帯域幅限界も一つの選択されたポリシー２１９０に応じて１０％だけ低減され
得る。別のポリシー２１９０によると、（ａ）任意の所与の子孫の限界が親の限界を超え
ない、且つ、（ｂ）所与の時間期間にわたる全ての子孫ノードの実際の資源使用の総和が
親の限界を超えない限り、子孫の限界は変更が明確にリクエストされない限り変更されて
はならない。
クライアント・リクエストされた資源使用限界を低減する方法
トに対して明確な資源使用限界がリクエストされてもよい。例えば、グループ２１２０Ａ
および２１２０Ｂには、それぞれの限界２１５０Ａおよび２１５０Ｂが割り当てられ、ユ
ーザ２１２３Ａ、２１２３Ｂ、２１２３Ｋ、および、２１２３Ｌには、それぞれの限界２
１６０Ａ、２１６０Ｂ，２１６０Ｋ、および、２１６０Ｌが割り当てられる。何人かのユ
ーザ（例えば、２１２３Ｃ）および／またはグループはそれぞれの限界が定められていな
い場合があり、その場合、その親グループの限界および／またはクライアント・アカウン
トの限界が適用され得る。リンク付けされたアカウント２１０４Ｂには、独自の資源使用
限界２１７０は定められ、これはリンク付けされたアカウント内で定められるユーザおよ
び／またはグループにも適用され得る。図２１に例示される資源使用限界に関して、クラ
イアント・アカウント２１０４Ａは「親」エンティティと考えられ、グループ、ユーザ、
および、リンク付けされたアカウントは「子孫」エンティティと考えられる。図２１に示
される異なる粒度またはレベルのいずれかで適用される資源使用限界における低減は、例
えば、図２０のリクエスト２０２０と同様のリクエストを介して、少なくとも幾つかの実
施形態において要請されてもよい。リクエストされた低減が親エンティティ（例えば、ク
ライアント・アカウント２１０４Ａ）に適用される場合、子孫エンティティに課せられる
限界に対する低減の影響は使用限界総和ポリシー２１９０に示され得る。例えば、一実施
形態では、全体として帯域幅における１０％の低減がクライアント・アカウントにリクエ
ストされた場合、クライアント・アカウントから由来する各ユーザまたはグループに適用
されるべき帯域幅限界も一つの選択されたポリシー２１９０に応じて１０％だけ低減され
得る。別のポリシー２１９０によると、（ａ）任意の所与の子孫の限界が親の限界を超え
ない、且つ、（ｂ）所与の時間期間にわたる全ての子孫ノードの実際の資源使用の総和が
親の限界を超えない限り、子孫の限界は変更が明確にリクエストされない限り変更されて
はならない。
クライアント・リクエストされた資源使用限界を低減する方法
図２２は、少なくとも幾つかの実施形態による、クライアントがネットワーク・アクセ
ス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよ
う実施される動作の態様を例示する。要素２２０１に示すように、一つ以上のプログラマ
チック・インターフェイスが実施されると、ネットワーク・アクセス可能サービス（プロ
バイダ・ネットワークで実施されるマルチテナント仮想コンピューティング・サービス等
）のクライアントは資源使用限界の低減を、資源使用限界が適用される一つ以上のサービ
ス・インスタンスについてリクエストすることができる。プログラマチック・インターフ
ェイスは、例えば、ウェブページまたはウェブサイト、一つ以上のＡＰＩ、ＧＵＩ、また
は、コマンド・ライン・ツールを含んでもよい。
ス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよ
う実施される動作の態様を例示する。要素２２０１に示すように、一つ以上のプログラマ
チック・インターフェイスが実施されると、ネットワーク・アクセス可能サービス（プロ
バイダ・ネットワークで実施されるマルチテナント仮想コンピューティング・サービス等
）のクライアントは資源使用限界の低減を、資源使用限界が適用される一つ以上のサービ
ス・インスタンスについてリクエストすることができる。プログラマチック・インターフ
ェイスは、例えば、ウェブページまたはウェブサイト、一つ以上のＡＰＩ、ＧＵＩ、また
は、コマンド・ライン・ツールを含んでもよい。
限界低減リクエストは、例えば、ネットワーク構成サーバーにおいて、プログラマチッ
ク・インターフェイスの一つを介して受信されてもよい（要素２２０４）。限界低減リク
エストは、図２０に示すリクエスト２０２０の構成要素の何らかの組み合わせ等、適用さ
れるべき新しい限界に関して様々な構成要素を有してもよい。低減された限界が適用され
るべき特定のクライアント・アカウント、トラフィック・カテゴリー、サービス・インス
タンス、および／または、時間期間がリクエストに示されてもよい。適当な構成の変化は
、リクエストに応じてなされてもよく、例えば、限界が計算インスタンスに適用されるべ
きシナリオでは、影響されるインスタンス・ホストにおける仮想化ソフトウェア・コンポ
ーネントが新しい限界に関して通知されてもよい。資源使用メトリックスは、時間をかけ
てターゲットとされたサービス・インスタンスから取得されてもよい（要素２２０７）。
測定された資源使用が閾値（閾値が新しく適用された限界について定められ得る）に到達
したとの検出に応答して、通知が（例えば、低減された限界のリクエスタに対して、また
は、リクエスタによって示される一つ以上の指定された通知ターゲットに対して）生成さ
れる（要素２２１０）。幾つかの実施形態では、他の作用が閾値に到達したとの検出に応
答して行われる。例えば、資源使用限界が帯域幅に適用される場合、一つ以上のパケット
がドロップされるか待ち行列に入れられ、幾つかのケースでは、限界が一時的に緩和され
る。幾つかのケースでは、このような使用限界の緩和は、警告メッセージに伴われる（例
えば、クライアントは、限界が一時的に緩和されるが、持続的にまたは繰り返し限界また
は閾値を超えることはデータ損失につながると警告されてもよい）。少なくとも幾つかの
実施形態では、一つ以上のこのような閾値および／または対応する応答作用は、使用限界
の低減をリクエストしたクライアントによって示される。
ク・インターフェイスの一つを介して受信されてもよい（要素２２０４）。限界低減リク
エストは、図２０に示すリクエスト２０２０の構成要素の何らかの組み合わせ等、適用さ
れるべき新しい限界に関して様々な構成要素を有してもよい。低減された限界が適用され
るべき特定のクライアント・アカウント、トラフィック・カテゴリー、サービス・インス
タンス、および／または、時間期間がリクエストに示されてもよい。適当な構成の変化は
、リクエストに応じてなされてもよく、例えば、限界が計算インスタンスに適用されるべ
きシナリオでは、影響されるインスタンス・ホストにおける仮想化ソフトウェア・コンポ
ーネントが新しい限界に関して通知されてもよい。資源使用メトリックスは、時間をかけ
てターゲットとされたサービス・インスタンスから取得されてもよい（要素２２０７）。
測定された資源使用が閾値（閾値が新しく適用された限界について定められ得る）に到達
したとの検出に応答して、通知が（例えば、低減された限界のリクエスタに対して、また
は、リクエスタによって示される一つ以上の指定された通知ターゲットに対して）生成さ
れる（要素２２１０）。幾つかの実施形態では、他の作用が閾値に到達したとの検出に応
答して行われる。例えば、資源使用限界が帯域幅に適用される場合、一つ以上のパケット
がドロップされるか待ち行列に入れられ、幾つかのケースでは、限界が一時的に緩和され
る。幾つかのケースでは、このような使用限界の緩和は、警告メッセージに伴われる（例
えば、クライアントは、限界が一時的に緩和されるが、持続的にまたは繰り返し限界また
は閾値を超えることはデータ損失につながると警告されてもよい）。少なくとも幾つかの
実施形態では、一つ以上のこのような閾値および／または対応する応答作用は、使用限界
の低減をリクエストしたクライアントによって示される。
図２３は、少なくとも幾つかの実施形態による、クライアントが分散システムのノード
において資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される
動作の態様を例示する。要素２３０１に示されるように、一つ以上のプログラマチック・
インターフェイスが様々なタイプのクエリーに対して実施されてもよい。幾つかのクライ
アントは、例えば、現在利用可能な限界に対して資源使用の現在の状態またはメトリック
を確定することを望むことがある。別のシナリオでは、クライアントは、一つ以上の特定
されたサービス・インスタンスにおいて経時的な資源使用における変化に関する傾向情報
を取得することを望むことがあり、それにより、例えば、クライアントは資源使用限界が
いつ変えられるべきかを予想することができる。更に別のシナリオでは、資源使用に関す
る予算ベースのクエリーがネットワーク構成サーバーによってサポートされてもよく、例
えば、クライアントは幾つかのサービス・インスタンスに関してネットワークに対するタ
ーゲット予算限界を示し、クライアントのコストを予算内で維持することを助け得る帯域
幅限界に対する変更を推奨するリクエストを出してもよい。クエリーは、プログラマチッ
ク・インターフェイスの一つを介してクライアントから受信されてもよい（要素２３０４
）。クエリーのタイプにより、クエリーが適用されるサービス・インスタンスから収集さ
れるメトリックスに基づいて異なる作用が取られ得る。
において資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される
動作の態様を例示する。要素２３０１に示されるように、一つ以上のプログラマチック・
インターフェイスが様々なタイプのクエリーに対して実施されてもよい。幾つかのクライ
アントは、例えば、現在利用可能な限界に対して資源使用の現在の状態またはメトリック
を確定することを望むことがある。別のシナリオでは、クライアントは、一つ以上の特定
されたサービス・インスタンスにおいて経時的な資源使用における変化に関する傾向情報
を取得することを望むことがあり、それにより、例えば、クライアントは資源使用限界が
いつ変えられるべきかを予想することができる。更に別のシナリオでは、資源使用に関す
る予算ベースのクエリーがネットワーク構成サーバーによってサポートされてもよく、例
えば、クライアントは幾つかのサービス・インスタンスに関してネットワークに対するタ
ーゲット予算限界を示し、クライアントのコストを予算内で維持することを助け得る帯域
幅限界に対する変更を推奨するリクエストを出してもよい。クエリーは、プログラマチッ
ク・インターフェイスの一つを介してクライアントから受信されてもよい（要素２３０４
）。クエリーのタイプにより、クエリーが適用されるサービス・インスタンスから収集さ
れるメトリックスに基づいて異なる作用が取られ得る。
クエリーが資源使用の現在の状態に関係する場合（要素２３１０）、資源使用の最近の
測定とサービス・インスタンスにおける適用可能な限界との間の差を示す応答が提供され
る（要素２３５１）。傾向クエリーが受信されると（要素２３１３）、選択された時間間
隔にわたる資源使用の変動を示す応答が提供される（要素２３５４）。予算ベースの推奨
クエリーが受信されると（要素２３１６）、ネットワーク構成サーバーは、クライアント
が予算目標を実現することを可能にする一つ以上の使用限界低減を確定するのに必要な計
算を実施し、計算の結果をクエリー応答で提供してもよい（要素２３５７）。幾つかの実
施形態では、他のタイプのクエリーがサポートされてもよい。
測定とサービス・インスタンスにおける適用可能な限界との間の差を示す応答が提供され
る（要素２３５１）。傾向クエリーが受信されると（要素２３１３）、選択された時間間
隔にわたる資源使用の変動を示す応答が提供される（要素２３５４）。予算ベースの推奨
クエリーが受信されると（要素２３１６）、ネットワーク構成サーバーは、クライアント
が予算目標を実現することを可能にする一つ以上の使用限界低減を確定するのに必要な計
算を実施し、計算の結果をクエリー応答で提供してもよい（要素２３５７）。幾つかの実
施形態では、他のタイプのクエリーがサポートされてもよい。
様々な実施形態において、図１０、図１１、図１２、図１３、図１８、図２２、および
、図２３のフロー図で例示される動作以外の動作が、記載するネットワーク構成の機能性
の様々な態様を実施するために使用され得、図示する動作の幾つかが実施されず、或いは
、順次的でなく異なる順序でまたは並列に実施されてもよいことに注意する。例えば、幾
つかの実施形態では、マルチスレッドＮＣＳが実施されてもよく、この場合、図１０に示
す動作の幾つかのストリームが並列に実行され、それぞれのターゲット・ノードに対する
分類メタデータのそれぞれのセットが生成され送信される。
使用ケース
、図２３のフロー図で例示される動作以外の動作が、記載するネットワーク構成の機能性
の様々な態様を実施するために使用され得、図示する動作の幾つかが実施されず、或いは
、順次的でなく異なる順序でまたは並列に実施されてもよいことに注意する。例えば、幾
つかの実施形態では、マルチスレッドＮＣＳが実施されてもよく、この場合、図１０に示
す動作の幾つかのストリームが並列に実行され、それぞれのターゲット・ノードに対する
分類メタデータのそれぞれのセットが生成され送信される。
使用ケース
分散システムの多数のノードでネットワーク・トラフィックをシェーピングし、ヒート
マップ・ベースの資源可視化能力を提供し、資源使用限界におけるクライアント・リクエ
ストされた低減を可能にするためにネットワーク構成サーバーの中央化セットを確立する
上述の技術は、幾つかのシナリオで有用である。例えば、プロバイダ・ネットワークは幾
つかのデータ・センター間で分散される数百の、或いは、数千のインスタンス・ホストお
よび多数のネットワーク装置を有してもよく、プロバイダ・ネットワークの収益の少なく
とも一部分はインスタンス・ホストに流入するまたは流出するネットワーク・トラフィッ
クの量に基づいて導出される。ネットワーク管理決定を行うために各インスタンス・ホス
トまたはネットワーク装置でローカル・モジュールを用いることは、このような大きな環
境では幾つかの問題を生ずる。第一に、所与のインスタンス・ホストで知的ネットワーク
管理決定を行うのに必要な全ての入力を取得することが可能でないこともある。第二に、
インスタンス・ホストで要求される決定論理の複雑性は、インスタンス・ホストの相当量
の計算能力を必要とし、これは、クライアント・リクエストされたサービス・インスタン
スに対して残されるコンピューティング能力を減少し得る。ネットワーク管理論理が変更
される必要がある場合、全てのインスタンス・ホストに変更が送信され適用されなくては
ならず、これ自体が資源集約的な且つエラーを起こしやすいエクササイズである。
マップ・ベースの資源可視化能力を提供し、資源使用限界におけるクライアント・リクエ
ストされた低減を可能にするためにネットワーク構成サーバーの中央化セットを確立する
上述の技術は、幾つかのシナリオで有用である。例えば、プロバイダ・ネットワークは幾
つかのデータ・センター間で分散される数百の、或いは、数千のインスタンス・ホストお
よび多数のネットワーク装置を有してもよく、プロバイダ・ネットワークの収益の少なく
とも一部分はインスタンス・ホストに流入するまたは流出するネットワーク・トラフィッ
クの量に基づいて導出される。ネットワーク管理決定を行うために各インスタンス・ホス
トまたはネットワーク装置でローカル・モジュールを用いることは、このような大きな環
境では幾つかの問題を生ずる。第一に、所与のインスタンス・ホストで知的ネットワーク
管理決定を行うのに必要な全ての入力を取得することが可能でないこともある。第二に、
インスタンス・ホストで要求される決定論理の複雑性は、インスタンス・ホストの相当量
の計算能力を必要とし、これは、クライアント・リクエストされたサービス・インスタン
スに対して残されるコンピューティング能力を減少し得る。ネットワーク管理論理が変更
される必要がある場合、全てのインスタンス・ホストに変更が送信され適用されなくては
ならず、これ自体が資源集約的な且つエラーを起こしやすいエクササイズである。
反対に、トラフィック・シェーピングに使用されるべき決定論理を幾つかのネットワー
ク構成サーバーに隔離することで、より大きなセットのソースからの入力が収集され、よ
り情報を得た上での決定が下され得る。ネットワーク構成サーバーは、コンピューティン
グ能力へのコンテンションを回避しながら、他のサービスと共有される必要がない専用の
コンピューティング資源を用いて実施されてもよい。ネットワーク構成論理への更新は、
数百或いは数千のインスタンス・ホストが更新される場合よりも、より簡単に適用され得
る。中央化ネットワーク構成サービスは、さもなければ取得することが難しいネットワー
ク・ステータス（構成可能なヒートマップを含む）の統一ビューをクライアントに簡単に
提供することができる。特定されたサービス・インスタンス、ユーザ・アカウント、また
は、グループ・アカウントに対してプログラムで資源使用限界を低減させる能力は、予算
を制御しようとするクライアントには有用である。
ク構成サーバーに隔離することで、より大きなセットのソースからの入力が収集され、よ
り情報を得た上での決定が下され得る。ネットワーク構成サーバーは、コンピューティン
グ能力へのコンテンションを回避しながら、他のサービスと共有される必要がない専用の
コンピューティング資源を用いて実施されてもよい。ネットワーク構成論理への更新は、
数百或いは数千のインスタンス・ホストが更新される場合よりも、より簡単に適用され得
る。中央化ネットワーク構成サービスは、さもなければ取得することが難しいネットワー
ク・ステータス（構成可能なヒートマップを含む）の統一ビューをクライアントに簡単に
提供することができる。特定されたサービス・インスタンス、ユーザ・アカウント、また
は、グループ・アカウントに対してプログラムで資源使用限界を低減させる能力は、予算
を制御しようとするクライアントには有用である。
本開示の実施形態は、以下の付記を考慮して説明され得る。
１．プロバイダ・ネットワークのマルチテナント・ネットワーク・アクセス可能サービ
スの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界
よりも低い資源使用限界を課すことを少なくとも時間間隔中にクライアントがリクエスト
することを可能にする一つ以上のプログラマチック・インターフェイスを実施し、該低資
源使用限界が資源使用依存価格決定ポリシーでネットワーク・トラフィックの少なくとも
一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介し
て、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特
定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上の
カテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けら
れる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベル
に到達したとの確定に応答して、通知の生成を含む一つ以上の応答作用を開始するよう構
成される、複数のコンピューティング装置を備えるシステム。
２．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信
速度、（ｂ）超えられてはならないピーク・トラフィック送信速度、（ｃ）転送されたデ
ータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数
に対する上限のいずれかの表示を含む、付記１記載のシステム。
３．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワー
ク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れ
るトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフ
ィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィ
ック、（ｄ）該特定のサービス・インスタンスと該プロバイダ・ネットワークで実施され
る異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付け
られるネットワーク・トラフィックの複数のカテゴリーから選択される、付記１記載のシ
ステム。
４．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ
以上の宛先に流れるトラフィック、（ｂ）一つ以上のソースから該特定のサービス・イン
スタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワー
ク・トラフィック・フローの一つ以上の方向を示す、付記１記載のシステム。
５．該クライアント・リクエストは、該マルチテナント・ネットワーク・アクセス可能
サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの
特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適
用される、付記１記載のシステム。
６．複数のコンピューティング装置により、
ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエ
スト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことをクライアン
トがリクエストすることを可能にするプログラマチック・インターフェイスを実施し、該
低資源使用限界がサービスと関連付けられるネットワーク・トラフィックの少なくとも一
つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介し
て、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特
定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上の
カテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けら
れる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベル
に到達したとの確定に応答して、一つ以上の応答作用を開始する、方法。
７．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信
速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送された
データのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの
数に対する上限のいずれかの表示を含む、付記６記載の方法。
８．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワー
ク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れ
るトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフ
ィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィ
ック、（ｄ）該サービスのノードと該プロバイダ・ネットワークで実施される異なるサー
ビスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネット
ワーク・トラフィックの複数のカテゴリーから選択される、付記６記載の方法。
９．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ
以上の宛先エンドポイントに流れるトラフィック、（ｂ）一つ以上のソースから該特定の
サービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用さ
れるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記６記載の方法。
１０．該クライアント・リクエストは、マルチテナント・ネットワーク・アクセス可能
サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの
特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適
用される、付記６記載の方法。
１１．該一つ以上の応答作用は、（ａ）一つ以上のパケットを破棄する、（ｂ）一つ以
上のパケットを待ち行列に入れる、または、（ｃ）該特定のサービス・インスタンスにお
いてネットワーク・トラフィックに課せられる資源使用限界を特定の時間期間にわたって
増加させることのいずれかを含む、付記６記載の方法。
１２．前記一つ以上のコンピューティング装置により、更に、
該特定のサービス・インスタンスにおいてネットワーク・トラフィックと関連付けら
れる測定された資源使用をクライアントが確定することを可能にする異なるプログラマチ
ック・インターフェイスを実施し、
該異なるプログラマチック・インターフェイスを介して受信されるリクエストに応答し
て、該測定された資源使用の表示を提供する、付記６記載の方法。
１３．該クライアント・リクエストは、該特定の低資源使用限界が課せられる時間期間
の表示を含む、付記６記載の方法。
１４．該クライアント・リクエストは、（ａ）閾値レベル、または、（ｂ）該一つ以上
の応答作用のうちの特定の応答作用の一方の表示を含む、付記６記載の方法。
１５．該ネットワーク・アクセス可能サービスは、プロバイダ・ネットワークのインス
タンス・ホストを用いて実施され、該方法は、
該一つ以上のコンピューティング装置により、更に、
該プロバイダ・ネットワークの中央化ネットワーク構成サービスの特定のサーバーに
おいて、特定されたサービス・インスタンスにおけるそれぞれの低資源使用限界に対する
複数のクライアント・リクエストを受信し、
該特定されたサービス・インスタンスのそれぞれのインスタンス・ホストでインスタ
ンス化されたそれぞれの制御モジュールに該特定のサーバーから該それぞれの低資源使用
限界の表示を送信することを含む、付記６記載の方法。
１６．一つ以上のプロセッサで実行されると、
プログラマチック・インターフェイスを介して、ネットワーク・アクセス可能サービ
スの特定のインスタンスにおいてネットワーク・トラフィックの少なくとも一つのカテゴ
リーに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のインスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリー
に対応する資源使用メトリックスを取得し、
該特定のインスタンスにおけるネットワーク・トラフィックと関連付けられる資源使
用が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始するプログラ
ム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
１７．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの第一および第二のインスタンスにおいてネ
ットワーク・トラフィックに集合的に課せられる組み合わされた資源使用限界を示す異な
るクリアント・リクエストを受信し、
該第一および第二のインスタンスにおけるネットワーク・トラフィックと関連付けられ
る該資源使用の総和が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を
開始する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１８．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サ
ービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれ
かを有する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１９．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの異なるインスタンスにおいて資源をネット
ワークすることに対するクライアント予算の上界を示す異なるクリアント・リクエストを
受信し、
該異なるインスタンスにおける資源をネットワークすることと関連付けられるクライア
ント請求金額が閾値を超えたとの確定に応答して、一つ以上の応答作用を開始する、付記
１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
２０．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送
信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送され
たデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージ
の数に対する上限のいずれかの表示を含む、付記１６記載の非一過性のコンピュータ・ア
クセス可能記憶媒体。
２１．プロバイダ・ネットワークの複数のクライアント・アカウントにアクセス可能な
少なくとも一つのマルチテナント・ネットワーク・アクセス可能サービスを実施するノー
ドのセットから収集されたネットワーク・トラフィック・メトリックスを含み、複数のソ
ースからメトリックスを取得し、
少なくとも（ａ）該ノードのセットの第一のノードおよび第二のノードが割り当てら
れるそれぞれのクライアント・アカウント間の関係、および、（ｂ）該第一のノードと該
第二のノードとの間の一つ以上のネットワーク・リンクを示すネットワーク・トポロジー
を確定し、
該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを
含む、該ネットワーク・トポロジーの複数のネットワーク性能インジケータの表現を生成
し、
プログラマチック・インターフェイスを介して受信されるリクエストに応答して表示
されるカスタマイズ可能な資源ヒートマップに含まれるよう該第一のノードおよび該第二
のノードのそれぞれのネットワーク性能インジケータを提供するよう構成される一つ以上
のコンピューティング装置を備える、システム。
２２．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該マルチテナント・ネットワーク・アクセ
ス可能サービスのために構成されるネットワーク構成サーバーにより該第一のノードにつ
いて確定される帯域幅限界との間の比の表示を有する、付記２１記載のシステム。
２３．該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応
じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特
定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アド
レスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフ
ィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうち
の別のカテゴリーと異なる、付記２１記載のシステム。
２４．該一つ以上のコンピューティング装置は、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度
、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラッ
クレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・セン
ター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域
レベルの粒度のうちの一つを有する、カスタマイズ可能な資源ヒートマップに表示される
一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該カスタマイズ可能なヒートマッ
プに含まれるよう一つ以上の収集されたメトリックスを統合するよう更に構成される、付
記２１記載のシステム。
２５．該プログラマチック・インターフェイスを介して受信される該リクエストに応答
して、該一つ以上のコンピューティング装置は、
該リクエストの要請側の許可設定を取得し、
該許可設定に少なくとも部分的に基づいて、該カスタマイズ可能な資源ヒートマップに
表される収集された資源メトリックスのサブセットを選択するよう更に構成される、付記
２１記載のシステム。
２６．一つ以上のコンピューティング装置により、
プロバイダ・ネットワークの一つ以上のクライアント・アカウントの代わりにネット
ワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・
トラフィック・メトリックスを含むメトリックスをプロバイダ・ネットワークの複数のソ
ースから取得し、
該ノードのセットの第一のノードと第二のノードとの間の一つ以上の関係を表すネッ
トワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう該第一のノー
ドと該第二のノードの、メトリックスの一部分から少なくとも部分的に導出されるそれぞ
れのネットワーク性能インジケータを提供する、方法。
２７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅
限界との間の比の表示を有する、付記２６記載の方法。
２８．該資源ヒートマップは、（ａ）該第一のノードのプロセッサ性能インジケータ、
（ｂ）該第一のノードのストレージ性能インジケータ、または、（ｃ）該第一のノードの
メモリ性能インジケータのいずれかを有する、付記２６記載の方法。
２９．該第一のノードの該ネットワーク性能インジケータは、測定されたネットワーク
待ち時間と、該第一のノードと関連付けられるトラフィックに対するネットワーク待ち時
間の上界との間の比の表示を有する、付記２６記載の方法。
３０．該資源ヒートマップはリクエストに応答して生成され、
該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該
第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカ
テゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アド
レスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフ
ィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうち
の別のカテゴリーと異なる、付記２６記載の方法。
３１．該一つ以上のコンピューティング装置により、
クライアントがネットワーク・トラフィックの一つ以上のカテゴリーを定めるよう異な
るプログラマチック・インターフェイスを実施し、
該特定のカテゴリーの定義を該異なるプログラマチック・インターフェイスを介して受
信する、付記３０記載の方法。
３２．該一つ以上のコンピューティング装置により、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度
、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラッ
クレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・セン
ター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域
レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメ
トリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよ
う一つ以上のメトリックスを統合する、付記２６記載の方法。
３３．該一つ以上のコンピューティング装置により、
該資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された収
集時間期間の表示を受信し、
該選択された収集時間期間に少なくとも部分的に基づいて、該資源ヒートマップに含ま
れるよう該一つ以上のメトリックスを統合する、付記２６記載の方法。
３４．該複数のソースは、（ａ）ネットワーク・インターフェイス・カード、（ｂ）仮
想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポ
ーネント、（ｃ）仮想化されたコンピューティング・サービスの計算インスタンスのネッ
トワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（ｆ）
ルーター、（ｇ）ゲートウェイ、または、（ｈ）ロード・バランサのうち一つ以上有する
、付記２６記載の方法。
３５．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サ
ービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれ
かを有する、付記２６記載の方法。
３６．一つ以上のプロセッサで実行されると、
複数のクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセ
ス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・
メトリックスを含む、メトリックスを複数のソースから取得し、
（ａ）該ノードのセットのうちの第一のノードおよび第二のノードが割り当てられる
それぞれのクライアント・アカウント間の関係、または、（ｂ）該第一のノードと該第二
のノードとの間の一つ以上のネットワーク・リンクの少なくとも一方を表すネットワーク
・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう、該メトリ
ックスの一部分から少なくとも部分的に導出される、該第一のノードおよび該第二のノー
ドのそれぞれのネットワーク性能インジケータを提供する、プログラム命令を記憶する非
一過性コンピュータ・アクセス可能記憶媒体。
３７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅
限界との間の比の表示を有する、付記１６記載の非一過性コンピュータ・アクセス可能記
憶媒体。
３８．命令は、該一つ以上のプロセッサで実行されると、
トラフィック・フィルタリング基準の表示を受信し、
該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴ
リーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケー
タが確定され、
該特定のカテゴリーが（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・ア
ドレスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラ
フィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのう
ちの別のカテゴリーと異なる、付記３６記載の非一過性コンピュータ・アクセス可能記憶
媒体。
３９．命令は、該一つ以上のプロセッサで実行されると、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度、
（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラック
レベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センタ
ー・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域レ
ベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメト
リックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよ
う一つ以上のメトリックスを統合する、付記３６記載の非一過性コンピュータ・アクセス
可能記憶媒体。
４０．命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスのクライアントが少なくとも該メトリックスの
サブセットをリクエストするようプログラマチック・インターフェイスを実施し、
該プログラマチック・インターフェイスを介して特定のクライアントからメトリック・
リクエストを受信し、
該メトリック・リクエストに示される一つ以上のメトリックスを取得する許可が該特定
のクライアントに与えられているとの確定に応答して、該特定のクライアントに該一つ以
上のメトリックスを提供する、付記３６記載の非一過性コンピュータ・アクセス可能記憶
媒体。
例示的コンピュータ・システム
１．プロバイダ・ネットワークのマルチテナント・ネットワーク・アクセス可能サービ
スの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界
よりも低い資源使用限界を課すことを少なくとも時間間隔中にクライアントがリクエスト
することを可能にする一つ以上のプログラマチック・インターフェイスを実施し、該低資
源使用限界が資源使用依存価格決定ポリシーでネットワーク・トラフィックの少なくとも
一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介し
て、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特
定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上の
カテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けら
れる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベル
に到達したとの確定に応答して、通知の生成を含む一つ以上の応答作用を開始するよう構
成される、複数のコンピューティング装置を備えるシステム。
２．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信
速度、（ｂ）超えられてはならないピーク・トラフィック送信速度、（ｃ）転送されたデ
ータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数
に対する上限のいずれかの表示を含む、付記１記載のシステム。
３．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワー
ク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れ
るトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフ
ィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィ
ック、（ｄ）該特定のサービス・インスタンスと該プロバイダ・ネットワークで実施され
る異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付け
られるネットワーク・トラフィックの複数のカテゴリーから選択される、付記１記載のシ
ステム。
４．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ
以上の宛先に流れるトラフィック、（ｂ）一つ以上のソースから該特定のサービス・イン
スタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワー
ク・トラフィック・フローの一つ以上の方向を示す、付記１記載のシステム。
５．該クライアント・リクエストは、該マルチテナント・ネットワーク・アクセス可能
サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの
特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適
用される、付記１記載のシステム。
６．複数のコンピューティング装置により、
ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエ
スト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことをクライアン
トがリクエストすることを可能にするプログラマチック・インターフェイスを実施し、該
低資源使用限界がサービスと関連付けられるネットワーク・トラフィックの少なくとも一
つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介し
て、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特
定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上の
カテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けら
れる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベル
に到達したとの確定に応答して、一つ以上の応答作用を開始する、方法。
７．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信
速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送された
データのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの
数に対する上限のいずれかの表示を含む、付記６記載の方法。
８．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワー
ク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れ
るトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフ
ィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィ
ック、（ｄ）該サービスのノードと該プロバイダ・ネットワークで実施される異なるサー
ビスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネット
ワーク・トラフィックの複数のカテゴリーから選択される、付記６記載の方法。
９．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ
以上の宛先エンドポイントに流れるトラフィック、（ｂ）一つ以上のソースから該特定の
サービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用さ
れるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記６記載の方法。
１０．該クライアント・リクエストは、マルチテナント・ネットワーク・アクセス可能
サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの
特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適
用される、付記６記載の方法。
１１．該一つ以上の応答作用は、（ａ）一つ以上のパケットを破棄する、（ｂ）一つ以
上のパケットを待ち行列に入れる、または、（ｃ）該特定のサービス・インスタンスにお
いてネットワーク・トラフィックに課せられる資源使用限界を特定の時間期間にわたって
増加させることのいずれかを含む、付記６記載の方法。
１２．前記一つ以上のコンピューティング装置により、更に、
該特定のサービス・インスタンスにおいてネットワーク・トラフィックと関連付けら
れる測定された資源使用をクライアントが確定することを可能にする異なるプログラマチ
ック・インターフェイスを実施し、
該異なるプログラマチック・インターフェイスを介して受信されるリクエストに応答し
て、該測定された資源使用の表示を提供する、付記６記載の方法。
１３．該クライアント・リクエストは、該特定の低資源使用限界が課せられる時間期間
の表示を含む、付記６記載の方法。
１４．該クライアント・リクエストは、（ａ）閾値レベル、または、（ｂ）該一つ以上
の応答作用のうちの特定の応答作用の一方の表示を含む、付記６記載の方法。
１５．該ネットワーク・アクセス可能サービスは、プロバイダ・ネットワークのインス
タンス・ホストを用いて実施され、該方法は、
該一つ以上のコンピューティング装置により、更に、
該プロバイダ・ネットワークの中央化ネットワーク構成サービスの特定のサーバーに
おいて、特定されたサービス・インスタンスにおけるそれぞれの低資源使用限界に対する
複数のクライアント・リクエストを受信し、
該特定されたサービス・インスタンスのそれぞれのインスタンス・ホストでインスタ
ンス化されたそれぞれの制御モジュールに該特定のサーバーから該それぞれの低資源使用
限界の表示を送信することを含む、付記６記載の方法。
１６．一つ以上のプロセッサで実行されると、
プログラマチック・インターフェイスを介して、ネットワーク・アクセス可能サービ
スの特定のインスタンスにおいてネットワーク・トラフィックの少なくとも一つのカテゴ
リーに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のインスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリー
に対応する資源使用メトリックスを取得し、
該特定のインスタンスにおけるネットワーク・トラフィックと関連付けられる資源使
用が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始するプログラ
ム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
１７．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの第一および第二のインスタンスにおいてネ
ットワーク・トラフィックに集合的に課せられる組み合わされた資源使用限界を示す異な
るクリアント・リクエストを受信し、
該第一および第二のインスタンスにおけるネットワーク・トラフィックと関連付けられ
る該資源使用の総和が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を
開始する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１８．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サ
ービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれ
かを有する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１９．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの異なるインスタンスにおいて資源をネット
ワークすることに対するクライアント予算の上界を示す異なるクリアント・リクエストを
受信し、
該異なるインスタンスにおける資源をネットワークすることと関連付けられるクライア
ント請求金額が閾値を超えたとの確定に応答して、一つ以上の応答作用を開始する、付記
１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
２０．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送
信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送され
たデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージ
の数に対する上限のいずれかの表示を含む、付記１６記載の非一過性のコンピュータ・ア
クセス可能記憶媒体。
２１．プロバイダ・ネットワークの複数のクライアント・アカウントにアクセス可能な
少なくとも一つのマルチテナント・ネットワーク・アクセス可能サービスを実施するノー
ドのセットから収集されたネットワーク・トラフィック・メトリックスを含み、複数のソ
ースからメトリックスを取得し、
少なくとも（ａ）該ノードのセットの第一のノードおよび第二のノードが割り当てら
れるそれぞれのクライアント・アカウント間の関係、および、（ｂ）該第一のノードと該
第二のノードとの間の一つ以上のネットワーク・リンクを示すネットワーク・トポロジー
を確定し、
該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを
含む、該ネットワーク・トポロジーの複数のネットワーク性能インジケータの表現を生成
し、
プログラマチック・インターフェイスを介して受信されるリクエストに応答して表示
されるカスタマイズ可能な資源ヒートマップに含まれるよう該第一のノードおよび該第二
のノードのそれぞれのネットワーク性能インジケータを提供するよう構成される一つ以上
のコンピューティング装置を備える、システム。
２２．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該マルチテナント・ネットワーク・アクセ
ス可能サービスのために構成されるネットワーク構成サーバーにより該第一のノードにつ
いて確定される帯域幅限界との間の比の表示を有する、付記２１記載のシステム。
２３．該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応
じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特
定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アド
レスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフ
ィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうち
の別のカテゴリーと異なる、付記２１記載のシステム。
２４．該一つ以上のコンピューティング装置は、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度
、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラッ
クレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・セン
ター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域
レベルの粒度のうちの一つを有する、カスタマイズ可能な資源ヒートマップに表示される
一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該カスタマイズ可能なヒートマッ
プに含まれるよう一つ以上の収集されたメトリックスを統合するよう更に構成される、付
記２１記載のシステム。
２５．該プログラマチック・インターフェイスを介して受信される該リクエストに応答
して、該一つ以上のコンピューティング装置は、
該リクエストの要請側の許可設定を取得し、
該許可設定に少なくとも部分的に基づいて、該カスタマイズ可能な資源ヒートマップに
表される収集された資源メトリックスのサブセットを選択するよう更に構成される、付記
２１記載のシステム。
２６．一つ以上のコンピューティング装置により、
プロバイダ・ネットワークの一つ以上のクライアント・アカウントの代わりにネット
ワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・
トラフィック・メトリックスを含むメトリックスをプロバイダ・ネットワークの複数のソ
ースから取得し、
該ノードのセットの第一のノードと第二のノードとの間の一つ以上の関係を表すネッ
トワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう該第一のノー
ドと該第二のノードの、メトリックスの一部分から少なくとも部分的に導出されるそれぞ
れのネットワーク性能インジケータを提供する、方法。
２７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅
限界との間の比の表示を有する、付記２６記載の方法。
２８．該資源ヒートマップは、（ａ）該第一のノードのプロセッサ性能インジケータ、
（ｂ）該第一のノードのストレージ性能インジケータ、または、（ｃ）該第一のノードの
メモリ性能インジケータのいずれかを有する、付記２６記載の方法。
２９．該第一のノードの該ネットワーク性能インジケータは、測定されたネットワーク
待ち時間と、該第一のノードと関連付けられるトラフィックに対するネットワーク待ち時
間の上界との間の比の表示を有する、付記２６記載の方法。
３０．該資源ヒートマップはリクエストに応答して生成され、
該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該
第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカ
テゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アド
レスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフ
ィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうち
の別のカテゴリーと異なる、付記２６記載の方法。
３１．該一つ以上のコンピューティング装置により、
クライアントがネットワーク・トラフィックの一つ以上のカテゴリーを定めるよう異な
るプログラマチック・インターフェイスを実施し、
該特定のカテゴリーの定義を該異なるプログラマチック・インターフェイスを介して受
信する、付記３０記載の方法。
３２．該一つ以上のコンピューティング装置により、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度
、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラッ
クレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・セン
ター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域
レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメ
トリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよ
う一つ以上のメトリックスを統合する、付記２６記載の方法。
３３．該一つ以上のコンピューティング装置により、
該資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された収
集時間期間の表示を受信し、
該選択された収集時間期間に少なくとも部分的に基づいて、該資源ヒートマップに含ま
れるよう該一つ以上のメトリックスを統合する、付記２６記載の方法。
３４．該複数のソースは、（ａ）ネットワーク・インターフェイス・カード、（ｂ）仮
想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポ
ーネント、（ｃ）仮想化されたコンピューティング・サービスの計算インスタンスのネッ
トワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（ｆ）
ルーター、（ｇ）ゲートウェイ、または、（ｈ）ロード・バランサのうち一つ以上有する
、付記２６記載の方法。
３５．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サ
ービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれ
かを有する、付記２６記載の方法。
３６．一つ以上のプロセッサで実行されると、
複数のクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセ
ス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・
メトリックスを含む、メトリックスを複数のソースから取得し、
（ａ）該ノードのセットのうちの第一のノードおよび第二のノードが割り当てられる
それぞれのクライアント・アカウント間の関係、または、（ｂ）該第一のノードと該第二
のノードとの間の一つ以上のネットワーク・リンクの少なくとも一方を表すネットワーク
・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう、該メトリ
ックスの一部分から少なくとも部分的に導出される、該第一のノードおよび該第二のノー
ドのそれぞれのネットワーク性能インジケータを提供する、プログラム命令を記憶する非
一過性コンピュータ・アクセス可能記憶媒体。
３７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける
測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅
限界との間の比の表示を有する、付記１６記載の非一過性コンピュータ・アクセス可能記
憶媒体。
３８．命令は、該一つ以上のプロセッサで実行されると、
トラフィック・フィルタリング基準の表示を受信し、
該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴ
リーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケー
タが確定され、
該特定のカテゴリーが（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・ア
ドレスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラ
フィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのう
ちの別のカテゴリーと異なる、付記３６記載の非一過性コンピュータ・アクセス可能記憶
媒体。
３９．命令は、該一つ以上のプロセッサで実行されると、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度、
（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラック
レベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センタ
ー・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域レ
ベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメト
リックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよ
う一つ以上のメトリックスを統合する、付記３６記載の非一過性コンピュータ・アクセス
可能記憶媒体。
４０．命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスのクライアントが少なくとも該メトリックスの
サブセットをリクエストするようプログラマチック・インターフェイスを実施し、
該プログラマチック・インターフェイスを介して特定のクライアントからメトリック・
リクエストを受信し、
該メトリック・リクエストに示される一つ以上のメトリックスを取得する許可が該特定
のクライアントに与えられているとの確定に応答して、該特定のクライアントに該一つ以
上のメトリックスを提供する、付記３６記載の非一過性コンピュータ・アクセス可能記憶
媒体。
例示的コンピュータ・システム
少なくとも幾つかの実施形態では、ネットワーク構成サーバー、ネットワーク構成サー
ビス・マネージャ、トポロジー可視化サーバー、および／または、インスタンス・ホスト
を実施する技術を含む、本願記載の一つ以上の技術の一部または全部を実施するサーバー
は、一つ以上のコンピュータ・アクセス可能媒体を含む或いは該媒体にアクセスするよう
構成される汎用コンピュータ・システムを含んでもよい。図２４は、汎用コンピューティ
ング装置３０００を示す。例示する実施形態では、コンピューティング装置３０００は、
入力／出力（Ｉ／Ｏ）インターフェイス３０３０を介してシステム・メモリ３０２０に接
続される一つ以上のプロセッサ３０１０を含む。コンピューティング装置３０００は、更
に、Ｉ／Ｏインターフェイス３０３０に接続されるネットワーク・インターフェイス３０
４０を含む。
ビス・マネージャ、トポロジー可視化サーバー、および／または、インスタンス・ホスト
を実施する技術を含む、本願記載の一つ以上の技術の一部または全部を実施するサーバー
は、一つ以上のコンピュータ・アクセス可能媒体を含む或いは該媒体にアクセスするよう
構成される汎用コンピュータ・システムを含んでもよい。図２４は、汎用コンピューティ
ング装置３０００を示す。例示する実施形態では、コンピューティング装置３０００は、
入力／出力（Ｉ／Ｏ）インターフェイス３０３０を介してシステム・メモリ３０２０に接
続される一つ以上のプロセッサ３０１０を含む。コンピューティング装置３０００は、更
に、Ｉ／Ｏインターフェイス３０３０に接続されるネットワーク・インターフェイス３０
４０を含む。
様々な実施形態では、コンピューティング装置３０００は、一つのプロセッサ３０１０
を含むユニ・プロセッサ・システム、または、幾つかのプロセッサ３０１０（例えば、二
つ、四つ、八つ、または、別の好適な数）を含むマルチプロセッサ・システムでもよい。
プロセッサ３０１０は、命令を実行することができる任意の好適なプロセッサでもよい。
例えば、様々な実施形態では、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡ
ＲＣ、または、ＭＩＰＳ ＩＳＡ、或いは、任意の他の好適なＩＳＡ等、様々なインスト
ラクション・セット・アーキテクチャ（ＩＳＡ）のいずれかを実施する汎用の或いは組み
込みプロセッサでもよい。マルチプロセッサ・システムでは、各プロセッサ３０１０は、
必ずではないが、同じＩＳＡを一般的に実施してもよい。幾つかの実施では、グラフィッ
クス・プロセッシング・ユニット（ＧＰＵ）が従来のプロセッサの代わりに、或いは、そ
れに加えて使用されてもよい。
を含むユニ・プロセッサ・システム、または、幾つかのプロセッサ３０１０（例えば、二
つ、四つ、八つ、または、別の好適な数）を含むマルチプロセッサ・システムでもよい。
プロセッサ３０１０は、命令を実行することができる任意の好適なプロセッサでもよい。
例えば、様々な実施形態では、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡ
ＲＣ、または、ＭＩＰＳ ＩＳＡ、或いは、任意の他の好適なＩＳＡ等、様々なインスト
ラクション・セット・アーキテクチャ（ＩＳＡ）のいずれかを実施する汎用の或いは組み
込みプロセッサでもよい。マルチプロセッサ・システムでは、各プロセッサ３０１０は、
必ずではないが、同じＩＳＡを一般的に実施してもよい。幾つかの実施では、グラフィッ
クス・プロセッシング・ユニット（ＧＰＵ）が従来のプロセッサの代わりに、或いは、そ
れに加えて使用されてもよい。
システム・メモリ３０２０は、プロセッサ３０１０によってアクセス可能な命令および
データを記憶するよう構成されてもよい。様々な実施形態では、システム・メモリ３０２
０は、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、同期型ダイナミックＲ
ＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ・タイプ・メモリ、または、任意の他のタイ
プのメモリ等、任意の好適なメモリ技術を用いて実施されてもよい。例示する実施形態で
は、上述の方法、技術、および、データ等、一つ以上の所望の機能を実施するプログラム
命令およびデータは、コード３０２５およびデータ３０２６としてシステム・メモリ３０
２０内に記憶されるとして示される。
データを記憶するよう構成されてもよい。様々な実施形態では、システム・メモリ３０２
０は、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、同期型ダイナミックＲ
ＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ・タイプ・メモリ、または、任意の他のタイ
プのメモリ等、任意の好適なメモリ技術を用いて実施されてもよい。例示する実施形態で
は、上述の方法、技術、および、データ等、一つ以上の所望の機能を実施するプログラム
命令およびデータは、コード３０２５およびデータ３０２６としてシステム・メモリ３０
２０内に記憶されるとして示される。
一実施形態では、Ｉ／Ｏインターフェイス３０３０は、プロセッサ３０１０、システム
・メモリ３０２０、および、ネットワーク・インターフェイス３０４０や他の周辺インタ
ーフェイス、例えば、データ・オブジェクト・パーティションの物理的レプリカを記憶す
るために使用される様々なタイプの永続性および／または揮発性ストレージ装置を含む、
装置における任意の周辺装置の間のＩ／Ｏトラフィックを調整するよう構成されてもよい
。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０は、任意の必要なプロトコル
、タイミングまたは他のデータ変換を実施して、一つのコンポーネント（例えば、システ
ム・メモリ３０２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ３０
１０）による使用に好適なフォーマットに変換してもよい。幾つかの実施形態では、Ｉ／
Ｏインターフェイス３０３０は、例えば、ペリフェラル・コンポーネント・インターコネ
クト（ＰＣＩ）バス規格またはユニバーサル・シリアル・バス（ＵＳＢ）規格の変形例等
、様々なタイプの周辺機器用バスを介して取り付けられる装置に対するサポートを含んで
もよい。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０の機能は、例えば、ノ
ース・ブリッジおよびサウス・ブリッジ等の二つの以上の別個の構成要素に分けられても
よい。更に、幾つかの実施形態では、システム・メモリ３０２０へのインターフェイス等
、Ｉ／Ｏインターフェイス３０３０の機能性の幾つかまたは全てがプロセッサ３０１０に
直接組み込まれてもよい。
・メモリ３０２０、および、ネットワーク・インターフェイス３０４０や他の周辺インタ
ーフェイス、例えば、データ・オブジェクト・パーティションの物理的レプリカを記憶す
るために使用される様々なタイプの永続性および／または揮発性ストレージ装置を含む、
装置における任意の周辺装置の間のＩ／Ｏトラフィックを調整するよう構成されてもよい
。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０は、任意の必要なプロトコル
、タイミングまたは他のデータ変換を実施して、一つのコンポーネント（例えば、システ
ム・メモリ３０２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ３０
１０）による使用に好適なフォーマットに変換してもよい。幾つかの実施形態では、Ｉ／
Ｏインターフェイス３０３０は、例えば、ペリフェラル・コンポーネント・インターコネ
クト（ＰＣＩ）バス規格またはユニバーサル・シリアル・バス（ＵＳＢ）規格の変形例等
、様々なタイプの周辺機器用バスを介して取り付けられる装置に対するサポートを含んで
もよい。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０の機能は、例えば、ノ
ース・ブリッジおよびサウス・ブリッジ等の二つの以上の別個の構成要素に分けられても
よい。更に、幾つかの実施形態では、システム・メモリ３０２０へのインターフェイス等
、Ｉ／Ｏインターフェイス３０３０の機能性の幾つかまたは全てがプロセッサ３０１０に
直接組み込まれてもよい。
ネットワーク・インターフェイス３０４０は、コンピューティング装置３０００と、例
えば、図１乃至図２３に例示される他のコンピュータ・システムまたは装置等のネットワ
ークまたは複数のネットワーク３０５０に取り付けられる他の装置３０６０との間のデー
タ交換を可能にするよう構成されてもよい。様々な実施形態では、ネットワーク・インタ
ーフェイス３０４０は、例えば、イーサネット（登録商標）・ネットワークのタイプ等、
全ての好適な有線または無線の総合データ・ネットワークを介して通信をサポートしても
よい。追加的には、ネットワーク・インターフェイス３０４０は、アナログ音声ネットワ
ークまたはデジタル・ファイバー通信ネットワーク等の電気通信／電話技術ネットワーク
を介して、ファイバー・チャネルＳＡＮ等のストレージ・エリア・ネットワークを介して
、または、全ての他の好適なタイプのネットワークおよび／またはプロトコルを介して通
信をサポートしてもよい。
えば、図１乃至図２３に例示される他のコンピュータ・システムまたは装置等のネットワ
ークまたは複数のネットワーク３０５０に取り付けられる他の装置３０６０との間のデー
タ交換を可能にするよう構成されてもよい。様々な実施形態では、ネットワーク・インタ
ーフェイス３０４０は、例えば、イーサネット（登録商標）・ネットワークのタイプ等、
全ての好適な有線または無線の総合データ・ネットワークを介して通信をサポートしても
よい。追加的には、ネットワーク・インターフェイス３０４０は、アナログ音声ネットワ
ークまたはデジタル・ファイバー通信ネットワーク等の電気通信／電話技術ネットワーク
を介して、ファイバー・チャネルＳＡＮ等のストレージ・エリア・ネットワークを介して
、または、全ての他の好適なタイプのネットワークおよび／またはプロトコルを介して通
信をサポートしてもよい。
幾つかの実施形態では、システム・メモリ３０２０は、対応する方法および装置の実施
形態を実施するための、図１乃至図２３について上述したようなプログラム命令およびデ
ータを記憶するよう構成されるコンピュータ・アクセス可能媒体の一実施形態でもよい。
しかしながら、他の実施形態では、プログラム命令および／またはデータは、異なるタイ
プのコンピュータ・アクセス可能媒体で受信され、送信され、または、記憶されてもよい
。一般的に、コンピュータ・アクセス可能媒体は、例えば、Ｉ／Ｏインターフェイス３０
３０を介してコンピューティング装置３０００に接続されるディスクまたはＤＶＤ／ＣＤ
等の磁気的または光学的媒体を含む、非一過性ストレージ媒体またはメモリ媒体を含んで
もよい。非一過性コンピュータ・アクセス可能ストレージ媒体は、システム・メモリ３０
２０または他のタイプのメモリとして、コンピューティング装置３０００の幾つかの実施
形態において含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＤＲＡ
Ｍ、ＳＲＡＭ等）、ＲＯＭ等の全ての揮発性または不揮発性媒体を含んでもよい。更に、
コンピュータ・アクセス可能媒体は、ネットワーク・インターフェイス３０４０を介して
実施され得る、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電
気的、電磁的、または、デジタルの信号を含む送信媒体または信号を含んでもよい。図２
４に例示されるような多数のコンピューティング装置の一部または全てが様々な実施形態
において説明した機能性を実施するために使用されてもよく、例えば、様々な異なる装置
やサーバーで実行されるソフトウェア・コンポーネントが協調して機能性を提供してもよ
い。幾つかの実施形態では、説明した機能性の一部分は、汎用コンピュータ・システムを
用いて実施されることに加えて、または、その代わりに、ストレージ装置、ネットワーク
装置、または、特殊目的コンピュータ・システムを用いて実施されてもよい。本願で使用
される「コンピューティング装置」といった用語は、少なくともこれらのタイプの装置全
てを含み、これらのタイプの装置に制限されない。
結論
形態を実施するための、図１乃至図２３について上述したようなプログラム命令およびデ
ータを記憶するよう構成されるコンピュータ・アクセス可能媒体の一実施形態でもよい。
しかしながら、他の実施形態では、プログラム命令および／またはデータは、異なるタイ
プのコンピュータ・アクセス可能媒体で受信され、送信され、または、記憶されてもよい
。一般的に、コンピュータ・アクセス可能媒体は、例えば、Ｉ／Ｏインターフェイス３０
３０を介してコンピューティング装置３０００に接続されるディスクまたはＤＶＤ／ＣＤ
等の磁気的または光学的媒体を含む、非一過性ストレージ媒体またはメモリ媒体を含んで
もよい。非一過性コンピュータ・アクセス可能ストレージ媒体は、システム・メモリ３０
２０または他のタイプのメモリとして、コンピューティング装置３０００の幾つかの実施
形態において含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＤＲＡ
Ｍ、ＳＲＡＭ等）、ＲＯＭ等の全ての揮発性または不揮発性媒体を含んでもよい。更に、
コンピュータ・アクセス可能媒体は、ネットワーク・インターフェイス３０４０を介して
実施され得る、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電
気的、電磁的、または、デジタルの信号を含む送信媒体または信号を含んでもよい。図２
４に例示されるような多数のコンピューティング装置の一部または全てが様々な実施形態
において説明した機能性を実施するために使用されてもよく、例えば、様々な異なる装置
やサーバーで実行されるソフトウェア・コンポーネントが協調して機能性を提供してもよ
い。幾つかの実施形態では、説明した機能性の一部分は、汎用コンピュータ・システムを
用いて実施されることに加えて、または、その代わりに、ストレージ装置、ネットワーク
装置、または、特殊目的コンピュータ・システムを用いて実施されてもよい。本願で使用
される「コンピューティング装置」といった用語は、少なくともこれらのタイプの装置全
てを含み、これらのタイプの装置に制限されない。
結論
様々な実施形態は、更に、前述の説明に応じて実施される命令および／またはデータを
コンピュータ・アクセス可能媒体で受信し、送信し、または、記憶することを含む。一般
的に、コンピュータ・アクセス可能媒体は、磁気的または光学的媒体、例えば、ディスク
またはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲ
ＡＭ等）等の揮発性または不揮発性媒体、ＲＯＭ等を含むストレージ媒体またはメモリ媒
体、並びに、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電気
的、電磁的、または、デジタルの信号等の送信媒体または信号を含んでもよい。
コンピュータ・アクセス可能媒体で受信し、送信し、または、記憶することを含む。一般
的に、コンピュータ・アクセス可能媒体は、磁気的または光学的媒体、例えば、ディスク
またはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲ
ＡＭ等）等の揮発性または不揮発性媒体、ＲＯＭ等を含むストレージ媒体またはメモリ媒
体、並びに、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電気
的、電磁的、または、デジタルの信号等の送信媒体または信号を含んでもよい。
図中に例示され、本願に記載される様々な方法は、方法の模範的な実施形態を示す。該
方法は、ソフトウェア、ハードウェア、または、その組み合わせにおいて実施されてもよ
い。方法の順序は変更されてもよく、様々な要素が追加される、再順序付けされる、組み
合わされる、省略される、変更されるなどされてもよい。
方法は、ソフトウェア、ハードウェア、または、その組み合わせにおいて実施されてもよ
い。方法の順序は変更されてもよく、様々な要素が追加される、再順序付けされる、組み
合わされる、省略される、変更されるなどされてもよい。
本開示の恩恵を得る当業者には明らかであるように、様々な変更および変化がなされて
もよい。これらの変更および変化全てを包含することが意図され、それに応じて、上述の
説明は限定的でなく例示的として考えられるべきである。
もよい。これらの変更および変化全てを包含することが意図され、それに応じて、上述の
説明は限定的でなく例示的として考えられるべきである。
Claims (15)
- 一つ以上のコンピューティング装置を備えたシステムであって、
前記一つ以上のコンピューティング装置は、
プロバイダ・ネットワークのクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセス可能サービスを実装する、ノードのセットから収集されたネットワーク・トラフィック・メトリックスを含む、前記プロバイダ・ネットワークのメトリックスを取得し、
第１のクライアント・アカウントに割当てられた前記ノードのセットの第１のノードと、第２のクライアント・アカウントに割当てられた前記ノードのセットの第２のノードの間の一つ以上の関係を表す、ネットワーク・トポロジーを生成し、
取得した前記メトリックスに基づいて、前記ネットワーク・トポロジーに対応する性能インジケータを提供する
システム。 - 前記一つ以上のコンピューティング装置は、前記性能インジケータを提供するために、さらに
前記第１のクライアント・アカウントに割当てられた前記第１のノードのネットワークトラフィックと、前記第２のクライアント・アカウントに割当てられた前記第２のノードのネットワークトラフィックのための、それぞれのネットワーク・性能インジケータを提供する
ように構成される請求項１記載のシステム。 - 前記第１のクライアント・アカウントに割当てられた前記第１のノードのネットワーク・性能インジケータは、
測定されたネットワーク待ち時間と前記第１のノードに関連するトラヒックのネットワーク待ち時間における上限との間の比の表示を有する
請求項２記載のシステム。 - 前記一つのクライアント・アカウントに割当てられた前記第１のノードのネットワーク・性能インジケータは、前記第１のノードにおける測定されたネットワークトラフィックレートと、前記第１のノードのための帯域幅制限との間の比の表示を有する
請求項２記載のシステム。 - 前記一つ以上のコンピューティング装置は、さらに
前記第１のノードと前記第２のノードのネットワークトラフィックのための前記それぞれのネットワーク・性能インジケータを含む資源ヒートマップを表示する
ように構成される請求項２記載のシステム。 - 前記資源ヒートマップは、（ａ）前記第１のノードのプロセッサ・性能インジケータ、（ｂ）前記第１のノードのストレージ・性能インジケータ、（ｃ）前記第１のノードのメモリ・性能インジケータの少なくとも一つを有する
請求項５記載のシステム。 - 前記第１のクライアント・アカウントに割当てられた前記第１のノードと、前記第２のクライアント・アカウントに割当てられた前記第２のノードの間の前記一つ以上の関係は、前記第１のノードと前記第２のノードの間の一つ以上のネットワークリンクを有する
請求項１記載のシステム。 - 一つ以上のコンピューティング装置によって実行される方法であって、
プロバイダ・ネットワークのクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセス可能サービスを実装する、ノードのセットから収集されたネットワーク・トラフィック・メトリックスを含む、前記プロバイダ・ネットワークのメトリックスを取得すること、
第１のクライアント・アカウントに割当てられた前記ノードのセットの第１のノードと、第２のクライアント・アカウントに割当てられた前記ノードのセットの第２のノードの間の一つ以上の関係を表す、ネットワーク・トポロジーを生成すること、
取得した前記メトリックスに基づいて、前記ネットワーク・トポロジーに対応する性能インジケータを提供すること
を含む方法。 - 前記第１のクライアント・アカウントに割当てられた前記第１のノードのネットワークトラフィックと、前記第２のクライアント・アカウントに割当てられた前記第２のノードのネットワークトラフィックのための、それぞれのネットワーク・性能インジケータを提供すること
をさらに含む請求項８記載の方法。 - 前記第１のクライアント・アカウントに割当てられた前記第１のノードのネットワーク・性能インジケータは、
測定されたネットワーク待ち時間と前記第１のノードに関連するトラヒックのネットワーク待ち時間における上限との間の比の表示を有する
請求項９記載の方法。 - 前記一つのクライアント・アカウントに割当てられた前記第１のノードのネットワーク・性能インジケータは、前記第１のノードにおける測定されたネットワークトラフィックレートと、前記第１のノードのための帯域幅制限との間の比の表示を有する
請求項９記載の方法。 - 前記第１のノードと前記第２のノードのネットワークトラフィックのための前記それぞれのネットワーク・性能インジケータを含む資源ヒートマップを表示すること
をさらに含む請求項９記載の方法。 - 前記資源ヒートマップは、（ａ）前記第１のノードのプロセッサ・性能インジケータ、（ｂ）前記第１のノードのストレージ・性能インジケータ、（ｃ）前記第１のノードのメモリ・性能インジケータの少なくとも一つを有する
請求項１２記載の方法。 - 前記第１のクライアント・アカウントに割当てられた前記第１のノードと、前記第２のクライアント・アカウントに割当てられた前記第２のノードの間の前記一つ以上の関係は、前記第１のノードと前記第２のノードの間の一つ以上のネットワークリンクを有する
請求項８記載の方法。 - 一つ以上のコンピューティング装置によって実行されるプログラム命令を記録する、コンピュータアクセス可能な記録媒体であって、
前記プログラム命令は、
プロバイダ・ネットワークのクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセス可能サービスを実装する、ノードのセットから収集されたネットワーク・トラフィック・メトリックスを含む、前記プロバイダ・ネットワークのメトリックスを取得すること、
第１のクライアント・アカウントに割当てられた前記ノードのセットの第１のノードと、第２のクライアント・アカウントに割当てられた前記ノードのセットの第２のノードの間の一つ以上の関係を表す、ネットワーク・トポロジーを生成すること、
取得した前記メトリックスに基づいて、前記ネットワーク・トポロジーに対応する性能インジケータを提供すること
を含むコンピュータアクセス可能な記録媒体。
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/089,230 | 2013-11-25 | ||
| US14/089,230 US9674042B2 (en) | 2013-11-25 | 2013-11-25 | Centralized resource usage visualization service for large-scale network topologies |
| US14/089,224 US9647904B2 (en) | 2013-11-25 | 2013-11-25 | Customer-directed networking limits in distributed systems |
| US14/089,224 | 2013-11-25 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016533633A Division JP6450759B2 (ja) | 2013-11-25 | 2014-11-25 | 分散システムにおける顧客志向ネットワークの限界 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2020047290A Division JP7057796B2 (ja) | 2013-11-25 | 2020-03-18 | 分散システムにおける顧客志向ネットワークの限界 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2018170803A JP2018170803A (ja) | 2018-11-01 |
| JP6679673B2 true JP6679673B2 (ja) | 2020-04-15 |
Family
ID=53180290
Family Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016533633A Expired - Fee Related JP6450759B2 (ja) | 2013-11-25 | 2014-11-25 | 分散システムにおける顧客志向ネットワークの限界 |
| JP2018146686A Active JP6679673B2 (ja) | 2013-11-25 | 2018-08-03 | 分散システムにおける顧客志向ネットワークの限界 |
| JP2020047290A Active JP7057796B2 (ja) | 2013-11-25 | 2020-03-18 | 分散システムにおける顧客志向ネットワークの限界 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016533633A Expired - Fee Related JP6450759B2 (ja) | 2013-11-25 | 2014-11-25 | 分散システムにおける顧客志向ネットワークの限界 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2020047290A Active JP7057796B2 (ja) | 2013-11-25 | 2020-03-18 | 分散システムにおける顧客志向ネットワークの限界 |
Country Status (6)
| Country | Link |
|---|---|
| EP (3) | EP3982270B1 (ja) |
| JP (3) | JP6450759B2 (ja) |
| CN (2) | CN105765556A (ja) |
| AU (2) | AU2014352692B2 (ja) |
| CA (3) | CA2931524C (ja) |
| WO (1) | WO2015077756A1 (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10002011B2 (en) | 2013-11-04 | 2018-06-19 | Amazon Technologies, Inc. | Centralized networking configuration in distributed systems |
| US9256467B1 (en) * | 2014-11-11 | 2016-02-09 | Amazon Technologies, Inc. | System for managing and scheduling containers |
| US10261782B2 (en) | 2015-12-18 | 2019-04-16 | Amazon Technologies, Inc. | Software container registry service |
| US10069869B2 (en) | 2016-05-17 | 2018-09-04 | Amazon Technologies, Inc. | Versatile autoscaling |
| US10212031B2 (en) * | 2016-06-22 | 2019-02-19 | Amazon Technologies, Inc. | Intelligent configuration discovery techniques |
| US10742498B2 (en) | 2016-06-22 | 2020-08-11 | Amazon Technologies, Inc. | Application migration system |
| US10412022B1 (en) | 2016-10-19 | 2019-09-10 | Amazon Technologies, Inc. | On-premises scaling using a versatile scaling service and an application programming interface management service |
| US10409642B1 (en) | 2016-11-22 | 2019-09-10 | Amazon Technologies, Inc. | Customer resource monitoring for versatile scaling service scaling policy recommendations |
| EP3549018B1 (en) * | 2016-11-29 | 2021-04-07 | Telefonaktiebolaget LM Ericsson (publ) | Distribution of resources among actor instances |
| CN108363671B (zh) * | 2018-02-07 | 2020-01-14 | 中国平安人寿保险股份有限公司 | 一种接口切换的方法、终端设备及存储介质 |
| CN111801654A (zh) | 2018-03-01 | 2020-10-20 | 谷歌有限责任公司 | 高可用性的多单租户服务 |
| JP6488421B1 (ja) | 2018-09-12 | 2019-03-20 | 高周波熱錬株式会社 | スナバ回路及びパワー半導体モジュール並びに誘導加熱用電源装置 |
| US11290491B2 (en) * | 2019-03-14 | 2022-03-29 | Oracle International Corporation | Methods, systems, and computer readable media for utilizing a security service engine to assess security vulnerabilities on a security gateway element |
| US11669365B1 (en) | 2019-08-26 | 2023-06-06 | Amazon Technologies, Inc. | Task pool for managed compute instances |
| CN110519183B (zh) | 2019-09-29 | 2022-12-02 | 北京金山云网络技术有限公司 | 一种节点限速的方法、装置、电子设备及存储介质 |
| CN113037794B (zh) * | 2019-12-25 | 2023-04-18 | 马上消费金融股份有限公司 | 计算资源配置调度方法、装置及系统 |
| CN111585892B (zh) * | 2020-04-29 | 2022-08-12 | 平安科技（深圳）有限公司 | 数据中心流量管控方法和系统 |
| CN112073329B (zh) * | 2020-08-25 | 2023-01-24 | 北京五八信息技术有限公司 | 分布式限流方法、装置、电子设备和存储介质 |
| CN115348208B (zh) * | 2021-04-27 | 2024-04-09 | 中移(苏州)软件技术有限公司 | 一种流量控制方法、装置、电子设备和存储介质 |
| US11855848B2 (en) | 2021-08-27 | 2023-12-26 | Juniper Networks, Inc. | Model-based service placement |
| US11323339B1 (en) * | 2021-08-27 | 2022-05-03 | Juniper Networks, Inc. | Service placement assistance |
| CN115277469A (zh) * | 2022-07-12 | 2022-11-01 | 深圳壹账通智能科技有限公司 | 弱网可视化控制方法、装置、电子设备及可读存储介质 |
| CN115442310B (zh) * | 2022-11-10 | 2023-01-24 | 中亿(深圳)信息科技有限公司 | 基于物联网卡的应用程序流量消耗级别划分方法及装置 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5996090A (en) * | 1997-10-29 | 1999-11-30 | International Business Machines Corporation | Method and apparatus for quantitative diagnosis of performance problems using external representations |
| US20030046396A1 (en) * | 2000-03-03 | 2003-03-06 | Richter Roger K. | Systems and methods for managing resource utilization in information management environments |
| US20020095498A1 (en) * | 2000-06-05 | 2002-07-18 | Accordion Networks | Network architecture for multi-client units |
| AU2003286489A1 (en) * | 2002-10-18 | 2004-05-04 | Cariden Technologies, Inc. | Methods and systems to perform traffic engineering in a metric-routed network |
| US7457262B1 (en) * | 2004-11-05 | 2008-11-25 | Cisco Systems, Inc. | Graphical display of status information in a wireless network management system |
| US7987272B2 (en) * | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
| JP4589847B2 (ja) * | 2005-09-05 | 2010-12-01 | 日本電信電話株式会社 | 動的制御用ネットワークリソース制御方法および動的制御用ネットワークリソース制御装置 |
| CA2569750A1 (en) * | 2005-12-27 | 2007-06-27 | Solana Networks Inc. | Real-time network analyzer |
| JP2007335997A (ja) * | 2006-06-12 | 2007-12-27 | Sharp Corp | 携帯通信端末装置 |
| US20080002711A1 (en) * | 2006-06-30 | 2008-01-03 | Bugenhagen Michael K | System and method for access state based service options |
| US7895353B2 (en) * | 2008-02-29 | 2011-02-22 | Oracle International Corporation | System and method for providing throttling, prioritization and traffic shaping during request processing via a budget service |
| US8065559B2 (en) * | 2008-05-29 | 2011-11-22 | Citrix Systems, Inc. | Systems and methods for load balancing via a plurality of virtual servers upon failover using metrics from a backup virtual server |
| US20100029282A1 (en) * | 2008-07-31 | 2010-02-04 | Qualcomm Incorporated | Resource partitioning in heterogeneous access point networks |
| JP5444174B2 (ja) * | 2010-09-13 | 2014-03-19 | 日本電信電話株式会社 | ネットワーク可視化装置 |
| US8572241B2 (en) * | 2010-09-17 | 2013-10-29 | Microsoft Corporation | Integrating external and cluster heat map data |
| WO2012077390A1 (ja) * | 2010-12-07 | 2012-06-14 | 株式会社日立製作所 | ネットワークシステム、及びそのサービス品質制御方法 |
| JP5256406B2 (ja) * | 2011-03-30 | 2013-08-07 | 日本電信電話株式会社 | ネットワーク可視化方法およびネットワーク可視化装置 |
| US9565074B2 (en) * | 2011-04-26 | 2017-02-07 | Openet Telecom Ltd. | Systems, devices, and methods of orchestrating resources and services across multiple heterogeneous domains |
| US9130864B2 (en) * | 2011-06-27 | 2015-09-08 | Citrix Systems, Inc. | Prioritizing classes of network traffic to provide a predetermined quality of service |
| WO2013158926A1 (en) * | 2012-04-19 | 2013-10-24 | 2Nd Watch, Inc. | Cloud computing consolidator billing systems and methods |
| US9537749B2 (en) * | 2012-06-06 | 2017-01-03 | Tufin Software Technologies Ltd. | Method of network connectivity analyses and system thereof |
-
2014
- 2014-11-25 JP JP2016533633A patent/JP6450759B2/ja not_active Expired - Fee Related
- 2014-11-25 CA CA2931524A patent/CA2931524C/en not_active Expired - Fee Related
- 2014-11-25 WO PCT/US2014/067302 patent/WO2015077756A1/en active Application Filing
- 2014-11-25 EP EP21209407.2A patent/EP3982270B1/en active Active
- 2014-11-25 CN CN201480064245.9A patent/CN105765556A/zh active Pending
- 2014-11-25 EP EP20156823.5A patent/EP3671480B1/en active Active
- 2014-11-25 CN CN202011029333.9A patent/CN112134741B/zh active Active
- 2014-11-25 AU AU2014352692A patent/AU2014352692B2/en not_active Ceased
- 2014-11-25 CA CA3051918A patent/CA3051918A1/en not_active Withdrawn
- 2014-11-25 EP EP14864410.7A patent/EP3074876B1/en active Active
- 2014-11-25 CA CA3051933A patent/CA3051933A1/en active Pending
-
2017
- 2017-10-25 AU AU2017251757A patent/AU2017251757B2/en active Active
-
2018
- 2018-08-03 JP JP2018146686A patent/JP6679673B2/ja active Active
-
2020
- 2020-03-18 JP JP2020047290A patent/JP7057796B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2020096385A (ja) | 2020-06-18 |
| EP3982270B1 (en) | 2024-07-03 |
| JP7057796B2 (ja) | 2022-04-20 |
| AU2017251757B2 (en) | 2019-09-12 |
| CA3051918A1 (en) | 2015-05-28 |
| CA2931524A1 (en) | 2015-05-28 |
| AU2014352692A1 (en) | 2016-06-09 |
| JP6450759B2 (ja) | 2019-01-09 |
| AU2014352692B2 (en) | 2017-08-03 |
| JP2018170803A (ja) | 2018-11-01 |
| CN112134741B (zh) | 2023-09-05 |
| AU2017251757A1 (en) | 2017-11-16 |
| CN112134741A (zh) | 2020-12-25 |
| EP3671480B1 (en) | 2022-01-05 |
| CA2931524C (en) | 2019-09-24 |
| EP3074876A1 (en) | 2016-10-05 |
| JP2016541183A (ja) | 2016-12-28 |
| CN105765556A (zh) | 2016-07-13 |
| CA3051933A1 (en) | 2015-05-28 |
| EP3074876B1 (en) | 2020-03-18 |
| EP3982270A1 (en) | 2022-04-13 |
| WO2015077756A1 (en) | 2015-05-28 |
| EP3671480A1 (en) | 2020-06-24 |
| EP3074876A4 (en) | 2017-06-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6679673B2 (ja) | 分散システムにおける顧客志向ネットワークの限界 | |
| US10855545B2 (en) | Centralized resource usage visualization service for large-scale network topologies | |
| US9647904B2 (en) | Customer-directed networking limits in distributed systems | |
| JP7116759B2 (ja) | 分散システムにおける集中ネットワーク構成 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180803 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190528 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190618 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190918 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20191015 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200115 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200218 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200318 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6679673 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |