JP7852026B2 - クラウドインフラストラクチャ環境におけるタグベースのリソース制限または割り当てのためのシステムおよび方法 - Google Patents

Description

著作権通知
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。著作権保有者は、この特許文献または特許開示の、それが特許商標庁の特許ファイルまたは記録に現れているとおりの、何人による複写複製にも異議を唱えないが、それ以外の場合にはすべての著作権をどのようなものであろうと所有する。

関連出願に対する優先権主張および相互参照：
本出願は、２０１９年８月９日に出願された「SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国仮特
許出願第６２／８８４，９３１号、および２０１９年８月９日に出願された「SYSTEM AND
METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と
題される米国仮特許出願第６２／８８４，９３３号に対する優先権の利益を主張し、上記の各出願は、参照によりその全体が本明細書に組み込まれる。

本出願は、２０２０年８月５日に出願された「SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国特許
出願第１６／９８６，１５８号、および２０２０年８月５日に出願された「SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題
される米国特許出願第１６／９８６，１６０号に対する優先権の利益も主張し、上記の各出願は、参照によりその全体が本明細書に組み込まれる。

技術分野
本明細書で説明される実施形態は、概して、サービスとしてのインフラストラクチャ（Infrastructure as a Service）（ＩａａＳ）等のクラウドインフラストラクチャ環境に
関し、特に、そのようなクラウドインフラストラクチャ環境内でリソース制約を提供するためのシステムおよび方法を提供するためのシステムならびに方法に関する。

背景：
クラウドインフラストラクチャ環境は、ユーザおよびクライアント（本明細書を通して、「クライアント」および「顧客」という用語は互換的に用いることができる）が、高度に利用可能なホストされた環境において広範囲のアプリケーションおよびサービスを構築ならびに実行することを可能にする、補完的クラウドサービスのセットを備えることができる。

年々、ますます多くの事業および組織が、ミッションクリティカルなアプリケーションおよびシステムをクラウドインフラストラクチャ環境に移行させている。このシフトの理由は様々である。例えば、多くの事業は、オンプレミスインフラストラクチャを運用し、維持し、増築するコストおよび複雑さを低減するために、クラウドに移動している。同様に、クラウドインフラストラクチャは、より迅速な情報技術（ＩＴ）配信機構も可能にする。いくつかの事業および組織は、さらに、クラウドインフラストラクチャ環境を、より敏捷なシステムに適合することによって、競争で優位に立つ手段として見る。

ＩａａＳ（Infrastructure as a Service）モデル内では、クラウドプロバイダは、従
来の設定では、各顧客／クライアントの場所においてオンプレミスとなるであろうインフ
ラストラクチャ構成要素を提供、ホスト、および管理することができる。従来ではオンプレミスで提供されるそのような構成要素は、ハードウェア、例えば、データウェアハウスおよびデータセンター、サーバ、ストレージ、ネットワーキングハードウェア、ならびに仮想化ソフトウェア等のソフトウェアを含むことができる。

ＩａａＳプロバイダは、従来ではオンプレミスであろうハードウェアおよびソフトウェアを提供することに加えて、それらのクライアントおよび顧客にサービスを提供することもできる。例として、クライアントおよび顧客は、彼らのＩａａＳサブスクリプションを彼らのニーズに適合するように調整することを可能にされ得、次いでこれは、詳細で分解された課金および請求を可能にする。ＩａａＳは、負荷分散、冗長性、複製、回復などの機能もサポートできる。そのようなサービスは、（顧客ではなく）ＩａａＳプロバイダによって提供およびサポートされるため、これは、クライアントおよび顧客を、彼らのサービスのための自動化およびオーケストレーションにさらにプッシュすることによって、彼らの事業を改善することに、より集中させる。

クラウドインフラストラクチャは、ユーザおよびクライアントが、従来の企業アプリケーションを、クラウドネイティブアプリとともに、すべて同じプラットフォーム上でシームレスに実行することを可能にし、運用オーバーヘッドを低減し、両方のタイプのワークロード間の直接接続性を可能にする。

概要：
クラウドインフラストラクチャ環境においてタグベースのリソース制限または割り当てを設けるためのシステムおよび方法が本明細書で説明される。本明細書に記載のシステムおよび方法は、クラウドインフラストラクチャ環境においてタグベースのリソース制限／割り当てをサポートする。細かい粒度のアプローチは、複数のコンテナに跨がるタグに基づいてリソース制限を設けることができる。タグは、主にリソース管理において用いられる機構であり、クラウドプロバイダはそれらをコスト管理のためにも用いる。システムおよび方法は、タグを通してグループレベルでコストを制御するための機構を作成することができる。システムおよび方法は、クラウドインフラストラクチャ環境のためのコンパートメント割り当てを設ける。

クラウド管理者は、既存のクラウドにおいてリソース使用を制限する能力を有するが、それは上位レベルにおいてのみであり、特定のユーザ、特定のリソースおよびリソースタイプ、またはコンテナ階層構造のレベルにおけるリソースを考慮しない。ある実施形態に従うと、リソースはタグに関連付けられ、その結果、それらの使用は、必要または所望に応じて、リソースレベルで制御され、追跡され、および／または他の態様で扱われ得る。リソース割り当ておよび／または制限を設けることにより、管理者などは、ユーザのリソース使用を適切なレベルに制限することができ、微調整されたコスト制御が可能になる。

ある実施形態に従うと、顧客は、アカウント作成時にクラウドインフラストラクチャ環境によって定義されるサービスレベル制限を割り当てられることができる。これらのサービスレベル制限は、顧客がテナンシ全体にわたって作成することができるリソースの総数（例えば、複数のコンパートメントを有する複数のリージョンにわたり、複数のコンテナに跨がる）を制限する。テナンシおよびコンパートメント管理者は、タグベースのリソース割り当てを利用して、リソース固有の制限を設定することができる。リソースに関連付けられるタグに基づくそのような制限がないと、インスタンスを起動する権限を付与されたユーザは、テナンシ全体においてすべての利用可能な容量を消費し得る。タグベースのリソース制限は、この問題を解決し、サービス制限とは異なり、例えば、コンソール、Ｓ
ＤＫ、またはＡＰＩを介して、クライアントおよび顧客によって設定ならびにカスタマイズされる。タグベースのリソース制限は、サービス制限の上に適用され、ネスト化されたコンパートメント階層を通して継承され得る。これは、コンパートメント管理者が、リソース消費を制限し、許容可能なリソース使用の周りに境界を設定することを可能にする。

ある実施形態に係る、クラウドインフラストラクチャ環境を提供するためのシステムを示す図である。 ある実施形態に係る、クラウドインフラストラクチャ環境内にクラウドインフラストラクチャリージョンを提供するためのシステムを示す図である。 ある実施形態に係る、クラウドインフラストラクチャリージョンに跨がるポリシー管理ならびに制御のためにコンパートメント、コンパートメントポリシー、サブコンパートメント、およびサブコンパートメントポリシーの間の関係を示すクラウドインフラストラクチャ環境システムを示す図である。 コンパートメントを移動させるときのコンパートメント、コンパートメントポリシー、サブコンパートメント、およびサブコンパートメントポリシーの間の関係を示すクラウドインフラストラクチャ環境４００を示す図である。 コンパートメントを移動させるときのポリシーの意味を示すクラウドインフラストラクチャ環境５００を示す図である。 例示的な実施形態による、定義済みタグの対を示す図である。 例示的な実施形態による、たとえばリソースタグおよびリソース要求コンテキストタグを含むタグに基づいてクラウドインフラストラクチャ環境においてリソースに対する割り当てまたは制限を実施するシステムのアーキテクチャを示す図である。 クラウドインフラストラクチャ環境におけるリソースのプロビジョニングなどの使用を制限するために要求コンテキストタグおよび／またはリソースタグを用いるシステムを示す図である。 一実施形態による、クラウドインフラストラクチャ環境においてリソース要求コンテキストタグベースの制限／割り当てを設けるシステムの機能概略図である。 例示的な実施形態による、要求コンテキストに基づいてクラウドインフラストラクチャ環境においてリソースをプロビジョニングすることを制限するかまたはそれに割り当てを課すための方法を示す流れ図である。 一実施形態による、クラウドインフラストラクチャ環境においてタグベースのリソース制限／割り当てを設けるシステムの機能概略図である。 例示的な実施形態による、リソースタグに基づいてクラウドインフラストラクチャ環境においてリソースをプロビジョニングすることを制限するかまたはそれに割り当てを課すための方法を示す流れ図である。

詳細な説明：
本明細書の実施形態によれば、「ベアメタルホスト」、「ベアメタルインスタンス」、または「ベアメタル計算インスタンス」という用語は、クラウドインフラストラクチャ環境による使用のために提供される物理ホスト（「ベアメタル」）マシンを指し得る。ベアメタル計算インスタンスは、ハイパーバイザなしでベアメタルサーバ上で直接動作する。ベアメタルインスタンスがプロビジョニングされると、ユーザ／クライアントは、物理ＣＰＵ、メモリ、およびネットワークインターフェイスカード（ＮＩＣ）の唯一の制御を維持することができる。ユーザ／クライアントは、あたかも自分自身のデータセンターで動作するハードウェアであるかのように、各物理マシンの全能力を構成し利用することができる。ユーザ／クライアントは、物理マシンを他のテナントと共有しない。

本明細書の実施形態によれば、クラウドインフラストラクチャ環境は、リージョンおよ
び可用性ドメインにおいて物理的にホストされ得る。用語「リージョン」は、局所化された地理的エリアを指すことができる。用語「可用性ドメイン」は、あるリージョン内に位置する１つ以上のデータセンターを意味することができる。リージョンは、１つ以上の可用性ドメインから構成される。クラウドインフラストラクチャは、仮想クラウドネットワークのようにリージョン固有、または計算インスタンスのように可用性ドメイン固有であり得る。可用性ドメインは、互いに隔離され、フォールトトレラントであり、同時に故障したり、別の可用性ドメインの故障によって影響を受ける可能性が低い。ユーザ／クライアントが自分のクラウドサービスを構成すると、ユーザ／クライアントは、複数の可用性ドメインを用いて、高い可用性を保証し、リソース障害から保護することができる。いくつかのリソースは、インスタンスおよびそれに付随するストレージボリューム等、同じ可用性ドメイン内で作成されなければならない。

本明細書の実施形態によれば、「レルム」という用語は、リージョンの論理的な集まりを指すことができる。レルムは互いに隔離されており、いかなるデータも共有しない。クライアントのテナンシは、単一のレルム内に存在し、そのレルムに属するリージョンの各々へのアクセスを有することができる。レルムは、例えば、商業的リージョンおよび行政クラウドリージョンのために提供されることができる。

本明細書の実施形態によれば、「コンソール」という用語は、ユーザ／クライアントがクラウドインフラストラクチャ環境にアクセスし、それを管理するために用いることができる（たとえば、ウェブベースの）ユーザインターフェイスを指すことができる。

本明細書の実施形態によれば、「テナンシ」という用語は、クラウドインフラストラクチャ環境内の安全かつ隔離されたパーティションを指すことができる。クライアント／ユーザがクラウドインフラストラクチャ環境についてサインアップすると、クラウドインフラストラクチャ環境は、そのユーザ／クライアント（または彼らの会社）のためにテナンシを作成することができる。テナンシは、ユーザ／クライアントが自分のクラウドリソースを作成、編成、および管理する場所であり得る。

本明細書の実施形態によれば、「コンパートメント」という用語は、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりを指すことができる。コンパートメントは、クライアント／ユーザが、彼らのクラウドリソースを編成し、それらへのアクセスを制御することを可能にする。クライアント／ユーザがコンソールにおいてリソースで作業し始めると、コンパートメントは、クライアント／ユーザが見ているものについてフィルタを提供することができる。

本明細書の実施形態によれば、「テナンシ」という用語は、テナントのクラウドリソースのすべてを含むルートコンパートメントを指すことができる。テナンシ（ルートコンパートメント）および対応するポリシー内に追加のコンパートメントを作成して、各コンパートメント内のリソースへのアクセスを制御することができる。ユーザ／クライアントが、インスタンス、ブロックボリューム、またはクラウドネットワーク等のクラウドリソースを作成すると、ユーザ／クライアントは、リソースがどのコンパートメントに属するべきかを指定することができる。

本明細書の実施形態によれば、「仮想クラウドネットワーク」という用語は、インスタンスが動作する、サブネット、ルートテーブル、およびゲートウェイを含む、従来のネットワークの仮想バージョンを指すことができる。クラウドネットワークは、単一のリージョン内に存在するが、そのリージョンのすべての可用性ドメインを含む。クラウドネットワークにおいて定義される各サブネットは、単一の可用性ドメイン内にあるか、またはそ
のリージョン内のすべての可用性ドメインにわたるかのいずれかであり得る。少なくとも１つの少なくとも１つのクラウドネットワークは、インスタンスが起動され得る前にセットアップされ得る。

本明細書の実施形態によれば、「インスタンス」という用語は、クラウド内で動作する計算ホストを指すことができる。クラウドインフラストラクチャ環境インスタンスは、ユーザ／クライアントが、従来のソフトウェアベースの仮想マシンとは対照的に、ホストされた物理ハードウェアを利用することを可能にし、それによって、増加したセキュリティおよび性能を提供することができる。

本明細書の実施形態によれば、「イメージ」という用語は、例えば、ＬＩＮＵＸ（登録商標）など、インスタンスのためにオペレーティングシステムおよび他のソフトウェアを定義する仮想ハードドライブのテンプレートを指すことができる。インスタンスが起動されると、そのイメージを選択することによって、その特性を定義することができる。イメージのセットを提供することができ、同じソフトウェアおよびカスタマイズでインスタンスを用いるために、（例えば、テンプレートとして）すでに構成されている既存のインスタンスからイメージを用いることができる。

本明細書の実施形態によれば、「シェイプ」という用語は、インスタンスに割り当てられるＣＰＵの数およびメモリの量の仕様を指すことができる。負荷分散において、シェイプは、入口＋出口トラフィックのためのロードバランサの予めプロビジョニングされた合計最大容量（帯域幅）を決定することができる。利用可能なシェイプは、例えば、１００Ｍｂｐｓ、４００Ｍｂｐｓ、および８０００Ｍｂｐｓを含むことができる。

本明細書の実施形態によれば、「キーペア」という用語は、クラウドインフラストラクチャ環境で用いられる認証機構を指すことができる。キーペアは、秘密鍵ファイルと公開鍵ファイルとからなる。公開鍵はアップロードされることができ、一方秘密鍵はユーザ／クライアントのデバイス上に保持される。秘密鍵は、パスワードのように、ユーザ／クライアントに秘密である。キーペアは、インスタンスＳＳＨキーペアおよびＡＰＩ署名キーペアなどの異なる仕様に従って生成され得る。インスタンスＳＳＨキーペアは、インスタンスへのセキュアシェル（ＳＳＨ）接続を確立するために用いられる。インスタンスがプロビジョニングされると、公開鍵が提供され得、公開鍵は、インスタンスの承認されたキーファイルに保存される。インスタンスにログオンするために、秘密鍵が提供され、それは公開鍵で検証される。ＡＰＩ署名キーペアは、ＰＥＭ（プライバシー拡張メール）フォーマットであり、ＡＰＩ要求を提出するときにユーザ／クライアントを認証するために用いられる。

本明細書の実施形態によれば、「ブロックボリューム」という用語は、クラウドインフラストラクチャ環境インスタンスのために永続的ブロックストレージを提供する仮想ディスクを指すことができる。ブロックボリュームは、例えばデータおよびアプリケーションを記憶するために、例えばコンピュータ上の物理ハードドライブと同様の方法で、用いることができる。ボリュームは、データの損失なしに、あるインスタンスから分離され、別のインスタンスにアタッチされることができる。

本明細書の実施形態によれば、「オブジェクトストレージ」という用語は、データをオブジェクトとして記憶および管理するために用いられ得るストレージアーキテクチャを指し得る。データファイルは任意のタイプであり得る。データがオブジェクトストレージにアップロードされると、それは任意の場所からアクセスすることができる。オブジェクトストレージは、大量のデータを記憶する必要があり、そのデータがあまり頻繁に変化しないときに、用いることができる。オブジェクトストレージのための典型的な使用は、デー
タバックアップ、ファイル共有、非構造化データ（例えば、ログおよびセンサ生成データ）の記憶を含むが、これらに限定されない。

本明細書の実施形態によれば、「バケット」という用語は、データおよびファイルを記憶するための論理コンテナを指すことができる。バケットは、無制限の数のオブジェクトを含むことができる。

上述のように、クラウドインフラストラクチャ環境は、ユーザおよびクライアントが、高度に利用可能なホストされた環境において広範囲のアプリケーションおよびサービスを構築ならびに実行することを可能にする、補完的クラウドサービスのセットを備えることができる。

図１は、一実施形態による、クラウドインフラストラクチャ環境を提供するためのシステムを示す。

