翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon EC2 Auto Scaling アイデンティティベースのポリシーの例
デフォルトでは、 のまったく新しいユーザー AWS アカウント には、何もするアクセス許可がありません。IAM 管理者は、IAM アイデンティティ (ユーザーやロールなど) に Amazon EC2 Auto Scaling API アクションを実行する許可を与える IAM ポリシーを作成して割り当てる必要があります。
これらの JSON ポリシードキュメント例を使用して IAM ポリシーを作成する方法については、IAM ユーザーガイドの「JSON タブでのポリシーの作成」を参照してください。
以下に示しているのは、アクセス許可ポリシーの例です。
このサンプルポリシーは、グループが タグを使用している場合に限り、Auto Scaling グループを作成、更新、削除する許可を付与します。purpose=testingDescribe アクションはリソースレベルの許可をサポートしないため、条件のない別のステートメントで指定する必要があります。起動テンプレートを使用してインスタンスを起動するには、ユーザーに ec2:RunInstances アクセス許可も必要です。詳細については、「Auto Scaling グループで Amazon EC2 起動テンプレートの使用を制御する」を参照してください。
注記
独自のカスタム IAM ポリシーを作成し、IAM アイデンティティ (ユーザーまたはロール) に Amazon EC2 Auto Scaling アクションを実行するための許可または拒否することができます。これらのカスタムポリシーは、指定された許可が必要な IAM アイデンティティにアタッチできます。次の例では、いくつかの一般的ユースケースの許可を示します。
Amazon EC2 Auto Scaling API アクションの中には、アクションによって作成/変更できるポリシー内に特定の Auto Scaling グループを持つことを許可するものもあります。これらのアクションの対象となるリソースを制限するには、Auto Scaling グループの ARN を個別に指定します。ただし、ベストプラクティスとして、特定のタグを持つ Auto Scaling グループに対するアクションを許可 (または拒否) するタグベースのポリシーを使用することをお勧めします。
例
作成できる Auto Scaling グループのサイズを制御する
次のポリシーでは、リクエスタが最小サイズとして 1 未満または最大サイズとして 10 より大きい値を指定しない限り、タグ を持つすべての Auto Scaling グループを作成および更新する許可が付与されます。可能な限りタグを使用して、アカウント内の Auto Scaling グループへのアクセスを制御できるようにします。environment=development
Auto Scaling グループへのアクセス制御にタグを使用していない場合は、ARN を使用して IAM ポリシーが適用される Auto Scaling グループを識別できます。
Auto Scaling グループには、次の ARN があります。
"Resource": "arn:aws:autoscaling:region:account-id:autoScalingGroup:*:autoScalingGroupName/my-asg"
複数の ARN をリストに含めて指定することもできます。Resource 要素での Amazon EC2 Auto Scaling リソースの ARN の指定の詳細については、「Amazon EC2 Auto Scaling のポリシーリソース」を参照してください。
使用できるタグキーとタグ値を制御する
また、IAM ポリシーの条件を使用して、Auto Scaling グループに適用できるタグキーとタグ値を制御することもできます。リクエスタが特定のタグを指定する場合に限り、Auto Scaling グループを作成またはタグ付けする許可を付与するには、aws:RequestTag 条件キーを使用します。特定のタグキーのみ許可するには、aws:TagKeys 修飾子とともに ForAllValues 条件キーを使用します。
次のポリシーでは、リクエストでキー にタグを指定することをリクエスタに要求されます。environment 値は、タグキーに何らかの値を含めることを強制します。ワイルドカードを含める場合は、"?*"StringLike 条件演算子を使用する必要があります。
次のポリシーでは、リクエスタが Auto Scaling グループにタグ付けできるタグは および purpose=webserver であることを指定し、cost-center=cc123 タグおよび purpose タグのみが許可されます (他のタグは指定できません)。cost-center
次のポリシーでは、リクエスタがリクエストで少なくとも 1 つのタグを指定することを要求し、 および cost-center キーのみ使用できます。owner
注記
条件においては条件キーでは大文字と小文字が区別されず、条件値では大文字と小文字が区別されます。したがって、タグキーの大文字と小文字を区別するには条件の値としてタグキーが指定される aws:TagKeys 条件キーを使用します。
削除できる Auto Scaling グループを制御する
次のポリシーは、グループにタグ が付けられている場合にのみ、Auto Scaling グループの削除を許可します。environment=development
次のポリシーでは、 autoscaling:ForceDelete条件キーを使用して DeleteAutoScalingGroup API アクションへのアクセスを制御します。これにより、特定のユーザーが強制削除オペレーションを使用できなくなり、グループを削除すると Auto Scaling グループ内のすべてのインスタンスが終了します。
Auto Scaling グループへのアクセス制御で条件キーを使用していない場合は、代わりに Resource 要素内のリソースの ARN を指定してアクセスを制御できます。
次のポリシーは、名前が で始まる Auto Scaling グループについてのみ、devteam-DeleteAutoScalingGroup API アクションを使用するための許可をユーザーに付与します。
複数の ARN をリストに含めて指定することもできます。UUID を含めることで、特定の Auto Scaling グループに確実にアクセス許可が付与されます。新しいグループの UUID は、削除された同じ名前のグループの UUID とは異なります。
"Resource": [ "arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-1", "arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-2", "arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-3" ]
削除できるスケーリングポリシーを制御する
次のポリシーでは、DeletePolicy アクションを使用してスケーリングポリシーを削除する許可が付与されます。ただし、処理対象の Auto Scaling グループに タグがある場合、そのアクションを拒否します。可能な限りタグを使用して、アカウント内の Auto Scaling グループへのアクセスを制御できるようにします。environment=production
インスタンスの更新アクションへのアクセスを制御する
次のポリシーは、処理対象の Auto Scaling グループにタグ が付けられている場合にのみ、インスタンスの更新を開始、ロールバック、キャンセルするアクセス許可を付与します。environment=testingDescribe アクションはリソースレベルの許可をサポートしないため、条件のない別のステートメントで指定する必要があります。
StartInstanceRefresh 呼び出しで希望する設定を指定するには、次のような関連するアクセス許可が必要になる場合があります。
-
ec2:RunInstances — ユーザーが起動テンプレートを使用して EC2 インスタンスを起動するには、IAM ポリシーの
ec2:RunInstancesアクセス許可が必要です。詳細については、「Auto Scaling グループで Amazon EC2 起動テンプレートの使用を制御する」を参照してください。 -
ec2:CreateTags — ユーザーがインスタンスとボリュームの作成時にタグを追加する起動テンプレートから EC2 インスタンスを起動するには、IAM ポリシーの
ec2:CreateTagsアクセス許可が必要です。詳細については、「インスタンスおよびボリュームにタグ付けするために必要なアクセス許可」を参照してください。 -
iam:PassRole — ユーザーがインスタンスプロファイル (IAM ロールのコンテナ) を含む起動テンプレートから EC2 インスタンスを起動するには、IAM ポリシーの
iam:PassRoleアクセス許可も必要です。詳細および IAM ポリシーの例については、「Amazon EC2 インスタンスで実行中のアプリケーション用の IAM ロール」を参照してください。 -
ssm:GetParameters – AWS Systems Manager パラメータを使用する起動テンプレートから EC2 インスタンスを起動するには、ユーザーに IAM ポリシーの アクセス
ssm:GetParameters許可も必要です。詳細については、「起動テンプレートで AMI ID の代わりに AWS Systems Manager パラメータを使用する」を参照してください。
サービスにリンクされたロールの作成
Amazon EC2 Auto Scaling では、 のユーザーが Amazon EC2 Auto Scaling API アクションを初めて AWS アカウント 呼び出すときに、サービスにリンクされたロールを作成するためのアクセス許可が必要です。サービスにリンクされたロールがまだ存在しない場合は、Amazon EC2 Auto Scaling によってアカウント内に作成されます。サービスにリンクされたロールは、ユーザーに代わって他の を呼び出すことができるように、Amazon EC2 Auto Scaling AWS のサービス にアクセス許可を付与します。
この自動ロール作成を成功させるには、ユーザーには iam:CreateServiceLinkedRole アクションへのアクセス許可が必要です。
"Action": "iam:CreateServiceLinkedRole"
以下は、Amazon EC2 Auto Scaling に対する Amazon EC2 Auto Scaling のサービスにリンクされたロールの作成をユーザーに許可するアクセス許可ポリシーの例です。
どのサービスにリンクされたロールを渡せるかを制御する (PassRole を使用)
Auto Scaling グループを作成または更新し、リクエストでカスタムサフィックスサービスにリンクされたロールを指定するユーザーは、iam:PassRole 許可が必要です。
異なるサービスにリンクされたロールに異なるキーへのアクセスを許可する場合は、 アクセスiam:PassRole許可を使用して AWS KMS カスタマーマネージドキーのセキュリティを保護できます。組織の必要に応じて、開発チームに 1 つの キー、QA チームにもう 1 つの キー、そして財務チームにもう 1 つの キー を持つことができます。まず、必要なキーにアクセスできるサービスリンクロールを作成します。例えば、AWSServiceRoleForAutoScaling_devteamkeyaccess という名前のサービスリンクロールを作成します。次に、ポリシーをユーザーまたはロールなどの IAM アイデンティティにアタッチします。
次のポリシーは、名前が で始まる Auto Scaling グループに devteam-AWSServiceRoleForAutoScaling_devteamkeyaccess ロールを渡すための許可を付与します。Auto Scaling グループを作成する IAM アイデンティティがサービスにリンクされた別のロールを指定しようとすると、エラーが表示されます。サービスにリンクされたロールを指定しないことを選択した場合は、代わりにデフォルトの AWSServiceRoleForAutoScaling ロールが使用されます。
カスタムサフィックス付きのサービスにリンクされたロールの詳細については、「Amazon EC2 Auto Scaling のサービスにリンクされたロール」を参照してください。