Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?

Question

What the title says.

Within the master AWS account, I have several personal accounts, i.e. AWS Identity and Access Management (IAM) users. I would like to assign certain IAM users to groups and prevent them from terminating certain Amazon EC2 instances, de-registering certain Amazon Machine Images (AMIs), etc.

I don't mind if they're playing with their own stuff, but I don't want them to touch my stuff.

Is that possible?

Solution

Update

AWS has just announced Resource-Level Permissions for Amazon EC2 and Amazon RDS to address this long standing shortcoming of IAM support within EC2 and RDS (in comparison to other AWS services, see my original answer below for details/background):

Today we are making IAM even more powerful with the introduction of resource-level permissions for Amazon EC2 and Amazon RDS. [...]

On the EC2 side, you can now construct and use IAM policies to control access to EC2 instances, EBS volumes, images, and Elastic IP addresses. [...]

Here are just a few of things that you can do:

• Allow users to act on a limited set of resources within a larger, multi-user EC2 environment.
• Set different permissions for "development" and "test" resources.
• Control which users can terminate which instances.
• Require additional security measures, such as MFA authentication, when acting on certain resources.

This solves a plethora of security complications and enables quite a few new use cases as well.

Furthermore, EC2 policy statements can include reference to tags on EC2 resources, which allows to use the same tagging model and schema for permissions and for billing reports. Finally, there's an expanded set of condition tags [...] including ec2:Region, ec2:Owner, and ec2:InstanceType, see Condition Keys for Amazon EC2 for details.

Solution

Here's a variation of Example 3: Allow users to stop and start only particular instances for the use case at hand, which allows users to start and stop [and terminate] only the instances that have the tag "department=dev":

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
        "ec2:StopInstances", 
        "ec2:StartInstances",
        "ec2:TeminateInstances"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/department": "dev"
        }
      }
    }
   ]
}

Caveat

Support for resource-level permissions is restricted to the following set of actions on the indicated resources still, which excludes parts of the use case (e.g. de-registering AMIs) - the confidence in the foundation for this complex and far-reaching feature is apparently high enough though to announce that they plan to add support for additional APIs throughout the rest of 2013 (AWS doesn't usually publish any roadmaps):

• Instances - Reboot, Start, Stop, Terminate.
• EBS Volumes - Attach, Delete, Detach.

---

Original Answer

I'm afraid this isn't possible the way you'd like to do it (and many others for that matter, including myself).

Problem

You want to restrict access to a particular service's resources rather than its actions - while AWS Identity and Access Management (IAM) supports both in principle, not every AWS product/service offers restrictions based on resources yet; unfortunately Amazon EC2 is one of these and even featured as an example for this very difference, see Integrating with Other AWS Products:

The following table summarizes whether you can grant IAM permissions that control access to a service's actions, resources, or both. For example, you can use IAM to control which Amazon EC2 actions users have access to, but you can't use IAM to control users' access to AMIs, volumes, instances, etc. [emphasis mine]

(Partial) Workaround

Depending on the needs of the other accounts, you might still be able to at least limit their ability to perform those actions considered destructive - you can explore the available actions via the AWS Policy Generator, for example:

• ec2:DeregisterImage - obvious effect, when denied for a user/group
• ec2:ModifyInstanceAttribute - this would help via Enabling Termination Protection for an Instance, when denied for a user/group:

By default, you can terminate any instances you launch. If you want to prevent accidental termination of the instance, you can enable termination protection for the instance.

That is, once you've enabled termination protection, anyone without permission to use ec2:ModifyInstanceAttribute cannot terminate these instances at all.

Obviously the respectively restricted accounts won't be able to facilitate those calls for their own resources anymore.

Furthermore this won't prevent them from running a fancy Cluster Compute Eight Extra Large Instance or so, incurring respective costs in turn ;)

Alternative Approach

Depending on your setup/environment you might want to look into Consolidated Billing instead, which essentially provides a way to gather one or many AWS accounts under another one, which is paying for the resources used by the others.

While this is primarily an accounting feature, it can be used to separate areas of concern as well - for example, it's quite common to facilitate separate development and production accounts to achieve respectively independent operation, not the least regarding IAM rights and the like.

The introductory blog post New AWS Feature: Consolidated Billing provides a good overview, and here is the relevant topic from the AWS Consolidated Billing Guide regarding your apparent use case:

The paying account is billed for all costs of the linked accounts. However, each linked account is completely independent in every other way (signing up for services, accessing resources, using AWS Premium Support, etc.). The paying account owner cannot access data belonging to the linked account owners (e.g., their files in Amazon S3). Each account owner uses their own AWS credentials to access their resources (e.g., their own AWS Secret Access Key). [emphasis mine]

Obviously this functionality is targeted at larger customers, but depending on your scenario you might be able to come up with a solution to separate your AWS accounts and resources as needed still.