ある実施形態に従うと、いくつかのハードウェアおよびソフトウェアリソース１１２上で実行することができるクラウドインフラストラクチャ環境１００は、コンソールインターフェイス１０２とＡＰＩ１０４とを備えることができる。加えて、クラウドインフラストラクチャ環境１００は、いくつかのガバナンスサービス１１０と、アイデンティティおよびアクセス管理（ＩＡＭ）サービス１２０と、プロビジョニングサービス１３０とをサポートすることができる。クラウドインフラストラクチャ環境１００はまた、たとえば、コンピュータリソース層１５０、ネットワークリソース層１６０、およびストレージリソース層１７０などの層において、いくつかのリソース１４０をサポートすることができる。クラウドインフラストラクチャ環境１００はまた、例えば、概してリソース１４０に関連付けられるリソースタグ１４０ａ、コンピュータリソース１５０に関連付けられるコンピュータリソースタグ１５０ａ、ネットワークリソース１６０に関連付けられるネットワークリソースタグ１６０ａ、およびストレージリソース１７０に関連付けられるストレージリソースタグ１７０ａを含む、リソースの各々に関連付けられるいくつかのタグをサポートすることもできる。

ある実施形態に従うと、デバイスハードウェア（プロセッサ、メモリなど）１２を有するコンピューティングデバイス１０などのクライアントデバイスは、たとえばワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、またはインターネットなどのネットワークを介してクラウドインフラストラクチャ環境と通信することができる。クライアントデバイスは、管理者アプリケーション１４を備えることができ、それは、ユーザインターフェイス１６を備えることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境内では、テナンシをサポートすることができる。登録および展開時に、クライアント／顧客ごとにテナンシを作成することができ、これは、クラウドインフラストラクチャ内に、クライアントが自分のクラウドリソースを作成、編成、および管理することができるセキュアかつ隔離されたパーティションを備えることができる。

ある実施形態に従うと、コンソールインターフェイス１０２およびＡＰＩ１０４は、クライアントに、インフラストラクチャ環境のそれぞれの部分に対するアクセスおよび制御を与える。ある実施形態に従うと、コンソールインターフェイスは、クライアントに、リソース、インスタンス、クラウドネットワーク、およびストレージボリュームを作成ならびに管理させるとともに、クライアントに関連付けられるユーザを管理させ、クライアント範囲内に許可を設定させる、直感的なグラフィカルインターフェイスを含むことができる。同様に、ＡＰＩ１０４は、例えばＨＴＴＰＳ（ハイパーテキスト転送プロトコルセキ
ュア）を利用するＲＥＳＴ ＡＰＩを含み得る。

ある実施形態に従うと、コンソールインターフェイスまたはＡＰＩの一例は、構成管理ツール（たとえばAnsible）とすることができる。構成管理ツールは、クラウドインフラ
ストラクチャプロビジョニング、オーケストレーション、および構成管理のために用いることができる。構成管理ツールは、クライアントが、クラウドインフラストラクチャの構成およびプロビジョニング、ソフトウェアアセットの展開および更新、ならびに複雑な動作プロセスのオーケストレーションを自動化することを可能にすることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境のガバナンスサービス１１０は、クライアントが単純なリソース管理を可能にし、コストを管理し、クラウドインフラストラクチャへのアクセスを制御するのを助けるツールをクライアントに提供する。例として、ガバナンスサービスはタグ付けを提供し、このタグ付けは、クライアントが情報上または動作上の理由で彼らのリソースにタグを適用することを可能にすることができる。定義済みタグは、正しくないタグがリソースに適用されることを回避するように制御され得る。タグはまた、管理スクリプトのために柔軟なターゲット化機構を提供することもできる。同様に、ガバナンスサービスは、予算管理を可能にし、実費および予測費をすべて１つの場所から追跡することができる。これにより、クライアントは、費用分析ダッシュボードで使用の上に留まり、コンパートメントおよびタグによってフィルタリングして、部門、チーム、およびプロジェクトによる支出を分析することができる。そのようなデータは、詳細なリソース利用報告ならびに既存のクラウド管理およびビジネスインテリジェンスツールとの統合のためにエクスポートすることもできる。ガバナンスサービスはまた、クラウドインフラストラクチャエンタイトルメントならびにコンパートメントにわたるセキュリティ、コンプライアンス、およびリソース最適化のために後で検索され、記憶され、分析され得るイベントを記録することもできる。

例示的な実施形態によれば、ガバナンスサービスは、クライアント、管理者などが、リソースがインスタンス化されているときに情報上または動作上の理由で彼らのリソースにタグを適用することを可能にするタグ付けを提供する。さらなる例示的実施形態によれば、ガバナンスサービスはまた、リソースがインスタンス化された後に、クライアントおよび他者が情報上または動作上の理由で彼らのリソースにタグを適用することを可能にし、それによって、タグを用いてシステムにおけるリソース割り当てまたは制限の遡及的実施を可能にする、タグ付けを提供する。

ある実施形態に従うと、アイデンティティおよびアクセス管理（ＩＡＭ）サービス１２０は、ＩＡＭサービスにおける各クライアント／顧客／ユーザについて、ユーザクレデンシャル（たとえばユーザ名およびパスワード）に関連付けられて、ユーザプロファイルを作成することができる。クライアントは、ＩＡＭサービスを介してクラウドインフラストラクチャにおいて管理者特権も付与され得る。

ある実施形態に従うと、アイデンティティおよびアクセス管理サービスは、クラウドインフラストラクチャ環境と統合することができる。クライアント登録で、ＩＡＭサービスは、アイデンティティサービスにおいて別のユーザクレデンシャルを作成することができ、それは、次いで、クラウドインフラストラクチャサービスへのシングルサインオンおよび追加のクラウドサービスへのアクセスを可能にすることができる。

ある実施形態に従うと、プロビジョニングサービス１３０は、たとえばリソース１４０内などのクラウドインフラストラクチャサービス内にテナンシをプロビジョニングすることができる。プロビジョニングサービスは、例えば、コンソールインターフェイスを通して、またはＡＰＩ１０４等の１つ以上のＡＰＩを介して、アクセスおよび制御することが
できる。プロビジョニングサービスは、クライアントが、インスタンスと称され得る計算ホストをプロビジョニングおよび管理することを可能にし得る。クライアントは、計算およびアプリケーション要件を満たすために必要に応じてインスタンスを起動することができる。クライアントがインスタンスを起動した後、プロビジョニングされたインスタンスは、例えば、クライアントデバイスからアクセスされることができる。プロビジョニングサービスはまた、インスタンスの再起動、インスタンスからのボリュームのアタッチおよびデタッチ、ならびにインスタンスの終了を提供することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境によって提供されるリソース１４０は、計算リソース層１５０、ネットワークリソース層１６０、およびストレージリソース層１７０などの複数の層に分割することができる。

ある実施形態に従うと、計算リソース層１５０は、たとえばベアメタルインスタンス１５２、仮想マシン１５４、エッジサービス１５６、およびコンテナ１５８などのいくつかのリソースを含み得る。計算リソース層は、例えば、ベアメタル計算インスタンスをプロビジョニングおよび管理し、オンプレミスデータセンターと同様に、アプリケーションを展開および実行するために必要に応じてインスタンスをプロビジョニングするために用いることができる。例示的実施形態によるクラウドインフラストラクチャ環境１００は、例えば、ベアメタルインスタンス１５２、仮想マシン１５４、エッジサービス１５６、およびコンテナ１５８を含むコンピュータリソース１５０と関連付けられるコンピュータリソースタグ１５０ａを含む、リソースの各々と関連付けられるいくつかのタグ１４０ａをサポートする。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内の１つ以上の物理ホスト（「ベアメタル」）マシンの制御を提供することができる。ベアメタル計算インスタンスは、ハイパーバイザなしでベアメタルサーバ上で直接動作する。ベアメタル計算インスタンスがプロビジョニングされると、クライアントは、物理ＣＰＵ、メモリ、およびネットワークインターフェイスカード（ＮＩＣ）の唯一の制御を維持することができる。ベアメタル計算インスタンスは、構成され、各物理マシンの全能力を、あたかもそれがオンプレミスの自身のデータセンターで動作するハードウェアであるかのように、利用することができる。したがって、ベアメタル計算インスタンスは、一般に、テナント間では共有されない。

ある実施形態に従うと、ベアメタル計算インスタンスは、ソフトウェアベースの仮想環境とは対照的に、関連付けられた物理ハードウェアを介して、高レベルのセキュリティおよびパフォーマンスを提供することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内においていくつかの仮想マシンの制御を提供することができる。仮想マシン計算ホストは、例えば、仮想マシン動作システムおよび他のソフトウェアを決定することができるイメージから起動することができる。仮想マシンインスタンスに利用可能なリソースのタイプおよび量は、例えば、仮想マシンが起動されたイメージに基づいて判断され得る。

ある実施形態に従うと、仮想マシン（ＶＭ）計算インスタンスは、物理ベアメタルハードウェアの上で動作する独立したコンピューティング環境を含み得る。仮想化は、互いに隔離された複数のＶＭを実行することを可能にする。ＶＭは、例えば、物理マシン全体の性能およびリソース（ＣＰＵ、メモリ、ネットワーク帯域幅、ストレージ）を必要としないアプリケーションを実行するために用いることができる。

いくつかの実施形態では、仮想マシンインスタンスは、ベアメタルインスタンスと同じ
ハードウェア上で実行することができ、これは、同じクラウド最適化ハードウェア、ファームウェア、ソフトウェアスタック、およびネットワーキングインフラストラクチャを用いることに影響を及ぼすことができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内にいくつかのグラフィカル処理ユニット（ＧＰＵ）計算インスタンスを提供することができる。高速化される計算は、あらゆるサービスにわたって一貫して高速なインフラストラクチャを必要とする。ＧＰＵインスタンスを用いて、クライアントは、より効率的に大量のデータセットを処理および分析することができ、それらを、複雑な機械学習（ＭＬ）、人工知能（ＡＩ）アルゴリズム、および多くの産業用ＨＰＣアプリケーションに対して有用にする。ＧＰＵ計算インスタンスは、仮想化された計算インスタンス（複数のＧＰＵ計算インスタンスが同じベアメタルハードウェアを共有する）として、または各ＧＰＵ計算インスタンスについて専用ハードウェアを提供するベアメタルインスタンスとして、プロビジョニングすることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内にいくつかのコンテナ化された計算インスタンスを提供することができる。スタンドアロンコンテナエンジンサービスを用いて、コンテナ化されたアプリケーションを構築し、クラウドに起動することができる。コンテナサービスは、例えば、クラウドネイティブアプリケーションを構築、展開、および管理するために用いることができる。コンテナサービスは、コンテナ化されたアプリケーションが必要とする計算リソースを指定することができ、次いで、コンテナエンジンは、プロビジョニングサービスを介して、（例えば、テナンシのコンテキストにおいて）クラウドインフラストラクチャ環境内で用いるために必要とされる計算リソースをプロビジョニングすることができる。

ある実施形態に従うと、用いることができるそのようなコンテナサービスエンジンの１つは、ホストのクラスタにわたるコンテナ化されたアプリケーションの展開、スケーリング、および管理を自動化するためのオープンソースシステムであるKubernetesである。そのようなコンテナサービスは、アプリケーションを構成するコンテナを、容易な管理および発見のために、論理ユニットにグループ化することができる。

ある実施形態に従うと、ネットワークリソース層１６０は、たとえば仮想クラウドネットワーク（ＶＣＮ）１６２、ロードバランサ１６４、エッジサービス１６６、および接続サービス１６８などのいくつかのリソースを含み得る。例示的な実施形態によるクラウドインフラストラクチャ環境１００は、たとえば、概してリソース１４０に関連付けられるリソースタグ１４０ａと、仮想クラウドネットワーク（ＶＣＮ）１６２、ロードバランサ１６４、エッジサービス１６６、および接続サービス１６８に関連付けられるネットワークリソースタグ１６０ａとを含む、リソースの各々に関連付けられるいくつかのタグをサポートする。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層において、いくつかの仮想クラウドネットワーク１６２を提供することができる。仮想クラウドネットワークは、クライアントインスタンスが動作できるサブネット、ルートテーブル、およびゲートウェイを含む従来のネットワークの仮想バージョンを含むことができる。クラウドネットワークは、単一のリージョン内に存在するが、そのリージョンのすべての可用性ドメインを含む。クラウドネットワークにおいて定義される各サブネットは、単一の可用性ドメイン内にあるか、またはそのリージョン内のすべての可用性ドメインにわたる（推奨）かのいずれかであり得る。少なくとも１つのクラウドネットワークを、インスタンスを起動する前に構成することができる。ある実施形態では、ＶＣＮは、公衆トラフィック、ＶＰＮ接続、または高速接続サービスを処理して、オンプレミスネッ
トワークを安全に拡張するよう、インターネットゲートウェイを介して構成することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層において、いくつかのロードバランサ１６４を提供することができる。負荷分散サービスは、１つのエントリポイントから、仮想クラウドネットワーク（ＶＣＮ）から到達可能な複数のサーバへの、自動化されたトラフィック分配を提供することができる。様々な負荷分散が、パブリックまたはプライベートＩＰアドレス、およびプロビジョニングされた帯域幅を提供することができる。

ある実施形態に従うと、ロードバランサは、リソース利用、スケーリングを改善し、高い可用性を確保するのを助けることができる。複数の負荷分散ポリシーを構成することができ、アプリケーション固有の健全性チェックを提供して、ロードバランサがトラフィックを健全なインスタンスにのみ向けることを確実にすることができる。ロードバランサは、不健全なアプリケーションサーバが保守のためにサービスから取り除かれる前に不健全なアプリケーションサーバからトラフィックを排出することによって、保守ウィンドウを縮小することができる。

ある実施形態に従うと、負荷分散サービスにより、ＶＣＮに関連したパブリックまたはプライベートロードバランサの作成が可能になる。パブリックロードバランサは、インターネットからアクセス可能なパブリックＩＰアドレスを有する。プライベートロードバランサは、ＶＣＮ内でのみ可視であるホスティングサブネットからのＩＰアドレスを有する。複数のリスナが、ＩＰアドレスについて、異なるトラフィックの層（例えば、層４および層７（ＴＣＰおよびＨＴＴＰ）トラフィック）を負荷分散トランスポートするよう、構成され得る。パブリックおよびプライベートの両方のロードバランサは、ＶＣＮから到達可能な任意のバックエンドサーバにデータトラフィックをルーティングすることができる。

ある実施形態に従うと、パブリックロードバランサは、インターネットからトラフィックを受け入れることができ、着信トラフィックのためのエントリポイントとしての役割を果たすパブリックアドレスを割り当てられるパブリックロードバランサを作成することができる。

ある実施形態に従うと、パブリックロードバランサは範囲がリージョナルである。リージョンが複数の可用性ドメインを含む場合、パブリックロードバランサは、例えば、リージョナルサブネット、または各々が別個の可用性ドメインにある２つの可用性ドメイン固有（ＡＤ固有）サブネットを有することができる。リージョナルサブネットでは、ロードバランサは、一次ロードバランサおよびスタンバイロードバランサを、各々異なる可用性ドメインにおいて作成して、可用性ドメイン機能停止中であってもアクセス可能性を保証することができる。負荷分散が複数のＡＤ固有サブネットにおいて形成される場合、一方のサブネットは一次ロードバランサをホストすることができ、他方のサブネットはスタンバイロードバランサをホストすることができる。一次ロードバランサが故障した場合、パブリックＩＰアドレスは二次ロードバランサに切り替わることができる。サービスは、２つのロードバランサを等価物として扱う。

ある実施形態に従うと、リージョンが１つの可用性ドメインのみを含む場合、サービスは、一次ロードバランサおよびスタンバイロードバランサの両方をホストするために、リージョナルであれＡＤ固有であれ、１つのサブネットのみを必要とする。一次ロードバランサおよびスタンバイロードバランサは、各々、割り当てられたフローティングパブリックＩＰアドレスに加えて、ホストサブネットからのプライベートＩＰアドレスを有するこ
とができる。可用性ドメイン機能停止がある場合、ロードバランサはフェイルオーバを有さない。

ある実施形態に従うと、プライベート負荷分散はまた、ロードバランサをインターネットから隔離し、セキュリティ姿勢を単純化するようにも提供され得る。ロードバランササービスは、着信トラフィックのためのエントリポイントとして機能するプライベートアドレスをロードバランサに割り当てることができる。

ある実施形態に従うと、プライベートロードバランサは、あるサービスによって、１つのサブネットのみに対応して一次ロードバランサとスタンバイロードバランサとの両方をホストするよう、作成され得る。ロードバランサは、ホストサブネットの範囲に応じて、リージョナルであり得るかまたはＡＤ固有であり得る。ロードバランサは、ホストサブネットを含むＶＣＮ内からのみ、またはセキュリティルールによってさらに制限されるとおりに、アクセス可能である。

ある実施形態に従うと、割り当てられたフローティングプライベートＩＰアドレスは、ホストサブネットに対してローカルである。一次ロードバランサおよびスタンバイロードバランサは、各々、ホストサブネットから追加のプライベートＩＰアドレスを必要とする。

