JP7060636B2 - 仮想ネットワークインタフェースオブジェクト - Google Patents

Description

多数の企業および他の組織は、（ローカルネットワークの一部として）同一場所に配置されているか、または代わりに、複数の別々の地理的位置に（例えば、１つもしくは複数のプライベートまたは公衆中間ネットワークを経由して）配置されているコンピューティングシステムを用いてなど、彼らの業務をサポートするために多数のコンピューティングシステムを相互接続するコンピュータネットワークを運用する。例えば、単一の組織によって、また単一の組織の代わりに運用されている民間データセンター、およびコンピューティング資源を顧客に提供するためにビジネスとして実体によって運用されている公共データセンターなどの、かなりの数の相互接続されたコンピューティングシステムを収容するデータセンターが当たり前になってきた。いくつかの公共データセンターの運営者は、様々な顧客によって所有されているハードウェアに対して、ネットワークアクセス、電力、および安全な設置施設を提供し、他方、他の公共データセンターの運営者は、彼らの顧客による利用に対して可能にされたハードウェア資源も含む、「完全なサービス」施設を提供する。しかし、通常のデータセンターの規模および範囲が増大するにつれて、物理的コンピューティング資源をプロビジョニング、運営、および管理するタスクがしだいに複雑になってきた。

コモディティハードウェアに対する仮想化技術の出現は、多様なニーズをもつ多数の顧客に対する大規模なコンピューティング資源の管理に関して利益をもたらし、様々なコンピューティング資源が複数の顧客によって効率的かつ安全に共有されるのを可能にする。例えば、仮想化技術は、単一の物理コンピューティングマシンが、各ユーザーに、その単一の物理コンピューティングマシンによってホストされる１つまたは複数の仮想マシンを提供することにより、複数のユーザー間で共有されるのを可能にし得、各かかる仮想マシンは、ユーザーに彼らが所与のハードウェアコンピューティング資源の唯一の運営者および管理者であるという錯覚を与え、同時に、様々な仮想マシン間にアプリケーションの分離およびセキュリティも提供する、別個の論理コンピューティングシステムとして動作するソフトウェアシミュレーションである。その上、いくつかの仮想化技術は、複数の別個の物理コンピューティングシステムにわたる複数の仮想プロセッサをもつ単一の仮想マシンなどの、２つ以上の物理資源にわたる仮想資源を提供することが可能である。別の例として、仮想化技術は、データ記憶ハードウェアが、各ユーザーに、複数のデータ記憶装置にわたって分散され得る仮想化データストアを提供することにより、複数のユーザー間で共有されるのを可能にし得、各かかる仮想データストアは、ユーザーに彼らがデータ記憶資源の唯一の運営者および管理者であるという錯覚を与える、別個の論理データストアとして機能する。

異なるタイプの仮想化コンピューティング、ストレージ、および／または他のサービスを提供するデータセンターの運営者は、通常、様々なタイプのネットワークインタフェースカード（ＮＩＣ）などのコモディティネットワークハードウェアを使用して、顧客の要求を受信し、かかる要求に対する応答を送信するために、標準的なネットワーキングプロトコルに依存する。仮想化技術における最近の進歩にもかかわらず、仮想サーバーの多数のネットワーキング関連の特性は依然として、通常、個々の物理ネットワークインタフェースカードのレベルで管理される。仮想化サービスの顧客によって要求される異なるタイプの動的ネットワーキング構成変更の複雑性が増大するにつれて、物理ＮＩＣレベルでのネットワーク管理がますます厄介になり得る。

少なくともいくつかの実施形態に従った、システム環境例を示す。 少なくともいくつかの実施形態に従った、インタフェースレコードの構成要素例を示す。 いくつかの実施形態に従って、インタフェースレコードが資源インスタンスにアタッチされる操作を示す。 いくつかの実施形態に従って、インタフェースレコードが資源インスタンスからデタッチされる操作を示す。 いくつかの実施形態に従って、インタフェースレコードが、そのレコードが以前にアタッチされていたのとは異なる資源インスタンスにアタッチされる操作を示す。 いくつかの実施形態に従って、第２のインタフェースレコードが資源インスタンスにアタッチされる操作を示す。 いくつかの実施形態に従って、アタッチされたインタフェースレコードをもつ資源インスタンスが、１つのサービスプラットフォームから別のサービスプラットフォームに移動される操作を示す。 いくつかの実施形態に従って、インタフェースレコードを資源インスタンスにアタッチすることにより達成可能ないくつかのネットワーク構成例の図を提供する。 少なくともいくつかの実施形態に従い、ネットワークインタフェース仮想化コーディネータによって提供され得る、例示的なウェブベースインタフェースの一部の図である。 少なくともいくつかの実施形態に従って、インタフェースレコードサービスを提供するための方法の流れ図である。 いくつかの実施形態で使用され得るコンピュータシステム例を示すブロック図である。

実施形態は、本明細書では、いくつかの実施形態および例示的な図に対する例として説明されるが、当業者は、実施形態は説明される実施形態または図に限定されないことを理解するであろう。本明細書に対する図および詳細な説明は、実施形態を、開示される特定の形に制限することを意図しておらず、意図は、添付の請求項によって定義されるとおりに精神および範囲に含まれる、全ての修正、均等物および代替手段を包含することである、ことが理解されるべきである。本明細書で使用される見出しは、編成目的のみのためであり、記述または請求項の範囲を制限するために使用されることを意味しない。本願を通して、「し得る（ｍａｙ）」という用語は、義務的な意味（すなわち、～しなければならないことを意味する）ではなく、許可的な意味（すなわち、～する可能性を有することを意味する）で使用される。同様に、「含む（ｉｎｃｌｕｄｅ）」，「含む（ｉｎｃｌｕｄｉｎｇ）」、および「含む（ｉｎｃｌｕｄｅｓ）」は、制限ではなく、包含を意味する。

仮想ネットワークインタフェースオブジェクトを管理するための方法および装置の様々な実施形態が説明される。企業または公共部門組織などの実体によって、インターネットを経由してアクセス可能な（様々なタイプのクラウドベースのコンピューティングまたはストレージなどの）１つまたは複数のサービスを、分散された組のクライアントに提供するために設定されたネットワークは、本文書では、プロバイダネットワークと呼ばれ得る。かかるプロバイダネットワークは、プロバイダによって提供されるサービスを実装および分散するために必要な、物理および仮想コンピュータサーバー、記憶装置、ネットワーキング装置および同類のものの集合などの、様々な資源プールを収容する多数のデータセンターを含み得る。

例えば、異なる組の資源が、厄介なセキュリティ設定変更、再構成および／またはネットワークインタフェースカードの物理的な移動を用いる必要なく、アクセスされ得る柔軟
性を大幅に強化するためなど、いくつかの異なる理由で、いくつかの実施形態では、プロバイダネットワークの運営者は、ネットワークインタフェースのために１組の仮想サービスを設定し得る。かかるサービスは、プロバイダネットワークの様々な資源にアクセスする必要のあるネットワーキング動作を管理するための１組のインタフェースレコードの維持、およびそれに関する様々な操作の実装に対して責任があるネットワークインタフェース仮想化コーディネータ（本文書では、略語の「ＮＩＶＣ」を使用しても参照され得る）によって可能にされ得る。いくつかの実施形態では、ＮＩＶＣの機能の異なる部分が、プロバイダネットワークの様々なハードウェアプラットフォーム上で実行するハイパーバイザーまたはオペレーティングシステムソフトウェアのモジュール、エッジ装置上のルーターソフトウェア、および同類のものなどの、いくつかの異なる協働するソフトウェア構成要素および／または装置内に組み込まれ得る。

一実施態様では、プロバイダネットワークは、顧客に、仮想化計算資源および／またはストレージ資源の多数のインスタンスを提供し得、その各々は、顧客がそれとやりとりすることを可能にするために、ネットワークアドレス指定能力を必要とし得る。かかる実施態様におけるＮＩＶＣは、顧客が、修正可能で移転可能なインタフェースレコードが作成されることを要求することを可能にし得、それは、顧客が設定し、次いで、時間とともに様々な資源インスタンスと必要に応じて関連付けおよび関連付けの解除を行うことを欲する、ネットワーキング構成情報（例えば、セキュリティポリシー、アドレス指定およびルーティング情報など）の様々なタイプの要素を含む。インタフェースレコードは、いくつかの実施形態では、１つまたは複数のインターネットプロトコル（ＩＰ）アドレスおよび、ＩＰアドレスまたは複数のアドレスが属するサブネットに対するサブネット識別子を含み得る。さらに、様々なセキュリティ関連の設定が、インタフェースレコード内に含まれ得、例えば、どの実体またはユーザーが、以下でさらに詳述する「アタッチ」および「デタッチ」操作を実行することが許可されるかを識別する。ＮＩＶＣは、要求されたインタフェースレコードを作成し得、いくつかの実施形態では、それを、永続的リポジトリまたはインタフェースレコードのデータベース内に格納し得る。

顧客は、いくつかの実施形態では、ＮＩＶＣが、インタフェースレコードを、仮想化計算サーバーまたはストレージサーバーなどの資源インスタンスに「アタッチする」ことを要求し得、それにより、資源インスタンスがインタフェースレコードのＩＰアドレスを対象とした入トラフィックを受信することを可能にして、資源インスタンスからのアウトバウンドトラフィックが、それがそのＩＰアドレスで生じたことを示すのを可能にする。ネットワークトラフィックは、仮想化資源インスタンスが現在その上でインスタンス化され得る物理プラットフォームでたまたまインストールされている１つまたは複数の物理ネットワークインタフェースカード（ＮＩＣ）にわたって流れ得るが、インタフェースレコードの特性は、任意の特定のＮＩＣまたは複数のＮＩＣとは無関係であり、任意の特定の資源インスタンスとも無関係であると見なされ得る。所与の時点において、例えば、インタフェースレコードは、資源インスタンスと関連付けられている（すなわち、それに「アタッチされている」）こともあれば、関連付けられていないこともある。それがどの資源インスタンスとも関連付けられていない間、インタフェースレコードは、インタフェースレコードのＮＩＶＣのリポジトリ内に、非アクティブまたは休止モードで存在し得、その特性を保持する。

インタフェースレコードを、現在それがアタッチされている資源インスタンスから「デタッチする」ための要求に応答して、ＮＩＶＣは、いくつかの実施形態では、インタフェースレコードのＩＰアドレスまたは複数のアドレスを対象としたトラフィックがその資源インスタンスにもう届かないことを確実にし得る。顧客は、ＮＩＶＣが、インタフェースレコードを、それが以前にアタッチされていたインスタンスとは異なる資源インスタンス（異なる仮想化計算サーバー）に今アタッチすることも要求し得る。この新しいアタッチ
操作は、次いで、物理ＮＩＣのどの組でも適切なものを使用して、インタフェースレコード内に含まれるＩＰアドレスを対象としたＩＰトラフィックが新しくアタッチされた資源インスタンスに届くという結果となり得、従って、顧客が、物理ＮＩＣに直接対処することなく、資源インスタンスにわたって、ネットワーク構成設定および関連付けられたセキュリティ設定を容易に転送することを可能にする。所与のインタフェースレコードに関連付けられたＩＰアドレスの修正、セキュリティ設定の修正、課金関連操作および同類のものなどの様々な他の操作が、様々な実施形態において、仮想ネットワークインタフェースコーディネータによってサポートされ得る。

システム環境例
図１は、少なくともいくつかの実施形態に従った、システム環境例を示す。システム１００は、複数の資源インスタンス１２０、例えば、クラウドコンピューティングサービスまたはクラウドストレージサービスなどの、様々なタイプのサービスをクライアント１４８に提供するように設定された、プロバイダネットワークのインスタンス１２０Ａ、１２０Ｂ、１２０Ｃおよび１２０Ｄを含み得る。クライアント１４８は、その結果として、バックエンドデータベースに関連付けられたウェブサイトなどの、インスタンス１２０上で様々なサービスを実装し、それらを彼ら自身の顧客に公開し得る。資源インスタンス１２０は、例えば、図１のサービスプラットフォーム１５０Ａ、１５０Ｂ、および１５０Ｃなどの１つまたは複数の物理プラットフォーム上に常駐している、仮想コンピューティングシステムまたは仮想記憶システムなどの、仮想化サービスを実装し得る。仮想コンピューティングシステムを提供する資源インスタンス１２０に対するサービスプラットフォーム１５０は、例えば、１つまたは複数のＣＰＵ（ならびに関連付けられたメモリ、ストレージおよびネットワーキングハードウェア）を有するハードウェアサーバーおよび、コンピューティングシステムの仮想化を実装する（ハイパーバイザーおよび／またはオペレーティングシステムの要素などの）ソフトウェアを含み得る。同様に、仮想記憶システムを提供するサービスプラットフォーム１５０は、例えば、１つまたは複数のハードウェア記憶装置（ディスク配列または記憶機器）の部分もしくは全部、ならびに関連付けられた処理要素およびソフトウェアを含み得る。

