Example policies to control access the Amazon EC2 API
You can use IAM policies to grant users the permissions required to work with Amazon EC2. For step-by-step directions, see Creating IAM policies in the IAM User Guide.
The following examples show policy statements that you could use to grant users permissions
to use Amazon EC2. These policies are designed for requests that are made using the AWS CLI or an
AWS SDK. In the following examples, replace each user input placeholder
with your own information.
For example policies for working in the Amazon EC2 console, see Example policies to control access to the Amazon EC2 console.
Example: Read-only access
The following policy grants users permissions to use all Amazon EC2 API actions whose names
begin with Describe. The Resource element uses a wildcard to
indicate that users can specify all resources with these API actions. The * wildcard is
also necessary in cases where the API action does not support resource-level
permissions. For more information about which ARNs you can use with which Amazon EC2 API
actions, see Actions, resources, and condition keys for Amazon EC2.
Users don't have permission to perform any actions on the resources (unless another statement grants them permission to do so) because they're denied permission to use API actions by default.
Example: Restrict access to a specific Region
The following policy denies users permission to use all Amazon EC2 API actions unless the
Region is Europe (Frankfurt). It uses the global condition key
aws:RequestedRegion, which is supported by all Amazon EC2 API actions.
Alternatively, you can use the condition key ec2:Region, which is specific to
Amazon EC2 and is supported by all Amazon EC2 API actions.
Work with instances
Examples
Example: Describe, launch, stop, start, and terminate all instances
The following policy grants users permissions to use the API actions specified in the
Action element. The Resource element uses a * wildcard
to indicate that users can specify all resources with these API actions. The *
wildcard is also necessary in cases where the API action does not support
resource-level permissions. For more information about which ARNs you can use with
which Amazon EC2 API actions, see Actions, resources, and condition keys for Amazon EC2.
The users don't have permission to use any other API actions (unless another statement grants them permission to do so) because users are denied permission to use API actions by default.
Example: Describe all instances, and stop, start, and terminate only particular instances
The following policy allows users to describe all instances, to start and
stop only instances i-1234567890abcdef0 and i-0598c7d356eba48d7,
and to terminate only instances in the us-east-1
Region, with the resource tag "purpose=test".
The first statement uses a * wildcard for the Resource element to indicate
that users can specify all resources with the action; in this case, they can list
all instances. The * wildcard is also necessary in cases where the API action does
not support resource-level permissions (in this case,
ec2:DescribeInstances). For more information about which ARNs you
can use with which Amazon EC2 API actions, see Actions, resources, and condition keys for Amazon EC2.
The second statement uses resource-level permissions for the
StopInstances and StartInstances actions. The
specific instances are indicated by their ARNs in the Resource
element.
The third statement allows users to terminate all instances in the
us-east-1 Region that belong to the
specified AWS account, but only where the instance has the tag
"purpose=test". The Condition element
qualifies when the policy statement is in effect.
Launch instances (RunInstances)
The RunInstances
API action launches one or more On-Demand Instances or one or more Spot Instances. RunInstances requires an AMI and
creates an instance. Users can specify a key pair and security group in the request. Launching
into a VPC requires a subnet, and creates a network interface. Launching from an Amazon EBS-backed
AMI creates a volume. Therefore, the user must have permissions to use these Amazon EC2 resources.
You can create a policy statement that requires users to specify an optional parameter on
RunInstances, or restricts users to particular values for a parameter.
For more information about the resource-level permissions that are required to launch an instance, see Actions, resources, and condition keys for Amazon EC2.
By default, users don't have permissions to describe, start, stop, or terminate the resulting instances. One way to grant the users permission to manage the resulting instances is to create a specific tag for each instance, and then create a statement that enables them to manage instances with that tag. For more information, see Work with instances.
Resources
AMIs
The following policy allows users to launch instances using only the specified AMIs,
ami-9e1670f7 and ami-45cf5c3c. The users can't
launch an instance using other AMIs (unless another statement grants the
users permission to do so).
Alternatively, the following policy allows users to launch instances from all AMIs owned
by Amazon, or certain trusted and verified partners. The Condition element of the first statement tests
whether ec2:Owner is amazon. The users can't
launch an instance using other AMIs (unless another statement grants the
users permission to do so).
Instance types
The following policy allows users to launch instances using only the
t2.micro or t2.small instance type, which you
might do to control costs. The users can't launch larger instances because
the Condition element of the first statement tests whether
ec2:InstanceType is either t2.micro or
t2.small.
Alternatively, you can create a policy that denies users permissions to launch any
instances except t2.micro and t2.small instance
types.
Subnets
The following policy allows users to launch instances using only the specified subnet,
subnet-. The group can't
launch instances into any another subnet (unless another statement grants the users
permission to do so).12345678
Alternatively, you could create a policy that denies users permissions to launch an
instance into any other subnet. The statement does this by denying permission to
create a network interface, except where subnet
subnet- is specified. This
denial overrides any other policies that are created to allow launching instances
into other subnets.12345678
EBS volumes
The following policy allows users to launch instances only if the EBS volumes for the instance are encrypted. The user must launch an instance from an AMI that was created with encrypted snapshots, to ensure that the root volume is encrypted. Any additional volume that the user attaches to the instance during launch must also be encrypted.
Tags
Tag instances on creation
The following policy allows users to launch instances and tag the instances during
creation. For resource-creating actions that apply tags, users must have permissions to use
the CreateTags action. The second statement uses the
ec2:CreateAction condition key to allow users to create tags only in the
context of RunInstances, and only for instances. Users cannot tag existing
resources, and users cannot tag volumes using the RunInstances request.
For more information, see Grant permission to tag Amazon EC2 resources during creation.
Tag instances and volumes on creation with specific tags
The following policy includes the aws:RequestTag condition key that requires users
to tag any instances and volumes that are created by RunInstances with the tags
environment=production and purpose=webserver. If users don't pass these
specific tags, or if they don't specify tags at all, the request fails.
Tag instances and volumes on creation with at least one specific tag
The following policy uses the ForAnyValue modifier on the
aws:TagKeys condition to indicate that at least one tag
must be specified in the request, and it must contain the key
environment or webserver. The tag must be
applied to both instances and volumes. Any tag values can be specified in
the request.
If instances are tagged on creation, they must be tagged with a specific tag
In the following policy, users do not have to specify tags in the request,
but if they do, the tag must be purpose=test. No other tags are
allowed. Users can apply the tags to any taggable resource in the
RunInstances request.
To disallow anyone called tag on create for RunInstances
Only allow specific tags for spot-instances-request. Surprise inconsistency number 2 comes into play here. Under normal circumstances, specifying no tags will result in Unauthenticated. In the case of spot-instances-request, this policy will not be evaluated if there are no spot-instances-request tags, so a non-tag Spot on Run request will succeed.
Tags in a launch template
In the following example, users can launch instances, but only if they use a
specific launch template (lt-09477bcd97b0d310e). The
ec2:IsLaunchTemplateResource condition key prevents users from overriding any
of the resources specified in the launch template. The second part of the statement allows
users to tag instances on creation—this part of the statement is necessary if tags
are specified for the instance in the launch template.
Elastic GPUs
In the following policy, users can launch an instance and specify an
elastic GPU to attach to the instance. Users can launch instances in any Region, but they
can only attach an elastic GPU during a launch in the us-east-2 Region.
The ec2:ElasticGpuType condition key ensures that
instances use either the eg1.medium or eg1.large
elastic GPU type.
Launch templates
In the following example, users can launch instances, but only if they use a
specific launch template (lt-09477bcd97b0d310e). Users can override any
parameters in the launch template by specifying the parameters in the
RunInstances action.
In this example, users can launch instances only if they use a launch template. The
policy uses the ec2:IsLaunchTemplateResource condition key to prevent users
from overriding any pre-existing ARNs in the launch template.
The following example policy allows user to launch instances, but only if they use a launch template. Users cannot override the subnet and network interface parameters in the request; these parameters can only be specified in the launch template. The first part of the statement uses the NotResource element to allow all other resources except subnets and network interfaces. The second part of the statement allows the subnet and network interface resources, but only if they are sourced from the launch template.
The following example allows users to launch instances only if they use a
launch template, and only if the launch template has the tag
Purpose=Webservers. Users cannot override any of the launch
template parameters in the RunInstances action.
Work with Spot Instances
You can use the RunInstances action to create Spot Instance requests, and tag the Spot Instance requests
on create. The resource to specify for RunInstances is
spot-instances-request.
The spot-instances-request resource is evaluated in the IAM policy as
follows:
-
If you don't tag a Spot Instance request on create, Amazon EC2 does not evaluate the
spot-instances-requestresource in the RunInstances statement. -
If you tag a Spot Instance request on create, Amazon EC2 evaluates the
spot-instances-requestresource in the RunInstances statement.
Therefore, for the spot-instances-request resource, the following rules
apply to the IAM policy:
-
If you use RunInstances to create a Spot Instance request and you don't intend to tag the Spot Instance request on create, you don’t need to explicitly allow the
spot-instances-requestresource; the call will succeed. -
If you use RunInstances to create a Spot Instance request and intend to tag the Spot Instance request on create, you must include the
spot-instances-requestresource in the RunInstances allow statement, otherwise the call will fail. -
If you use RunInstances to create a Spot Instance request and intend to tag the Spot Instance request on create, you must specify the
spot-instances-requestresource or*wildcard in the CreateTags allow statement, otherwise the call will fail.
You can request Spot Instances using RunInstances or RequestSpotInstances. The following example IAM policies apply only when requesting Spot Instances using RunInstances.
Example: Request Spot Instances using RunInstances
The following policy allows users to request Spot Instances by using the RunInstances action.
The spot-instances-request resource, which is created by RunInstances,
requests Spot Instances.
Note
To use RunInstances to create Spot Instance requests, you can omit
spot-instances-request from the Resource list if you
do not intend to tag the Spot Instance requests on create. This is because Amazon EC2 does not
evaluate the spot-instances-request resource in the RunInstances
statement if the Spot Instance request is not tagged on create.
Warning
NOT SUPPORTED – Example: Deny users permission to request Spot Instances using RunInstances
The following policy is not supported for the spot-instances-request
resource.
The following policy is meant to give users the permission to launch On-Demand Instances, but deny
users the permission to request Spot Instances. The spot-instances-request
resource, which is created by RunInstances, is the resource that requests Spot Instances. The
second statement is meant to deny the RunInstances action for the
spot-instances-request resource. However, this condition is not
supported because Amazon EC2 does not evaluate the spot-instances-request
resource in the RunInstances statement if the Spot Instance request is not tagged on
create.
Example: Tag Spot Instance requests on create
The following policy allows users to tag all resources that are created during
instance launch. The first statement allows RunInstances to create the listed resources.
The spot-instances-request resource, which is created by RunInstances, is
the resource that requests Spot Instances. The second statement provides a *
wildcard to allow all resources to be tagged when they are created at instance
launch.
Note
If you tag a Spot Instance request on create, Amazon EC2 evaluates the
spot-instances-request resource in the RunInstances statement.
Therefore, you must explicitly allow the spot-instances-request
resource for the RunInstances action, otherwise the call will fail.