ある実施形態に従うと、可用性ドメイン機能停止がある場合、マルチＡＤリージョン内のリージョナルサブネットにおいて作成されたプライベートロードバランサは、フェイルオーバ能力を提供する。ＡＤ固有サブネットにおいて、または単一の可用性ドメインリージョン内のリージョナルサブネットにおいて作成されたプライベートロードバランサは、可用性ドメイン機能停止に応答してフェイルオーバ能力を有さない。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層においていくつかのエッジサービス１６６を提供することができる。概して、エッジサービスは、クライアントがドメインおよびエンドポイントを管理、セキュリティ保護、および維持することを可能にする、いくつかのサービスを備える。これらは、例えば、ＤＮＳ（ドメイン名システム）、ＤＤｏＳ（分散型サービス妨害）保護、電子メール配信などを含む。これらのサービスは、クライアントが性能を最適化し、サイバー攻撃を阻止し、通信をスケール変更することを可能にする。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層においていくつかの接続サービス１６８を提供することができる。そのような接続サービスは、クライアントデータセンターまたは既存のネットワークとクラウドインフラストラクチャ環境との間に専用のプライベート接続を作成するための容易な方法を提供することができる。接続サービスは、広帯域幅、および信頼できる一貫したネットワークを提供することができる。

ある実施形態に従うと、ストレージリソース層１７０は、たとえばブロックボリューム１７２、ファイルストレージ１７４、オブジェクトストレージ１７６、およびローカルストレージ１７８などのいくつかのリソースを含み得る。例示的な実施形態によるクラウドインフラストラクチャ環境１００は、例えば、概してリソース１４０に関連付けられるリソースタグ１４０ａと、ブロックボリューム１７２、ファイルストレージ１７４、オブジェクトストレージ１７６、およびローカルストレージ１７８に関連付けられるストレージリソースタグ１７０ａとを含む、リソースの各々に関連付けられるいくつかのタグをサポートする。

ある実施形態に従うと、ブロックボリューム１７２は、広範囲のＩ／Ｏ集約的ワークロードをサポートする高性能ネットワークストレージ容量を提供する。クライアントは、ブロックボリュームを用いて、計算インスタンスの記憶容量を拡張し、計算インスタンスにわたって移行することができる耐久性のある永続的なデータストレージを提供し、大きなデータベースをホストすることができる。

ある実施形態に従うと、ファイルストレージ１７４により、クライアントは、スケーラブルで分散型の企業グレードのネットワークファイルシステムを作成することができる。ファイルストレージは、セマンティクス、スナップショット能力、およびデータ保存時の暗号化をサポートする。

ある実施形態に従うと、オブジェクトストレージは、非構造化データに対して高スループットストレージを提供する。オブジェクトストレージサービスは、大量の分析データ、または画像および映像のような豊富なコンテンツのための、ほぼ無制限の記憶容量を可能にする。ブロックボリュームは、追加の耐久性のためにオブジェクトストレージにバックアップされることができる。

ある実施形態に従うと、ローカルストレージ１７８は、たとえば、Ｉ／Ｏ集約型アプリケーション用のソリッドステートドライブの形態で高速かつ信頼性のあるストレージを提供することができる。これらは、例えば、ベアメタルインスタンス内に設けることができる。ローカルストレージは、ＶＭおよびベアメタル計算インスタンスに対して高いストレージ性能を提供する。いくつかの例は、リレーショナルデータベース、データウェアハウス、ビッグデータ、分析、ＡＩ、およびＨＰＣアプリケーションを含む。

図２は、ある実施形態に係る、クラウドインフラストラクチャ環境内にクラウドインフラストラクチャリージョンを提供するためのシステムを示す図である。

ある実施形態に従うと、図１において上述したクラウドインフラストラクチャ環境のインスタンスは、クラウドインフラストラクチャリージョン２２０と呼ばれる異なるリージョンにおいてホストされることができる。これらは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット２１０などのネットワークを介して顧客ネットワーク２００によってアクセスすることができる。各クラウドインフラストラクチャリージョンは、管理サービス２２２と、計算サービス２２４と、ストレージサービス２２６と、エッジサービス２２８と、ネットワークサービス２３０と、物理インフラストラクチャ２３２とを備えることができる。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、リージョンにわたって利用可能ないくつかのサービスがある。これらは、例えば、管理サービス２２２、計算サービス２２４、ストレージサービス２２６、エッジサービス２２８、およびネットワークサービス２３０を含む。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。例えば、１つのコンパートメントは、例として、会社の人事（ＨＲ）システムの制作物を構成するすべてのサーバおよびストレージボリュームを含み得、他のコンパートメントは、各々、さらなる例として、会社の法務、マーケティング、経理、営業、および情報技術（ＩＴ）システムに別々に専用とすることができる。ある例では、そのコンパートメントに対する許可を有するユーザのみが、それらのサーバおよびボリュームを管理し、および／またはそれらにアクセスすることができる。さらなる例では、コンパートメントは、会社の人事（ＨＲ）システム、および法務、マーケティング、経理、営業、および情報技術（ＩＴ）システムの収集の制作物を構成するすべてのサーバならびにストレージボリュームを含むことができる。ある例では、それらのリソースの部分に対する許可を有するユーザのみが、サーバおよびボリューム上でそれらの部分を管理し、および／またはそれらにアクセスすることができる。

例示的実施形態のコンパートメントは、１つ以上の論理グループを備え、必ずしも物理メモリコンテナではないが、所望または必要に応じて、物理メモリコンテナであり得る。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。コンパートメントは、クラウドリソースのために用いられ得る主要構築ブロックであり、それらは、リソースを編成および隔離して、それらのリソースへのアクセスを管理およびセキュリティ保護することをより容易にするために用いられ得る。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシは、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。ルートコンパートメント（テナンシ）内に追加のコンパートメントを作成することができ、対応するポリシーを作成して、各コンパートメント内のリソースへのアクセスを制御することができる。クライアントが、計算、ストレージ、ＶＣＮ、ＩＰアドレスおよび／もしくはＤＮＳインスタンス、ブロックボリューム、また
はクラウドネットワークなどのクラウドリソースを作成するとき、そのようなリソースは、特定のあるコンパートメントまたは複数のコンパートメントに向けられ得る。コンパートメントは、リージョンに跨がることができる。

障害ドメイン
ある実施形態に従うと、障害ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループ化を含むことができる。各可用性ドメインは、３つの障害ドメインを含むことができる。障害ドメインは、インスタンスが単一の可用性ドメイン内の同じ物理ハードウェア上にないように、インスタンスが分散されることを可能にする。ある障害ドメインに影響を及ぼすハードウェア障害または計算ハードウェア保守は、他の障害ドメインにおけるインスタンスに影響を及ぼさない。

ある実施形態に従うと、計算、ベアメタルＤＢシステム、または仮想マシンＤＢシステムインスタンスなどのリソースの配置は、任意で、起動時に障害ドメインまたは新たなインスタンスを指定することができる。リソースは、配置後に、リソースを現在の障害ドメインで終了し、リソースの新たなインスタンスを別の障害ドメインで起動することによって、障害ドメインを追加的に変更することができる。

ある実施形態に従うと、障害ドメインは、予期せぬハードウェア障害からの保護および保守による計画された機能停止からの保護といった多くの理由で利用することができる。

可用性
ある実施形態に従うと、サービス可用性を提供することができる。クラウドインフラストラクチャ環境内のリージョンは、以下を含むコアインフラストラクチャサービスおよびリソースを提供することができる：
・計算：計算（ベアメタルおよびVM, DenseIOおよび Standard）、Kubernetesのためのコンテナエンジン、レジストリ...
・ストレージ：ブロックボリューム、ファイルストレージ、オブジェクトストレージ、アーカイブストレージ
・ネットワーキング：仮想クラウドネットワーク、負荷分散、高速接続
・データベース：データベース、Exadataクラウドサービス、自律データウェアハウス、
自律トランザクション
・処理
・エッジ：ＤＮＳ
・プラットフォーム：アイデンティティおよびアクセス管理、タグ付け、監査
ある実施形態に従うと、上記サービスおよびリソースは一般に利用可能であり得るが、他のサービスおよびリソースも（例えば、リージョナルな需要または顧客要求に基づいて）追加的に利用可能であり得る。例として、新たなクラウドサービスは、リージョナルな顧客需要、適用可能な場合には規制遵守を達成する能力、リソース可用性、および他の要因を含む様々な考慮事項に基づいて、リージョンにおいてできるだけ迅速に利用可能にされ得る。低レイテンシの相互接続バックボーンのため、顧客は、クラウドサービスが自分の本拠リージョンで利用可能でないときに、それらを他の地理的リージョンで効果的な結果を伴って用いることができるが、ただし、データレジデンシー要件がそうすることを妨げないことを条件とする。

ある実施形態に従うと、リソース可用性は、グローバルな可用性、リージョナルな可用性、単一リージョン可用性、およびドメイン可用性のコンテキストにおいて考慮することができる。概して、ＩＡＭリソースは、グローバルに利用可能であり、ＤＢシステム、インスタンス、およびボリュームは、実行可能性ドメインに固有である。他のほとんどのリソースはリージョナルである。

ある実施形態に従うと、グローバルに利用可能なリソースの例には、ＡＰＩ署名キー、コンパートメント、動的グループ、フェデレーションリソース、グループ、ポリシー、タグ名前空間、タグキー、およびユーザを含むことができる。

ある実施形態に従うと、リージョナルに利用可能なリソースの例には、アラーム、アプリケーション、バケット（バケットはリージョナルなリソースであるが、ＡＰＩコールのための正しいリージョン固有のオブジェクトストレージＵＲＬを用いると、バケットは任意の位置からアクセスできる）、クラスタ、クラウドイベントルール、顧客構内機器（ＣＰＥ）、ＤＨＣＰオプションセット、動的ルーティングゲートウェイ（ＤＲＧ）、暗号化キー、関数、イメージ、インターネットゲートウェイ、ジョブ、キーボールト、ロードバランサ、ローカルピアリングゲートウェイ（ＬＰＧ）、メトリック、ＮＡＴゲートウェイ、ネットワークセキュリティグループ、ノードプール、ons-subscriptions、ons-topics
、リポジトリ、予約されたパブリックＩｐ、ルートテーブル、セキュリティリスト、サービスゲートウェイ、スタック、サブネット（サブネットが作成されると、それはリージョナルまたは可用性ドメインに固有であると宣言され得る）、仮想クラウドネットワーク（ＶＣＮ）、およびボリュームバックアップ（ボリュームバックアップは、新たなボリュームとして、それらが格納される同じリージョン内の任意の可用性ドメインに復元することができる）などが含まれ得る。

ある実施形態に従うと、可用性ドメイン固有リソースの例は、ＤＢシステム、一過性のパブリックＩｐ、インスタンス（インスタンスは、同じ可用性ドメイン内のボリュームにアタッチすることができる）、サブネット（サブネットが作成されると、それはリージョナルまたは可用性ドメインに固有であると宣言され得る）、およびボリューム（ボリュームは、同じ可用性ドメイン内のインスタンスにアタッチすることができる）を含み得る。

コンパートメント
ある実施形態に従うと、管理者は、クラウドインフラストラクチャ環境内においてコンパートメントを管理することができる。

ある実施形態に従うと、タグを、コンパートメント内のリソースに適用することができる。タグは、例えば、事業ニーズスキーマなどのスキーマに従ってリソースを編成するために用いることができる。タグはリソースの作成時にリソースに適用されることができ、またはタグは既存のリソース上で更新されることができる。リソースの各々に関連付けられるタグは、例えば、概してリソース１４０に関連付けられるリソースタグ１４０ａ（図１）、コンピュータリソース１５０に関連付けられるコンピュータリソースタグ１５０ａ、ネットワークリソース１６０に関連付けられるネットワークリソースタグ１６０ａ、およびストレージリソース１７０に関連付けられるストレージリソースタグ１７０ａを含んでもよい。

ある実施形態に従うと、コンパートメントは、クラウドインフラストラクチャの構築および編成にとって重要である。リソースをコンパートメント間で移動させることができ、（例えば、ユーザインターフェイスを介して）表示し、現在のリージョン内でコンパートメントによって編成することができる。リソースで作業し、およびリソース管理する場合、まずコンパートメントを選択することができる。

ある実施形態に従うと、コンパートメントはテナンシ幅であり、リージョンに跨がることができる。コンパートメントが作成されると、コンパートメントは、テナンシが加入されるあらゆるリージョン内で利用可能にされることができる。

ある実施形態に従うと、コンパートメントを削除することができる。コンパートメントを削除するために、コンパートメントは、削除に先立って、その中のすべてのリソースを除去されることができる。

ある実施形態に従うと、コンパートメントを削除するアクションは、非同期とすることができ、ワーク要求を開始する。コンパートメントの状態は、ワーク要求の実行中に「削除」に変わる。ワーク要求が失敗した場合、コンパートメントは削除されず、アクティブ状態に戻る。

ある実施形態に従うと、クラウドインフラストラクチャ環境内に作成される各コンパートメントは、あるプロパティを有することができる。例えば、各コンパートメントに、一意の識別子（ＩＤ）を割り当てることができ、加えて、随意に、変更可能な記述および名前を提供することができる。ある実施形態に従うと、サブコンパートメントは、ベースコンパートメントの下に階層的に定義することができる。

ある実施形態に従うと、コンパートメントおよびサブコンパートメントに対するアクセスならびに制御は、管理者または充分なクレデンシャルを有する他のユーザに限定することができる。クレデンシャルは、異なるレベルのコンパートメントアクセスに関連付けることができる。例えば、管理者は、すべてのコンパートメントを閲覧し、およびそれらにアクセスし、ならびにテナンシの任意のコンパートメント内のリソースで作業する許可を有することができるが、アクセスがより制限されたユーザは、そのようなレベルのアクセスおよび制御を有さない。

図３は、一実施形態による、クラウドインフラストラクチャリージョンに跨がるポリシー管理および制御のためにコンパートメント３６０、コンパートメントポリシー３６５、サブコンパートメント３７０、およびサブコンパートメントポリシー３７５の間の関係を示すクラウドインフラストラクチャ環境３００を示す。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境のインスタンスは、クラウドインフラストラクチャリージョン３２０、３３０、３４０、３５０などの異なるリージョンにおいてホストされ得る。これらは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク３０２を介して顧客ネットワーク３０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク３０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、図には示されていないが、各クラウドインフラストラクチャリージョンはいくつかのサービスを含み得、各サービスは、管理サービス、計算サービス、ストレージサービス、エッジサービス、ネットワークサービス、および物理インフラストラクチャなどのいくつかのリソースを含む。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、リージョンにわたって利用可能ないくつかのサービスがある。これらは、例えば、管理サービス、計算サービス、ストレージサービス、エッジサービス、およびネットワークサービスを含む。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ３０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメント３６０がテナンシコンパートメントの下のレベルであり、サブコンパートメント３７０がコンパートメント３６０の下の追加の層であるように、階層的態様で編成することができる。ある実施形態に従うと、各コンパートメントは、コンパートメントポリシー３６５およびサブコンパートメントポリシー３７５などの１つ以上のコンパートメントポリシーに関連付けることができる。テナントコンパートメントポリシーは、図に示されていない。

ある実施形態に従うと、コンパートメントまたはサブコンパートメント、たとえばコンパートメント３６０およびサブコンパートメント３７０の作成中、作成時、または作成後に、コンパートメントポリシー３６５およびサブコンパートメントポリシー３７５などのポリシーを、各コンパートメントおよびサブコンパートメントについて記述／作成することができる。ポリシーが適所にない場合、コンパートメントおよび／またはサブコンパートメントへのアクセスは、テナンシ３０５レベルにおいて許可を有するユーザに制限され得る。

ある実施形態に従うと、コンパートメント内におけるコンパートメント（すなわち、サブコンパートメント）の作成時に、サブコンパートメントは、その階層の上位のコンパートメントからアクセス許可を継承する。

ある実施形態に従うと、コンパートメントまたはサブコンパートメントポリシーを作成すると、そのポリシーは、それがどのコンパートメントにアタッチするかを示す仕様を含み得る。そのような仕様は、ポリシーのサブシーケンス制御、修正、または削除のためのアクセスを制限する制御を含み得る。いくつかの実施形態では、ポリシーは、テナンシ、親コンパートメント、またはポリシーが向けられる特定のコンパートメントにアタッチされ得る。

ある実施形態に従うと、新たなリソースをコンパートメントに配置することができる。これは、新たなリソースの作成時にターゲットとされるコンパートメントを指定することによって達成することができる（コンパートメントは、リソースを作成するために必要な情報の１つである）。これは、コンソールインターフェイスを介して達成することができる。

ある実施形態に従うと、既存のリソースを異なるコンパートメントに移すこともできる。ほとんどのリソースは、それらが作成された後に移動され得る。あるコンパートメントから別のコンパートメントに移動することができないリソースは少数である。

ある実施形態に従うと、いくつかのリソースはアタッチされたリソース依存関係を有し、いくつかはアタッチされたリソース依存関係を有さない。親リソースが移動するとき、すべてのアタッチされた依存関係が同じように振る舞うわけではない。