いくつかの実施形態では、資源インスタンス１２０は、１つのプラットフォーム１５０から別へ転送可能であり得、例えば、仮想コンピューティングシステムが、当初はある物理サーバー上で起動され、後に、必要に応じて、別の物理サーバーに移動され得る。さらに、複数の資源インスタンスが１つのサービスプラットフォーム１５０上に常駐し得、例えば、資源インスタンス１２０Ｂおよび１２０Ｃが、サービスプラットフォーム１５０Ｂ上に常駐して示されている。複数の常駐資源インスタンス１２０を有するサービスプラットフォーム１５０Ｂの物理資源（例えば、ＣＰＵおよびネットワークカード）は、異なる実施形態では、様々な方式を使用して分散され得る。一実施形態では、資源のいくつかは、独占的に資源インスタンスに割り当てられ得、例えば、サービスプラットフォーム１５０Ｂが４つのＣＰＵを有する場合、２つのＣＰＵが資源インスタンス１２０Ｂに割り当てられ得、他方、他の２つは資源インスタンス１２０Ｃに割り当てられ得る。別の実施形態では、物理資源は、タイムスライスを使用して共有され得、例えば、４つ全てのＣＰＵが、それらのコンピューティング需要に応じて、所与のタイムスライス内のＣＰＵサイクルがどのようにインスタンス間で分散されるかを決定するために設定されたスケジューリング機構を用いて、いずれかの資源インスタンスによって利用可能にされ得る。図１に示された実施形態では、各サービスプラットフォーム１５０が、１つまたは複数の物理ネットワークインタフェースカード（ＮＩＣ）を有する―サービスプラットフォーム１５０ＡはＮＩＣ １１０Ａを有し、サービスプラットフォーム１５０ＢはＮＩＣ １１０Ｂを有し、サービスプラットフォーム１５０ＣはＮＩＣ １１０Ｃおよび１１０Ｄを有する。所与のサービスプラットフォーム１５０上にたまたま常駐している資源インスタンス１２０に出入りして流れるネットワークトラフィックは、サービスプラットフォームのＮＩＣ １
１０のうちの１つまたは複数を通って流れる。いくつかの実施態様では、単一の資源インスタンス１２０が複数のハードウェアサービスプラットフォーム１５０に拡がり得、その場合、複数のサービスプラットフォーム１５０のうちのいずれかで利用可能なＮＩＣ １１０のいずれかが使用され得る。一実施形態では、資源インスタンス１２０は、非仮想化サーバーを含み得、すなわち、資源インスタンスは、ハイパーバイザーを使用する代わりに、裸のハードウェアサービスプラットフォーム１５０上で実行する従来型のオペレーティングシステムを使用して実装され得る。

システム１００は、図示した実施形態でネットワークインタフェースに対して１組の仮想化サービスを提供するために動作可能であるネットワークインタフェース仮想化コーディネータ（ＮＩＶＣ）１８０を含み得る。クライアント１４８は、インタフェースレコード１７０を作成する、それらを資源インスタンス１２０にアタッチする、それらをデタッチする、それらを修正する、それらの問合せを行う、などを行うための要求を含む様々なタイプの要求１５３を投入し得るが、これらのタイプの操作の各々は、以下でさらに詳述される。所与の要求１５３に応答して、ＮＩＶＣ １８０は、１５７Ａ、１５７Ｂ、１５７Ｃおよび１５７Ｄというラベルの付けられた矢印によって示されるように、インタフェースレコード１７０およびサービスプラットフォーム１５０上の資源インスタンス１２０に影響を及ぼし得る様々な操作を実行し得る。例えば、ＮＩＶＣ １８０は、クライアント１４８からの作成要求に応答して、様々な資源インスタンス１２０と要求に応じて関連付けおよび関連付けの解除を行うことができる、１組のネットワーキング関連特性を各々が含み得る１７０Ａおよび１７０Ｂなどのインタフェースレコードを生成し得る。インタフェースレコード１７０は、１組のインメモリデータ構造で生成され得、いくつかの実施形態では、永続記憶装置上のデータベースなどの、リポジトリ１８５内に格納され得る。ＴＣＰ／ＩＰプロトコルを使用したネットワークに対するインタフェースレコードは、例えば、１つまたは複数のＩＰアドレス、そのＩＰアドレスまたは複数のアドレスを含むサブネットの１つまたは複数のサブネット識別子、および以下でさらに詳述する１組のセキュリティ特性を含み得る。いくつかの実施形態では、インタフェースレコード１７０は、様々な状態フィールドなどの１つまたは複数の他のフィールド、送信元および宛先アドレスチェック設定、課金関連情報、現在関連付けられている資源インスタンス１２０の識別、インタフェースレコードと現在関連付けられている物理ネットワークインタフェースカード１１０の媒体アクセス制御（ＭＡＣ）アドレス、および同類のものも含み得る。ＴＣＰ／ＩＰ以外のネットワークプロトコルを採用するネットワークに対するインタフェースレコードは、使用されたプロトコルに適切なネットワークアドレス関連情報を含み得る。

いくつかの実施形態では、ＮＩＶＣ １８０は、インタフェースレコード１７０を資源インスタンス１２０と動的に関連付けるために「アタッチ」操作を実行し、それにより、インタフェースレコード１７０で指定されたネットワーキングおよびセキュリティ特性に従って、トラフィックが、資源インスタンス１２０に出入りして流れることを可能にするように構成され得る。クライアント１４８から受信したアタッチ要求１５３に応答して、例えば、一実施態様では、ＮＩＶＣ １８０は、次の操作の一部または全部を実行し得る：（ａ）指定されたインタフェースレコード１７０および／または他の場所に格納されたセキュリティ情報に基づいて、クライアントが、インタフェースレコードの指定された資源インスタンス１２０とのアタッチを要求することを認可されていることを検証する；（ｂ）インタフェースレコードのネットワーキング情報（ＩＰアドレスまたは複数のアドレス、サブネット識別子など）が、指定された資源インスタンス１２０との間のネットワークトラフィックのアクティブ化に対して適切であることを検証する（例えば、ＮＩＶＣ １８０は、ＩＰアドレスが既に別のインスタンスに対して使用されているか、従って利用できないかどうかをチェックし得る）；（ｃ）物理ＮＩＣ １１０が動作可能であり、資源インスタンス１２０が現在常駐しているサービスプラットフォーム１５０での資源インスタンス１２０による使用に対して利用可能であることを確実にする；（ｄ）必要な構成
変更を開始または実行して、例えば、サービスプラットフォーム１５０で、ならびにプロバイダネットワークの適切なルーター、ゲートウェイおよび他のネットワーク装置で、実行するハイパーバイザーまたはオペレーティングシステムソフトウェア内で、特定の資源インスタンス１２０が、インタフェースレコード内で指定されたＩＰアドレスまたは複数のアドレスからトラフィックの送信、およびそのアドレスでのトラフィックの受信を開始することを可能にする；ならびに（ｅ）インタフェースレコード１７０および／またはリポジトリ１８５に対する変更を行って、実行されたアタッチ操作を反映する。構成変更の一部として、いくつかの実施形態では、ルーティングテーブルエントリなどの新規または修正されたルーティング情報が、１組のルーター、ゲートウェイ、および同類のものに伝搬され得る。一実施形態では、ＮＩＶＣ １８０は、各資源インスタンス１２０が、その資源インスタンスがアクティブ化されているか、または起動されている場合にはいつでも、それにアタッチされた少なくとも１つのインタフェースレコード１７０を有することを確実にし得る。

ＮＩＶＣ １８０は、いくつかの実施形態では、それが現在アタッチされている資源インスタンス１２０からインタフェースレコード１７０を「デタッチ」または関連付けを解除するように動作可能でもあり得る。クライアント１４８からのデタッチ要求１５３に応答して、ＮＩＶＣ １８０は、かかる実施形態では、インタフェースレコード１７０内で指定されたＩＰアドレスまたは複数のアドレスを対象としたか、またはそこからのトラフィックがさらに、資源インスタンスに出入りして流れるのを禁止し得る。それを行うために、ＮＩＶＣ １８０は、次の操作の一部または全部を実行し得る：（ａ）指定されたインタフェースレコード１７０および／または他の場所に格納されたセキュリティ情報に基づいて、クライアントが、インタフェースレコードの指定された資源インスタンス１２０からのデタッチを要求することを認可されていることを検証する；（ｂ）必要な構成変更を開始または実行して、例えば、サービスプラットフォーム１５０で、ならびに適切なルーター、ゲートウェイおよび他のネットワーク装置で、実行するハイパーバイザーまたはオペレーティングシステムソフトウェア内で、インタフェースレコード１７０のＩＰアドレス（複数可）に関連付けられたネットワークトラフィックが、指定された資源インスタンス１２０に出入りして流れるのを防ぐ；ならびに（ｃ）インタフェースレコード１７０および／またはリポジトリ１８５に対する変更を行って、実行されたデタッチ操作を反映する。

以前、特定の資源インスタンス１２０にアタッチされ、その後その資源インスタンス１２０からデタッチされたインタフェースレコード１７０は、いくつかの実施形態では、後に、クライアントの要求で、ＮＩＶＣ １８０により、任意の所望の資源インスタンス（異なる資源インスタンス、またはそれが以前にアタッチされたのと同じ資源インスタンスのいずれか）にアタッチされ得る。各実施形態では、同じＩＰアドレスが、まず、１つの「アタッチ期間」中に、特定のＮＩＣ １１０Ａを通して、１つの資源インスタンス１２０Ａでトラフィックの送信および受信を行うために、次いで、後続の「アタッチ期間」中に、潜在的に異なるＮＩＣ １１０Ｂを通して、および／または異なるサービスプラットフォーム１５０で、異なる資源インスタンス１２０Ｂでトラフィックの送信および受信を行うために、使用され得る。クライアントが所与のＩＰアドレスを異なる時に異なる資源インスタンス１２０にマッピングするのを可能にすることに加えて、ＮＩＶＣ １８０は、クライアントが、インタフェースレコード１７０に関連付けられたセキュリティ設定の一部または全部を再使用することも可能にし得、このようにして、ネットワーキング構成変更を行うために必要とされる労力および複雑性を実質的に削減する。多くの実施形態では、複数のインタフェースレコード１７０が、単一の資源インスタンス１２０にアタッチされ得、このようにして、複数のＩＰアドレスが同一の資源インスタンスに対して使用されるのを可能にする。いくつかの実施態様では、単一のインタフェースレコード１７０が、複数の資源インスタンス１２０に同時にアタッチされ得：例えば、ＮＩＶＣ １８０は
、インタフェースレコード１７０内で指定された単一のＩＰアドレスを対象としたトラフィックを、２つ以上の資源インスタンス１２０にわたって、分散するか、または負荷分散することが可能であり得る。ＮＩＶＣ １８０のこれらの機能を使用して、ＩＰアドレス、サブネット、およびネットワークセキュリティ設定の資源インスタンス１２０への高度に柔軟なマッピングが、様々な実施形態で実装され得る。

インタフェースレコードの構成要素例
図２は、少なくともいくつかの実施形態に従った、インタフェースレコード１７０の構成要素の例を示す。図２に示す要素のサブセットまたはフィールドのみがいくつかの実施態様では実装され得、実装された全てのフィールドがデータを投入される必要はない（すなわち、フィールドのいくつかはブランクまたは空文字のままにされ得る）。インタフェースレコード１７０が作成される場合、新しいインタフェース識別子２０１がそれに対して作成され得る。いくつかの実施態様では、記述フィールド２０２が、インタフェースレコードの作成を要求したクライアント１４８によって、例えば、「ニュースウェブサイト用のインタフェース１」を記入され得る。インタフェースレコードがその中で使用されるプロバイダネットワークは、いくつかの実施形態では、複数の論理パーティションを含み得、インタフェースレコード１７０は、かかる場合には、論理パーティション識別子２０３を含み得る。例えば、プロバイダネットワークの運営者は、特定の顧客に対する論理パーティションを、１組のサービスプラットフォーム１５０、１組のネットワークアドレス範囲、他の機器または資源、およびネットワーク管理機能をその顧客による排他的使用のために確保することにより、確立し得、その顧客に、顧客によって使用されている機器が実際には他の顧客によって共有される施設に常駐し得る場合でも、それ自身の分離された、および専用のデータセンターまたは複数のセンターを効率的に提供する。論理パーティションは、いくつかの実施形態では、地理的に分散されている資源を含み得、それにより、顧客に、資源の仮想プライベート「クラウド」へのアクセスの利益を供与する。いくつかの場合、インタフェースレコード１７０は、区域識別子２０４を含み得、それは、例えば、そのサービスプラットフォーム１５０がインタフェースレコード１７０へのアタッチのために利用可能であり得る地理的地域またはデータセンターの組を示す。

いくつかのタイプのネットワークアドレス関連フィールドのいずれでも、異なる実施形態では、インタフェースレコード１７０内に含まれ得る。１つまたは複数のプライベートＩＰアドレス２０５が、いくつかの実施形態では、インタフェースレコードに対して指定され得；これらのＩＰアドレスは、プロバイダネットワーク内でのルーティング用に内部で使用され得、プロバイダネットワークの外部から直接アクセス可能でない。１つまたは複数のパブリックＩＰアドレス２１５も、いくつかの実施形態では含まれ得；これらのＩＰアドレスは、プロバイダネットワークの外部で、例えば、パブリックインターネットの様々なルーターまたはプロバイダネットワークのピアネットワークに対して、可視であり得る。例えば、ＮＩＶＣ １８０の構成要素を含め、様々な装置または構成要素が、必要に応じ、様々な実施形態で、パブリックＩＰアドレス２１５とプライベートＩＰアドレス２０５との間で変換するために、任意の所望のネットワークアドレス変換技術または複数の技術を実装し得る。１つまたは複数のサブネット識別子２２５は、インタフェースレコード内に含まれ得る。

