すべてのプロダクト
Search
ドキュメントセンター

Auto Scaling:リソースグループを使用したスケーリンググループの管理

最終更新日:Jun 22, 2026

アカウントにスケーリンググループなどのクラウドリソースが多数ある場合は、リソースグループを使用してリソースを整理し、リソース分離ときめ細かなアクセス制御を実現できます。このトピックでは、リソースグループを使用して Auto Scaling リソースを管理する方法について説明します。

背景

リソースグループは、目的、権限、所有者などのディメンションに基づいてクラウドリソースをグループ化することで、リソースの管理に役立ちます。これにより、組織内の複数のユーザーやプロジェクトの階層的なリソース管理が容易になります。クラウドリソースは 1 つのリソースグループにのみ属することができ、リソースグループに追加されても他のリソースとの関係に影響はありません。詳細については、「リソースグループ」をご参照ください。

リソースグループを使用する際は、次の点にご注意ください。

  • スケーリンググループをリソースグループに追加すると、スケーリング設定、スケーリングルール、イベントトリガータスク、スケジュールタスクなどの関連リソースが、自動的に同じリソースグループに追加されます。

  • スケーリンググループのリソースグループと、そのグループ内のインスタンスのリソースグループは、互いに独立しています。

    たとえば、あるスケーリンググループと、そのグループによってスケールアウトされる ECS インスタンスやエラスティックコンテナインスタンスが、それぞれ異なるリソースグループに属することが可能です。

  • リソースグループには、異なるリージョンのスケーリンググループを含めることができます。

    たとえば、あるリソースグループに、中国 (北京) リージョンのスケーリンググループと、中国 (杭州) リージョンの別のスケーリンググループを含めることができます。

  • すべての Alibaba Cloud リソースを管理する権限を RAM ユーザーに付与した場合、その RAM ユーザーはメインアカウントのすべてのリソースグループを閲覧できます。

ユースケース

説明

リソースグループを使用してスケーリンググループを管理する前に、RAM ユーザーが作成済みであることを確認してください。まだ作成していない場合は、「RAM ユーザーの作成」をご参照ください。

リソースグループを使用して、次のユースケースでスケーリンググループを管理できます。

シナリオ 1:目的別のスケーリンググループのグループ化

概要

本番環境とテスト環境の両方があると仮定します。これらのスケーリンググループが整理されていない場合、すべてが 1 つのリストに表示され、操作ミスが発生しやすくなります。管理を簡素化し、ミスを防ぐために、本番環境用とテスト環境用に 2 つのリソースグループを作成することを推奨します。その後、目的に応じてスケーリンググループをそれぞれのリソースグループに追加できます。

たとえば、Alibaba Cloud アカウントに、本番環境用のスケーリンググループ A とテスト環境用のスケーリンググループ B の 2 つのスケーリンググループがあるとします。スケーリンググループ A を本番リソースグループに、スケーリンググループ B をテストリソースグループに追加します。要件は次のとおりです。

  • テストリソースグループでは、スケーリンググループ B のみを表示および管理できます。これにより、[すべてのリソース] スコープが選択されている場合に、オンラインサービスに影響を与える可能性のあるスケーリンググループ A への意図しない変更を防ぐことができます。

  • 本番リソースグループでは、スケーリンググループ A のみを表示および管理できます。これにより、[すべてのリソース] スコープが選択されている場合に、本番リリースのスケジュールに影響を与える可能性のあるスケーリンググループ B への意図しない変更を防ぐことができます。

