Can I restrict the access of IAM Identity to specific Amazon EC2 resources?

Last updated: 2022-10-20

I want to restrict access of an AWS Identity and Access Management (IAM) user/group/role to a specific Amazon Elastic Compute Cloud (Amazon EC2) resource on the same account. How can I do this?

Resolution

Amazon EC2 has partial support for resource-level permissions or conditions. This means that for certain Amazon EC2 actions, you can control when users are allowed to use those actions based on conditions that have to be fulfilled, or specific resources that users are allowed to use.

Isolating IAM users or groups of user's access to Amazon EC2 resources by any criteria other than AWS Region doesn't fit most use cases. If you must isolate your resources by Region or any conditions on the same account, be sure to check the list of Amazon EC2 actions that support resource-level permissions and conditions to verify that your use case is supported.

Below is an example of a policy that can be used to restrict access of an IAM identity (user/group/role) to only Start/Stop/Reboot EC2 instances in the N. Virginia (us-east-1) Region. The instance must have a tag key of "Owner" with a tag value of "Bob." "ec2:Describe*" is added to the policy to grant permission to describe the EC2 instance and all associated resources in the AWS management EC2 console.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": [
        "arn:aws:ec2:us-east-1:111122223333:instance/*"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Owner": "Bob"
        }
      }
    }
  ]
}

Note: Replace "Owner," "Bob," and the resource ARN with parameters from your environment.

After creating the policy, you can attach it to either an IAM user, group, or role

For tagging use cases and best practices, see Best practices.