サブネットという用語は、本明細書で広く使用されるように、ネットワークの論理的に可視な下位区分である。ＩＰネットワークの場合、サブネットに属する論理または物理装置の組は、それらのＩＰアドレス内の、共通で、同一の、最上位ビットグループでアドレス指定され得る。これは、ＩＰアドレスの２つのフィールド（ネットワークまたはルーティングプレフィックスおよび「残り」のフィールド）への論理的分割という結果となる。残りのフィールドは、論理または物理装置に対する特定の識別子として機能し得る。ルーティングプレフィックスは、クラスレスドメイン間ルーティング（ＣＩＤＲ）表記法で表
され得、それは、スラッシュ（／）で分けられたプレフィックスのビット長が続く、ネットワークの第１のアドレスとして書かれ得る。例えば、１０．１．１．０／２４は、アドレス１０．１．１．０から始まり、２４ビットがネットワークプレフィックスに対して割り当てられ、残りの８ビットが装置識別子用に予約されている、インターネットプロトコルバージョン４ネットワークのプレフィックスである。ＩＰｖ４では、ルーティングプレフィックスはサブネットマスクの形式でも指定され得、それは、アドレスに似た、ドットで区切られた４つの１０進表現である。例えば、２５５．２５５．２５５．０は、１０．１．１．０／２４プレフィックスに対するネットワークマスクである。わずかに異なる表記法が、ＩＰバージョン６ネットワークに対して、およびＴＣＰ／ＩＰスイート以外のプロトコルを使用するネットワークに対して、使用され得る。サブネットは、一般に、様々な理由で（例えば、異なる組のネットワークアドレス指定可能装置間に論理的分離を提供するため、論理パーティションの資源（仮想プライベートクラウドなど）をより容易な管理のために階層構造に配置するため、など）、使用され得る。インタフェースレコード１７０内に含まれるサブネット識別子２２５は、いくつかの実施態様では、その結果として、サブネットに対するＣＩＤＲ表現を含み得るか、またはそれにコード化し得る文字列―例えば、「サブネット－ｄｆ５４３ｆｄａ－１０．１．１．０／２４」を含み得る。一実施形態では、ドメインネームサーバー（ＤＮＳ）も、インタフェースレコード１７０に含まれ得る。

いくつかの実施形態では、インタフェースレコード１７０は、セキュリティ関連特性２３５を含み得る。いくつかのプロバイダネットワークは、ユーザーが、例えば、インタフェースレコード１７０がそれに対してアタッチされ得る資源インスタンス１２０で許可される入トラフィックおよび／または出トラフィックのタイプに対して、ファイアウォール関連規則を含む、規則を指定することを可能にし得；かかる規則は、「セキュリティグループ」と呼ばれ得、セキュリティグループ（複数可）フィールド２４５で識別され得る。様々なポートおよびプロトコル制約が、かかる規則を使用して実施され得、また、複数の規則が各インタフェースレコードと関連付けられ得る。例えば、ユーザーは、ＨＴＴＰおよびＨＴＴＰｓ出トラフィックまたは入トラフィックのみが許可されることを確実にするため、トラフィックがそれに対して許可されるＴＣＰまたはＵＤＰ（ユーザーデータグラムプロトコル）ポートの組を制限するため、様々なポリシーに従って入トラフィックおよび出トラフィックをフィルタ処理するためなどで、セキュリティグループを使用し得る。いくつかの実施態様では、アタッチャ（ａｔｔａｃｈｅｒ）リスト２４７が指定され得、どのユーザーまたは実体がインタフェースレコード１７０の資源インスタンス１２０へのアタッチを要求することを許可されているかを示す。いくつかの場合には、別個のデタッチャリストが、どの実体がインタフェースレコード１７０をデタッチできるかを指定するために使用され得、他方、他の場合には、アタッチャリスト２４７などの単一のリストが認可されたアタッチャおよびデタッチャを識別するために使用され得る。インタフェースレコード１７０のＩＰアドレス（例えば、パブリックＩＰアドレス２１５および／またはプライベートＩＰアドレス２０５）を設定または修正することを許可されているユーザーまたは実体の組が、ＩＰアドレス設定者（ｓｅｔｔｅｒ）リスト２４９で提供され得、いくつかの実施形態では、インタフェースレコード１７０を所有する（または、その様々な他のフィールドを修正できる）ユーザーまたは実体の組が、所有者／修正者フィールド２５３で指定され得る。例えば、フィールド２５３で識別された所有者／修正者は、いくつかの実施形態では、アタッチャリスト２４７またはＩＰアドレス設定者リストを変更することを許可され得、このようにして、インタフェースレコードをアタッチもしくはデタッチするか、またはそのＩＰアドレス（複数可）を修正することを許可された実体の組を変更する。「リスト」という用語が、フィールド２４７、２４９、および２５３に対して使用されているが、様々な実施形態では、リスト以外の論理データ構造（配列、ハッシュテーブル、組および同類のものなど）が、様々なセキュリティ特権、役割および／または機能を与えられた実体のグループを表すために使用され得る。

いくつかの実施形態では、ユーザーは、資源インスタンス１２０を「終了する（ｔｅｒｍｉｎａｔｅ）」ことを許可され得る。例えば、クライアント１４８は、仮想計算サーバー資源インスタンス１２０を設定し、インタフェースレコード１７０をそのインスタンスにアタッチして、所望の組の計算をそのインスタンス上で実行し、次いで、所望の計算が完了するとそのインスタンスを終了する要求を発行し得る（従って、資源インスタンス１２０がもはや要求されないことを示す）。かかる実施形態では、「終了時に削除」設定２５１が、資源インスタンス１２０の終了時に、アタッチされたインタフェースレコード１７０に何が起こるかを指定するために使用される。終了時に削除が、終了されている資源インスタンス１２０にアタッチされたインタフェースレコード１７０に対して「真」に設定される場合、ＮＩＶＣ １８０は、インタフェースレコード１７０を削除し得る（例えば、レコードがリポジトリ１８５から除去され得る）。終了時に削除が「偽」に設定される場合、ＮＩＶＣ １８０は、インタフェースレコード１７０を、例えば、それが何等かの他の資源インスタンスに再度アタッチされ得るように、保持し得る。一実施形態では、インタフェースレコード１７０が資源インスタンス１２０にアタッチされる場合、インタフェースレコードとは別のアタッチレコードが、その関係を表すために作成され得、終了時に削除特性が、インタフェースレコードとの関連付けの代わりに、またはそれに加えて、アタッチレコードと関連付けられ得る。かかる実施形態では、インタフェースレコード１７０は、インタフェースレコードが現在関与している各アタッチに対するアタッチレコードまたは複数のレコードへの参照またはポインタを含み得、「終了時に削除」の異なる値が各アタッチレコードに対して設定され得る。かかる環境では、どの資源インスタンス１２０にもたまたまアタッチされていないインスタンスレコード１７０は、それがアタッチされていないままである限り、それと関連付けられた「終了時に削除」特性を持たない。このようにインタフェースレコードを資源インスタンスとは無関係に持続することにより、新しいインスタンスがアクティブ化されるたびに、様々なセキュリティ関連特性および他の特性を設定するオーバーヘッドが、クライアント２４８に対して削減され得る。

一実施形態では、インタフェースレコード１７０は、インタフェースレコード１７０がアタッチされている資源インスタンス１２０に伝送されるネットワークパケットに対して、送信元および／または宛先チェックが実行されるかどうかの指標２６５などの、ルーティング関連情報を含み得る。送信元／宛先チェック設定が「偽」または「オフ」に設定されている場合、ルーティング判断は、パケットの送信元および宛先ＩＰアドレスに基づいて行われ得、例えば、パケットが、１つのサブネットから別のサブネットへ転送され得；設定が「真」または「オン」に設定されている場合、いくつかの実施形態では、資源インスタンスはルーティングを実行しない。従って、送信元／宛先フィールド２６５は、いくつかの実施形態では、インタフェースレコードがアタッチされる資源インスタンスが、それが最終宛先ではないパケットについてルーティングもしくはゲートウェイ機能を実行するかどうか、または、それがかかるパケットを無視するかどうかを制御するために使用され得る。他の実施形態では、ルーティングテーブルエントリなどの、他のタイプのルーティング関連情報も、または代わりに、インタフェースレコード１７０に含まれ得る。課金関連情報２６７が、いくつかの実施態様では含まれ得、例えば、インタフェースレコード１７０と関連付けられたネットワークトラフィックに対して請求される実体またはユーザーを識別する。いくつかの実施態様では、顧客は、いくつのインスタンスレコードが資源インスタンスにアタッチされているかに関係なく、彼らが作成するインスタンスレコード１７０の数に少なくとも一部基づいて請求され得；他の実施態様では、課金は、定期的な料金（例えば、インスタンスレコード数および／またはアタッチされたインスタンスレコードの数に基づく）および非定期的な料金（例えば、トラフィックフロー測定値に基づく）の両方を含み得る。

インタフェース状態フィールド２６８は、インタフェースレコード１７０の現在の状態
―例えば、インタフェースレコードが「利用可能」、「無効」、または「修理中（ｉｎ－ｒｅｐａｉｒ）」であるかを、示すために使用され得る。同様に、アタッチ状態フィールド２６９は、いくつかの実施形態では、インタフェースレコード１７０が、現在、アタッチされているか、デタッチされているか、またはアタッチもしくはデタッチされている途中であるかを示すために使用され得る。一実施態様では、前述のように、（インタフェースレコード１７０とは別の）アタッチのレコードが、対応するアタッチ操作が実行されるときに作成され得、インタフェースレコード１７０の現在のアタッチの識別子または複数の識別子がアタッチｉｄフィールド２７１に格納され得る。インタフェースレコード１７０が現在アタッチされている、資源インスタンスまたは複数のインスタンス１２０の識別子が、アタッチされたインスタンスフィールド２７３に格納され得、いくつかの実施形態では、そのアタッチを要求したユーザーまたは実体が、アタッチ所有者フィールド２７５で識別され得る。一実施形態では、インタフェースレコード１７０のＩＰアドレスを対象とした／そこからのトラフィックに対して現在使用可能なＮＩＣまたは複数のＮＩＣ １１０の識別子のリストが、例えば、ＭＡＣアドレス（複数可）フィールド２７７の形式で、保持され得る。いくつかの実施態様では、インタフェースレコードのＩＰアドレスへの、またはそのＩＰアドレスから流れるトラフィックの量に関する統計値などの、監視情報２７９も、インタフェースレコードで保持され得る。様々な実施形態では、図２に示していない他のフィールドが、インタフェースレコード１７０に含まれ得る。いくつかの実施形態では、クライアントは、ネットワークの分離を実装するために、ＶＬＡＮ規格（８０２．１Ｑ規格など）に従ってフォーマットされた仮想ローカルエリアネットワーク（ＶＬＡＮ）タグなどの、タグをインタフェースレコード１７０と関連付け得る。かかる実施形態では、かかるタグもインタフェースレコード１７０に格納され得るか、またはそこから参照され得る。

一実施形態では、図２に示すフィールドのいくつかは、他のオブジェクトへの参照またはポインタで置換され得る。例えば、インタフェースレコード１７０に対するセキュリティ情報が、別個のセキュリティオブジェクト内に格納され得、インタフェースレコード１７０は、そのセキュリティオブジェクトへの参照を格納し得る。同様に、資源インスタンス１２０のインタフェースレコード１７０への各アタッチは、アタッチオブジェクトによって表され得、いくつかの実施態様では、インタフェースレコードは、適切なアタッチオブジェクトへのポインタまたは参照であり得る。

アタッチ、デタッチ、およびインスタンス移動操作
図３～図７は、様々な実施形態において、ＮＩＶＣ １８０によってサポートされるいくつかのタイプの操作例を示す。図３は、いくつかの実施形態に従って、インタフェースレコード１７０が資源インスタンス１２０にアタッチされる操作を示す。アタッチ要求３０１は、クライアント１４８によってＮＩＶＣ １８０に送信され得、インタフェースレコード１７０Ａおよびそのインタフェースレコードがアタッチされる資源インスタンス１２０Ａを識別する。図３では、要求３０１に対する表記「＋＋」（「１７０Ａ＋＋１２０Ａ」におけるような）は、その要求が、アタッチ要求であることを示す。要求を受信すると、ＮＩＶＣ １８０は、要求しているクライアントがアタッチを要求することを認可されていること、およびインタフェースレコード内のアドレス指定および他の情報が有効であることを検証し得、次いで、インタフェースレコード１７０Ａに指定された詳細に従って、トラフィックが、資源インスタンス１２０Ａに出入りして流れることを可能にするために、必要な構成変更を開始し得る。アタッチ要求３０１に応答してＮＩＶＣ １８０によって実行される操作は、図３で、３１１とラベルを付けられた矢印およびアタッチインジケータ３２１によって示される。前述のように、例えば、資源インスタンス１２０Ａが常駐しているプラットフォーム１５０Ａのハイパーバイザーまたはオペレーティングシステムで、および使用されているプロバイダネットワークのルーターおよびゲートウェイなどの様々なネットワーキング装置で、いくつかの構成変更が、行われ、かつ／または伝搬
される必要があり得る。いくつかの実施形態では、インタフェースレコード１７０Ａ自体が、例えば、インタフェース状態２６８、アタッチ状態２６９、アタッチＩＤ ２７１、アタッチされたインスタンス２７３、アタッチ所有者２７５、および／またはＭＡＣアドレスフィールド２７７などの様々な構成要素の値を変更することにより、修正され得る。図示した例では、インタフェースレコードのＭＡＣアドレスフィールド２７７が、ＮＩＣ
１１０のＭＡＣアドレスに設定され得、ＮＩＣは、ＮＩＣを取り囲む破線によって示されるように、資源インスタンス１２０Ａによって使用可能である。