手順

  1. テスト環境と本番環境用のリソースグループを作成します。

    この例では、ProdResourceGroup という名前の本番リソースグループと TestResourceGroup という名前のテストリソースグループを使用します。詳細については、「リソースグループの作成」をご参照ください。

    操作が完了すると、リソースグループのステータスは 作成中... になります。約 3 秒後、p80945.png をクリックします。ステータスが [使用可能] に変わると、リソースグループは正常に作成されたことになります。

  2. テスト環境用のスケーリンググループを作成します。

    スケーリンググループ内の ECS インスタンスをスケーリンググループと同じリソースグループに所属させるには、スケーリンググループ (たとえば TestScalingGroup) を作成する際に、選択した インスタンス設定ソース に応じて、次の方法を使用します。

    • インスタンス設定ソース起動テンプレート に設定した場合は、起動テンプレートを作成する際の [高度な設定 (オプション)] ステップで、リソースグループTestResourceGroup として指定します。詳細については、「起動テンプレートの作成」をご参照ください。

    • インスタンス設定ソース既存のインスタンスを選択 に設定した場合は、ECS インスタンスを作成する際の [高度な設定 (オプション)] セクションで、リソースグループTestResourceGroup として指定します。詳細については、「ウィザードを使用したインスタンスの作成」をご参照ください。

    • インスタンス設定ソース新規作成 に設定した場合は、スケーリング設定を作成する際の 詳細設定 セクションで、リソースグループTestResourceGroup として指定します。詳細については、「ECS インスタンスのスケーリング設定の作成」をご参照ください。

    スケーリンググループのパラメーターを設定する際、リソースグループTestResourceGroup に設定して、テスト環境用のスケーリンググループを作成します。詳細については、「スケーリンググループの作成」をご参照ください。

  3. 本番環境用のスケーリンググループを作成します。

    スケーリンググループ内の ECS インスタンスをスケーリンググループと同じリソースグループに所属させるには、スケーリンググループ (たとえば ProdScalingGroup) を作成する際に、選択した インスタンス設定ソース に応じて、次の方法を使用します。

    • インスタンス設定ソース起動テンプレート に設定した場合は、起動テンプレートを作成する際の [高度な設定 (オプション)] ステップで、リソースグループProdResourceGroup として指定します。詳細については、「起動テンプレートの作成」をご参照ください。

    • インスタンス設定ソース既存のインスタンスを選択 に設定した場合は、ECS インスタンスを作成する際の [高度な設定 (オプション)] セクションで、リソースグループProdResourceGroup として指定します。詳細については、「ウィザードを使用したインスタンスの作成」をご参照ください。

    • インスタンス設定ソース新規作成 に設定した場合は、スケーリング設定を作成する際の 詳細設定 セクションで、リソースグループProdResourceGroup として指定します。詳細については、「ECS インスタンスのスケーリング設定の作成」をご参照ください。

    スケーリンググループのパラメーターを設定する際、リソースグループProdResourceGroup に設定して、本番環境用のスケーリンググループを作成します。詳細については、「スケーリンググループの作成」をご参照ください。

結果の検証

  1. Auto Scalingコンソールにログインします。

  2. 上部メニューの左上で、異なるリソースグループを選択し、スケーリンググループとそれらのインスタンスの可視性を確認します。

    • [すべてのリソース] を選択すると、テストスケーリンググループ (TestScalingGroup) と本番スケーリンググループ (ProdScalingGroup) の両方がスケーリンググループリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、テストリソースグループ (TestResourceGroup) と本番リソースグループ (ProdResourceGroup) の両方に属するすべてのインスタンスを表示できます。

    • [TestResourceGroup] を選択すると、TestScalingGroup スケーリンググループのみがリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、テストリソースグループ (TestResourceGroup) に属するインスタンスのみを表示できます。

    • [ProdResourceGroup] を選択すると、ProdScalingGroup スケーリンググループのみがリストに表示されます。スケーリンググループが新しい ECS インスタンスをスケールアウトした場合、インスタンス タブで、本番リソースグループ (ProdResourceGroup) に属するインスタンスのみを表示できます。

シナリオ 2:リソースグループによる権限管理

概要

ある企業では、異なる部門が別々のスケーリンググループを使用しており、それらは異なるリソースグループ (たとえば、本番リソースグループとテストリソースグループ) に属していると仮定します。各部門には独自の管理者がいます。管理者が自部門のリソースグループ内のスケーリンググループのみを管理できるようにするには、スコープをそのグループに限定した権限を付与します。これにより、特定の管理者は本番環境のリソースのみを表示および操作でき、他の管理者はテスト環境のみに制限されます。

