アカウントにスケーリンググループなどのクラウドリソースが多数ある場合は、リソースグループを使用してリソースを整理し、リソース分離ときめ細かなアクセス制御を実現できます。このトピックでは、リソースグループを使用して Auto Scaling リソースを管理する方法について説明します。
背景
リソースグループは、目的、権限、所有者などのディメンションに基づいてクラウドリソースをグループ化することで、リソースの管理に役立ちます。これにより、組織内の複数のユーザーやプロジェクトの階層的なリソース管理が容易になります。クラウドリソースは 1 つのリソースグループにのみ属することができ、リソースグループに追加されても他のリソースとの関係に影響はありません。詳細については、「リソースグループ」をご参照ください。
リソースグループを使用する際は、次の点にご注意ください。
-
スケーリンググループをリソースグループに追加すると、スケーリング設定、スケーリングルール、イベントトリガータスク、スケジュールタスクなどの関連リソースが、自動的に同じリソースグループに追加されます。
-
スケーリンググループのリソースグループと、そのグループ内のインスタンスのリソースグループは、互いに独立しています。
たとえば、あるスケーリンググループと、そのグループによってスケールアウトされる ECS インスタンスやエラスティックコンテナインスタンスが、それぞれ異なるリソースグループに属することが可能です。
-
リソースグループには、異なるリージョンのスケーリンググループを含めることができます。
たとえば、あるリソースグループに、中国 (北京) リージョンのスケーリンググループと、中国 (杭州) リージョンの別のスケーリンググループを含めることができます。
-
すべての Alibaba Cloud リソースを管理する権限を RAM ユーザーに付与した場合、その RAM ユーザーはメインアカウントのすべてのリソースグループを閲覧できます。
ユースケース
リソースグループを使用してスケーリンググループを管理する前に、RAM ユーザーが作成済みであることを確認してください。まだ作成していない場合は、「RAM ユーザーの作成」をご参照ください。
リソースグループを使用して、次のユースケースでスケーリンググループを管理できます。
-
目的の異なるスケーリンググループを異なるリソースグループに追加して、分類・管理します。詳細については、「シナリオ 1:目的別のスケーリンググループのグループ化」をご参照ください。
-
各リソースグループに個別の管理者を割り当てて、各グループのスコープ内でユーザーと権限を管理します。詳細については、「シナリオ 2:リソースグループへの管理者アクセスのスコープ設定」をご参照ください。
シナリオ 1:目的別のスケーリンググループのグループ化
概要
本番環境とテスト環境の両方があると仮定します。これらのスケーリンググループが整理されていない場合、すべてが 1 つのリストに表示され、操作ミスが発生しやすくなります。管理を簡素化し、ミスを防ぐために、本番環境用とテスト環境用に 2 つのリソースグループを作成することを推奨します。その後、目的に応じてスケーリンググループをそれぞれのリソースグループに追加できます。
たとえば、Alibaba Cloud アカウントに、本番環境用のスケーリンググループ A とテスト環境用のスケーリンググループ B の 2 つのスケーリンググループがあるとします。スケーリンググループ A を本番リソースグループに、スケーリンググループ B をテストリソースグループに追加します。要件は次のとおりです。
-
テストリソースグループでは、スケーリンググループ B のみを表示および管理できます。これにより、[すべてのリソース] スコープが選択されている場合に、オンラインサービスに影響を与える可能性のあるスケーリンググループ A への意図しない変更を防ぐことができます。
-
本番リソースグループでは、スケーリンググループ A のみを表示および管理できます。これにより、[すべてのリソース] スコープが選択されている場合に、本番リリースのスケジュールに影響を与える可能性のあるスケーリンググループ B への意図しない変更を防ぐことができます。
手順
-
テスト環境と本番環境用のリソースグループを作成します。
この例では、
ProdResourceGroupという名前の本番リソースグループとTestResourceGroupという名前のテストリソースグループを使用します。詳細については、「リソースグループの作成」をご参照ください。操作が完了すると、リソースグループのステータスは 作成中... になります。約 3 秒後、
をクリックします。ステータスが [使用可能] に変わると、リソースグループは正常に作成されたことになります。 -
テスト環境用のスケーリンググループを作成します。
スケーリンググループ内の ECS インスタンスをスケーリンググループと同じリソースグループに所属させるには、スケーリンググループ (たとえば
TestScalingGroup) を作成する際に、選択した インスタンス設定ソース に応じて、次の方法を使用します。-
インスタンス設定ソース を 起動テンプレート に設定した場合は、起動テンプレートを作成する際の [高度な設定 (オプション)] ステップで、リソースグループ を
TestResourceGroupとして指定します。詳細については、「起動テンプレートの作成」をご参照ください。 -
インスタンス設定ソース を 既存のインスタンスを選択 に設定した場合は、ECS インスタンスを作成する際の [高度な設定 (オプション)] セクションで、リソースグループ を
TestResourceGroupとして指定します。詳細については、「ウィザードを使用したインスタンスの作成」をご参照ください。 -
インスタンス設定ソース を 新規作成 に設定した場合は、スケーリング設定を作成する際の 詳細設定 セクションで、リソースグループ を
TestResourceGroupとして指定します。詳細については、「ECS インスタンスのスケーリング設定の作成」をご参照ください。
スケーリンググループのパラメーターを設定する際、リソースグループ を
TestResourceGroupに設定して、テスト環境用のスケーリンググループを作成します。詳細については、「スケーリンググループの作成」をご参照ください。 -
-
本番環境用のスケーリンググループを作成します。
スケーリンググループ内の ECS インスタンスをスケーリンググループと同じリソースグループに所属させるには、スケーリンググループ (たとえば
ProdScalingGroup) を作成する際に、選択した インスタンス設定ソース に応じて、次の方法を使用します。-
インスタンス設定ソース を 起動テンプレート に設定した場合は、起動テンプレートを作成する際の [高度な設定 (オプション)] ステップで、リソースグループ を
ProdResourceGroupとして指定します。詳細については、「起動テンプレートの作成」をご参照ください。 -
インスタンス設定ソース を 既存のインスタンスを選択 に設定した場合は、ECS インスタンスを作成する際の [高度な設定 (オプション)] セクションで、リソースグループ を
ProdResourceGroupとして指定します。詳細については、「ウィザードを使用したインスタンスの作成」をご参照ください。 -
インスタンス設定ソース を 新規作成 に設定した場合は、スケーリング設定を作成する際の 詳細設定 セクションで、リソースグループ を
ProdResourceGroupとして指定します。詳細については、「ECS インスタンスのスケーリング設定の作成」をご参照ください。
スケーリンググループのパラメーターを設定する際、リソースグループ を
ProdResourceGroupに設定して、本番環境用のスケーリンググループを作成します。詳細については、「スケーリンググループの作成」をご参照ください。 -
結果の検証
Auto Scalingコンソールにログインします。
-
上部メニューの左上で、異なるリソースグループを選択し、スケーリンググループとそれらのインスタンスの可視性を確認します。
-
[すべてのリソース] を選択すると、テストスケーリンググループ (
TestScalingGroup) と本番スケーリンググループ (ProdScalingGroup) の両方がスケーリンググループリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、テストリソースグループ (TestResourceGroup) と本番リソースグループ (ProdResourceGroup) の両方に属するすべてのインスタンスを表示できます。 -
[TestResourceGroup] を選択すると、
TestScalingGroupスケーリンググループのみがリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、テストリソースグループ (TestResourceGroup) に属するインスタンスのみを表示できます。 -
[ProdResourceGroup] を選択すると、
ProdScalingGroupスケーリンググループのみがリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、本番リソースグループ (ProdResourceGroup) に属するインスタンスのみを表示できます。
-
シナリオ 2:リソースグループによる権限管理
概要
ある企業では、異なる部門が別々のスケーリンググループを使用しており、それらは異なるリソースグループ (たとえば、本番リソースグループとテストリソースグループ) に属していると仮定します。各部門には独自の管理者がいます。管理者が自部門のリソースグループ内のスケーリンググループのみを管理できるようにするには、スコープをそのグループに限定した権限を付与します。これにより、特定の管理者は本番環境のリソースのみを表示および操作でき、他の管理者はテスト環境のみに制限されます。
たとえば、ある企業が単一の Alibaba Cloud アカウントを使用し、各部門に RAM ユーザーを割り当てているとします。部門 A と部門 B の 2 つの部門について、互いに干渉することなく、それぞれが独立してスケーリンググループを管理できるようにすることが目標です。アクセス制御の要件は次のとおりです。
-
管理者は、他の部門のスケーリンググループを作成または変更したり、スケーリングルールなどの設定を変更したりすることはできません。
-
管理者は、他の部門のスケーリンググループを表示することはできません。
手順
-
RAM で、
ApiWithoutResourcePolicyという名前のカスタムポリシーを作成します。一部の Auto Scaling の API 操作はリソースグループベースの認証をサポートしていないため、これらの操作に対する権限を付与するカスタムポリシーを作成する必要があります。詳細については、「カスタムポリシーの作成」をご参照ください。
-
次の API 操作は、リソースグループベースの認証をサポートしていません。
-
DescribeRegions
-
DescribeLimitation
-
DescribeNotificationTypes
-
ListTagKeys
-
ListTagValues
-
-
ApiWithoutResourcePolicyカスタムポリシーには、次の内容を使用します。{ "Version": "1", "Statement": [ { "Action": [ "ess:DescribeRegions", "ess:DescribeLimitation", "ess:DescribeNotificationTypes", "ess:ListTagKeys", "ess:ListTagValues" ], "Resource": "*", "Effect": "Allow" } ] }
-
-
部門 A と部門 B の管理者用に RAM ユーザーを作成し、[Alibaba Cloud アカウント] スコープの権限を付与します。
この手順では、部門 A の管理者の例を示します。部門 A の管理者の RAM ユーザーを 権限付与の対象 として選択します。手順 1 で作成した
ApiWithoutResourcePolicyカスタムポリシーと AliyunECSFullAccess システムポリシーをアタッチします。詳細については、「RAM ユーザーへの権限付与」をご参照ください。-
部門 A の管理者にカスタムポリシーを付与します。
[権限の追加] パネルで、[承認スコープ] を [Alibaba Cloud アカウント] に設定し、[プリンシパル] がターゲットの RAM ユーザーであることを確認し、[カスタムポリシー] タブをクリックして、
ApiWithoutResourcePolicyポリシーを検索して選択します。 -
[権限の追加] ページで、[承認スコープ] を [Alibaba Cloud アカウント] に設定し、[プリンシパル] がターゲットの RAM ユーザーであることを確認し、[システムポリシー] タブをクリックして、
AliyunECSFullAccess(Elastic Compute Service を管理する権限) を検索して選択します。
-
-
部門 A 用に DepartmentA という名前のリソースグループを、部門 B 用に DepartmentB という名前のリソースグループを作成します。
詳細については、「リソースグループの作成」をご参照ください。
-
部門 A の管理者に、スコープを DepartmentA リソースグループに限定した AliyunESSFullAccess ポリシーを付与します。
詳細については、「リソースグループの RAM ID への権限付与」または「RAM ユーザーへの権限付与」をご参照ください。
-
手順 4 を繰り返し、部門 B の管理者に、スコープを DepartmentB リソースグループに限定した AliyunESSFullAccess ポリシーを付与します。
権限の範囲 を「特定のリソースグループ」に設定して
DepartmentBを選択し、部門 B の管理者の RAM ユーザーを 権限付与の対象 として選択します。
結果の検証
Auto Scalingコンソールにログインします。
-
上部メニューの左上で、異なるリソースグループを選択し、スケーリンググループの作成を試みます。
詳細については、「スケーリンググループの作成」をご参照ください。
-
[DepartmentA] を選択すると、部門 A の管理者は DepartmentA リソースグループにスケーリンググループを正常に作成できます。
スケーリンググループページに、スケーリンググループ ScalingGroup-A がタイプ ECS、ステータス 有効 で表示されます。
-
[DepartmentB] を選択すると、部門 A の管理者には DepartmentB リソースグループにスケーリンググループを作成する権限がありません。
コンソールはエラーコード
Forbidden.Unauthorizedを返します。ポリシータイプは アイデンティティベースのポリシー (リソースグループレベル) で、権限判定は「暗黙的に拒否」です。
-
-
部門 A の管理者が異なるリソースグループのスケーリンググループを表示できるかどうかを確認します。
詳細については、「スケーリンググループの表示」をご参照ください。
-
部門 A の管理者は、DepartmentA リソースグループのスケーリンググループを正常に表示できます。
スケーリンググループページには、ScalingGroup-A が、タイプが ECS、ステータスが「有効」、最大インスタンス数が 1、実行中のインスタンスがない状態で表示されます。
-
部門 A の管理者が DepartmentB リソースグループのスケーリンググループを表示しようとすると、権限が拒否されます。
エラー詳細には、エラーコード「
Forbidden.Unauthorized」、認証アクション「ess:DescribeScalingGroups」、ポリシータイプ「アイデンティティベースのポリシー (リソースグループレベル)」、および権限判定「暗黙的に拒否」が表示されます。
-