インタフェースレコード１７０は、一実施形態では、資源インスタンスの有効期間の多数の異なる段階で、資源インスタンス１２０にアタッチされ得る。例えば、資源インスタンス１２０は、特定のインタフェースレコードがそれにアタッチされるとき、ブートに続く、実行状態にあり得る（そして、それが既にアタッチされている別のインタフェースレコードのＩＰアドレスで受信された要求に既にサービスしている可能性がある）。いくつかの実施形態では、ＮＩＶＣ １８０は、たとえ資源インスタンス１２０が現在オンまたは実行中でない場合でさえ―例えば、資源インスタンスが停止もしくは中断されているか、またはアクティブ化の途中である場合、インタフェースレコード１７０が、資源インスタンス１２０にアタッチされるのを許可し得る。かかる場合は、例えば、資源インスタンスがアクティブ化またはブートされる前、および、それがその上で起動されるサービスプラットフォーム１５０が選択される前でさえ、ネットワークインタフェースレコードは資源インスタンスにアタッチされ得る。アタッチ操作が要求されるときに不十分な情報しか利用できない場合―例えば、使用されるＮＩＣまたは複数のＮＩＣのＭＡＣアドレスがまだ分かっていない場合―ＮＩＶＣ １８０は、値が実際に利用可能になるまで、インタフェースレコード１７０Ａのいくつかのフィールドをブランクまたは空文字のままにし得る。いくつかの実施形態では、ＮＩＶＣ １８０は、各アタッチに対して、レコードまたはデータ構造を生成および／または格納し得―例えば、関連付けられたアタッチ識別子を有するオブジェクトがリポジトリ１８５またはいくつかの他のデータベースに格納され得、アタッチ操作が開始または完了したときなどに、資源インスタンス１２０Ａ、インタフェースレコード１７０Ａ、およびアタッチに関する他の情報を識別する。いくつかの実施形態では、所与のクライアント１４８は、クライアントの資源インスタンス１２０に対して使用可能なインタフェースレコード１７０の組またはプールを有し得、クライアントは、指定された資源インスタンス１２０にアタッチするために、単に、ＮＩＶＣ １８０が、インタフェースレコードのプールから利用可能なインタフェースレコード１７０を選択することを要求し得る。

インタフェースレコード１７０にアタッチされる資源インスタンス１２０に対して使用されるＩＰアドレスは、いくつかの実施形態では、アタッチ操作が完了した後に、修正可能であり得る。例えば、パブリックＩＰアドレス２１５またはプライベートＩＰアドレス２０５などのＩＰアドレスを変更することを認可されているとして識別されるユーザーまたは実体がＩＰアドレス修正要求をＮＩＶＣ １８０に送信すると、ＮＩＶＣは、要求された変更を有効にするために必要とされる必要な構成変更を行い得る。例えば、インタフェースレコード１７０に対するＩＰアドレス修正要求を受信すると、ＮＩＶＣはまず、どの資源インスタンス１２０（ある場合）が現在インタフェースレコード１７０にアタッチされているかを判断し、次いで、変更されたＩＰアドレスを対象としたトラフィックがそれらの資源インスタンス（複数可）に到達できるようにして、インタフェースレコード１７０自体に必要な変更を行い得る。一実施形態では、パブリックＩＰアドレス２１５またはプライベートＩＰアドレス２０５のいずれかなどの、インタフェースレコード１７０に関連付けられたＩＰアドレスのうちの１つまたは複数が、クライアントの代わりにＮＩＶＣ １８０によって、そのクライアントに割り当てられた１組のＩＰアドレスから選択され得る。

図４は、いくつかの実施形態に従って、インタフェースレコード１７０が資源インスタンス１２０からデタッチされる操作を示す。デタッチ要求４０１は、クライアント１４８によってＮＩＶＣ １８０に送信され得、インタフェースレコード１７０Ａおよびそのインタフェースレコードがそこからデタッチされる資源インスタンス１２０Ａを識別する。図３では、要求４０１に対する表記「－－」（「１７０Ａ－－１２０Ａ」におけるような）は、その要求が、デタッチ要求であることを示す。要求を受信すると、ＮＩＶＣ １８０は、いくつかの実施形態では、まず、指定されたインタフェースレコード１７０Ａが実際に資源インスタンス１２０Ａに現在アタッチされていることを検証し得る。インタフェースレコード１７０Ａが資源インスタンス１２０Ａにアタッチされていない場合、ＮＩＶＣ １８０は、エラーメッセージを要求しているクライアント１４８に送り返すか、またはいくつかの実施形態では、単にその要求をログに書き込み、かつ／もしくは無視するかのいずれかであり得る。インタフェースレコード１７０Ａが資源インスタンス１２０Ａにアタッチされている場合、ＮＩＶＣ １８０は、要求しているクライアントがデタッチを要求することを認可されていることをチェックし得、次いで、インタフェースレコード１７０Ａに指定された詳細に従って、トラフィックが、資源インスタンス１２０Ａに出入りして流れるのを停止させるために、必要な構成変更を開始し得る。デタッチ要求３０１に応答してＮＩＶＣ １８０によって実行される操作は、図４で、４１１とラベルを付けられた矢印およびアタッチインジケータ３２１上の「Ｘ」によって示される。デタッチ構成変更は、実際には、単に前述のアタッチ構成変更を取り消し得る。インタフェースレコード１７０Ａ自体は、いくつかの実施形態では、例えば、インタフェース状態２６８、アタッチ状態２６９、アタッチＩＤ ２７１、アタッチされたインスタンス２７３、アタッチ所有者２７５、および／またはＭＡＣアドレスフィールド２７７などの様々な構成要素の値を変更することにより、修正され得る。図示した例では、インタフェースレコードのＭＡＣアドレスフィールド２７７が、デタッチ時に空文字に設定され得る。

いくつかの実施形態では、デタッチ要求４０１は、削除されるインタフェースレコード１７０Ａを明示的に指定しない可能性があり―代わりに、要求しているクライアントは単に、任意のアタッチされたインタフェースレコード１７０Ａが指定された資源インスタンス１２０からデタッチされるべきであることを示し得る。かかる場合、ＮＩＶＣ １８０は、まず、例えば、リポジトリ１８５内で情報を検索することにより、どのインタフェースレコード１７０が指定された資源インスタンス１２０からデタッチされるべきかを発見し、次いで、デタッチ操作を開始するように動作可能であり得る。（アタッチされているインタフェースレコード１７０全てをデタッチするための）かかる要求は、例えば、資源インスタンスがシャットダウンされているか、無効にされているか、終了されているか、または廃棄されている場合に生成され得る。いくつかの実施態様では、「終了時に削除」フィールドがインタフェースレコード１７０に対して「真」に設定され、アタッチされた資源インスタンス１２０が終了されている場合、インタフェースレコード自体がリポジトリ１８５から削除され得；そうでなく、「終了時に削除」が「偽」に設定されている場合、インタフェースレコードは、あり得る後の再使用のために、その特性と共にリポジトリ内に保持され得る。前述のように、いくつかの実施形態では、「終了時に削除」特性は、インタフェースレコード自体と関連付けられる代わりに、インタフェースレコードが参照し得るアタッチレコードと関連付けられ得る。いくつかの実施態様では、デタッチ要求４０１は、必ずしも資源インスタンス１２０Ａを示すことはなく、指定されたインタフェースレコード１７０Ａが、たまたまアタッチされているどの資源インタフェース１２０（ある場合）からもデタッチされるべきことだけを示し得る。

図５は、いくつかの実施形態に従って、１つの資源インスタンス１２０Ａに以前アタッチされ、その後デタッチされた、インタフェースレコード１７０Ａが、異なる資源インスタンス１２０Ｃにアタッチされる操作を示す。アタッチ要求５０１は、クライアント１４８によってＮＩＶＣ １８０に送信され得、インタフェースレコード１７０Ａおよびその
インタフェースレコードがアタッチされている資源インスタンス１２０Ｃを識別する。図５では、図３におけるように、表記「＋＋」（「１７０Ａ＋＋１２０Ｃ」におけるような）は、その要求が、アタッチ要求であることを示す。要求を受信すると、ＮＩＶＣ １８０は、図３の説明に関連して前述されたものに類似した機能を実行し得、今回は、インタフェースレコード１７０Ｃを、以前にアタッチされたインスタンス１２０Ａとは異なるサービスプラットフォーム（１５０Ｂ）上に常駐している、資源インスタンス１２０Ｃにアタッチし、異なるＮＩＣ（図５で破線によって示されるように、ＮＩＣ １１０Ｂ）を使用する。アタッチ要求５０１に応答してＮＩＶＣ １８０によって実行される操作は、図５で、５１１とラベルを付けられた矢印およびアタッチインジケータ５２１によって示される。異なる資源インスタンス１２０に動的にアタッチでき（かつ、使用されたＮＩＣ １１０を動的に変更できる）インタフェースレコード１７０の使用は、以下のユースケースに関する節で説明するように、ＮＩＶＣ １８０が、クライアント１４８に、彼らのアプリケーションに対して使用されるネットワークアーキテクチャにおける著しい柔軟性、およびビジネス境界を越えて連携する機会を提供することを可能にする。例えば、一環境では、資源インスタンス１２０は、顧客からの特定のアプリケーションのウェブサービス要求を処理するように設定されている可能性がある。かかる環境では、図４に示すように、インタフェースレコード１７０ＡのＩＰアドレス（複数可）を変更しない状態で保ちながら、単に、インタフェースレコード１７０Ａを１つの資源インスタンス１２０Ａからデタッチし、次いでそのインタフェースレコードを異なる資源インスタンス１２０Ｃとアタッチすることにより、以前、資源インスタンス１２０Ａで処理されていた着信ウェブサービス要求の作業負荷が、現在は資源インスタンス１２０Ｃで処理できる。これは、クライアント１４８が、例えば、資源インスタンス１２０Ａが停止もしくは故障を経験する場合に強化された可用性を、または、資源インスタンス１２０Ｃが強化されたバージョンを有する場合にウェブサービスアプリケーションの強化されたバージョンを配備するための使い易い機構を提供するのを可能にし得る。

いくつかの実施態様では、ＮＩＶＣ １８０は、複数のインタフェースレコード１７０が同一の資源インスタンス１２０にアタッチされることを可能にし得る。図６は、１つのかかる実施形態を示し、ここでは、第２のインタフェースレコード１７０Ｂが、インタフェースレコード１７０Ａが既にアタッチされている資源インスタンス１２０Ｃにアタッチされる。アタッチ要求６０１に応答して、ＮＩＶＣ １８０は、図３のアタッチ要求３０１に対して説明されたものに類似した機能を実行し得、これにより、インタフェースレコード１７０Ａおよび１７０Ｂの両方の特性に従って、資源インスタンス１２０Ｃに出入りするネットワークトラフィックが最終的に流れるようになる。アタッチ要求６０１に応答してＮＩＶＣ １８０によって実行される操作は、図６で、６１１とラベルを付けられた矢印および追加のアタッチインジケータ６２１によって示される。図６に示す例では、単一のＮＩＣ １１０Ｂが、アタッチされたインタフェースレコード１７０Ａおよび１７０Ｂの両方に対するトラフィックを処理するために使用される。いくつかの実施態様では、インタフェースレコード１７０と物理ＮＩＣ １１０との間のマッピングが柔軟であり得る：すなわち、所与のＮＩＣ １１０を通って流れるトラフィックは、任意の数のインタフェースレコード１７０に対応し得、所与のインタフェースレコード１７０に対するトラフィックは、複数の物理ＮＩＣ １１０を通って流れ得る。

いくつかの実施態様では、資源インスタンス１２０は、それらのアタッチされたインタフェースレコード１７０および対応するネットワーキング関連特性のうちの少なくともいくつかを保持したまま、サービスプラットフォーム１５０を越えて転送可能であり得る。図７は、少なくともいくつかの実施形態に従って、アタッチされたインタフェースレコード１７０Ａをもつ資源インスタンス１２０Ａ（以前に図３に示すように）が、１つのサービスプラットフォーム１５０Ａから資源インスタンス１５０Ｃに移動される操作を示す。図７では、クライアント１４８は、「インスタンスの移動」要求７０１をシステム１００
のインスタンスマネージャ７８０に送信して、今までサービスプラットフォーム１５０Ａ上に常駐していた資源インスタンス１２０Ａが、今はサービスプラットフォーム１５０Ｃ上に常駐させられるべきであることを示す。要求７０１に対する表記「→」（「１２０Ａ→１５０Ｃ」におけるような）は、その要求が、移動要求であることを示す。要求を受信すると、インスタンスマネージャ７８０は、ＮＩＶＣ １８０とともに、要求された移動を実装するために必要なタスクを実行し得る。例えば、移動要求７０１は、リクエスタが、正しい許可を有していることを確実にするために検証され得、資源インスタンス１２０Ａは、次いで、中断されるか、または着信要求が一時的にキューに登録されている状態にされ得る。資源インスタンス１２０Ａは、次いで、サービスプラットフォーム１５０Ｃ上で起動されるか、または有効にされ得、アタッチされたインタフェース１７０ＡのＩＰアドレス（複数可）を対象としたトラフィックが、サービスプラットフォーム１５０Ｃで適切なＮＩＣまたは複数のＮＩＣ １１０を通って流れるようにするために必要とされる構成変更が、次いで開始され得る。図７に示す例では、資源インスタンス１２０Ａに出入りするトラフィックが、インスタンスが移動した後、ＮＩＣ １１０Ｃを通ってルーティングされる（いくつかの実施形態では、インタフェースレコード１７０ＡのＭＡＣアドレスフィールドがこれを反映するように修正され得る）。このように、資源インスタンスのネットワーキング特性（すなわち、そのアタッチされたインタフェースレコードのネットワーキング特性）が、使用された実際のネットワーキングハードウェアとは実質的に無関係にされ得る。別個のインスタンスマネージャ７８０が図８に示されているが、資源インスタンスを移動させる機能は、いくつかの実施形態では、インタフェース仮想化機能とともに管理され得、すなわち、同じソフトウェアおよび／またはハードウェア実体が資源インスタンス管理操作およびインタフェースレコード管理操作を同様にサポートする。

ユースケース例
指定されたＩＰアドレスおよびサブネットをもつ１つまたは複数のインタフェースレコード１７０を資源インスタンス１２０に対して動的にアタッチおよびデタッチする機能は、前述の機能によって有効にされて、顧客が、いくつかの異なる有用なタイプのネットワーク構成を容易にセットアップすることを可能にする。図８ａ～図８ｄは、いくつかの実施形態に従って、達成可能ないくつかのかかるネットワーク構成例の図を提供する。