たとえば、ある企業が単一の Alibaba Cloud アカウントを使用し、各部門に RAM ユーザーを割り当てているとします。部門 A と部門 B の 2 つの部門について、互いに干渉することなく、それぞれが独立してスケーリンググループを管理できるようにすることが目標です。アクセス制御の要件は次のとおりです。

  • 管理者は、他の部門のスケーリンググループを作成または変更したり、スケーリングルールなどの設定を変更したりすることはできません。

  • 管理者は、他の部門のスケーリンググループを表示することはできません。

手順

  1. 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"
             }
          ]
      }
  2. 部門 A と部門 B の管理者用に RAM ユーザーを作成し、[Alibaba Cloud アカウント] スコープの権限を付与します。

    この手順では、部門 A の管理者の例を示します。部門 A の管理者の RAM ユーザーを 権限付与の対象 として選択します。手順 1 で作成した ApiWithoutResourcePolicy カスタムポリシーと AliyunECSFullAccess システムポリシーをアタッチします。詳細については、「RAM ユーザーへの権限付与」をご参照ください。

    • 部門 A の管理者にカスタムポリシーを付与します。

      [権限の追加] パネルで、[承認スコープ][Alibaba Cloud アカウント] に設定し、[プリンシパル] がターゲットの RAM ユーザーであることを確認し、[カスタムポリシー] タブをクリックして、ApiWithoutResourcePolicy ポリシーを検索して選択します。

    • [権限の追加] ページで、[承認スコープ][Alibaba Cloud アカウント] に設定し、[プリンシパル] がターゲットの RAM ユーザーであることを確認し、[システムポリシー] タブをクリックして、AliyunECSFullAccess (Elastic Compute Service を管理する権限) を検索して選択します。

  3. 部門 A 用に DepartmentA という名前のリソースグループを、部門 B 用に DepartmentB という名前のリソースグループを作成します。

    詳細については、「リソースグループの作成」をご参照ください。

  4. 部門 A の管理者に、スコープを DepartmentA リソースグループに限定した AliyunESSFullAccess ポリシーを付与します。

    詳細については、「リソースグループの RAM ID への権限付与」または「RAM ユーザーへの権限付与」をご参照ください。

  5. 手順 4 を繰り返し、部門 B の管理者に、スコープを DepartmentB リソースグループに限定した AliyunESSFullAccess ポリシーを付与します。

    権限の範囲 を「特定のリソースグループ」に設定して DepartmentB を選択し、部門 B の管理者の RAM ユーザーを 権限付与の対象 として選択します。

結果の検証

  1. Auto Scalingコンソールにログインします。

  2. 上部メニューの左上で、異なるリソースグループを選択し、スケーリンググループの作成を試みます。

    詳細については、「スケーリンググループの作成」をご参照ください。

    • [DepartmentA] を選択すると、部門 A の管理者は DepartmentA リソースグループにスケーリンググループを正常に作成できます。

      スケーリンググループページに、スケーリンググループ ScalingGroup-A がタイプ ECS、ステータス 有効 で表示されます。

    • [DepartmentB] を選択すると、部門 A の管理者には DepartmentB リソースグループにスケーリンググループを作成する権限がありません。

      コンソールはエラーコード Forbidden.Unauthorized を返します。ポリシータイプは アイデンティティベースのポリシー (リソースグループレベル) で、権限判定は「暗黙的に拒否」です。

  3. 部門 A の管理者が異なるリソースグループのスケーリンググループを表示できるかどうかを確認します。

    詳細については、「スケーリンググループの表示」をご参照ください。

    • 部門 A の管理者は、DepartmentA リソースグループのスケーリンググループを正常に表示できます。

      スケーリンググループページには、ScalingGroup-A が、タイプが ECS、ステータスが「有効」、最大インスタンス数が 1、実行中のインスタンスがない状態で表示されます。

    • 部門 A の管理者が DepartmentB リソースグループのスケーリンググループを表示しようとすると、権限が拒否されます。

      エラー詳細には、エラーコード「Forbidden.Unauthorized」、認証アクション「ess:DescribeScalingGroups」、ポリシータイプ「アイデンティティベースのポリシー (リソースグループレベル)」、および権限判定「暗黙的に拒否」が表示されます。