ある実施形態に従うと、いくつかのリソースについて、アタッチされた依存関係は親リソースとともに新たなコンパートメントに移動する。親リソースは直ちに移動するが、場合によっては、アタッチされた依存関係は非同期的に移動し、移動が完了するまで新たなコンパートメント内においては可視ではない。

ある実施形態に従うと、他のリソースについては、アタッチされたリソース依存関係は新たなコンパートメントには移動しない。このようなアタッチされたリソースは、独立して移動させることができる。

ある実施形態に従うと、リソースが新たなコンパートメントに移動された後、その新たなコンパートメントを管理するポリシーが即座に適用され、そのリソースへのアクセスに影響を与える。コンパートメント編成の構造に応じて、メータリング、課金、および警報も影響を受ける可能性がある。

ある実施形態に従うと、作成後、コンパートメントを、たとえば同じテナンシ内の異なる親コンパートメントに移動させることができる。コンパートメントを移動させると、コンパートメントのコンテンツ（サブコンパートメントおよびリソースを含む）のすべてがコンパートメントとともに移動する。

図４は、ある実施形態に係る、クラウドインフラストラクチャ環境内でのコンパートメント移動のためのシステムを示す図である。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境４００のインスタンスは、異なるリージョンにおいてホストされ得る。テナ
ンシ４０５、コンパートメントＡ４６０およびコンパートメントＢ４７０などのコンパートメントは、クラウドインフラストラクチャ環境内に画定することができ、これらのコンパートメントは、リージョンに跨がることができる。そのようなコンパートメントは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク４０２を介して顧客ネットワーク４０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク４０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ４０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメントＡ４６０およびコンパートメントＢ４７０がテナンシコンパートメントの下のレベルであり、サブコンパートメントＡ４６５がコンパートメントＡの下に画定され、サブコンパートメントＢ４７５がコンパートメントＢの下に画定されるように、階層的様式で編成することができる。ある実施形態に従うと、各コンパートメントは、１つ以上のコンパートメントポリシー（図示せず）に関連付けることができる。

ある実施形態に従うと、たとえばテナンシ内に画定されたコンパートメントは、たとえばコンパートメントまたはサブコンパートメントを再画定することによって移動させることができる。

ある実施形態に従うと、コンパートメントを移動させるために、充分な許可を有する要求を受け取ることができる。すなわち、当該要求は、例えば、現在のコンパートメントおよび移動コンパートメントの宛先コンパートメントに対する最も低い層で共有された親コンパートメントに関する「全リソース管理」許可を有するグループに属するユーザからの要求である。

すなわち、例えば、サブコンパートメントＡ４６５をコンパートメントＡ４６０からコンパートメントＢ４７０に移動する（４６５から４７６に移動する）要求は、ユーザから充分な許可とともに受信されなければならない。テナンシ４０５は、送信元コンパートメントであるコンパートメントＡ４６０および宛先コンパートメントであるコンパートメントＢ４７０の両方の最も低い層で共有された親コンパートメントであるため、図に示されるように、サブコンパートメントＡを移動させる要求は、テナンシ４０５のコンパートメント内で「全リソースを管理する」許可を有するユーザから受信されなければならない。

ある実施形態に従うと、別の例では、サブコンパートメントＡ４６５をコンパートメントＡからコンパートメントＢに移動させる要求が、コンパートメントＡ内の「全リソースを管理する」許可のみを有するユーザから受信された場合、その要求は失敗し得、なぜならば、ユーザからの要求は、宛先コンパートメント、すなわちコンパートメントＢ内のリソースを管理することができないからである。

ある実施形態に従うと、コンパートメントを新たな親コンパートメントに移動させると、新たな親コンパートメントのアクセスポリシーが有効となり、前の親コンパートメントのポリシーはもはや適用されない。場合によっては、階層を指定するポリシーとともに入れ子にされたコンパートメントを移動させるとき、それらのポリシーは整合性を保証するために自動的に更新され得る。

したがって、ある実施形態によると、以前にサブコンパートメントＡに適用されたコンパートメントＡ４６０のコンパートメントポリシーは、サブコンパートメントＡのコンパートメントＢへの移動にはもはや適用されないであろう。次いで、コンパートメントＢのコンパートメントポリシーが、代わりにサブコンパートメントＡに適用される。これは、以下の図でさらに説明される。

図５は、クラウドインフラストラクチャ環境内のコンパートメント移動中のポリシー管理および施行のためのシステムを示す。

一実施形態によれば、より具体的には、図５は、コンパートメントが移動されるコンパートメント階層と、異なるポリシーに関する結果とを示す。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境５００のインスタンスは、異なるリージョンにおいてホストされ得る。テナンシ５０５、コンパートメントＡ５６０およびコンパートメントＢ５６５、ならびにコンパートメントＤ５６６等のコンパートメントは、クラウドインフラストラクチャ環境内で画定することができ、これらのコンパートメントは、リージョンに跨がることができる。そのようなコンパートメントは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク５０２を介して顧客ネットワーク５０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク５０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ５０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメントＡ５６０がテナンシの下のレベルであるように、階層的に編成することができる。次いで、コンパートメントＢ５６５およびコンパートメントＤ５６６は、コンパートメントＡ５６０の下のさらに別のレベルとして編成されるが、サブコンパートメントＣ５７０は、最初はコンパートメントＢの下のレベルとして示される。ある実施形態に従うと、各コンパートメントは、コンパートメントＢポリシー５８２、コンパートメントＡポリシー５８０、およびコンパートメントＤポリシー５８３などの１つ以上のコンパートメントポリシーに関連付けることができる。そのようなポリシーは、例えば、コンパートメントへのアクセスのためのユーザ／クライアント許可、ならびに任意の所与のコンパートメント内のリソースへのアクセスおよびそれらリソースの制御のための許可を管理することができる。上述のように、コンパートメントポリシーは、コンパートメントＢ５６５にアクセスするユーザが、コンパートメントＡポリシー５８０に加えてコンパートメントＢポリシー５８２によって管理／制限されているコンパートメントＢ５６５との対話を有するように、互いに追加（すなわち「スタック」）することができる。

ある実施形態に従うと、たとえば、コンパートメントＢポリシー５８２が、あるグループ、グループ１がコンパートメントＡ－Ｂ内のインスタンスファミリーを管理することを可能にすると仮定する（コンパートメント階層は、コンパートメントＡのサブコンパート
メントであるコンパートメントＢを含む）。

ある実施形態に従うと、コンパートメントＤポリシー５８３は、別のグループ、グループ２がコンパートメントＡ－Ｄ内のインスタンスファミリーを管理することを可能にすることも仮定する（コンパートメント階層は、コンパートメントＡのサブコンパートメントであるコンパートメントＤを含む）。

ある実施形態に従うと、コンパートメントＣがコンパートメントＢからコンパートメントＤに移動されると、グループ１のメンバーは、もはやコンパートメントＣ内のインスタンスファミリーを管理することはできず、グループ２のメンバーが、今度は、コンパートメントＣ内のインスタンスファミリーを管理することができる。

ある実施形態に従うと、ある状況において、コンパートメントを移動させると、あるポリシーを自動的に更新することができる。例えば、移動されるコンパートメントまでのコンパートメント階層を指定するポリシーは、ポリシーが現在のターゲット親の共有先祖にアタッチされると、自動的に更新され得る。

再び図５を参照すると、例えば、一実施形態によれば、コンパートメントＡポリシーは、あるグループ、グループＸのメンバーがコンパートメントＢ：Ｃ内のバケットを管理することを可能にすると仮定する。コンパートメントＣをコンパートメントＤに移動すると、コンパートメントＢとコンパートメントＤとの間の共有先祖（コンパートメントＡ）のため、コンパートメントＡポリシーは、グループＸのメンバーがコンパートメントＤ：Ｃ内のバケットを管理することを可能にするように、自動的に更新され得る。

ある実施形態に従うと、テナンシにアタッチされたポリシーは同様に、コンパートメントがテナンシ内を移動すると、自動的に更新されることができる。

しかしながら、ある実施形態に従うと、コンパートメントの移動で、すべてのポリシーが自動的に更新されるわけではない。例えば、図５を参照すると、コンパートメントＣがコンパートメントＢからコンパートメントＤに移動される状況において、コンパートメントＢポリシーは、（移動前に）コンパートメントＣ内のバケットの管理を可能にすると仮定する。コンパートメントＣが移動される場合、コンパートメントＢポリシーは自動的に更新されない。代わりに、ポリシーは、もはや有効ではなく、（例えば、手動または自動で）除去され得る。

タグベースのリソース制限／割り当て
ある実施形態に従うと、クラウド管理者は一般に、既存のクラウドにおけるリソース使用を制限する能力を有していない。ユーザにリソースを作成するための許可を与えることにより、ユーザは、事前定義されたアカウント限度まで任意の数のリソースを作成することが可能になる。タグベースのリソース制限または割り当ては、コンパートメント内でリソースを作成または使用する能力に、微調整されたコスト制御を可能にする適切なレベルへの制限を課すことを可能にする。

ある実施形態に従うと、顧客は、アカウント作成時にクラウドインフラストラクチャ環境によって定義されるサービスレベル制限を割り当てられることができる。これらのサービスレベル制限は、顧客がテナンシ全体にわたって（例えば、複数のコンパートメントを伴う複数のリージョンにわたって）作成することができるリソースの総数を制限する。テナンシおよびコンパートメント管理者は、タグベースのリソース制限または割り当てを利用して、リソース固有の厳しい制限を設定することができる。個々のリソースに対するそのようなコンパートメント制限がなければ、インスタンスを起動することを承認されたユ
ーザは、テナンシ全体においてすべての利用可能な容量を消費し得る。タグベースのリソース制限または割り当ては、この問題を解決し、サービス制限とは異なり、例えば、コンソール、ＳＤＫ、またはＡＰＩを介して、クライアントおよび顧客によって設定およびカスタマイズされる。タグベースのリソース制限または割り当ては、サービス制限の上に適用され、ネスト化されたコンパートメント階層を通じて継承され得る。これは、クラウド管理者がリソース消費を制限し、許容可能なリソース使用の周りに境界を設定することを可能にする。

ある実施形態に従うと、タグベースのリソース制限または割り当ては、テナントおよびコンパートメント管理者に、クラウドインフラストラクチャ環境においてリソースがどのように消費されるかをよりよく制御させ、管理者が、たとえばコンソール、ＳＤＫ、もしくはＡＰＩを用いて、ユーザまたはユーザのグループにリソースを容易に割り当てることを可能にする。コンパートメント割り当ては、テナント内でのクライアントの支出を管理するための強力なツールセットである。

ある実施形態に従うと、クライアントがテナンシにおいて複数のコンパートメントにわたってリソース（例えば、インスタンス、ＶＣＮ、ロードバランサ、およびブロックボリューム）を有する場合、特定の目的のために用いられるリソースを追跡すること、またはそれらを集約すること、それらについて報告すること、もしくはそれらについてバルクアクションをとることは困難になり得る。タグ付けは、クライアントがキーおよび値を定義し、それらをリソースに関連付けることを可能にする。タグは、リソースの編成およびリスト化を支援するために用いることができる。一般に２種類のタグ、すなわち自由形式タグおよび定義済みタグがあるが、例示的な実施形態によれば、他のタイプのタグも可能である。

ある実施形態に従うと、自由形式タグはキーおよび値からなることができる。例えば、「環境：制作」は自由形式タグの例であり、「環境」はキーであり、「制作」は値である。複数の自由形式タグを単一のリソースに適用することができる。

ある実施形態に従うと、定義済みタグは、自由形式タグよりも多くの特徴および制御を提供する。クライアントが定義済みタグキーを作成する前に、定義済みタグに対してタグ名前空間を設定することができる。名前空間は、タグキーのセットのためのコンテナと考えることができる。定義済みタグは、誰があなたの定義済みタグを適用することができるかに対する制御を可能にするポリシーをサポートする。タグ名前空間は、クライアントがポリシーを適用することができるエンティティである。

ある実施形態に従うと、定義済みタグをリソースに適用するために、ユーザはまずタグ名前空間を選択し、次いで名前空間内でタグキーを選択し、次いでユーザは値を割り当てることができる。管理者は、どのグループのユーザが各名前空間を用いることを許されるかを制御することができる。例示的な実施形態によれば、タグは、リソースが作成される際にリソースに適用されてもよい。別の実施形態では、タグは、リソースがプロビジョニングされた後にリソースに適用されてもよく、それによって、タグを用いるシステムにおけるリソース割り当てまたは制限の遡及的実施を可能にする。ある実施形態に従うと、タグを用いて、コスト管理および／またはリソース管理を可能にすることができる。このように、タグは、コストを追跡するために用いられ得る。

図６は、一実施形態による２つの定義済みタグを示す。２つのタグ名前空間、名前空間１ ６００および名前空間２ ６２０（例えば、名前空間１は「営業」であり得、名前空間２は「人事」であり得る）が設定される。タグキー６０５，６１０，６２５，および６３０は、名前空間において定義される。各名前空間内では、タグキーは一意であり得るが
、タグキー名は名前空間にわたって繰り返され得る。例えば、両方の名前空間は、「環境」と名付けられたキーを含むことができる。

ある実施形態に従うと、多くのクラウドプロバイダは、容量不足からの保護のためにサービス制限を設ける。しかしながら、多くの場合、クライアントは、自分自身がリソース過剰にならないように制限を設定することも望む。１つのそのようなアプローチは、グループレベルで制限を指定することである。グループは、ユーザ、リソース、またはユーザが指定したい任意のもののセットを含むことができる。グループレベル制限は、特定のテナンシ／アカウントの管理者／ユーザによって設定される。

ある実施形態に従うと、一例として、テナンシ管理者またはグループ管理者は、それらのクラウドコストを制御するために、グループレベルで制限を構成することができる。これは、クラウドリソースが、特定のグループ内で作成されるリソースと関連付けられるドルコストに変換される使用データを放出する際に、そのグループが、テナンシまたはアカウント管理者によって設定される使用制限を超えないことの保証を、顧客／会社に与える。この意味で、グループは、コストセンターグループと考えることができ、なぜならば、そのグループのメンバーによって作成されるリソースのクラウドコストのすべてが、単一の集約された一括料金として顧客／会社に割り当てられたり、または単一のグループアカウントに対して集約されるなどするからである。

しかしながら、ある実施形態によれば、管理者がコストを制御するための非常に単純な機構が存在するため、問題が存在する。例として、管理者は、特定のグループを含むかまたはリソース過剰から除外することができ、または管理者は、アクセスを拒否することによってリソースを作成する特定のユーザを除外することができる。しかしながら、これらは粒度の粗い機構であり、顧客は概して、彼らのクラウドリソースを管理するための柔軟性およびより良好な制御を彼らに与える細かい粒度の機構を指定する能力を有しているというわけではない。

ある実施形態に従うと、細かい粒度のアプローチは、タグに基づいてリソース制限を設けることができ、特定のグループの１人以上のメンバーによってプロビジョニングされ得るリソースのすべてが、そのグループを表すコストセンタータグに関連付けられるか、またはさもなければコストセンタータグを提供される。この性質のコストセンタータグは、リソース管理における使用のための機構を提供し、クラウドプロバイダは、コスト管理のためにもそれらを用いる。システムおよび方法は、タグを通してグループレベルでコストを制御するための機構を作成することができる。例として、ユーザは、以下のような細かい粒度のルール／ポリシーを指定することができる：
Set limits <resource type> to 10 in group A where target.resource.tag = “finance”
（制限＜リソースタイプ＞をグループＡにおいて１０に設定し、ターゲットリソースタグ＝「財務」である）
ある実施形態に従うと、タグはリソースに関連付けることができ、上記アプローチを用いて、タグは、顧客をグループレベルでリソース過剰から保護することができる。上記の例では、タグ値がグループＡにおいて「財務」である場合、ユーザメンバーは、＜リソースタイプ＞の１０を超えるインスタンスを作成することはできないことになる。グループレベルでコストを制限するこのアプローチは、コストおよびリソース使用をより良く管理するために、細かい粒度の機構をクライアントに提供する。

ある実施形態に従うと、システムは、クラウドインフラストラクチャ環境において、リソース要求コンテキストタグベースの限度／割り当てを設ける。システムは、要求コンテキストに基づいてクラウドインフラストラクチャ環境におけるリソースのプロビジョニン
グを制限するかまたはそれに割り当てを課すための方法を実行する。

ある実施形態に従うと、システムは、クラウドインフラストラクチャ環境においてタグベースのリソース制限／割り当てを設ける。システムは、リソースタグに基づいてクラウドインフラストラクチャ環境においてリソースをプロビジョニングすることを制限するかまたはそれに割り当てを課すための方法を実行する。

ある実施形態に従うと、高度にセキュアな環境では、顧客は、リソースおよび顧客のデータへのアクセスをセキュリティ保護したいと望む。例として、顧客は、彼らのリソースを、高機密性、機密性、制限付き、公開などとして分類することによって保護し、ユーザに対して、制約に従ったユーザのクリアランスに基づいて、アクセスを許可する。分類されたリソース／データへのアクセスを有するユーザは、情報漏洩がないことを確実にし、共有コンテキスト内においてデータ分類にわたるリソースへの不注意による変更を回避するために、データにアクセスする際に極めて慎重である必要がある。本明細書の実施形態は、ユーザが、所与のセッション／コンテキストについてデータ分類境界内においてアクセスを制限するかまたはリソースを修正することを可能にするための改善されたシステムおよび方法を提供するが、ユーザは、そうでなければ、より高いアクセスを有し得る。