図８ａ～図８ｄに示すネットワーキング構成は、資源インスタンス１２０を含み得るプロバイダネットワークに対する３つの異なる構成または階層レベル：論理パーティションレベル、サブネットレベル、およびインタフェースレコードレベルを示す。かかるプロバイダネットワークの運営者は、所与の顧客（プロバイダネットワークによってサポートされる仮想コンピューティングおよび／または仮想ストレージサービスを利用したいと欲する企業または組織など）が、その顧客による使用のために専用の１つまたは複数の論理パーティションをセットアップすることを許可し得る。論理パーティションは、例えば、顧客による必要に応じて、比較的大規模な組のサービスプラットフォーム１５０および、それらのサービスプラットフォーム上で起動され得る様々な資源インスタンス１２０に対して使用可能であり得る比較的多数のＩＰアドレスを含み得、顧客は、その組の資源に対するネットワーク管理機能を提供され得る。いくつかの実施形態では、例えば、論理パーティションのＩＰアドレスの組が、ＣＩＤＲ表記法で「１０．１．０．０／１６」などの「／１６」ブロックとして指定され得、それは、最大で６５，５３６のＩＰアドレスがその論理パーティションに対して使用可能であり得ることを示す。論理パーティションは、いくつかの実施形態では、「仮想プライベートクラウド」と呼ばれ得る。論理パーティションは、いくつかの実施形態では、インターネットゲートウェイまたは仮想プライベートネットワーク（ＶＰＮ）ゲートウェイなどの、それに対してセットアップされた１つまたは複数のゲートウェイを有し得る。加えて、いくつかの実施形態では、デフォルトのＤＮＳサーバーが、各論理パーティションに対してセットアップされ得、１つまたは複数のサブネットおよびルーティングテーブルエントリも、論理パーティションがセットアップされ
る際にセットアップされ得る。例えば、一実施態様では、顧客が、「／１６」ブロックをもつ論理パーティションがセットアップされるのを要求すると、顧客は、論理パーティション内でセットアップされる少なくとも１つの「／２４」サブネットに対するＣＩＤＲ仕様も指定することを要求され得る。「／２４」サブネット（例えば、「１０．１．１．０／２４」）は、２５６のＩＰアドレスを含む。代わりに論理パーティションがセットアップされる顧客は、いくつかの実施形態では、様々なサイズのサブネットのセットアップ、ならびに必要に応じたインタフェースレコード１７０の作成、アタッチおよびデタッチなどの、幅広い種類のネットワーク管理タスクを必要に応じて実行することを許可され得る。異なる論理パーティションおよびサブネットが、様々なレベルの論理的分離を達成するためにセットアップされ得：例えば、顧客は、ソフトウェア開発ビルド関連のネットワークトラフィックを企業の電子メールネットワークトラフィックから分離したいと欲し得、それを行うために、論理パーティションおよびサブネットの適切な階層構造をセットアップし得る。一実施形態では、ＣＩＤＲ仕様は、インタフェースレコード１７０に対するプライベートＩＰアドレス（例えば、図２に示すフィールド２０５に格納される）を参照し得、他方、パブリックＩＰアドレス（フィールド２１５に格納される）は、他のポリシーに従って選択され得る。サブネット（図２のフィールド２２５）および論理パーティション（フィールド２０３）に対する識別子が、いくつかの実施形態では、インタフェースレコード内に格納され得る。いくつかの実施形態では、インタフェースレコードのアドレス指定情報（論理パーティション識別子、サブネット識別子、プライベートおよび／またはパブリックＩＰアドレス）の一部または全部が、インタフェースレコード１７０の作成後、動的に修正可能であり得る。

ユースケースシナリオ１：単一サブネット内の複数のＩＰアドレス
図８ａは、一実施形態に従って、２つのインタフェースレコード１７０Ａおよび１７０Ｂが、サブネット８１１Ａ内で単一の資源インスタンス１２０Ａと関連付けられる単純なネットワーキング構成を示す。インタフェースレコード１７０ＡはＩＰアドレス例ｘ．ｘ．ｘ．９とともに示され、インタフェースレコード１７０ＢはＩＰアドレス例ｘ．ｘ．ｘ．１０とともに示されている（２つのアドレスに共通の表記「ｘ．ｘ．ｘ」は、この場合、２つのＩＰＶ４アドレスの最初の３つのドットで区切られた要素が同一であることを意味し、例えば、２つのアドレスは、１１．２．３．９および１１．２．３．１０であり得る）。図のように、複数のインタフェースレコード１７０をアタッチすることにより、必要なだけ多くの異なるＩＰアドレスが、いくつかの実施形態では、同一の資源インスタンスと関連付けられ得る。これは、例えば、異なるアプリケーションまたはアプリケーションインスタンスに対するトラフィックをＩＰアドレスによって分離するために有用であり得る。一環境では、例えば、いくつかの異なるウェブサイトが単一の資源インスタンス１２０上でセットアップされ得、各々がそれ自身のＩＰアドレスをもつ。別の実施形態では、顧客は、単一の資源インスタンス１２０上にセットアップされた同一の基礎となるコンテンツを供給する複数のウェブサーバーを有し得、各ウェブサーバーを異なるＩＰアドレスと関連付けることを欲し得る。

ユースケースシナリオ２：単一の論理パーティション内の複数のサブネットとのアタッチ
図８ｂは、一実施形態に従って、異なるサブネットからの２つのインタフェースレコード１７０Ａおよび１７０Ｃが、単一の資源インスタンス１２０Ａと関連付けられる構成を示す。インタフェースレコード１７０Ａは、サブネット８１１Ａ内のＩＰアドレス例ｘ．ｘ．０．９とともに示され、インタフェースレコード１７０Ｃは、異なるサブネット８１１Ｂ内のＩＰアドレスｘ．ｘ．１．１０とともに示されている。この種の構成は、例えば、ネットワーク管理トラフィックが１つのサブネット８１１Ａを通って流れ、他方、アプリケーションデータトラフィックが別のサブネット８１１Ｂを通って流れ、各サブネットが異なるセキュリティ特性を有する環境で有用であり得る。１つのかかる場合には、ネッ
トワーク管理トラフィック用のサブネット８１１Ａは、アプリケーションデータに対して使用されるサブネット８１１Ｂよりも厳格なセキュリティ規則およびアクセス制御を有し得る。別の例では、複数のサブネット８１１にアタッチされた資源インスタンス１２０は、様々なネットワークセキュリティ機能を実行するようにも構成可能であり得る。例えば、第１のサブネット８１１Ａからのトラフィックが、資源インスタンス１２０を通って、第２のサブネット８１１Ｂにルーティングされる必要がある場合、資源インスタンスは、ファイアウォールを実装して、ウイルス対策ゲートウェイとして機能し、侵入検出および／または他のタイプのネットワークトラフィック分析、フィルタ処理、もしくは監視などを実行し得る。

図８ｂに示すものに類似した構成は、いくつかの実施形態では、資源インスタンス１２０を１つのサブネットから別のサブネットに動的かつ効率的に移動するためにも使用され得る。例えば、顧客は、ソフトウェア開発環境専用のサブネット８１１Ａ内でインタフェースレコード１７０Ａにアタッチされた資源インスタンス１２０Ａ上で、アプリケーションサーバーインスタンスをセットアップし、アプリケーションの更新されたバージョンを、そのアプリケーションサーバーインスタンス上に配備させ得る。顧客が、更新されたバージョンについて品質保証（ＱＡ）検査を開始することを欲していて、ＱＡ検査環境が開発サブネット８１１Ａから分離されたサブネット８１１Ｂ内にある場合、次のステップが取られ得る。まず、サブネット８１１Ｂからの第２のインタフェースレコード１７０Ｃが、資源インスタンス１２０Ａにアタッチされ得る。次いで、インタフェースレコード１７０Ａが、資源インスタンス１２０Ａからデタッチされ得、このようにして、異なる資源インスタンス上の更新されたバージョンを配備する必要なく、検査が所望のＱＡサブネット内だけで実行されることを可能にする。同様に、アプリケーションは、ＱＡ環境から製造環境へ、など、他の開発ライフサイクル段階遷移を通じて容易に移動され得る。

一環境では、顧客は、１組のフロントエンドウェブサーバーまたは外部ネットワーク（すなわち、資源インスタンス１２０を含むプロバイダネットワークの外部の装置）からアクセス可能な他の資源を、極秘データを格納し得るデータベースサーバーなどの１組のバックエンドサーバーから分離し、このようにして、外部ネットワークからのバックエンドサーバーへの直接のネットワークアクセスを防ぐようにすることを欲し得る。かかる場合、図８ｂの資源インスタンス１２０Ａは、いくつかの実施形態では、フロントエンドトラフィックに対してサブネット８１１Ａを、バックエンドトラフィックに対してサブネット８１１Ｂを使用し得る。従って、ウェブサービスに対する要求が、資源インスタンス１２０Ａ上で実行するウェブサーバーで、サブネット８１１Ａを介して受信され得、それらの要求を実現するために必要とされる対応するバックエンド要求が、サブネット８１１Ｂ内のバックエンドサーバーに送信され得る。バックエンドサーバーからの応答が、サブネット８１１Ｂから受信され、サブネット８１１Ａを介してリクエスタに送り返され得る。

いくつかの実施態様では、異なるサブネット内の複数のインタフェースレコード１７０にアタッチされているインスタンス１２０は、ルーターとしても使用され得る。例えば、資源インスタンスで受信されたパケットが、資源インスタンスから１つのサブネットを通って到達可能な送信元ＩＰアドレス、および別のサブネットを通って到達可能な宛先ＩＰアドレスを有し、かつ、必要とされる適切な設定が設定されている場合（例えば、ルーティングテーブルエントリが適切にセットアップされている場合）、インスタンスはパケットを第２のサブネットを経由して宛先アドレスにルーティングし得る。

ユースケースシナリオ３：同一顧客の複数の論理パーティションへのアタッチ
図８ｃは、一実施形態に従って、同一の顧客（顧客Ａ）に対してセットアップされた異なる論理パーティション８０１Ａおよび８０１Ｂからの２つのインタフェースレコード１７０Ａおよび１７０Ｄが、単一の資源インスタンス１２０Ａと関連付けられる構成を示す
。インタフェースレコード１７０Ａは、論理パーティション８０１Ａのサブネット８１１Ａ内のＩＰアドレス例１０．０．０．９とともに示され、インタフェースレコード１７０Ｄは、異なる論理パーティション８０１Ｂのサブネット８１１Ｂ内のＩＰアドレス１７２．１６．１．１０とともに示されている。この種の構成は、いくつかの目的で有用であり得る。２つの論理パーティション８０１Ａおよび８０１Ｂは、顧客Ａの代わりに、様々な理由のいずれかに対して―例えば、顧客Ａのプライベートイントラネットのトラフィックを、顧客Ａによって彼ら自身の顧客に公開されている非武装地帯（ＤＭＺ）ネットワークを対象としたトラフィックから分離するために、セットアップされている可能性がある。かかる環境では、図８ｃの資源インスタンス１２０Ａは、例えば、パーティション間ルーティングを実行するように構成され得る。いくつかの実施形態では、顧客は、サービスを、２つの論理パーティション内の装置からアクセス可能な資源インスタンス１２０Ａによって提供されることを欲し得、それは、図８ｃのものと類似した構成を使用しても可能にされ得る。

言うまでもなく、前述のユースケース１および２で説明したＮＩＶＣ １８０によってサポートされる他の機能のいくつかも、図８ｃに示すタイプの構成を使用して、論理パーティション境界にわたって拡げられ得る。例えば、様々な実施形態では、複数のＩＰアドレスが、２つの異なるＣＩＤＲ／１６アドレス範囲内の所与の資源インスタンス１２０に対して提供され得、資源インスタンスが論理パーティションを越えて移動され得る、など。資源インスタンス１２０Ａは、いくつかの実施形態では、論理パーティション８０１にわたるプロキシサービスも提供されるか、またはデータネットワークとは別個の論理パーティション内にある管理ネットワークを実装するために使用され得る。

ユースケースシナリオ４：異なる顧客の論理パーティションへのアタッチ
ＮＩＶＣ １８０は、いくつかの実施形態では、異なる顧客に対してセットアップされた論理パーティションにわたるいくつかのブリッジサービス（ｂｒｉｄｇｉｎｇ ｓｅｒｖｉｃｅ）を提供することが可能であり得る。図８ｄは、一実施形態に従って、それぞれの顧客に対してセットアップされた異なる論理パーティション８０１Ａおよび８０１Ｂ（顧客Ａに対するパーティション８０１Ａおよび顧客Ｂに対するパーティション８０１Ｂ）からの２つのインタフェースレコード１７０Ａおよび１７０Ｅが、単一の資源インスタンス１２０Ａと関連付けられている構成を示す。

図８ｄに示す機能は、いくつかの異なる連携的なシナリオを可能にし得る。一例では、顧客Ａおよび顧客Ｂが、あるプロジェクトについて連携している可能性がある。顧客Ａは、彼らの論理パーティション８０１Ａ内の資源インスタンス１２０Ａ上にコンテンツサーバーアプリケーションを配備している可能性がある。顧客Ｂは、そのコンテンツサーバーアプリケーションにアクセスすることを欲し得るが、どちらの会社もこのサーバーをパブリックインターネットに公開したくない可能性がある。代わりに、顧客Ｂは、彼ら自身の論理パーティション８０１Ｂ内のインタフェースレコード１７０Ｅを作成し、そのインタフェースレコード１７０Ｅに許可を設定して、顧客Ａがそれにアタッチすることを可能にし得る。顧客Ａは、インタフェースレコード１７０Ｅを、顧客Ａの論理パーティション８０１Ａ内でコンテンツサーバーを実行する資源インスタンス１２０Ａにアタッチし得る。このようにして、両方の顧客が、大規模な変更を行う必要なく、コンテンツサーバーに安全にアクセスし得る。さらに、顧客Ａは、いくつかの実施態様では、インタフェースレコード１７０Ｅのセキュリティ特性を使用して、ＨＴＴＰおよびＨＴＴＰＳポートだけが顧客Ｂに対して利用可能であることを確実にし得るか、または必要に応じて、他の方法で、顧客Ｂの論理パーティションからのアクセスを制限し得る。

顧客間のピアリングが有効にされ得る第２のシナリオでは、顧客Ａおよび顧客Ｂは、いくつかのプロジェクトについて連携している可能性があり、互いに他の論理パーティショ
ンに対するプライベートアクセスを有したい可能性がある。１つのかかる実施形態では、顧客Ａは、資源インスタンス１２０Ａ上でゲートウェイアプリケーション（ファイアウォールまたはルーターなど）を起動し得、顧客Ｂはインタフェースレコード１７０Ｅを作成し得る。ゲートウェイアプリケーション所有者の顧客Ａは、両方の論理パーティションが、ゲートウェイアプリケーションを実行するデュアルホームド資源インスタンス１２０Ａを介して接続されるように、インタフェースレコード１７０Ｅを資源インスタンス１２０Ａにアタッチし得る。このシナリオは、２顧客の論理パーティションのＩＰアドレス範囲にいくつかの制約を課し得―例えば、いくつかの実施態様では、それらが重なり合うＩＰアドレスを有する場合、何等かの形式のネットワークアドレス変換が必要とされ得る。いくつかの環境では、資源インスタンス１２０Ａは、専用ネットワーク機器（例えば、ルーター機器またはファイアウォール機器）上でホストされ得る。

パーティション間アタッチ（ｃｒｏｓｓ－ｐａｒｔｉｔｉｏｎ ａｔｔａｃｈｍｅｎｔ）機能も、いくつかの実施形態では、技術的サポートを提供するために使用され得る。１つのかかるシナリオでは、顧客Ａは、資源インスタンス１２０ＡでベンダーＸからのアプリケーションを使用している可能性があり、ここで、ベンダーＸもシステム１００の運営者の顧客である。顧客Ａは、アプリケーションに関連する問題に遭遇している可能性があり、ベンダーＸからハンズオンサポートを受けたい可能性がある。顧客ＡはベンダーＸに連絡し得、ベンダーＸは彼ら自身の論理パーティション内にインタフェースレコード１７０Ｅを作成して、顧客Ａにアタッチする許可を与え得る。顧客Ａは、彼らの資源インスタンス１２０Ａを、ベンダーＸのインタフェースレコード１７０Ｅにアタッチし得、そのため、例えば、ベンダーＸが、セキュアシェル（ＳＳＨ）またはリモートデスクトッププロトコル（ＲＤＰ）を使用して、その問題のあるアプリケーションにアクセスして、必要に応じトラブルシューティングを実行し得る。かかるサポートは、顧客Ａの論理パーティションにアクセスするためにインターネットゲートウェイまたは仮想プライベートネットワークゲートウェイを使用することなく、サポートされ得る。さらに、顧客Ａは、いくつかの実施形態では、資源インスタンス１２０ＡからベンダーＸの論理パーティション８０１Ｂに伝送されているいかなるトラフィックも防ぐために、出力（ｅｇｒｅｓｓ）ポリシー（例えば、インタフェースレコード１７０Ｅのセキュリティ特性の使用）を修正し得る。これは、ベンダーＸが、不注意に、または故意に、顧客Ａの論理パーティション８０１Ａ内の他の資源にアクセスするのを防ぎ得る。

マネージドサービスプロバイダ（ＭＳＰ）も、いくつかの実施形態では、パーティション間アタッチ機能を活用することが可能であり得る。ＭＳＰ（顧客Ａ）は、それ自身の論理パーティション（例えば、８０１Ａ）内でアプリケーションをホストして、彼らの顧客の論理パーティション（例えば、ＭＳＰ顧客Ｂのパーティション８０１Ｂ）内のインタフェースレコード１７０にアタッチし得、このようにしてＭＳＰ顧客に、ＭＳＰアプリケーションにアクセスするための彼ら自身のパーティション内のエンドポイントを提供する。ＭＳＰは、彼らのアプリケーションを実行する資源インスタンス（例えば、１２０Ａ）の制御を保持し得、他方、ＭＳＰ顧客は、ＭＳＰ顧客のネットワーク空間内のＩＰアドレスを介してＭＳＰアプリケーションにアクセスすることが可能であり得る。ＭＳＰアプリケーションは、顧客関係管理（ＣＲＭ）、コンテンツ管理、連携、データベースおよび同類のものなどの、任意の様々な異なるタイプのサービスを含み得る。

図８ａ～図８ｄに示す例に加えて、ＮＩＶＣ １８０の機能は、様々な実施形態で、他のタイプのサービスも有効にし得る。例えば、もし、インタフェースレコード１７０にアタッチされた第１の資源インスタンス１２０が障害を起こすか、または停止するとき、一種の高可用性（ＨＡ）が、インタフェースレコード１７０を、第１の資源インスタンスと類似のサービスを提供することが可能な第２の資源インスタンスにアタッチすることにより、実装され得る。システム１００が、リレーショナルデータベースサービス、マップリ
デュースもしくは他の分散またはパラレルコンピューティングサービス、配備サービスまたは負荷分散サービスなどの、様々なサービスをサポートする実施形態では、複数の顧客の論理パーティションにアタッチされる資源インスタンス１２０は、様々なサービスに対して管理および制御サービスを実装するために使用され得る。かかる管理サービスは、「制御プレーン（ｃｏｎｔｒｏｌ ｐｌａｎｅ）」機能と呼ばれ得、非管理アプリケーションデータまたはユーザーデータを伝送するために使用される「データプレーン（ｄａｔａ
ｐｌａｎｅ）」から区別される。

ウェブインタフェース例
いくつかの実施形態では、ＮＩＶＣ １８０は、前述のインタフェースレコードに関連したサービスの一部または全部を定義およびサポートする１つまたは複数のインタフェースを実装するように動作可能であり得る。例えば、１つまたは複数のアプリケーションプログラミングインタフェース（ＡＰＩ）が実装され得るか、または様々なタイプのグラフィカルユーザーインタフェース（ＧＵＩ）もしくはコマンドラインインタフェースが、様々な実施形態で提供され得る。図９は、少なくともいくつかの実施形態に従い、ＮＩＶＣ
１８０によって提供され得る、例示的なウェブベースインタフェースの一部の図である。

図９のウェブページ９００は、クライアント１４８が、インタフェースレコード作成要求の詳細を提供するために記入し得る、いくつかのフォームフィールドを含む。ウェブページ９００の領域９０３では、友好的な挨拶および概要メッセージが提供され得る。フォームフィールド９０４は、クライアントが、インタフェースレコードに対する名前および記述を指定することを可能にし得る。論理パーティションが実装される実施形態では、クライアントが、要求されたインタフェースレコード１７０に対して論理パーティションを指定することを可能にするために、フォームフィールド９０５が提供され得る。いくつかの実施態様では、クライアント１４８がそこから１つを選択することを認可されている、１組の論理パーティションの識別子が、例えば、ドロップダウンメニューを介して、自動的に利用可能にされ得、かつ／またはフィールド９０５が、クライアントが修正し得る、デフォルトの論理パーティション識別子で事前に埋められ得る。フォームフィールド９０９は、インタフェースレコードに対するサブネット識別子を指定するために使用され得る。１つまたは複数のＩＰアドレス（プライベートおよび／またはパブリックＩＰアドレスを含む）が、フォームフィールド９１７を使用して指定され得る。フォームフィールド９２１は、セキュリティグループ、インタフェースレコードにアタッチすることを許可されている実体のリスト、および同類のものなどの、様々なセキュリティ特性を指定するために利用可能であり得る。フィールド９２５は、任意選択で、インタフェースレコードがアタッチされる資源インスタンス１２０を識別するために使用され得る。フィールド９０５の場合のように、ウェブページ９００上のいくつかの他のフィールドも、いくつかの実施形態では、デフォルト値で事前に埋められ得、かつ／または許可された選択項目の選択が、ドロップダウンメニューまたは類似の機構を介して提供され得る。投入ボタン９３１は、インタフェースレコード作成要求を投入するために使用され得る。

ＮＩＶＣ １８０は、一実施態様では、要求しているクライアント１４８によって記入されないまま残され得る、一部または全部のフィールドに対して値を生成し得る。ウェブベースのインタフェースを採用するいくつかの実施態様では、いくつかの異なるウェブページが、インタフェースレコードの作成プロセス中に採用され得る。クライアントが１つのフォームエントリに記入すると、ＮＩＶＣ １８０は、後続のフォームエントリに対して利用可能な選択肢の組をカスタマイズするか、または狭めることを可能にし得る。いくつかの実施態様では、ウェブページ９００のようなインタフェースを経由した、フォームデータの投入は、ＮＩＶＣ １８０によってサポートされ得る１つまたは複数のＡＰＩ呼び出しの起動という結果になり得る。

インタフェースレコード１７０を作成するための、図９に示すものに類似したインタフェースは、様々な実施形態で、アタッチ操作、デタッチ操作、削除操作、ＩＰアドレス変更操作、および同類のものなどの、ＮＩＶＣ １８０によってサポートされる他のタイプの操作に対しても提供され得る。いくつかの実施形態では、クライアント１４８は、例えば、インタフェースレコード１７０の状態の判断、所与の資源インスタンス１２０にアタッチされたインタフェースレコード１７０の識別、所与のサブネットまたは論理パーティション内でクライアント１４８によってセットアップされた全てのインタフェースレコードのリストなどを行うための問合せを投入することを許可され得る

インタフェースレコード操作のための方法
図１０は、少なくともいくつかの実施形態に従って、インタフェースレコード操作を提供するための方法の流れ図である。流れ図内の要素１８００に示すように、インタフェース仮想化サービスは、例えば、ＮＩＶＣ １８０の形式で、実装され得る。いくつかの実施態様では、サービスは、例えば、プロバイダネットワーク内の様々な装置上で実行する、ハイパーバイザーソフトウェア、オペレーティングシステムソフトウェア、またはルーティングソフトウェアの構成要素を介して、ソフトウェアおよび／またはハードウェア構成要素の組合せによって実装され得る。要素１８０５に示すように、サービスの１つの要素は、インタフェース仮想化要求を待つように構成され得、それは、例えば、図１０に示すものと類似したウェブベースのインタフェースを介して受信され得る。

受信された要求の特定のタイプに応じて、適切な組の動作がそれに応答して取られ得る。例えば、新しいインタフェースレコードを作成するための要求が受信されると（図１０の要素１８１０）、かかるレコード１７０がインスタンス化され、任意選択でリポジトリに格納され得る（要素１８１５）。既存のインタフェースレコードをアタッチするための要求が受信されると（要素１８２０）、そのインタフェースレコードに対して指定されたＩＰアドレスまたは複数のアドレスに出入りするトラフィックの流れが、それに対するアタッチが要求されている資源インスタンス１２０で有効にされ得る（要素１８２５）。デタッチ要求が受信されると（要素１８３０）、インタフェースレコードのＩＰアドレス（複数可）に出入りするトラフィックが、インタフェースレコードがアタッチされた資源インスタンスで無効にされ得る（要素１８３５）。インタフェースレコードを削除するための要求が受信されると（要素１８４０）、そのレコードは、例えば、リポジトリ１８５から削除され得る（要素１８４５）。

インタフェースレコードを修正する（例えば、ＩＰアドレスを変更する）ための要求が受信されると（要素１８５０）、レコードは要求されたように修正され得、任意の必要な構成変更が開始され得る（要素１８５５）。インタフェースレコードの問合せ（例えば、インタフェースレコードのまたは複数のレコードの状態を判断するため）を受信すると（要素１８６０）、問合せに対する応答が生成されて、提供され得る（要素１８６５）。各々の場合、要求された動作または複数の動作を実行する前に、適切な認可およびセキュリティチェックが実行され得る。いくつかの実施態様では、いくつかのタイプのインタフェースレコード操作が、冪等（ｉｄｅｍｐｏｔｅｎｔ）操作として実装され得え、例えば、ＩＰアドレスをＡ．Ｂ．Ｃ．Ｄに変更するための第１の要求が受信され、同じ変更を要求する第２の要求が続く場合、第２の要求は影響を及ぼさない。予期しない、未サポートの、認可されていないか、またはそうでなければ無効である要求が受信されると、いくつかの実施態様では、エラーメッセージが生成され得る。所与の要求に対して応答した後、サービスは、次いで、次のインタフェース仮想化要求を待つ。いくつかの実施態様では、図１０に示す機能の部分が、並行して実装され得、例えば、２つ以上の要求が同時に処理され得る。いくつかの実施態様では、いくつかの要求が組み合わされ得―例えば、インスタンスレコードの作成およびアタッチの両方のための単一の要求がサポートされ得る。