ある実施形態に従うと、クラウドアーキテクチャは、ユーザを役割内に投入することにより、ルール（役割）をベースとしたアクセス制御技術を用いて、特定のセキュリティ境界へのアクセスを制限／許可することができる。しかしながら、これらの技術は粗粒化されている。実施義務は、ユーザがアクセスしている、修正している、または実行しているものについて、ユーザが入念かつ慎重であることにある。

ある実施形態に従うと、本開示のシステムおよび方法は、ユーザが意図しないときにある動作を実行するようリソースにアクセスすることからユーザを保護する。一例は、ユーザが高度に分類されたリソースへのアクセスを有するときに他の分類のデータにアクセスすることである。例えば、ユーザが、高度に分類されたリソースをフィルタリングで除去することによって、分類されていないリソースにアクセスすることのみを必要とするスクリプトを有すると仮定する。ここで、ユーザ／スクリプトは、どのデータ／リソースが分類され、どのデータ／リソースが分類されないかを知らなければならない。

ある実施形態に従うと、別の例は、ユーザが、事業の終了後にビジネスクリティカルではないインフラストラクチャをシャットダウンすることにのみ関心があり、ビジネスクリティカルである他のリソースは稼働させ続けることを望む場合である。ここで、ユーザは、どのインスタンスをオフにすべきかを正確に知らなければならない。

ある実施形態に従うと、本明細書のシステムおよび方法は、そのような問題に対する解決策を、リソースに対する１つ以上の要求に添付されるタグを介して提供する。スクリプトからの要求は、ユーザの代わりに、例えば、インスタンスをシャットダウンすること、リソースの詳細を読み出すこと、リソースを更新すること、分類されたリソースにアクセスすること等の動作を実行する。ユーザは、これらの要求を、要求コンテキストに添付された１つ以上のタグとともに送信する。要求がリソース上でアクションを実行するとき、要求コンテキストからのこれらのタグを検査することができ、次いで、たとえユーザが、最初は、ユーザが実行したい動作を実行するためのアクセスを有していたとしても、その動作を実行するためのアクセスを拒否または許可することができる。これは、ユーザがその特定のリソースに対して意図しなかった操作を行うことによる、高度に分類されたデータまたはリソースへの意図しないアクセスを回避する。これは、タグベースの自動化に該当し得る。それは、セキュリティに関連する分野だけでなく、多種多様な使用例に対応することができる。

ある実施形態に従うと、リソース要求コンテキストを表すタグを用いることにより、要求を送信することによってリソースにアクセスする際に、タグを介してセキュリティ境界を形成することができる。

ある実施形態に従うと、ある動作を実行するためにユーザがリソースにアクセスしたい場合、ユーザは一般にソフトウェア開発キットを介して呼び出しを行うことができるか、またはＡＰＩ呼び出しを直接行うことになる。ユーザは、リソースに送信される要求に追加される１つ以上のタグを渡すことができる。ユーザを承認している間、リソースインプリメンテーションは、要求に関連付けられるタグを検査することができ、タグがユーザタグと一致する場合、要求は許可され、そうでない場合には、要求は拒絶／拒否される。

図７は、例示的な実施形態による、たとえばリソースタグおよび／またはリソース要求コンテキストタグを含むタグに基づいてクラウドインフラストラクチャ環境においてリソースに対する割り当てまたは制限を実施するシステムにおいてインスタンスを起動するユーザのためのアーキテクチャフローを示す。

ある実施形態に従うと、ステップ１において、ユーザ７０１は、リージョン７００においてインスタンスを起動するように要求し、この要求は、リージョン７００内で規定される１つ以上のタグ（例えば、自由形式タグまたは定義済みタグ）に関連付けられる。例示的実施形態では、タグは、リソースに対するユーザからの要求のコンテキストを表す。

ある実施形態に従うと、ステップ２において、ロードバランサ７２０は、パブリックプロキシＡＰＩ７２５のようなＡＰＩに要求を転送する。

ある実施形態に従うと、ステップ３において、ＡＰＩは、アイデンティティデータプレーン７３５において認証を実行する。

ある実施形態に従うと、ステップ４において、インスタンスを起動する要求を、計算制御プレーン（ＣＣＰ）７３０に転送することができる。次いで、ＣＣＰは、ステップ５において、アイデンティティデータプレーンにおいて要求をさらに認証することができる。

ある実施形態に従うと、ステップ６において、計算制御プレーンは、ユーザ７０１からの要求の一部であるタグに関連付けられるすべてのタグベースの制限／割り当て７５０を制限サービスデータプレーン７４０からフェッチすることができる（代替的に、フェッチ動作は、リソース制御プレーンにおいて実行され得る）。そのようなタグベースの割り当ては、例えば、テナンシ全体にわたって適用することができ、コンパートメント固有である必要はない。

ある実施形態に従うと、ステップ７において、計算制御プレーンは、７５０において、要求された使用が任意のものに対するタグベースの制限／割り当てのいずれかに違反するかどうかをチェックすることができる。要求された使用がいかなるコンパートメント割り当てにも違反しない場合、要求は、例えばデータベース７４５に処理されることができる。要求された使用がコンパートメントツリーに沿ったタグベースの制限／割り当てのいずれかに違反する場合、要求はドロップされ得、ユーザに通知すべくメッセージが送信され得る。

ある実施形態に従うと、タグベースの制限／割り当ては、たとえばテナンシがテナンシ内における有効化されたコンパートメントであるすべてのリージョンを含むテナンシ全体にわたって適用される。要求されたインスタンスがタグベースの制限／割り当てに違反す
るかどうかを判断するとき、ＣＣＰは、新たな要求が、例えばサービス開発者キット（ＳＤＫ）を介して、割り当てのいずれにも違反しないことを保証することができる。要求が割り当てを超える場合、ＣＣＰは要求を落とすことができる。

ある実施形態に従うと、ＣＣＰのＳＤＫは、クラウドインフラストラクチャ環境のすべての制御プレーンに存在し得る。

ある実施形態に従うと、ＣＣＰは、制限サービスデータプレーンと連携して、新たな要求をタグベースの制限／割り当てに対してチェックすることができる。

ある実施形態に従うと、クライアントがクラウドリソースを作成する動作をトリガすると、要求はリソース制御プレーンに進む。リソース制御プレーンは、グループレベルで構成された制限を考慮して、リソースが安全にスピンアップされ得るかどうかを知るべく、制限サービスから尋ねる。制限サーバがリソース制御プレーンに否定／失敗応答を返す場合、リソースは作成されない。

内部的に、制限サービスが要求を受信すると、制限サービスは、リソース作成に関連付けられるタグをチェックし、その特定のタグを有するリソースの現在の使用を見るために、ストアもしくはデータベースまたはメモリを参照する。タグ値がグループレベルで設定された制限を超える場合、リソース生成が失敗するようにリソース制御プレーンに失敗／否定応答を送信する。

リソース制限／割り当てのためのタグの使用
図８は、クラウドインフラストラクチャ環境におけるリソースのプロビジョニングなどの使用を制限するために要求コンテキストタグおよび／またはリソースタグを用いるシステムを示す。

ある実施形態に従うと、クライアントデバイス８１０は、クラウドインフラストラクチャ環境に要求８１１を提出することができ、要求は、たとえば要求のコンテキストを表すタグなどのタグ８１２に関連付けられる。クライアントデバイスは、コンソール８０２、ＡＰＩ８０４、またはＳＤＫ８０６等のインターフェイスのうちの１つを介して、（デバイスハードウェア８０１上で動作する）クラウドインフラストラクチャ環境８００に要求を提出することができる。

ある実施形態に従うと、要求はリソース８４０に転送され得、これは、タグ付けされたリソース８５１～８５４を含む計算リソース層８５０、タグ付けされたリソース８６１～８６４を含むネットワークリソース層８６０、およびタグ付けされたリソース８７１～８７４を含むストレージリソース層８７０など、（上述したように）いくつかの層を含み得る。

ある実施形態に従うと、クライアントデバイスが高いセキュリティ／優先度特権（たとえば不正保護、またはインテリジェンス）を享受する場合、クライアントデバイスは、要求に関して広範囲のタグを利用することができる。例として、要求に関連付けられるタグは、ユーザが保護されたリソースに誤って触れることから助けるために用いられ得る。例えば、コストを節約するために、特定の計算リソースを毎日午後６時以降にシャットダウンすることができると仮定する。そのような計算リソースは、低セキュアなタグを有する。しかしながら、同じシステムは、シャットダウンすることができない他の計算リソースも有する（２４／７で実行されなければならない）。そのような計算リソースは、高セキュアなタグを有する。低特権計算リソースをシャットダウンするために、ユーザは、タグ付けされた要求を有することなく、各リソースに進み、シャットダウンされるべきリソー
スのみを選択するか、またはそうするようスクリプトを書いて、２４／７を実行する必要がある高特権リソースをシャットダウンすることを回避するようにしなければならないであろう。これは、計算リソースが毎日追加および除去され得るため、これを維持することが困難である。

ある実施形態に従うと、ユーザは代わりに、タグ付けされた要求を提供して低特権リソースをシャットダウンすることができる。すなわち、要求に関連付けられるタグは、午後６時にシャットダウンされ得る計算リソースと、低セキュアなタグを共有するであろう。次いで、タグは、ネットワーク内のすべてのリソースに進むことができるが、要求が有するタグを有さない高度に保護されたリソースはバイパスすることになる。このように、計算リソースをシャットダウンするタグ付き要求は、低セキュアなタグが一致する計算リソースのみをシャットダウンし、高セキュアなタグ付き計算リソースはバイパスした。

ある実施形態に従うと、別の例として、クライアント８１０が高度にセキュアな計算インスタンスをブロックボリュームにアタッチすることを望むと仮定する。そのような状況では、高度にセキュアな計算インスタンスをアタッチする要求は、高セキュアなタグでタグ付けされ得る。次いで、そうすることによって、これは、高度にセキュアな計算インスタンスが、より低セキュアなタグを有するブロックボリュームにアタッチされないことを保証することができ、代わりに、要求は、高度にセキュアな計算インスタンスを、同様にタグ付けされた（高度にセキュアな）ブロックボリュームにアタッチすることしかできない。言い換えれば、要求は、高度にセキュアな計算を低セキュアなブロックボリュームにアタッチしない（タグチェックは失敗することになる）。

要求コンテキストタグベースの制限／割り当て
図９は、一実施形態による、クラウドインフラストラクチャ環境においてリソース要求タグベースの制限／割り当てを設けるシステム９００の機能概略図である。概して、クライアントデバイス８１０（図８）は、複数のタグ付けされたリソース９４０の中で新たなリソースをプロビジョニングするための要求９１１をクラウドインフラストラクチャ環境に提出することができる。複数のタグ付けされたリソース９４０は、例えば、計算リソース層８５０のタグ付けされた計算リソース８５１～８５４、ネットワークリソース層８６０のタグ付けされたネットワークリソース８６１～８６４、および／またはストレージリソース層８７０のタグ付けされたストレージリソース８７１～８７４のいずれかであり得る。

例示的実施形態によると、リソースは、クラウドインフラストラクチャ環境においてプロビジョニングされるアイテムであり、例えば、いくつか例を挙げると、計算リソースタイプ、ストレージサービスリソースタイプ、ＶＣＮサービスタイプ、ＩＰアドレスサービスタイプ、ＤＮＳサービスタイプ、ＤＤｏＳサービス保護タイプ、および電子メール配信サービスタイプを含み得る、種々のタイプであり得る。本明細書における例示的な実施形態は、これらの特定のリソースタイプに限定されず、他のタイプも含み得、さらなるリソースタイプの例が、例として以下で言及される。

例示的な実施形態によれば、プロビジョニングされるリソースおよびサービスはタグ付け可能である。例示的実施形態では、リソースに対する要求およびリソースは、１つ以上のタグと関連付けられる。加えて、リソースは、それらのタグ値に基づいてグループ化され得る。本質的に、例示的実施形態では、各プロビジョニングされたリソースと関連付けられるリソースタグは、クラウドインフラストラクチャ環境においてプロビジョニングされたリソースにアタッチされ得るか、または別様にそれらに関連付けられ得る、キー値ペアである。タグキー値ペアは、例えば、様々な会計目的を含む多くの目的のために用いられ得る。ある例では、プロビジョニングされたリソースに関連付けられるリソースキー値ペアタグは、リソースをグループ化するために用いられ、リソースタグによって提供されるグループ化は、クラウドインフラストラクチャ環境における値のすべてのコスト管理および／またはリソース管理を可能にする。

クラウドインフラストラクチャ環境においてプロビジョニングされるリソースは、各リソースに割り当てられたタグ値に基づいて、または必要もしくは所望に応じて他の基準に基づいて、コンテナ９４２、９４４、９４６にグループ化されてもよい。例として、第１のコンテナ９４２は、クラウド内でプロビジョニングされ、クライアントユーザ７０１（図７）の会計グループと関連付けられる計算リソースおよびストレージリソースを記憶し得、第２のコンテナ９４４は、クラウド内でプロビジョニングされ、クライアントユーザ７０１の営業グループと関連付けられる計算リソースを保持し得、第３のコンテナ９４６は、クラウド内でプロビジョニングされ、クライアントユーザ７０１の人事グループと関連付けられる計算リソースを保持し得る。本明細書における例示的な実施形態は、これらのグループに限定されず、他のグループも同様に用いることができ、さらなる例示的なグループを例として以下に示す。

ある例に従うと、リソースインスタンスは、異なるコンテナ９４２、９４４、９４６に論理的に配置され、それにより、別々のコストセンターを提供し、各コストセンターにはタグ値が割り当てられ、エンドユーザは、さまざまなコストセンターへのアクセスについて請求され得、コストセンターのタグは、コスト管理および課金のために用いられる。一
部の顧客は、彼らのエンドグループ価格内で複数のコストセンターをモデル化し得る。各コストセンターに対して別個のタグが存在してもよく、クラウドは、各タグに対して、限定されたリソースのセットを割り当ててもよい。

例示的実施形態では、１つ以上のポリシー９２０は、エンドユーザがアクセスについて標準契約で許可されるよりも多くのリソースにアクセスすることから自身を保護するための機構を提供し、実質的過剰は、エンドユーザが標準契約の標準契約条件下で許可されるよりも多くのリソースにアクセスすることによって生じ得る。例えば、顧客は、リソース制御プレーン９３０を介して、例えば、１００個の計算リソース等の複数の計算リソースのプロビジョニングをアクティブにする、リソースに対する要求を送信し得、契約条件は、標準レートで９０個のコンピュータリソースのプロビジョニングのみを許可しており、過剰分が、この実施例では１０が、顧客エンドユーザに対して追加費用を招く。

上述したように、そしてある実施形態に従うと、細かい粒度のアプローチは、タグに基づいてリソース制限を設けることができる。タグは、主にリソース管理において用いられる機構であり、クラウドプロバイダはそれらをコスト管理のためにも用いる。システムおよび方法は、タグを通してグループレベルでコストを制御するための機構を作成することができる。例として、ユーザは、以下のような細かい粒度のルール／ポリシーを指定することができる：
Set limits <resource type> to 10 in group A where target.resource.tag = “finance”
（制限＜リソースタイプ＞をグループＡにおいて１０に設定し、ターゲットリソースタグ＝「財務」である）
ある実施形態に従うと、タグは、リソースおよびリソースの要求またはその両方に関連付けることができ、上記アプローチを用いて、タグは、たとえばグループレベルなどの１つ以上の選択されたレベルで顧客をリソース過剰から保護することができる。上記の例では、タグ値がグループＡにおいて「財務」である場合、ユーザメンバーは、＜リソースタイプ＞の１０を超えるインスタンスを作成することはできないことになる。グループレベルでコストを制限するこのアプローチは、コストおよびリソース使用をより良く管理するために、細かい粒度の機構をクライアントに提供する。

例示的な実施形態によれば、第１のポリシー９２２は、第１のコンテナ９４２においてグループ化されたリソースについてグループレベルで顧客をリソース過剰から保護する。同様に、第２のポリシー９２４は、第２のコンテナ９４４においてグループ化されたリソースについてグループレベルで顧客をリソース過剰から保護し、第３のポリシー９２６は、第３のコンテナ９４６においてグループ化されたリソースについてグループレベルで顧客をリソース過剰から保護する。

ある例に従うと、リソース要求９１１ａ～９１１ｄの各々は、要求されているリソースインスタンスのタイプを表すデータ（リソースタイプ）と、要求されているリソースインスタンスのグループを表すデータ（リソースグループ）と、リソース要求のコンテキストを表すデータ（コンテキストタグ）とを有するフィールドを含む。この点に関して、リソース要求９１１ａ～９１１ｄの各々は、要求されているリソースインスタンスのタイプを表すデータ（リソースタイプ）を有するリソースタイプフィールド９１２ａ～９１２ｄを含む。加えて、リソース要求９１１ａ～９１１ｄの各々は、要求されているリソースインスタンスのグループ（リソースグループ）を表すリソースグループフィールド９１３ａ～９１３ｄを含む。さらに加えて、リソース要求９１１ａ～９１１ｄの各々は、リソース要求のコンテキストを表す要求コンテキストデータ（コンテキストタグ）を含む要求コンテキストフィールド９１４ａ～９１４ｄを含む。