実施形態例は、以下の付記項を考慮して記述できる：
付記項１．第１の資源インスタンスおよび第２の資源インスタンスを含む複数の資源インスタンスと、
ネットワークインタフェース仮想化コーディネータとを備えるシステムであって、
ネットワークインタフェース仮想化コーディネータが： インタフェースレコード作成要求に応答して、第１のインターネットプロトコル（ＩＰ）アドレス、第１のＩＰアドレスを含む第１のサブネットのサブネット識別子、および第１の組のセキュリティ特性を含むインタフェースレコードを生成し、インタフェースレコードをリポジトリに格納することと、
インタフェースレコードを第１の資源インスタンスにアタッチするための第１のアタッチ要求に応答して、第１の資源インスタンスが、第１の組のセキュリティ特性に従って、第１のＩＰアドレスを対象としたトラフィックを第１のネットワークインタフェースカードを通して受信することを可能にすることと、
インタフェースレコードを第１の資源インスタンスからデタッチするためのデタッチ要求に応答して、第１の資源インスタンスが、第１のＩＰアドレスを対象としたトラフィックを受信するのを防ぐことと、
インタフェースレコードを第２の資源インスタンスにアタッチするための第２のアタッチ要求に応答して、第２の資源インスタンスが、第１の組のセキュリティ特性に従って、第１のＩＰアドレスを対象としたトラフィックを第２のネットワークインタフェースカードを通して受信することを可能にすることとを行うように動作可能である、システム。付記項２．ネットワークインタフェース仮想化コーディネータが： 第２のインタフェースレコード作成要求に応答して、第２のＩＰアドレスを含む第２のインタフェースレコードを生成し、第２のインタフェースレコードを前記リポジトリに格納することと、
第２のインタフェースレコードを第１の資源インスタンスにアタッチするための新しいアタッチ要求に応答して、第１の資源インスタンスが、第２のＩＰアドレスを対象としたトラフィックを受信することを可能にすることとを行うようにさらに動作可能である、付記項１に記載のシステム。
付記項３．第２のＩＰアドレスが、第２のサブネットの部分であり、かつ、第２のインタフェースレコードが第２のサブネットのサブネット識別子を含む、付記項２に記載のシステム。
付記項４．ネットワークインタフェース仮想化コーディネータが： 第１の資源インスタンスで、ネットワークパケットを送信元ＩＰアドレスから受信することであって、送信元ＩＰアドレスが、第１の資源インスタンスから第１のサブネットを介して到達可能であり、かつ、ネットワークパケットが、第１の資源インスタンスから第２のサブネットを介して到達可能な宛先ＩＰアドレスを有する、ネットワークパケットを送信元ＩＰアドレスから受信することと、
ネットワークパケットを第２のサブネットを介して宛先ＩＰアドレスにルーティングすることとを行うようにさらに動作可能である、付記項３に記載のシステム。
付記項５．インタフェースレコードが、１つまたは複数の追加のＩＰアドレスを含み、かつ、インタフェースレコードを第１の資源インスタンスにアタッチするための第１のアタッチ要求に応答して、ネットワークインタフェース仮想化コーディネータが、第１の資源インスタンスが１つまたは複数の追加のＩＰアドレスを対象としたトラフィックを受信することを可能にするようにさらに動作可能である、付記項１に記載のシステム。
付記項６．ネットワークインタフェース仮想化コーディネータが： 新しいＩＰアドレスを含むＩＰアドレス修正要求に応答して、
インタフェースレコードを新しいＩＰアドレスを含むように修正することと、
インタフェースレコードがアタッチされる複数の資源インスタンスのうちの現在アタッチされている資源インスタンスを識別することと、
現在アタッチされている資源インスタンスが、新しいＩＰアドレスを対象としたトラ
フィックを受信することを可能にすることとを行うようにさらに動作可能である、付記項１に記載のシステム。
付記項７．インタフェースレコード作成要求に応答して、ＩＰアドレスおよび第１のＩＰアドレスを含む第１のサブネットのサブネット識別子を含むインタフェースレコードを生成すること、およびインタフェースレコードを永続的リポジトリに格納することと、
インタフェースレコードを、複数の資源インスタンスのうちの第１の資源インスタンスにアタッチするための第１のアタッチ要求に応答して、第１の資源インスタンスが、第１のＩＰアドレスを対象としたトラフィックを受信することを可能にすることと、
インタフェースレコードを第１の資源インスタンスからデタッチするためのデタッチ要求に応答して、第１の資源インスタンスが、第１のＩＰアドレスを対象としたトラフィックを受信するのを防ぐこと、およびインタフェースレコードを永続的リポジトリ内に保持することとを含む、方法。
付記項８．第２のインタフェースレコード作成要求に応答して、第２のＩＰアドレスを含む第２のインタフェースレコードを生成することと、
第２のインタフェースレコードを第１の資源インスタンスにアタッチするための第２のアタッチ要求に応答して、第１の資源インスタンスが、第２のＩＰアドレスを対象としたトラフィックを受信することを可能にすることとをさらに含む、付記項７に記載の方法。付記項９．第２のＩＰアドレスが、第２のサブネットの部分であり、かつ、第２のインタフェースレコードが第２のサブネットのサブネット識別子を含む、付記項８に記載の方法。
付記項１０．第１の資源インスタンスで、ネットワークパケットを送信元ＩＰアドレスから受信することであって、送信元ＩＰアドレスが、第１の資源インスタンスから第１のサブネットを介して到達可能であり、かつ、ネットワークパケットが、第１の資源インスタンスから第２のサブネットを介して到達可能な宛先ＩＰアドレスを有する、ネットワークパケットを送信元ＩＰアドレスから受信することと、
ネットワークパケットを第２のサブネットを介して宛先ＩＰアドレスにルーティングすることとをさらに含む、付記項９に記載の方法。
付記項１１．新しいＩＰアドレスを含むＩＰアドレス修正要求に応答して、
インタフェースレコードを新しいＩＰアドレスを含むように修正することと、
インタフェースレコードがアタッチされる複数の資源インスタンスのうちの現在アタッチされている資源インスタンスを識別することと、
現在アタッチされている資源インスタンスが、新しいＩＰアドレスを対象としたトラフィックを受信することを可能にすることとをさらに含む、付記項９に記載の方法。
付記項１２．第１のサブネットが、第１の共通インターネットドメインルーティング（ＣＩＤＲ）アドレスプレフィックスをもつネットワークの第１の論理パーティションの部分であり、かつ、第２のサブネットが、第２のＣＩＤＲアドレスプレフィックスをもつネットワークの第２の論理パーティションの部分である、付記項９に記載の方法。
付記項１３．インタフェースレコードが、アタッチ要求を投入することを認可された１つまたは複数の実体を識別する第１の認可エントリを含む１組のセキュリティ特性を含む、付記項７に記載の方法。
付記項１４．１組のセキュリティ特性が、第１の認可エントリを修正することを認可された１つまたは複数の実体を識別する第２の認可エントリを含む、付記項１３に記載の方法。
付記項１５．インタフェースレコード作成要求に応答して、ＩＰアドレスおよび第１のＩＰアドレスを含む第１のサブネットのサブネット識別子を含むインタフェースレコードを生成すること、およびそのインタフェースレコードを永続的リポジトリに格納することと、
インタフェースレコードを、複数の資源インスタンスのうちの第１の資源インスタンスにアタッチするための第１のアタッチ要求に応答し、第１の資源インスタンスが、そのブートアップに続いて実行状態にあり、第１のＩＰアドレスを対象としたトラフィックが第
１の資源インスタンスで受信されることを可能にすることを実装するためにコンピュータ実行可能なプログラム命令を格納する持続性コンピュータアクセス可能記憶媒体。
付記項１６．プログラム命令が、
第２のインタフェースレコード作成要求に応答して、第２のＩＰアドレスを含む第２のインタフェースレコードを生成することと、
第２のインタフェースレコードを第１の資源インスタンスにアタッチするための第２のアタッチ要求に応答して、第１の資源インスタンスが、第２のＩＰアドレスを対象としたトラフィックを受信することを可能にすることとを実装するためにコンピュータ実行可能である、付記項１５に記載の持続性コンピュータアクセス可能記憶媒体。
付記項１７．第２のＩＰアドレスが、第２のサブネットの部分であり、かつ、第２のインタフェースレコードが第２のサブネットのサブネット識別子を含む、付記項１６に記載の持続性コンピュータアクセス可能記憶媒体。
付記項１８．プログラム命令が、
第１の資源インスタンスで、ネットワークパケットを送信元ＩＰアドレスから受信することであって、送信元ＩＰアドレスが、第１の資源インスタンスから第１のサブネットを介してアクセス可能であり、かつ、ネットワークパケットが、第１の資源インスタンスから第２のサブネットを介してアクセス可能な宛先ＩＰアドレスを有する、ネットワークパケットを送信元ＩＰアドレスから受信することと、
ネットワークパケットを第２のサブネットを介して宛先ＩＰアドレスにルーティングすることとを実装するためにコンピュータ実行可能である、付記項１７に記載の持続性コンピュータアクセス可能記憶媒体。
付記項１９．インタフェースレコードが、ＩＰアドレスを修正することを認可された１つまたは複数の実体を識別する認可エントリを含む１組のセキュリティ特性を含む、付記項１５に記載の持続性コンピュータアクセス可能記憶媒体。
付記項２０．インタフェースレコードが：入トラフィックに対するポート制約、入トラフィックに対するプロトコル制約、出トラフィックに対するプロトコル制約、または出トラフィックに対するプロトコル制約のうちの少なくとも１つを識別する認可エントリを含む１組のセキュリティ特性を含む、付記項１５に記載の持続性コンピュータアクセス可能記憶媒体。
付記項２１．プログラム命令が、
新しいＩＰアドレスを含むＩＰアドレス修正要求に応答して、
インタフェースレコードを新しいＩＰアドレスを含むように修正することと、
インタフェースレコードがアタッチされる複数の資源インスタンスのうちの現在アタッチされている資源インスタンスを識別することと、
現在アタッチされている資源インスタンスが、新しいＩＰアドレスを対象としたトラフィックを受信することを可能にすることとを実装するためにコンピュータ実行可能である、付記項１５に記載の持続性コンピュータアクセス可能記憶媒体。
付記項２２．第１のサブネットがクライアントアプリケーションデータの伝送用に指定されたデータサブネットであり、かつ、第２のサブネットがネットワーク管理データの伝送用に指定された管理サブネットである、付記項１７に記載の持続性コンピュータアクセス可能記憶媒体。
付記項２３．第１のＩＰアドレスが、第１の顧客の代わりに保持された第１のネットワーク論理パーティションの部分であり、第２のＩＰアドレスが、第２の顧客の代わりに保持された第２のネットワーク論理パーティションの部分である、付記項１６に記載の持続性コンピュータアクセス可能記憶媒体。

例示的なコンピュータシステム
少なくともいくつかの実施形態では、インタフェースレコード１７０に関連した様々なサービスおよび操作を提供するための技術を含む、本明細書で記載する１つまたは複数の技術の一部または全部を実装するサーバーは、図１１に示すコンピュータシステム２００
０などの、１つまたは複数のコンピュータアクセス可能媒体を含むか、またはそれにアクセスするように構成されている、汎用コンピュータシステムを含み得る。図示した実施形態では、コンピュータシステム２０００は、入力／出力（Ｉ／Ｏ）インタフェース２０３０を介して、システムメモリ２０２０に結合された、１つまたは複数のプロセッサ２０１０を含む。コンピュータシステム２０００は、入出力インタフェース２０３０に結合されたネットワークインタフェース２０４０をさらに含む。

様々な実施形態では、コンピュータシステム２０００は、１つのプロセッサ２０１０を含む単一プロセッサシステム、またはいくつかのプロセッサ２０１０（例えば、２、４、８、または別の適切な数）を含むマルチプロセッサシステムであり得る。プロセッサ２０１０は、命令を実行可能な任意の適切なプロセッサであり得る。例えば、様々な実施形態では、プロセッサ２０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ
ＩＳＡ、または任意の他の適切なＩＳＡなどの、様々な命令セットアーキテクチャ（ＩＳＡ）のいずれかを実装する汎用または組込みプロセッサであり得る。マルチプロセッサシステムでは、プロセッサ２０１０の各々は、一般に、必ずしもではないが、同じＩＳＡを実装し得る。

システムメモリ２０２０は、プロセッサ（複数可）２０１０によってアクセス可能な命令およびデータを格納するように構成され得る。様々な実施形態では、システムメモリ２０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、または任意の他のタイプのメモリなどの、任意の適切なメモリ技術を使用して実装され得る。図示した実施形態では、前述したような方法、技術、およびデータなどの、１つまたは複数の所望の機能を実装する、プログラム命令およびデータは、コード２０２５およびデータ２０２６としてシステムメモリ２０２０内に格納されて示されている。

一実施形態では、入出力インタフェース２０３０は、ネットワークインタフェース２０４０または他の周辺インタフェースを含む、プロセッサ２０１０、システムメモリ２０２０、および装置内の任意の周辺機器の間の入出力トラフィックを調整するように構成され得る。いくつかの実施形態では、入出力インタフェース２０３０は、１つの構成要素（例えば、システムメモリ２０２０）からのデータ信号を、別の構成要素（例えば、プロセッサ２０１０）による使用に適した形式に変換するために、任意の必要なプロトコル、タイミングまたはデータ変換を実行し得る。いくつかの実施形態では、入出力インタフェース２０３０は、例えば、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス規格またはユニバーサルシリアルバス（ＵＳＢ）規格の変形などの、様々なタイプの周辺機器用バスを通してアタッチされた装置に対するサポートを含み得る。いくつかの実施形態では、入出力インタフェース２０３０の機能は、例えば、ノースブリッジおよびサウスブリッジなどの、２つ以上の別個の構成要素に分割され得る。また、いくつかの実施形態では、システムメモリ２０２０に対するインタフェースなどの、入出力インタフェース２０３０の機能の一部または全部が、プロセッサ２０１０に直接組み込まれ得る。

ネットワークインタフェース２０４０は、データが、コンピュータシステム２０００と、ネットワークまたは複数のネットワーク２０５０にアタッチされた他の装置２０６０（例えば、図１～図１０に示すような他のコンピュータシステムまたは装置）との間で、交換されるのを可能にするように構成され得る。様々な実施形態では、ネットワークインタフェース２０４０は、例えば、イーサネット（登録商標）ネットワークのタイプなどの、任意の適切な有線または無線の一般的なデータネットワークを介した通信をサポートし得る。加えて、ネットワークインタフェース２０４０は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどの、電気通信／電話網を介した、ファイバーチャ
ンネルＳＡＮなどのストレージエリアネットワークを介した、または任意の他の適切なタイプのネットワークおよび／もしくはプロトコルを介した、通信をサポートし得る。