ある例に従うと、計算制御プレーンは、ユーザ７０１からの要求の一部であるタグに関連付けられるすべてのタグベースの制限／割り当て９５０を制限サービスデータプレーン７４０（図７）からフェッチすることができる（代替的に、フェッチ動作は、リソース制御プレーン９３０において実行され得る）。そのようなタグベースの割り当ては、例えば、テナンシ全体にわたって適用することができ、コンパートメント固有である必要はない。

ある実施形態に従うと、計算制御プレーンは、要求された使用がメモリ９５０において任意の割り当てまたは制限ルールについてタグベースの制限／割り当てのいずれかに違反するかどうかをチェックすることができる。要求された使用がいかなるコンパートメント割り当てにも違反しない場合、要求は、例えばデータベースに処理することができる。要求された使用がコンパートメントツリーに沿ったタグベースの制限／割り当てのいずれかに違反する場合、要求はドロップされ得、ユーザに通知すべくメッセージが送信され得る。

例示的な実施形態によれば、タグベースの制限／割り当ては、テナンシ内のコンパートメントに適用される。以下で説明する例示的な実施形態によれば、タグベースの制限／割り当ては、たとえば、テナンシが有効にされる本質的に複数のコンパートメントに跨がるすべてのリージョンを含む、テナンシ全体にわたって適用される。要求されたインスタンスがタグベースの制限／割り当てに違反するかどうかを判断するとき、計算制御プレーンは、新たな要求が、例えばサービス開発者キット（ＳＤＫ）を介して、割り当てのいずれにも違反しないことを保証することができる。要求が割り当てを超える場合、計算制御プレーンは要求を落とすことができる。

ある実施形態に従うと、計算制御プレーンのＳＤＫは、クラウドインフラストラクチャ環境のすべての制御プレーンに存在し得る。ある実施形態に従うと、計算制御プレーンは、制限サービスデータプレーンと連携して、新たな要求をタグベースの制限／割り当てに対してチェックすることができる。

ある実施形態に従うと、タグは、リソースおよびリソースの要求またはその両方に関連付けることができ、この手法では、タグは、リソースを不注意なアクセスから保護することができ、顧客ユーザを不注意なリソース過剰から保護することもできる。

この点に関して、システム９００は、関連付けられるクラウドインフラストラクチャ環境におけるリソース９４０の取り扱いを制御するために要求コンテキストタグ９１４ａ～９１４ｄを用いて提供される。システムは、関連付けられるクラウドインフラストラクチャ環境においてテナンシを定義する１つ以上のマイクロプロセッサを備える１つ以上のコンピュータを含むことができる。例示的な実施形態では、コンピュータに作動的に結合されるメモリデバイス９４０は、テナンシにおけるリソースの取り扱いの制御を提供するために、コンピュータによって実行可能な論理を記憶する。メモリデバイスはまた、テナンシにおけるリソースの取り扱いを可能にするための複数の必要とされるクレデンシャルゲートレベルを表すアクセス制御データ９５０を記憶し得る。テナンシにおいて第１のリソースを取り扱う要求９１１ａ～９１１ｄが受信され得、要求９１１ａ～９１１ｄは、要求の要求コンテキスト情報を表す要求コンテキストタグデータ９１４ａ～９１４ｄを含む。要求された第１のリソースに関連付けられる第１の特権レベル分類が判断され、要求の要求コンテキスト情報は、第１の特権レベル分類を有する、テナンシにおけるリソースの取り扱いを可能にするために、複数の必要とされるクレデンシャルゲートレベルのうちの第１の必要とされるクレデンシャルゲートレベルと比較される。例示的な実施形態によれば、第１のリソースを取り扱う要求は、第１の必要とされるクレデンシャルゲートレベルに一致する要求コンテキスト情報に基づいて選択的に許可される。

第１のリソースを取り扱う要求は、テナンシにおいて第１のリソースをプロビジョニングする要求を含み得る。例示的な実施形態によれば、第１のリソースは、第１の必要とされるクレデンシャルゲートレベルに一致する要求コンテキスト情報に基づいて、テナンシにおいて選択的にプロビジョニングされる。

例示的な実施形態によれば、テナンシにおいて第１のリソースをプロビジョニングする要求は、関連付けられるクラウドインフラストラクチャ環境における計算リソース層内の１つ以上の物理ホストマシンのユーザに制御を与えるために、テナンシにおいてベアメタル計算インスタンスをプロビジョニングする、システムのユーザからの要求を含むことができる。この例では、要求の要求コンテキストタグデータは、ユーザのユーザ識別情報を表すユーザコンテキストタグデータ９１３ａ～９１３ｄを含む。メモリデバイスに記憶されたアクセス制御データは、テナンシにおけるリソースの取り扱いを可能にするための複数のユーザ必要とされるクレデンシャルゲートレベルを表すユーザアクセス制御データを含み、ユーザのユーザ識別情報は、第１の特権分類を有する、テナンシにおけるリソースの取り扱いを可能にするための複数のユーザ必要とされるクレデンシャルゲートレベルのうちの第１のユーザ必要とされるクレデンシャルゲートレベルと比較される。この例では、ベアメタル計算インスタンスは、第１のユーザ必要とされるクレデンシャルゲートレベルに一致するユーザのユーザ識別情報に基づいて、テナンシにおいてユーザに選択的にプロビジョニングされる。

例示的な実施形態によれば、テナンシにおいて第１のリソースをプロビジョニングする要求は、第１の特権レベル分類を有する、テナンシにおける複数のリソースをプロビジョニングする要求を含み得る。この場合、テナンシ内の複数のリソースは、第１の必要とされるクレデンシャルゲートレベルに一致する要求コンテキスト情報に基づいて選択的にプロビジョニングされる。

例示的な実施形態によれば、要求の要求コンテキストタグデータは、ユーザのユーザ識別情報を表すユーザコンテキストタグデータ９１３ａ～９１３ｄを含んでもよく、第１のリソースを取り扱う要求は、テナンシにおいてプロビジョニングされ、第２の特権レベル分類に関連付けられるすべてのリソースを取り扱う要求を含んでもよい。システム９００は、第２の特権レベル分類を有する、テナンシにおけるリソースの取り扱いを可能にするために、要求のユーザ識別情報を複数の必要とされるクレデンシャルゲートレベルのうちの第２の要求される要求クレデンシャルゲートレベルと比較するように動作する。システム９００は、第２の必要とされるクレデンシャルゲートレベルに一致するユーザ識別情報に基づいて、テナンシにおいて、第２の特権レベル分類に関連付けられる、プロビジョニングされるリソースのすべてを取り扱う要求を選択的に許可する。

例示的な実施形態によれば、テナンシは、第２の特権レベル分類に関連付けられるリソースを格納する複数のコンパートメント９４２、９４４、９４６を含むことができ、複数のコンパートメントの各コンパートメントは、他のコンパートメント内の第２の特権レベル分類に関連付けられるリソースの１つ以上の他のセットに対する、各コンパートメント内の第２の特権レベル分類に関連付けられるリソースのセットの隔離を提供する。システム９００は、複数のコンパートメントに跨がる第２の特権レベル分類に関連付けられる、テナンシにおいてプロビジョニングされるリソースのすべてを取り扱う要求を、第２の必要とされるクレデンシャルゲートレベルに一致するユーザ識別情報に基づいて選択的に許可する。

テナンシにおいて第１のリソースを取り扱うためにシステムによって受信される要求の要求コンテキストデータは、要求されているリソースインスタンスのタイプを表すリソー
スタイプデータ９１２ａ～９１２ｄおよび／または要求されているリソースインスタンスのグループを表すリソースグループデータ９１３ａ～９１３ｄのうちの１つ以上を含み得る。

ある実施形態に従うと、クライアントがクラウドリソースを作成する動作をトリガすると、要求はリソース制御プレーンに進む。リソース制御プレーンは、グループレベルで構成された制限を考慮して、リソースが安全にスピンアップされ得るかどうかを知るべく、制限サービスから尋ねる。制限サーバがリソース制御プレーンに否定／失敗応答を返す場合、リソースは作成されない。

内部的に、制限サービスが要求を受信すると、制限サービスは、リソース作成に関連付けられるタグをチェックし、その特定のタグを有するリソースの現在の使用を見るために、ストアもしくはデータベースまたはメモリを参照する。タグ値がグループレベルで設定された制限を超える場合、リソース生成が失敗するようにリソース制御プレーンに失敗／否定応答を送信する。

例示的な実施形態の機能性を説明する目的のためだけであり、それを限定する目的のためではないが、第１のポリシー９２２は、以下のような細かい粒度のルール／ポリシーに従って、第１のコンテナ９４２にグループ化されたリソースについて、財務グループレベルにおいて、顧客をリソース過剰から保護することができる：
Set limits <Compute> to 10 in Container #1 (642) where target.resource.tag = “Finance”
（制限＜計算＞をコンテナ＃１（６４２）において１０に設定し、ターゲットリソースタグ＝「財務」である）
上記の特定の例では、ユーザは、財務コンテナ９４２内に１０を超える計算リソースのインスタンスを作成することはできない。このようにして、コンテナ９４２内のリソースをプロビジョニングするための要求９１１ｄは、ポリシー９２２によって処理されて、いかなる過剰も被ることなく要求が実行され得るかまたは他の態様で実行され得るかどうかを判断する。

同様に、第２のポリシー９２４は、以下のような細かい粒度のルール／ポリシーに従って、第２のコンテナ６４４にグループ化されたリソースについて、営業グループレベルにおいて、顧客をリソース過剰から保護することができる：
Set limits <db storage> to 100 in Container #2 (644) where target.resource.tag =
“Operations”
（制限＜ｄｂストレージ＞をコンテナ＃２（６４４）において１００に設定し、ターゲットリソースタグ＝「営業」である）
上記の例では、ユーザは、営業コンテナ６４４内に１００を超えるストレージリソースのインスタンスを作成することはできない。このようにして、コンテナ９４４内のリソースをプロビジョニングするための要求９１１ｃは、ポリシー９２４によって処理されて、いかなる過剰も被ることなく要求が実行され得るかまたは他の態様で実行され得るかどうかを判断する。

同様に、第３のポリシー９２６は、以下のような細かい粒度のルール／ポリシーに従って、第３のコンテナ９４６にグループ化されたリソースについて、人事グループレベルにおいて、顧客をリソース過剰から保護することができる：
Set limits <Compute> to 10 and <db storage> to 100 in Container #3 (646) where target.resource.tag = “Human Resources”
（コンテナ＃３（６４６）において、制限＜計算＞を１０に、および＜ｄｂストレージ＞を１００設定し、ターゲットリソースタグ＝「人事」である）
上記の例では、ユーザは、１０を超える計算リソースのインスタンスまたは１００を超えるストレージリソースのインスタンスを人事コンテナ９４６に作成することはできない。このようにして、コンテナ９４６内のリソースをプロビジョニングするための要求９１１ａ、９１１ｂは、ポリシー９２６によって処理されて、いかなる過剰も被ることなく要求が実行され得るかまたは他の態様で実行され得るかどうかを判断する。

図１０は、例示的な実施形態による、例えば、要求コンテキストに基づいてクラウドインフラストラクチャ環境においてリソースをプロビジョニングすることなど、リソースを取り扱うことを制限するかまたはそれに割り当てを課すための方法１０００を示すフロー図である。ここでその図を参照すると、クラウドインフラストラクチャ環境においてリソースをプロビジョニングするための要求が、ステップ１０１０において受信される。要求は、例えば、上述の第１の要求９１１ａであってもよい。要求は、たとえば、要求の要求コンテキスト情報を表す要求コンテキストタグデータ９１４ａを含み得る。

ステップ１０２０において、要求９１１ａが検査され、要求されたリソースに対する要求のコンテキストが判断される。判断されたリソースタイプは、例えば、計算リソースタイプをプロビジョニングするための要求、またはストレージリソースタイプをプロビジョニングするための要求であってもよい。

ステップ１０３０において、要求されたリソースに関連付けられる特権レベル分類が判断される。例示的実施形態によれば、リソースは、リソースにアクセスするために必要とされる特権レベルを反映する印に関連して記憶されてもよい。特権レベルは、例えば図８の８５１～８５４、８６１～８６４、８７１～８７４および図１の１４０ａ、１６ａ、１７０ａに示すような１つ以上の特権レベルタグ内に、またはそのような１つ以上の特権レベルタグとして、記憶することができる。判断されたリソースグループは、例えば、人事グループにグループ化されたリソースをプロビジョニングするための要求であってもよい。

ステップ１０４０において、リソース要求９１１ａを、判断された要求のグループに従って、特定のコンテナに割り当てることができる。この例では、リソース要求９１１ａは、たとえば、この例に従って、第３のコンテナ９４６に割り当てられ得る。割り当てられたコンパートメントに対応するポリシーは、リソース要求に選択的に適用され得る。図示の例では、第３のポリシー９２６は、リソース要求９１１ａに選択的に適用され得る。ステップ１０４０において、リソース要求９１１ａの内容に従った追加のリソースのプロビジョニングが、コンパートメント９４６に割り当てられたポリシー９２６において指定される制限および／または割り当てを超えないと判断された場合、要求９１１ａにおいて要求されたインスタンスは、コンパートメント９４６において作成されてもよい。

ステップ１０５０において、要求９１１ａの要求コンテキスト情報９１４ａは、第１の特権レベル分類を有する、テナンシにおけるリソースの取り扱いを可能にするために、複数の必要とされるクレデンシャルゲートレベルのうちの第１の必要とされるクレデンシャルゲートレベルと比較される。

ステップ１０６０において、要求コンテキスト情報が第１の必要とされるクレデンシャルゲートレベルと一致すると判断された場合、ステップ１０７０において、第１のリソースを扱う要求が許可され、例えば、要求されたリソースのインスタンスが作成され得る、要求されたリソースがプロビジョニングされ得る、要求されたリソースが終了され得る、または別様にプロビジョニング解除され得るなど、リソースが取り扱われ得る。

ステップ１０６０において、要求コンテキスト情報が第１の必要とされるクレデンシャ
ルゲートレベルと一致しないと判断された場合、ステップ１０８０において、第１のリソースを取り扱う要求はドロップされる。

リソースタグベースの制限／割り当て
図１１は、一実施形態による、クラウドインフラストラクチャ環境においてタグベースのリソース制限／割り当てを設けるシステム１１００の機能概略図である。

概して、クライアントデバイス８１０（図８）は、複数のタグ付けされたリソース１０４０の中で新たなリソースをプロビジョニングするための要求１１１１をクラウドインフラストラクチャ環境に提出することができる。複数のタグ付けされたリソース１１４０は、例えば、計算リソース層８５０のタグ付けされた計算リソース８５１～８５４、ネットワークリソース層８６０のタグ付けされたネットワークリソース８６１～８６４、および／またはストレージリソース層８７０のタグ付けされたストレージリソース８７１～８７４のいずれかであり得る。

例示的な実施形態によれば、プロビジョニングされるリソースおよびサービスはタグ付け可能である。例示的実施形態では、リソースは、１つ以上のタグと関連付けられる。加えて、リソースは、それらのタグ値に基づいてグループ化され得る。本質的に、例示的実施形態では、各プロビジョニングされたリソースと関連付けられるリソースタグは、クラウドインフラストラクチャ環境においてプロビジョニングされたリソースにアタッチされ得るか、または別様にそれらに関連付けられ得る、キー値ペアである。タグキー値ペアは、例えば、様々な会計目的を含む多くの目的のために用いられ得る。ある例では、プロビジョニングされたリソースに関連付けられるリソースキー値ペアタグは、リソースをグループ化するために用いられ、リソースタグによって提供されるグループ化は、クラウドインフラストラクチャ環境における値のすべてのコスト管理および／またはリソース管理を可能にする。

クラウドインフラストラクチャ環境においてプロビジョニングされるリソースは、各リソースに割り当てられるタグ値に基づいて、コンテナ１１４２、１１４４、１１４６にグループ化されてもよい。

ある例に従うと、リソースインスタンスは、異なるコンテナ１１４２、１１４４、１１４６に論理的に配置され、それにより、別々のコストセンターを提供し、各コストセンターにはタグ値が割り当てられ、エンドユーザは、さまざまなコストセンターへのアクセスについて請求され得、コストセンターのタグは、コスト管理および課金のために用いられる。一部の顧客は、彼らのエンドグループ価格内で複数のコストセンターをモデル化し得る。各コストセンターに対して別個のタグが存在してもよく、クラウドは、各タグに対して、限定されたリソースのセットを割り当ててもよい。

例示的実施形態では、１つ以上のポリシー１１２０は、エンドユーザがアクセスについて標準契約で許可されるよりも多くのリソースにアクセスすることから自身を保護するための機構を提供し、実質的過剰は、エンドユーザが標準契約の標準契約条件下で許可されるよりも多くのリソースにアクセスすることによって生じ得る。例えば、顧客は、リソース制御プレーン１１３０を介して、例えば、１００個の計算リソース等の複数の計算リソースのプロビジョニングをアクティブにする、リソースに対する要求を送信し得、契約条件は、標準レートで９０個のコンピュータリソースのプロビジョニングのみを許可しており、過剰分が、この実施例では１０が、顧客エンドユーザに対して追加費用を招く。

上述のように、およびある実施形態に従うと、細かい粒度のアプローチは、タグ、特にリソースに関連付けられるタグに基づいて、リソース制限を設けることができる。リソー
スと関連付けられるタグは、リソース管理１１０（図１）において用いられ得る機構を提供し、クラウドプロバイダは、コスト管理のためにもそれらを使用し得る。システムおよび方法は、タグを通して、グループレベルを含むレベルでコストを制御するための機構を作成することができる。例として、ユーザは、以下のような細かい粒度のルール／ポリシーを指定することができる：
Set limits <resource type> to 10 in group A where target.resource.tag = “finance”
（制限＜リソースタイプ＞をグループＡにおいて１０に設定し、ターゲットリソースタグ＝「財務」である）
ある実施形態に従うと、タグは、リソースに関連付けることができ、上記アプローチを用いて、タグは、たとえばグループレベルなどの１つ以上の選択されたレベルで顧客をリソース過剰から保護することができる。上記の例では、タグ値がグループＡにおいて「財務」である場合、のユーザメンバーは、＜リソースタイプ＞の１０を超えるインスタンスを作成することはできないことになる。グループレベルでコストを制限するこのアプローチは、コストおよびリソース使用をより良く管理するために、細かい粒度の機構をクライアントに提供する。

例示的な実施形態によれば、第１のポリシー１１２０ａは、第１のタグに関連付けられ、コンテナ１１４２、１１４４、１１４６のいずれかにグループ化され得るリソースの過剰使用から顧客を保護する。同様に、第２のポリシー１１２０ｂは、第２のタグに関連付けられ、コンテナ１１４２、１１４４、１１４６のいずれかにグループ化され得るリソースの過剰使用から顧客を保護する。同様に、第３および第４のポリシー１１２０ｃ、１１２０ｄは、第３および第４のタグに関連付けられ、コンテナ１１４２、１１４４、１１４６のいずれかにグループ化されもし得るリソースの過剰使用から顧客を保護する。

ある例に従うと、リソース要求１１１１ａ～１１１１ｄの各々は、要求されているリソースインスタンスのタイプを表すデータ（リソースタイプ）と、要求されているリソースインスタンスのグループを表すデータ（リソースグループ）と、リソース要求の特性を表すデータ（リソース特性）と、リソース要求のコンテキストを表すデータ（コンテキストタグ）とを有するフィールドを含む。この点に関して、リソース要求１１１１ａ～１１１１ｄの各々は、要求されているリソースインスタンスのタイプを表すデータ（リソースタイプ）を有するリソースタイプフィールド１１１２ａ～１１１２ｄを含む。加えて、リソース要求１１１１ａ～１１１１ｄの各々は、要求されているリソースインスタンスのグループ（リソースグループ）を表すリソースグループフィールド１１１３ａ～１１１３ｄを含む。さらに加えて、リソース要求１１１１ａ～１１１１ｄの各々は、リソース要求のコンテキストを表す要求コンテキストデータ（コンテキストタグ）を含む要求コンテキストフィールド１１１４ａ～１１１４ｄを含む。さらに追加して、リソース要求１１１１ａ～１１１１ｄの各々は、リソース要求の特性を表す要求特性データ（特性タグ）を含む要求特性フィールド１１１５ａ～１１１５ｄを含む。要求特性フィールド１１１５ａ～１１１５ｄは、説明を容易にするために別途示され説明されるが、それは、リソースタイプ情報から、またはリソースグループ情報から、またはリソース要求を形成する任意の他の情報から導出され得ることを理解されたい。

ある例に従うと、計算制御プレーンは、ユーザ７０１からの要求の一部であるタグに関連付けられるすべてのタグベースの制限／割り当て１１５０を制限サービスデータプレーン７４０（図７）からフェッチすることができる（代替的に、フェッチ動作は、リソース制御プレーン１１３０において実行され得る）。そのようなタグベースの割り当ては、例えば、テナンシ全体にわたって適用することができ、コンパートメント固有である必要はない。

ある実施形態に従うと、計算制御プレーンは、要求された使用がメモリ１１５０において任意の割り当てまたは制限ルールについてタグベースの制限／割り当てのいずれかに違反するかどうかをチェックすることができる。要求された使用がいかなるリソースタグベースの割り当てにも違反しない場合、要求は、たとえばデータベースに対して処理され得る。要求された使用がコンパートメントツリーに沿ったリソースタグベースの制限／割り当てのいずれかに違反する場合、要求はドロップされ得、ユーザに通知すべくメッセージが送信され得る。

例示的な実施形態によれば、リソースタグベースの制限／割り当ては、テナンシ内のコンパートメントに適用される。以下で説明する例示的な実施形態によれば、リソースタグベースの制限／割り当ては、たとえば、テナンシが有効にされる本質的に複数のコンパートメントに跨がるすべてのリージョンを含む、テナンシ全体にわたって適用される。要求されたインスタンスがリソースタグベースの制限／割り当てに違反するかどうかを判断するとき、計算制御プレーンは、新たな要求が、例えばサービス開発者キット（ＳＤＫ）を介して、割り当てのいずれにも違反しないことを保証することができる。要求が割り当てを超える場合、計算制御プレーンは要求を落とすことができる。

ある実施形態に従うと、計算制御プレーンのＳＤＫは、クラウドインフラストラクチャ環境のすべての制御プレーンに存在し得る。ある実施形態に従うと、計算制御プレーンは、制限サービスデータプレーンと連携して、新たな要求をリソースタグベースの制限／割り当てに対してチェックすることができる。

ある実施形態に従うと、クライアントがクラウドリソースを作成する動作をトリガすると、要求はリソース制御プレーンに進む。リソース制御プレーンは、たとえばグループレベルなどの選択されたレベルで構成された制限を考慮して、リソースが安全にスピンアップされ得るかどうかを知るべく、制限サービスから尋ねる。制限サーバがリソース制御プレーンに否定／失敗応答を返す場合、リソースは作成されず、要求はドロップされる。

内部的に、制限サービスが要求を受信すると、制限サービスは、リソース作成に関連付けられるタグをチェックし、その特定のタグを有するリソースの現在の使用を見るために、ストアもしくはデータベースまたはメモリを参照する。リソースは、複数のタグに関連付けられてもよく、リソースは、複数の異なるタグに関連付けられてもよい。タグ値が、たとえばグループレベルなどの選択されたレベルで構成された制限を超える場合、それは、リソース作成が失敗するように、リソース制御プレーンに失敗／否定応答を送信する。

ある実施形態に従うと、メモリデバイス１１４０は、テナンシ３０５（図３）におけるリソースプロビジョニングの、複数のタグベースの割り当てを表す、タグベースの割り当てデータ１１５０を記憶する。テナンシにおいてリソースをプロビジョニングする要求１１１１ａ～１１１１ｄが受信される。要求１１１１ａ～１１１１ｄは、要求の要求特性を表す要求特性データ１１１５ａ～１１１５ｄを含み得る。ある実施形態に従うと、要求の要求特性に対応するリソースタグ１５０ａ、１６０ａ、１７０ａ（図１）に関連付けられる、テナンシにおけるリソースの使用が判断され、複数のタグベースの割り当ておよび／または制限１１５０と比較される。リソースをプロビジョニングする要求は、判断された使用が複数のタグベースの割り当てのうちの１つを超えることに基づいてドロップされる。

実施形態の例によれば、テナンシ３０５は、リソースを格納する複数のコンパートメント１１４２、１１４４、１１４６を備え、複数のコンパートメントの各コンパートメントは、他のコンパートメント内のリソースの１つ以上の他のセットに対する、各コンパートメント内のリソースのセットの隔離を提供する。要求の要求特性に対応するリソースタグ
に関連付けられる、テナンシにおけるリソースの使用は、複数のコンパートメントにわたってまとめて判断され、複数のコンパートメントにわたってまとめて判断された使用は、テナンシの複数のタグベースの割り当てと比較される。リソースをプロビジョニングする要求１１１１ａ～１１１１ｄは、複数のコンパートメントにわたってまとめて判断された使用が複数のタグベースの割り当てのうちの１つを超えることに基づいてドロップされる。

実施形態の例によれば、メモリデバイス１１４０に記憶されたタグベースの割り当てデータ１１５０は、テナンシの対応する複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当てを表す。加えて、テナントにおいてリソースをプロビジョニングする要求１１１１ａ～１１１１ｄの要求特性データ１１１５ａ～１１１５ｄは、要求されたリソースの第１のリソースタイプ１１１２ａ～１１１２ｄを表すリソースタイプデータを含む。例示的な実施形態では、第１のリソースタイプ１１１２ａに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が判断され、第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て１１２０ａと比較される。第１のリソースタイプ１１１２ａのリソースをプロビジョニングする要求１１１１ａは、第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおける判断されたリソースの使用が、第１のリソースタイプの、テナンシにおけるリソースプロビジョニングのたとえばポリシー１１２０ａとして記憶される第１のタグベースの割り当てを超えることに基づいて、ドロップされる。

実施形態の一例によれば、メモリデバイス１１４０に記憶されたタグベースの割り当てデータ１１５０は、テナンシの対応する複数のユーザグループに割り当てられた、テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当てを表す。テナンシにおいてリソースをプロビジョニングする要求１１１１ａ～１１１１ｄの要求特性データ１１１５ａ～１１１５ｄは、リソースを要求するシステムのユーザに割り当てられたユーザグループカテゴリを表すユーザグループデータ１１１３ａ～１１１３ｄを含む。ユーザグループカテゴリに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が判断され、ユーザグループカテゴリに割り当てられた、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て１１２０ｂと比較される。リソースをプロビジョニングする要求は、ユーザグループカテゴリに対応するリソースタグに関連付けられる、テナンシにおける判断されたリソースの使用が、ユーザグループカテゴリに割り当てられた、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てを超えることに基づいて、ドロップされる。

実施形態の一例によれば、メモリデバイスに記憶されたタグベースの割り当てデータは、テナンシの複数のユーザグループに割り当てられた、テナンシの複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、タグベースの割り当てを表す。テナンシにおいてリソースをプロビジョニングする要求の要求特性データは、たとえば、ｉ）要求されたリソースの第１のリソースタイプを表すリソースタイプデータ、および／またはｉｉ）リソースを要求するシステムのユーザに割り当てられたユーザグループカテゴリを表すユーザグループデータを含んでもよい。この例では、第１のユーザグループカテゴリにプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が判断され、第１のユーザグループカテゴリに割り当てられた第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てと比較される。加えて、リソースをプロビジョニングする要求は、第１のユーザグループカテゴリにプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおける判断されたリソースの使用が、第１のユーザグループカテゴリに割り当てられた第１のリソースタイプの、テナンシに
おけるリソースプロビジョニングの、第１のタグベースの割り当てを超えることに基づいて、ドロップされる。

実施形態の一例によれば、メモリデバイス１１４０に記憶されたタグベースの割り当てデータ１１５０は、テナンシの複数のユーザグループに割り当てられた、テナンシの複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、タグベースの割り当てを表す。テナンシのリソース使用を追跡する第１の要求がユーザ７０１から受信され得、第１の要求は、第１のユーザグループカテゴリ１１１３ａ～１１１３ｄおよび第１のリソースタイプ１１１２ａ～１１１２ｄを表す要求特性データ１１１５ａ～１１１５ｄを含む。

第１のユーザグループカテゴリによってプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおけるリソースの第１の使用が判断され、リソース使用追跡データは、第１のユーザグループによってプロビジョニングされる第１のリソースタイプの、テナンシにおけるリソースの、判断された第１の使用に基づいて生成される。

実施形態の一例によれば、リソースをプロビジョニングする要求は、判断された使用が複数のタグベースの割り当てのうちの１つを超えることに基づいてドロップされる。しかしながら、テナンシのリソースをプロビジョニングするオーバーライド要求が、ユーザ７０１から受信されてもよい。リソースは、実施形態の一例に従って、システムがオーバーライド要求を受信することに基づいて、選択的にプロビジョニングされる。加えて、システムがオーバーライド要求を受信したことに応答してリソースが選択的にプロビジョニングされることに基づいて、リソース使用過剰データが生成される。

図１２は、例示的な実施形態による、リソースタグに基づいてクラウドインフラストラクチャ環境においてリソースをプロビジョニングすることを制限するかまたはそれに割り当てを課すための方法１２００を示す流れ図である。

方法１２００によれば、ステップ１２１０において、テナンシが提供され、タグベースの制限／割り当てデータがメモリに記憶される。その好ましい形態では、テナンシは、関連付けられるクラウドインフラストラクチャ環境において、１つ以上のプロセッサと、コンピュータに作動的に結合されるメモリデバイスとを含むコンピュータによって提供される。メモリデバイスは、関連付けられるクラウドインフラストラクチャ環境におけるリソース使用のタグベースの制御を提供するためにコンピュータによって実行可能なタグベースの制御論理を記憶する。例示的な実施形態では、メモリデバイスに記憶されたタグベースの割り当てデータは、テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当てを表す。

ステップ１２２０において、テナンシにおいてリソースをプロビジョニングする要求が受信される。要求は、要求の要求特性を表す要求特性データを含む。

ステップ１２３０において、要求されたリソースのリソースタイプが判断される。
ステップ１２４０において、要求の要求特性に対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が、１つ以上のプロセッサがタグベースの制御論理を実行することにより、判断される。

要求は、ステップ１２５０において、要求されたリソースのグループに基づいて、コンパートメントのうちの１つ以上に割り当てられる。

タグベースの制御論理を実行する１つ以上のプロセッサは、タグに関連付けられるリソースの使用を判断し、判断された使用は、ステップ１２６０において、複数のタグベースの割り当てと比較される。

リソース要求は、ステップ１２９０において、ステップ１２７０における、使用が複数のタグベースの割り当てのうちの１つを超えるという判断に基づいて、リソースをプロビジョニングする要求を、１つ以上のプロセッサがタグベースの制御論理を実行することによって、ドロップされる。

要求されたリソースのインスタンスは、ステップ１２８０において、ステップ１２７０における、使用が複数のタグベースの割り当てのうちの１つを超えないという判断に基づいて、リソースをプロビジョニングする要求を、１つ以上のプロセッサがタグベースの制御論理を実行することによって、作成される。

実施形態の例によれば、テナンシは、リソースを格納する複数のコンパートメントを提供することにより提供され、複数のコンパートメントの各コンパートメントは、他のコンパートメント内のリソースの１つ以上の他のセットに対する、各コンパートメント内のリソースのセットの隔離を提供する。加えて、使用を判断することは、複数のコンパートメントにわたってまとめて、要求の要求特性に対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用を判断することを含み、比較することは、判断された使用を、複数のコンパートメントにわたってまとめて、テナンシの複数のタグベースの割り当てと比較することを含む。さらに加えて、要求をドロップすることは、複数のコンパートメントにわたってまとめて判断された使用が複数のタグベースの割り当てのうちの１つを超えることに基づいて、リソースをプロビジョニングする要求をドロップすることを含む。

実施形態の例によれば、タグベースの割り当てデータを記憶することは、テナンシの対応する複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当てを表す、タグベースの割り当てデータを、メモリデバイスに記憶することを含む。加えて、要求を受信することは、要求されたリソースの第１のリソースタイプを表すリソースタイプデータを含む要求を受信することを含み、判断することは、第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が判断されることを判断することを含む。さらに加えて、比較することは、判断された使用を、第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てと比較することを含み、要求をドロップすることは、第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおける判断されたリソースの使用が、第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てを超えることに基づいて、要求をドロップすることを含む。

実施形態の例によれば、タグベースの割り当てデータを記憶することは、テナンシの対応する複数のユーザグループに割り当てられた、テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当てを表す、タグベースの割り当てデータを、メモリデバイスに記憶することを含み、要求を受信することは、リソースを要求するシステムのユーザに割り当てられたユーザグループカテゴリを表すリソースタイプデータを含む要求を受信することを含む。加えて、判断することは、ユーザグループカテゴリに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用を判断することを含み、比較することは、判断された使用を、ユーザグループカテゴリに割り当てられた、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てと比較することを含む。加えて、要求をドロップすることは、ユーザグループカテゴリに対応するリソースタ
グに関連付けられる、テナンシにおける判断されたリソースの使用が、ユーザグループカテゴリに割り当てられた、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てを超えることに基づいて、要求をドロップすることを含む。