いくつかの実施形態では、システムメモリ２０２０は、仮想ネットワークインタフェースレコードに対する方法および機器の実施形態を実装するための図１～図１０について前述したように、プログラム命令およびデータを格納するように構成されたコンピュータアクセス可能媒体の一実施形態であり得る。しかし、他の実施形態では、プログラム命令および／またはデータが、異なるタイプのコンピュータアクセス可能媒体上で受信、送信または格納され得る。一般的に言えば、コンピュータアクセス可能媒体は、磁気または光媒体などの持続性記憶媒体またはメモリ媒体、例えば、入出力インタフェース２０３０を介してコンピュータシステム２０００に結合されたディスクまたはＤＶＤ／ＣＤを含み得る。持続性コンピュータアクセス可能記憶媒体は、コンピュータシステム２０００のいくつかの実施形態で、システムメモリ２０２０または他のタイプのメモリとして含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの任意の揮発性または不揮発性媒体も含み得る。さらに、コンピュータアクセス可能媒体は、ネットワークインタフェース２０４０を介して実装され得るような、ネットワークおよび／または無線リンクなどの通信媒体を経由して伝達される、電気的、電磁気的、または他のデジタル信号などの伝送媒体または信号を含み得る。図１１に示されるもののような複数のコンピュータシステムのうちの一部または全部が、様々な実施形態で説明した機能を実装するために使用され得；例えば、様々な異なる装置およびサーバー上で実行するソフトウェア構成要素が、機能を提供するために連携し得る。

結論
様々な実施態様は、コンピュータアクセス可能媒体に関する前述の説明に従った、命令および／またはデータの受信、送信または格納をさらに含み得る。一般的に言えば、コンピュータアクセス可能媒体は、磁気または光などの記憶媒体またはメモリ媒体、例えば、ディスクまたはＤＶＤ／ＣＤ－ＲＯＭ、揮発性または不揮発性媒体（ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなど）、ならびに、ネットワークおよび／または無線リンクなどの通信媒体を経由して伝達される、電気的、電磁気的、もしくは他のデジタル信号などの伝送媒体または信号を含み得る。

図に示し、本明細書で説明する様々な方法は、方法の例示的な実施形態を提示する。方法は、ソフトウェア、ハードウェア、またはそれらの組合せで実施され得る。方法の順序は、変更され得、また、様々な要素が、追加、並べ替え、組み合わせ、省略などが行われ得る。

本開示の利益を有する当業者には明らかであるように、様々な修正および変更が行われ得る。かかる修正および変更の全てを包含し、それに応じて、前述の説明は制限的な意味ではなく例示的な意味で考えられることを意図する。

Claims (15)

1. 複数のコンピュータによって実装される複数の資源インスタンスと、
   １つ以上のコンピュータによって実装されるネットワークインタフェース仮想化コーディネータと、
   を備えるシステムであって、
   前記ネットワークインタフェース仮想化コーディネータは、
   永続的リポジトリにおいて定義された第１のインタフェースレコードを前記複数のコンピュータの中の第１のコンピュータで実装される第１の資源インスタンスにアタッチすることであって、前記第１のインタフェースレコードは、第１のインターネットプロトコル（ＩＰ）アドレスを指定し、且つ、前記第１のインタフェースレコードを前記第１の資源インスタンスにアタッチすることは、前記第１の資源インスタンスが、前記第１のコンピュータにおいて、第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にし、前記第１のインタフェースレコードは、セキュリティ設定に関連付いている、永続的リポジトリにおいて定義された前記第１のインタフェースレコードを前記複数のコンピュータの中の前記第１のコンピュータで実装される前記第１の資源インスタンスにアタッチすることと、
   移動要求に応答して、前記第１のインタフェースレコードを前記複数のコンピュータの中の第２のコンピュータで実装される前記資源インスタンスの１つにアタッチすることを変更することであって、前記アタッチすることを変更することは、前記第２のコンピュータで実装される前記資源インスタンスが、前記第２のコンピュータにおいて、第２のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にし、且つ、前記第１のコンピュータにおいて、前記第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを妨げる、前記第１のインタフェースレコードを前記複数のコンピュータの中の前記第２のコンピュータで実装される前記資源インスタンスの１つにアタッチすることを変更することと、
   前記第２のコンピュータで実装される前記資源インスタンスの１つにおいて、前記第１のインタフェースレコードに関連付けられた前記セキュリティ設定を再使用することを可能にすることと
   を行うように構成される、システム。
2. 前記ネットワークインタフェース仮想化コーディネータは、
   インタフェースレコード作成要求に応答して、第２のＩＰアドレスを指定する第２のインタフェースレコードを生成すると共に、前記第２のインタフェースレコードを前記永続的リポジトリに格納することと、
   前記第１のコンピュータで実装される前記資源インスタンスの１つに前記第２のインタフェースレコードをアタッチするための新しいアタッチ要求に応答して、前記第１のコンピュータで実装される前記第１の資源インスタンスが、前記第２のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にすることと、
   を行うように更に構成される、請求項１に記載のシステム。
3. 前記第１のインタフェースレコードは１つ以上の追加のＩＰアドレスを指定し、且つ、前記第１のインタフェースレコードを前記第２のコンピュータで実装される前記資源インスタンスの１つにアタッチすることは、前記第２のコンピュータで実装される前記資源インスタンスの１つが、前記１つ以上の追加のＩＰアドレスを対象としたトラフィックを受信することを可能にする、請求項１又は請求項２に記載のシステム。
4. 前記ネットワークインタフェース仮想化コーディネータは、
   新しいＩＰアドレスを備えるＩＰアドレス修正要求に応答して、
   前記新しいＩＰアドレスを含むように前記第１のインタフェースレコードを修正することと、
   前記第１のインタフェースレコードがアタッチされる前記複数の資源インスタンスの中で現在アタッチされている資源インスタンスを識別することと、
   前記現在アタッチされている資源インスタンスが、前記新しいＩＰアドレスを対象としたトラフィックを受信することを可能にすることと、
   を行うように更に構成される、請求項１から請求項３のいずれか一項に記載のシステム。
5. 前記移動要求は、前記第１のコンピュータで実装される前記第１の資源インスタンスを前記第２のコンピュータへ移動させるための要求を含み、その結果として、前記第１の資源インスタンスの実装は、前記第１のコンピュータから前記第２のコンピュータへ変更され、且つ、前記第１の資源インスタンスが、前記第２のコンピュータにおいて、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にするために、前記第１のインタフェースレコードは、前記第２のコンピュータにおいて、前記第１の資源インスタンスにアタッチされる、請求項１から請求項４のいずれか一項に記載のシステム。
6. 永続的リポジトリにおいて定義された第１のインタフェースレコードを第１のコンピュータで実装される第１の資源インスタンスにアタッチすることであって、前記第１のインタフェースレコードは第１のインターネットプロトコル（ＩＰ）アドレスを指定し、且つ、前記第１のインタフェースレコードを前記第１の資源インスタンスにアタッチすることは、前記第１の資源インスタンスが、前記第１のコンピュータにおいて、第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にし、前記第１のインタフェースレコードは、セキュリティ設定に関連付いている、永続的リポジトリにおいて定義された前記第１のインタフェースレコードを第１のコンピュータで実装される前記第１の資源インスタンスにアタッチすることと、
   移動要求に応答して、前記第１のインタフェースレコードを第２のコンピュータで実装される資源インスタンスにアタッチすることを変更することであって、前記アタッチすることを変更することは、前記第２のコンピュータで実装される前記資源インスタンスが、前記第２のコンピュータにおいて、第２のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にし、且つ、前記第１のコンピュータにおいて、前記第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを妨げる、前記第１のインタフェースレコードを前記第２のコンピュータで実装される前記資源インスタンスにアタッチすることを変更することと、
   前記第２のコンピュータで実装される前記資源インスタンスの１つにおいて、前記第１のインタフェースレコードに関連付けられた前記セキュリティ設定を再使用することを可能にすることと
   を備える、方法。
7. インタフェースレコード作成要求に応答して、第２のＩＰアドレスを指定する第２のインタフェースレコードを生成すると共に、前記永続的リポジトリに前記第２のインタフェースレコードを格納することと、
   前記第２のインタフェースレコードを前記第１のコンピュータで実装される前記資源インスタンスの１つにアタッチするための新しいアタッチ要求に応答して、前記第１のコンピュータで実装される前記第１の資源インスタンスが、前記第２のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にすることと、
   を更に備える、請求項６に記載の方法。
8. 前記第１のインタフェースレコードは１つ以上の追加のＩＰアドレスを指定し、且つ、前記第１のインタフェースレコードを前記第１の資源インスタンスにアタッチすることは、実装される前記第１の資源インスタンスが、前記１つ以上の追加のＩＰアドレスを対象としたトラフィックを受信することを可能にする、請求項６又は請求項７に記載の方法。
9. 新しいＩＰアドレスを備えるＩＰアドレス修正要求に応答して、
   前記新しいＩＰアドレスを含むように前記第１のインタフェースレコードを修正することと、
   前記第１のインタフェースレコードがアタッチされる複数の資源インスタンスの中で現在アタッチされている資源インスタンスを識別することと、
   前記現在アタッチされている資源インスタンスが、前記新しいＩＰアドレスを対象としたトラフィックを受信することを可能にすることと、
   を更に備える、請求項６から請求項８のいずれか一項に記載の方法。
10. 前記移動要求は、前記第１のコンピュータで実装される前記第１の資源インスタンスを前記第２のコンピュータに移動させるための要求を含み、その結果として、前記第１の資源インスタンスの実装は、前記第１のコンピュータから前記第２のコンピュータに変更され、且つ、前記第１の資源インスタンスが、前記第２のコンピュータにおいて、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にするために、前記第１のインタフェースレコードは、前記第２のコンピュータにおいて、前記第１の資源インスタンスにアタッチされる、請求項６から請求項９のいずれか一項に記載の方法。
11. 永続的リポジトリにおいて定義された第１のインタフェースレコードを第１のコンピュータで実装される第１の資源インスタンスにアタッチすることであって、前記第１のインタフェースレコードは第１のインターネットプロトコル（ＩＰ）アドレスを指定し、且つ、前記第１のインタフェースレコードを前記第１の資源インスタンスにアタッチすることは、前記第１の資源インスタンスが、前記第１のコンピュータにおいて、第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にし、前記第１のインタフェースレコードは、セキュリティ設定に関連付いている、永続的リポジトリにおいて定義された前記第１のインタフェースレコードを前記第１のコンピュータで実装される前記第１の資源インスタンスにアタッチすることと、
    移動要求に応答して、前記第１のインタフェースレコードを第２のコンピュータで実装される資源インスタンスにアタッチすることを変更することであって、前記アタッチすることを変更することは、前記第２のコンピュータで実装される前記資源インスタンスが、前記第２のコンピュータにおいて、第２のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にし、且つ、前記第１のコンピュータにおいて、前記第１のネットワークインタフェースカードを通して、前記第１のＩＰアドレスを対象としたトラフィックを受信することを妨げる、前記第１のインタフェースレコードを前記第２のコンピュータで実装される前記資源インスタンスにアタッチすることを変更することと、
    前記第２のコンピュータで実装される前記資源インスタンスの１つにおいて、前記第１のインタフェースレコードに関連付けられた前記セキュリティ設定を再使用することを可能にすることと
    を実装するためにコンピュータ実行可能であるプログラム命令を格納する１つ以上の持続性コンピュータアクセス可能記憶媒体。
12. 前記プログラム命令は、
    インタフェースレコード作成要求に応答して、第２のＩＰアドレスを指定する第２のインタフェースレコードを生成すると共に、前記永続的リポジトリに前記第２のインタフェースレコードを格納することと、
    前記第２のインタフェースレコードを前記第１のコンピュータで実装される前記資源インスタンスの１つにアタッチするための新しいアタッチ要求に応答して、前記第１のコンピュータで実装される前記第１の資源インスタンスが、前記第２のＩＰアドレスを対象としたネットワークトラフィックを受信することを可能にすることと、
    を実装するためにコンピュータ実行可能である、請求項１１に記載の１つ以上の持続性コンピュータアクセス可能記憶媒体。
13. 前記第１のインタフェースレコードは１つ以上の追加のＩＰアドレスを指定し、且つ、前記第１のインタフェースレコードを前記第１の資源インスタンスにアタッチすることは、実装される前記第１の資源インスタンスが、前記１つ以上の追加のＩＰアドレスを対象としたトラフィックを受信することを可能にする、請求項１１又は請求項１２に記載の１つ以上の持続性コンピュータアクセス可能記憶媒体。
14. 前記プログラム命令は、
    新しいＩＰアドレスを備えるＩＰアドレス修正要求に応答して、
    前記新しいＩＰアドレスを含むように前記第１のインタフェースレコードを修正することと、
    前記第１のインタフェースレコードがアタッチされる複数の資源インスタンスの中で現在アタッチされている資源インスタンスを識別することと、
    前記現在アタッチされている資源インスタンスが、前記新しいＩＰアドレスを対象としたトラフィックを受信することを可能にすることと、
    を実装するためにコンピュータ実行可能である、請求項１１から請求項１３のいずれか一項に記載の１つ以上の持続性コンピュータアクセス可能記憶媒体。
15. 前記移動要求は、前記第１のコンピュータで実装される前記第１の資源インスタンスを前記第２のコンピュータに移動させるための要求を含み、その結果として、前記第１の資源インスタンスの実装は、前記第１のコンピュータから前記第２のコンピュータに変更され、且つ、前記第１の資源インスタンスが、前記第２のコンピュータにおいて、前記第１のＩＰアドレスを対象としたトラフィックを受信することを可能にするために、前記第１のインタフェースレコードは、前記第２のコンピュータにおいて、前記第１の資源インスタンスにアタッチされる、請求項１１から請求項１４のいずれか一項に記載の１つ以上の持続性コンピュータアクセス可能記憶媒体。

Images