実施形態の例によれば、タグベースの割り当てデータを記憶することは、テナンシの複数のユーザグループに割り当てられた、テナンシの複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、タグベースの割り当てを表す、タグベースの割り当てデータを、メモリデバイスに記憶することを含み、要求を受信することは、ｉ）要求されたリソースの第１のリソースタイプを表すリソースタイプデータと、ｉｉ）リソースを要求するシステムのユーザに割り当てられたユーザグループカテゴリを表すユーザグループデータとを含むリソースタイプデータを含む要求を受信することを含む。加えて、判断することは、第１のユーザグループカテゴリにプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用を判断することを含み、比較することは、判断された使用を、第１のユーザグループカテゴリに割り当てられた第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てと比較することを含む。さらに加えて、要求をドロップすることは、第１のユーザグループカテゴリにプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおける判断されたリソースの使用が、第１のユーザグループカテゴリに割り当てられた第１のリソースタイプの、テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当てを超えることに基づいて、要求をドロップすることを含む。

実施形態の一例によれば、テナンシの複数のユーザグループに割り当てられた、テナンシの複数のリソースタイプの、テナンシにおけるリソースプロビジョニングの、タグベースの割り当てを表す、タグベースの割り当てデータを、メモリデバイスに記憶する。本方法はさらに、テナンシのリソース使用を追跡する第１の要求を受信することを含み、第１の要求は、第１のユーザグループカテゴリおよび第１のリソースタイプを表す要求特性データを含む。加えて、第１のユーザグループカテゴリによってプロビジョニングされる第１のリソースタイプに対応するリソースタグに関連付けられる、テナンシにおけるリソースの第１の使用を判断し、第１のユーザグループによってプロビジョニングされる第１のリソースタイプの、テナンシにおける判断されたリソースの第１の使用に基づいて、リソース使用追跡データを生成する。

本方法はさらに、テナンシのリソースをプロビジョニングするオーバーライド要求を受信することと、システムがオーバーライド要求を受信することに基づいてリソースを選択的にプロビジョニングすることと、システムがオーバーライド要求を受信したことに応答してリソースが選択的にプロビジョニングされることに基づいて、リソース使用過剰データを生成することとを含む。

様々な実施形態によれば、本明細書の教示は、本開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリ、および／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを使用して都合よく実現されてもよい。適切なソフトウェアコーディングは、ソフトウェア技術の当業者には明らかなように、本開示の教示に基づいて熟練したプログラマーによって容易に準備することができる。

いくつかの実施形態では、本開示の教示は、コンピュータ可読媒体を用いて、１つ以上のプログラマブルプロセッサまたはコンピュータが本教示のプロセスのいずれかを実行するための命令を伝達する（たとえば、記憶するまたは搬送する）ことができるコンピュータプログラム製品を含むことができる。コンピュータ可読媒体の一例は、本教示のプロセ
スのいずれかを実行するようにコンピュータをプログラムするために用いられ得る命令が記憶された非一時的コンピュータ可読記憶媒体である。そのような記憶媒体の例は、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、もしくは他の電気機械データストレージデバイス、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム、または命令および／もしくはデータの非一時的な格納に適した他のタイプの記憶媒体もしくはデバイスを含み得るが、それらに限定はされない。コンピュータ可読媒体の別の例は、コンピュータシステム間または所与のコンピュータシステムのコンポーネント間でそのような命令を伝達する過渡的媒体である。過渡媒体の例は、搬送波および伝送信号を含むことができるが、これらに限定されない。

したがって、ある観点から、クラウドインフラストラクチャ環境においてタグベースのリソース制限または割り当てをサポートするシステムおよび方法が説明された。クラウド管理者は、概して、既存のクラウドにおいてリソース使用を制限する能力を有していない。ユーザにリソースを作成するための許可を与えることにより、ユーザは、事前定義されたアカウント限度まで任意の数のリソースを作成することが可能になる。タグは、微調整されたコスト制御を可能にすることによって、管理者がユーザのリソース使用を適切なレベルに制限することを可能にするために、リソースと関連付けられる。リソースをプロビジョニングする要求の要求特性に対応するリソースタグに関連付けられる、テナンシにおけるリソースの使用が判断され、複数のタグベースの割り当てと比較され、リソースをプロビジョニングする要求は、判断された使用が複数のタグベースの割り当てのうちの１つを超えることに基づいてドロップされる。

前述の説明は、例示および説明を目的として提供された。それは、網羅的であること、または保護の範囲を開示された厳密な形態に限定することを意図するものではない。多くの修正および変形が当業者には明らかであろう。例えば、本開示で提供される例のいくつかは、Oracle Fusion Applicationsなどの企業ソフトウェアアプリケーションコンポーネント、Oracle Cloud Infrastructureなどのクラウド環境、およびOracle Fusion Analyticsなどのクラウドサービスとの使用を例示するが、様々な実施形態によれば、本開示に記載のシステムおよび方法は、他のタイプの企業ソフトウェアアプリケーション、クラウド環境、クラウドサービス、クラウドコンピューティング、または他のコンピューティング環境とともに用いることができる。

実施形態は、本教示の原理およびそれらの実際の適用を最もよく説明するために選択および記載されており、それにより、当業者は、企図される特定の使用に適した様々な実施形態および様々な修正を理解することができる。その範囲は、特許請求の範囲およびそれらの均等物によって規定されることが意図される。

Claims (15)

1. 関連付けられるクラウドインフラストラクチャ環境におけるリソース使用のタグベースの制御のためのシステムであって、
   １つ以上のマイクロプロセッサを含むコンピュータと、
   前記関連付けられるクラウドインフラストラクチャ環境において定義されるテナンシとを備え、前記テナンシは、関連リソースの集まりへのアクセスを制御する１つ以上のコンパートメントに関連付けられ、
   前記コンピュータは、前記テナンシによるリソース使用を制御する際の使用のために、前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表す、タグベースの割り当てデータを記憶するメモリデバイスを含み、
   前記テナンシにおいてリソースをプロビジョニングする要求が受信され、前記要求は、前記要求の要求特性を表す要求特性データを含み、
   前記要求の前記要求特性に対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量が判断され、判断された使用量は前記テナンシに関連付けられる前記複数のタグベースの割り当て量と比較され、
   前記テナンシにおいて前記リソースをプロビジョニングする前記要求は、処理されるか、または前記テナンシもしくは関連付けられるコンパートメント内のリソースの前記判断された使用量が前記複数のタグベースの割り当て量のうちの１つを超えることに基づいてドロップされるか、の少なくとも１つである、システム。
2. 前記テナンシは、前記リソースを格納する複数のコンパートメントを備え、前記複数のコンパートメントの各コンパートメントは、他のコンパートメント内のリソースの１つ以上の他のセットに対する、前記各コンパートメント内のリソースのセットの隔離を提供し、
   前記要求の前記要求特性に対応する前記リソースタグに関連付けられる、前記テナンシにおける前記リソースの前記使用量は、前記複数のコンパートメントにわたってまとめて判断され、前記複数のコンパートメントにわたってまとめて判断された前記使用量は、前記テナンシの前記複数のタグベースの割り当て量と比較され、
   前記リソースをプロビジョニングする前記要求は、前記複数のコンパートメントにわたってまとめて判断された前記使用量が前記複数のタグベースの割り当て量のうちの１つを超えることに基づいてドロップされる、請求項１に記載のシステム。
3. 前記メモリデバイスに記憶された前記タグベースの割り当てデータは、前記テナンシの対応する複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表し、
   前記テナンシにおいて前記リソースをプロビジョニングする前記要求の前記要求特性データは、前記要求されたリソースの第１のリソースタイプを表すリソースタイプデータを含み、
   前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量が判断され、判断された使用量は前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較され、
   前記第１のリソースタイプの前記リソースをプロビジョニングする前記要求は、前記第１のリソースタイプに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、ドロップされる、請求項１または２に記載のシステム。
4. 前記メモリデバイスに記憶された前記タグベースの割り当てデータは、前記テナンシの対応する複数のユーザグループに割り当てられた前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表し、
   前記テナンシにおいて前記リソースをプロビジョニングする前記要求の前記要求特性データは、前記リソースを要求する前記システムのユーザに割り当てられたユーザグループカテゴリを表すユーザグループデータを含み、
   前記ユーザグループカテゴリに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量が判断され、判断された使用量は前記ユーザグループカテゴリを割り当てられた前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較され、
   前記リソースをプロビジョニングする前記要求は、前記ユーザグループカテゴリに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記ユーザグループカテゴリに割り当てられた前記テナンシにおけるリソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、ドロップされる、請求項１～３のいずれかに記載のシステム。
5. 前記メモリデバイスに記憶された前記タグベースの割り当てデータは、前記テナンシの複数のユーザグループに割り当てられた、前記テナンシの複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、タグベースの割り当て量を表し、
   前記テナンシにおいて前記リソースをプロビジョニングする前記要求の前記要求特性データは、ｉ）前記要求されたリソースの第１のリソースタイプを表すリソースタイプデータと、ｉｉ）前記リソースを要求する前記システムのユーザに割り当てられた第１のユーザグループカテゴリを表すユーザグループデータとを含み、
   前記第１のユーザグループカテゴリにプロビジョニングされる前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量が判断され、判断された使用量は前記第１のユーザグループカテゴリに割り当てられた前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較され、
   前記リソースをプロビジョニングする前記要求は、前記第１のユーザグループカテゴリにプロビジョニングされる前記第１のリソースタイプに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記第１のユーザグループカテゴリに割り当てられた前記第１のリソースタイプの、前記テナンシにおける前記リソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、ドロップされる、請求項１～４のいずれかに記載のシステム。
6. 前記メモリデバイスに記憶された前記タグベースの割り当てデータは、前記テナンシの複数のユーザグループに割り当てられた、前記テナンシの複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、タグベースの割り当て量を表し、
   前記テナンシのリソース使用量を追跡する第１の要求が受信され、前記第１の要求は、第１のユーザグループカテゴリおよび第１のリソースタイプを表す要求特性データを含み、
   前記第１のユーザグループカテゴリによってプロビジョニングされる前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの第１の使用量が判断され、
   リソース使用追跡データが、前記第１のユーザグループカテゴリによってプロビジョニングされる前記第１のリソースタイプの、前記テナンシにおける前記判断されたリソースの第１の使用量に基づいて生成される、請求項１～５のいずれかに記載のシステム。
7. 前記リソースをプロビジョニングする前記要求は、前記判断された使用量が前記複数のタグベースの割り当て量のうちの１つを超えることに基づいてドロップされ、
   前記テナンシの前記リソースをプロビジョニングするオーバーライド要求が受信され、
   前記リソースは、前記システムが前記オーバーライド要求を受信することに基づいて選択的にプロビジョニングされ、
   前記システムが前記オーバーライド要求を受信したことに応答して前記リソースが選択的にプロビジョニングされることに基づいて、リソース使用過剰データが生成される、請求項１～６のいずれかに記載のシステム。
8. 関連付けられるクラウドインフラストラクチャ環境におけるリソース使用のタグベースの制御のための方法であって、
   １つ以上のプロセッサと、コンピュータに作動的に結合されるメモリデバイスとを備える前記コンピュータが、前記関連付けられるクラウドインフラストラクチャ環境においてテナンシを提供することを含み、前記メモリデバイスは、前記テナンシによるリソース使用を制御する際の使用のために、前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表す、タグベースの割り当てデータを記憶し、前記方法はさらに、
   前記テナンシにおいてリソースをプロビジョニングする要求を受信することを含み、前記要求は、前記要求の要求特性を表す要求特性データを含み、前記方法はさらに、
   前記１つ以上のプロセッサが前記タグベースの制御論理を実行することによって、前記要求の前記要求特性に対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量を判断することと、
   前記１つ以上のプロセッサが前記タグベースの制御論理を実行することによって、前記判断された使用量を前記テナンシに関連付けられる前記複数のタグベースの割り当て量と比較することと、
   前記テナンシにおける前記リソースをプロビジョニングする前記要求を処理すること、または前記テナンシもしくは関連付けられるコンパートメント内のリソースの前記判断された使用量が前記複数のタグベースの割り当て量のうちの１つを超えることに基づいて、前記リソースをプロビジョニングする前記要求をドロップすること、のうちの少なくとも１つとを含む、方法。
9. 前記テナンシを提供することは、前記リソースを格納する複数のコンパートメントを提供することを含み、前記複数のコンパートメントの各コンパートメントは、他のコンパートメント内のリソースの１つ以上の他のセットに対する、前記各コンパートメント内のリソースのセットの隔離を提供し、
   前記使用量を判断することは、前記複数のコンパートメントにわたってまとめて、前記要求の前記要求特性に対応する前記リソースタグに関連付けられる、前記テナンシにおける前記リソースの使用量を判断することを含み、
   前記比較することは、前記複数のコンパートメントにわたってまとめて判断された前記使用量を、前記テナンシの前記複数のタグベースの割り当て量と比較することを含み、
   前記ドロップすることは、前記複数のコンパートメントにわたってまとめて判断された前記使用量が前記複数のタグベースの割り当て量のうちの１つを超えることに基づいて、前記リソースをプロビジョニングする前記要求をドロップすることを含む、請求項８に記載の方法。
10. 前記タグベースの割り当てデータを記憶することは、前記テナンシの対応する複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表す、タグベースの割り当てデータを、前記メモリデバイスに記憶することを含み、
    前記要求を受信することは、前記要求されたリソースの第１のリソースタイプを表すリソースタイプデータを含む要求を受信することを含み、
    前記判断することは、前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量を判断することを含み、
    前記比較することは、前記判断された使用量を、前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較することを含み、
    前記要求をドロップすることは、前記第１のリソースタイプに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記第１のリソースタイプの、前記テナンシにおける前記リソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、前記要求をドロップすることを含む、請求項８または９に記載の方法。
11. 前記タグベースの割り当てデータを記憶することは、前記テナンシの対応する複数のユーザグループに割り当てられた、前記テナンシにおけるリソースプロビジョニングの、複数のタグベースの割り当て量を表す、タグベースの割り当てデータを、前記メモリデバイスに記憶することを含み、
    前記要求を受信することは、前記リソースを要求するユーザに割り当てられたユーザグループカテゴリを表すリソースタイプデータを含む要求を受信することを含み、
    前記判断することは、前記ユーザグループカテゴリに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量を判断することを含み、
    前記比較することは、前記判断された使用量を、前記ユーザグループカテゴリに割り当てられた前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較することを含み、
    前記要求をドロップすることは、前記ユーザグループカテゴリに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記ユーザグループカテゴリに割り当てられた前記テナンシにおけるリソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、前記要求をドロップすることを含む、請求項８～１０のいずれかに記載の方法。
12. 前記タグベースの割り当てデータを記憶することは、前記テナンシの複数のユーザグループに割り当てられた、前記テナンシの複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、タグベースの割り当て量を表す、タグベースの割り当てデータを、前記メモリデバイスに記憶することを含み、
    前記要求を受信することは、ｉ）前記要求されたリソースの第１のリソースタイプを表すリソースタイプデータと、ｉｉ）前記リソースを要求するユーザに割り当てられた第１のユーザグループカテゴリを表すユーザグループデータとを含むリソースタイプデータを含む要求を受信することを含み、
    前記判断することは、前記第１のユーザグループカテゴリにプロビジョニングされる前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの使用量を判断することを含み、
    前記比較することは、前記判断された使用量を、前記第１のユーザグループカテゴリに割り当てられた前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、第１のタグベースの割り当て量と比較することを含み、
    前記要求をドロップすることは、前記第１のユーザグループカテゴリにプロビジョニングされる前記第１のリソースタイプに対応する前記リソースタグに関連付けられる、前記テナンシにおける前記判断されたリソースの使用量が、前記第１のユーザグループカテゴリに割り当てられた前記第１のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの前記第１のタグベースの割り当て量を超えることに基づいて、前記要求をドロップすることを含む、請求項８～１１のいずれかに記載の方法。
13. 前記方法はさらに、
    前記テナンシの複数のユーザグループに割り当てられた、前記テナンシの複数のリソースタイプの、前記テナンシにおけるリソースプロビジョニングの、タグベースの割り当て量を表す、タグベースの割り当てデータを、前記メモリデバイスに記憶することと、
    前記テナンシのリソース使用量を追跡する第１の要求を受信することとを含み、前記第１の要求は、第１のユーザグループカテゴリおよび第１のリソースタイプを表す要求特性データを含み、前記方法はさらに、
    前記第１のユーザグループカテゴリによってプロビジョニングされる前記第１のリソースタイプに対応するリソースタグに関連付けられる、前記テナンシにおけるリソースの第１の使用量を判断することと、
    前記第１のユーザグループカテゴリによってプロビジョニングされる前記第１のリソースタイプの、前記テナンシにおける前記判断されたリソースの第１の使用量に基づいて、リソース使用追跡データを生成することとを含む、請求項８～１２のいずれかに記載の方法。
14. 前記方法はさらに、
    前記テナンシの前記リソースをプロビジョニングするオーバーライド要求を受信することと、
    前記オーバーライド要求を受信することに基づいて前記リソースを選択的にプロビジョニングすることと、
    前記オーバーライド要求を受信したことに応答して前記リソースが選択的にプロビジョニングされることに基づいて、リソース使用過剰データを生成することとを含む、請求項８～１３のいずれかに記載の方法。
15. 請求項８～１４のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。