# Identity and access management for Amazon Elastic VMware Service
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Amazon Elastic VMware Service (Amazon EVS) resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [Audience](#security-iam-audience)
+ [Authenticating with identities](#security-iam-authentication)
+ [Managing access using policies](#security-iam-access-manage)
+ [How Amazon EVS works with IAM](security_iam_service-with-iam.md)
+ [Amazon EVS identity-based policy examples](security-iam-id-based-policy-examples.md)
+ [Troubleshooting Amazon EVS identity and access](security-iam-troubleshoot.md)
+ [AWS managed policies for Amazon EVS](security-iam-awsmanpol.md)
+ [Using service-linked roles for Amazon EVS](using-service-linked-roles.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs, depending on the work you do in Amazon EVS.
**Service user** – If you use the Amazon EVS service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Amazon EVS features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator.
If you cannot access a feature in Amazon EVS, see [Troubleshooting Amazon EVS identity and access](security-iam-troubleshoot.md).
**Service administrator** - If you’re in charge of Amazon EVS resources at your company, you probably have full access to Amazon EVS. It’s your job to determine which Amazon EVS features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Amazon EVS, see [How Amazon EVS works with IAM](security_iam_service-with-iam.md).
** IAM administrator** - If you’re an IAM administrator, you might want to learn details about how you can write policies to manage access to Amazon EVS. To view example Amazon EVS identity-based policies that you can use in IAM, see [Amazon EVS identity-based policy examples](security-iam-id-based-policy-examples.md).
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be *authenticated* (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company’s single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role.
Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the * AWS Sign-In User Guide*.
If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests using your credentials. If you don’t use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see [Signature Version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the * AWS General Reference*.
Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide* and [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.
### AWS account root user
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don’t use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html) in the *Account Management Reference Guide*.
### Federated identity
As a best practice, require human users, including users that require administrator access, to use federation with an identity provider to access AWS services by using temporary credentials.
A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. When federated identities access AWS accounts, they assume roles, and the roles provide temporary credentials.
For centralized access management, we recommend that you use AWS IAM Identity Center. You can create users and groups in IAM Identity Center, or you can connect and synchronize to a set of users and groups in your own identity source for use across all your AWS accounts and applications. For information about IAM Identity Center, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*.
### IAM users and groups
An * [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) * is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see [Rotate access keys regularly for use cases that require long-term credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) in the *IAM User Guide*.
An [IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is an identity that specifies a collection of IAM users. You can’t sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named *IAMAdmins* and give that group permissions to administer IAM resources.
Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see [When to create an IAM user (instead of a role)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) in the *IAM User Guide*.
### IAM roles
An * [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) * is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*.
IAM roles with temporary credentials are useful in the following situations:
+ **Federated user access** – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [Creating a role for a third-party Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*.
+ **Temporary IAM user permissions** – An IAM user can assume an IAM role to temporarily take on different permissions for a specific task.
+ **Cross-account access** – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.
+ **Cross-service access** – Some AWS services use features in other AWS services. For example, when you make a call in a service, it’s common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal’s permissions, using a service role, or using a service-linked role.
+ **Principal permissions** – When you use an IAM user or role to perform actions in AWS, you are considered a principal. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a different service. In this case, you must have permissions to perform both actions.
+ **Service role** – A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
+ **Service-linked role** – A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
+ **Applications running on Amazon EC2 ** – You can use an IAM role to manage temporary credentials for applications that are running on an Amazon EC2 instance and making AWS CLI or AWS API requests. This is preferable to storing access keys within the Amazon EC2 instance. To assign an AWS role to an Amazon EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the Amazon EC2 instance to get temporary credentials. For more information, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*.
To learn whether to use IAM roles, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
Every IAM entity (user or role) starts with no permissions. By default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group that has the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions.
IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, role, or group. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*.
### Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket. Service administrators can use these policies to define what actions a specified principal (account member, user, or role) can perform on that resource and under what conditions. Resource-based policies are inline policies. There are no managed resource-based policies.
### Access control lists (ACLs)
Access control lists (ACLs) are a type of policy that controls which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.
### Other policy types
AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types.
+ **Permissions boundaries** – A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (IAM user or role). You can set a permissions boundary for an entity. The resulting permissions are the intersection of entity’s identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role in the `Principal` field are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see [How SCPs work](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) in the * AWS Organizations User Guide*.
+ **Session policies** – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session’s permissions are the intersection of the user or role’s identity-based policies and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How Amazon EVS works with IAM
Before you use IAM to manage access to Amazon EVS, learn what IAM features are available to use with Amazon EVS.
| IAM feature | Amazon EVS support |
| --- | --- |
| [Identity-based policies for Amazon EVS](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies within Amazon EVS](#security_iam_service-with-iam-resource-based-policies) | No |
| [Policy actions for Amazon EVS](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources for Amazon EVS](#security_iam_service-with-iam-id-based-policies-resources) | Partial |
| [Policy condition keys for Amazon EVS](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes |
| [Access control lists (ACLs) in Amazon EVS](#security_iam_service-with-iam-acls) | No |
| [Attribute-based access control (ABAC) with Amazon EVS](#security_iam_service-with-iam-tags) | Yes |
| [Using temporary credentials with Amazon EVS](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Forward access sessions for Amazon EVS](#security_iam_service-with-iam-principal-permissions) | Yes |
| [Service roles for Amazon EVS](#security_iam_service-with-iam-roles-service) | No |
| [Service-linked roles for Amazon EVS](#security_iam_service-with-iam-roles-service-linked) | Yes |
To get a high-level view of how Amazon EVS and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Identity-based policies for Amazon EVS
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. You can’t specify the principal in an identity-based policy because it applies to the user or role to which it is attached. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Identity-based policy examples for Amazon EVS
To view examples of Amazon EVS identity-based policies, see [Amazon EVS identity-based policy examples](security-iam-id-based-policy-examples.md).
### Resource-based policies within Amazon EVS
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only half of establishing the trust relationship. When the principal and the resource are in different AWS accounts, an IAM administrator in the trusted account must also grant the principal entity (user or role) permission to access the resource. They grant permission by attaching an identity-based policy to the entity. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the IAM User Guide.
### Policy actions for Amazon EVS
**Supports actions** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation.
Policy actions in Amazon EVS use the following prefix before the action: `evs:`. For example, to grant someone permission to create an environment with the Amazon EVS `CreateEnvironment` API operation, you include the `evs:CreateEnvironment` action in their policy. Policy statements must include either an `Action` or `NotAction` element. Amazon EVS defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows:
```
"Action": [
"evs:action1",
"evs:action2"
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `List`, include the following action:
```
"Action": "evs:List*"
```
To see a list of Amazon EVS actions, see [Actions Defined by Amazon EVS](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticvmwareservice.html#amazonelasticvmwareservice-actions-as-permissions) in the *Service Authorization Reference*.
### Policy resources for Amazon EVS
**Supports policy resources:** Partial
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. Statements must include either a `Resource` or a `NotResource` element. As a best practice, specify a resource using its Amazon Resource Name (ARN). You can do this for actions that support a specific resource type, known as *resource-level permissions*.
For actions that don’t support resource-level permissions, such as listing operations, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
To see a list of Amazon EVS resource types and their ARNs, see [Resources defined by Amazon Elastic VMware Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticvmwareservice.html#amazonelasticvmwareservice-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by Amazon Elastic VMware Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticvwareservice.html#amazonelasticvmwareservice-actions-as-permissions).
Some Amazon EVS API actions support multiple resources. For example, multiple environments can be referenced when calling the `ListEnvironments` API action. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": [
"EXAMPLE-RESOURCE-1",
"EXAMPLE-RESOURCE-2"
```
For example, the Amazon EVS environment resource has the following ARN:
```
arn:${Partition}:evs:${Region}:${Account}:environment/${EnvironmentId}
```
To specify the environments `my-environment-1` and `my-environment-2` in your statement, use the following example ARNs:
```
"Resource": [
"arn:aws:evs:us-east-1:123456789012:environment/my-environment-1",
"arn:aws:evs:us-east-1:123456789012:environment/my-environment-2"
```
To specify all environments that belong to a specific account, use the wildcard (\$1):
```
"Resource": "arn:aws:evs:us-east-1:123456789012:environment/*"
```
### Policy condition keys for Amazon EVS
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element (or `Condition` block) lets you specify conditions in which a statement is in effect. The `Condition` element is optional. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request.
If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, AWS evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement’s permissions are granted.
You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see [IAM policy elements: variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *IAM User Guide*.
Amazon EVS defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
All Amazon EC2 actions support the `aws:RequestedRegion` and `ec2:Region` condition keys. For more information, see [Example: Restricting access to a specific region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
To see a list of Amazon EVS condition keys, see [Condition Keys for Amazon EVS](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticvmwareservice.html#amazonelasticvmwareservice-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by Amazon EVS](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticvmwareservice.html#amazonelasticvmwareservice-actions-as-permissions).
## Access control lists (ACLs) in Amazon EVS
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## Attribute-based access control (ABAC) with Amazon EVS
**Supports ABAC (tags in policies):** Yes
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. You can attach tags to IAM entities (users or roles) and to many AWS resources. Tagging entities and resources is the first step of ABAC. Then you design ABAC policies to allow operations when the principal’s tag matches the tag on the resource that they are trying to access.
ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.
You can attach tags to Amazon EVS resources or pass tags in a request to Amazon EVS. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/`, `aws:RequestTag/`, or `aws:TagKeys` condition keys. For more information about which actions that you can use tags in condition keys with, see [Actions defined by Amazon EVS](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticvmwareservice.html#amazonelasticvmwareservice-actions-as-permissions) in the *Service Authorization Reference*.
## Using temporary credentials with Amazon EVS
**Supports temporary credentials:** Yes
Some AWS services don’t work when you sign in using temporary credentials. For additional information, including which AWS services work with temporary credentials, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
You are using temporary credentials if you sign in to the AWS Management Console using any method except a user name and password. For example, when you access AWS using your company’s single sign-on (SSO) link, that process automatically creates temporary credentials. You also automatically create temporary credentials when you sign in to the console as a user and then switch roles. For more information about switching roles, see [Switch from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) in the *IAM User Guide*.
You can manually create temporary credentials using the AWS CLI or AWS API. You can then use those temporary credentials to access AWS. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html).
## Forward access sessions for Amazon EVS
**Supports forward access sessions (FAS):** Yes
When you use an IAM user or role to perform actions in AWS, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other AWS services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Amazon EVS
**Supports service roles:** No
A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
## Service-linked roles for Amazon EVS
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about creating or managing Amazon EVS service-linked roles, see [Using service-linked roles for Amazon EVS](using-service-linked-roles.md).
# Amazon EVS identity-based policy examples
By default, IAM users and roles don’t have permission to create or modify Amazon EVS resources. They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies using the JSON editor](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices)
+ [Using the Amazon EVS console](#security-iam-id-based-policy-examples-console)
+ [Allow users to view their own permissions](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Create and manage an Amazon EVS environment](#security-iam-id-based-policy-examples-create-env)
+ [Get and list Amazon EVS environments, hosts, and VLANs](#security-iam-id-based-policy-examples-list-env)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Amazon EVS resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [IAM JSON policy elements: condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or root users in your account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
## Using the Amazon EVS console
To access the Amazon EVS console, an IAM principal must have a minimum set of permissions. These permissions must allow the principal to list and view details about the Amazon EVS resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won’t function as intended for principals with that policy attached to them.
To ensure that your IAM principals can still use the Amazon EVS console, create a policy with your own unique name, such as `AmazonEVSAdminPolicy`. Attach the policy to the principals. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"evs:*"
],
"Resource": "*"
},
{
"Sid": "EVSServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/evs.amazonaws.com/AWSServiceRoleForEVS",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "evs.amazonaws.com"
}
}
}
]
}
```
You don’t need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you’re trying to perform.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Create and manage an Amazon EVS environment
This example policy includes the permissions required to create and delete an Amazon EVS environment, and add or delete hosts after the environment has been created.
You can replace the AWS Region with the AWS Region that you want to create an environment in. If your account already has the `AWSServiceRoleForAmazonEVS` role, you can remove the `iam:CreateServiceLinkedRole` action from the policy. If you’ve ever created an Amazon EVS environment in your account, a role with these permissions already exists, unless you deleted it.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyDescribeActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeInstanceStatus",
"ec2:DescribeHosts",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAddresses",
"ec2:DescribeKeyPairs",
"ec2:DescribeSubnets",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstances",
"ec2:DescribeRouteServers",
"ec2:DescribeRouteServerEndpoints",
"ec2:DescribeRouteServerPeers",
"ec2:DescribePlacementGroups",
"ec2:DescribeVolumes",
"ec2:DescribeSecurityGroups",
"support:DescribeServices",
"support:DescribeSupportLevel",
"servicequotas:GetServiceQuota",
"servicequotas:ListServiceQuotas"
],
"Resource": "*"
},
{
"Sid": "ModifyNetworkInterfaceStatement",
"Effect": "Allow",
"Action": [
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface"
],
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "ModifyNetworkInterfaceStatementForSubnetAssociation",
"Effect": "Allow",
"Action": [
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws:ec2:*:*:subnet/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "CreateNetworkInterfaceWithTag",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"Null": {
"aws:RequestTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "CreateNetworkInterfaceAdditionalResources",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "TagOnCreateEC2Resources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:subnet/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": [
"CreateNetworkInterface",
"RunInstances",
"CreateSubnet",
"CreateVolume"
]
},
"Null": {
"aws:RequestTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "DetachNetworkInterface",
"Effect": "Allow",
"Action": [
"ec2:DetachNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "RunInstancesWithTag",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"Null": {
"aws:RequestTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "RunInstancesWithTagResource",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "RunInstancesWithoutTag",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:placement-group/*"
]
},
{
"Sid": "TerminateInstancesWithTag",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances",
"ec2:ModifyInstanceAttribute"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "CreateSubnetWithTag",
"Effect": "Allow",
"Action": [
"ec2:CreateSubnet"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*"
],
"Condition": {
"Null": {
"aws:RequestTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "CreateSubnetWithoutTagForExistingVPC",
"Effect": "Allow",
"Action": [
"ec2:CreateSubnet"
],
"Resource": [
"arn:aws:ec2:*:*:vpc/*"
]
},
{
"Sid": "DeleteSubnetWithTag",
"Effect": "Allow",
"Action": [
"ec2:DeleteSubnet"
],
"Resource": "arn:aws:ec2:*:*:subnet/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "VolumeDeletion",
"Effect": "Allow",
"Action": [
"ec2:DeleteVolume"
],
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "VolumeDetachment",
"Effect": "Allow",
"Action": [
"ec2:DetachVolume"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "RouteServerAccess",
"Effect": "Allow",
"Action": [
"ec2:GetRouteServerAssociations"
],
"Resource": "arn:aws:ec2:*:*:route-server/*"
},
{
"Sid": "EVSServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/evs.amazonaws.com/AWSServiceRoleForEVS",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "evs.amazonaws.com"
}
}
},
{
"Sid": "SecretsManagerCreateWithTag",
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/AmazonEVSManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonEVSManaged"
]
}
}
},
{
"Sid": "SecretsManagerTagging",
"Effect": "Allow",
"Action": [
"secretsmanager:TagResource"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/AmazonEVSManaged": "true",
"aws:ResourceTag/AmazonEVSManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonEVSManaged"
]
}
}
},
{
"Sid": "SecretsManagerOps",
"Effect": "Allow",
"Action": [
"secretsmanager:DeleteSecret",
"secretsmanager:GetSecretValue",
"secretsmanager:UpdateSecret"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonEVSManaged": "false"
}
}
},
{
"Sid": "SecretsManagerRandomPassword",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword"
],
"Resource": "*"
},
{
"Sid": "EVSPermissions",
"Effect": "Allow",
"Action": [
"evs:*"
],
"Resource": "*"
},
{
"Sid": "KMSKeyAccessInConsole",
"Effect": "Allow",
"Action": [
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:*:*:key/*"
},
{
"Sid": "KMSKeyAliasAccess",
"Effect": "Allow",
"Action": [
"kms:ListAliases"
],
"Resource": "*"
}
]
}
```
## Get and list Amazon EVS environments, hosts, and VLANs
This example policy includes the minimum permissions required for an administrator to get and list all Amazon EVS environments, hosts, and VLANs within a given account in the us-east-2 AWS Region.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"evs:Get*",
"evs:List*"
],
"Resource": "*"
}
]
}
```
# Troubleshooting Amazon EVS identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Amazon EVS and IAM.
**Topics**
+ [AccessDeniedException](#security-iam-troubleshoot-access-denied)
+ [I want to allow people outside of my AWS account to access my Amazon EVS resources](#security-iam-troubleshoot-cross-account-access)
## AccessDeniedException
If you receive an `AccessDeniedException` when calling an AWS API operation, then the IAM principal credentials that you’re using don’t have the required permissions to make that call.
```
An error occurred (AccessDeniedException) when calling the CreateEnvironment operation:
User: arn:aws:iam::111122223333:user/user_name is not authorized to perform:
evs:CreateEnvironment on resource: arn:aws:evs:region:111122223333:environment/my-env
```
In the previous example message, the user does not have permissions to call the Amazon EVS `CreateEnvironment` API operation. To provide Amazon EVS admin permissions to an IAM principal, see [Amazon EVS identity-based policy examples](security-iam-id-based-policy-examples.md).
For more general information about IAM, see [Control access to AWS resources using policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) in the *IAM User Guide*.
## I want to allow people outside of my AWS account to access my Amazon EVS resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Amazon EVS supports these features, see [How Amazon EVS works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing Access to Externally Authenticated Users (Identity Federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.
# AWS managed policies for Amazon EVS
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they’re available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the * IAM User Guide*.
## AWS managed policy: AmazonEVSServiceRolePolicy
You can’t attach `AmazonEVSServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon EVS to perform actions on your behalf. For more information, see [Using service-linked roles for Amazon EVS](using-service-linked-roles.md). When you create an environment using an IAM principal that has the `iam:CreateServiceLinkedRole` permission, the `AWSServiceRoleforAmazonEVS` service-linked role is automatically created for you with this policy attached to it.
This policy allows the `AWSServiceRoleForAmazonEVS` service-linked role to call AWS services on your behalf.
**Permissions details**
This policy includes the following permissions that allow Amazon EVS to complete the following tasks.
+ `ec2` - Discover VPC networking components, including subnets and VPCs. Create, modify, tag, and delete elastic network interfaces that are used to establish a persistent connection between Amazon EVS and the VMware Virtual Cloud Foundation (VCF) SDDC Manager appliance in your VPC subnet. This connectivity is required for Amazon EVS to deploy, manage, and monitor the VCF deployment.
+ `ec2` - Delete EC2 instances that Amazon EVS creates when you make an EVS host deletion request. Describe and modify EC2 instance attributes so that default EC2 instance termination and stop protection can be disabled if needed to support EVS host deletion.
+ `ec2` - Manage EBS volumes for Cloud Builder installation and cleanup. During environment creation, Cloud Builder is installed onto one of the Amazon EVS deployed hosts to perform VCF configuration changes. After completion, Amazon EVS removes Cloud Builder by detaching and deleting the EC2 volume it is stored on.
+ `ec2` - Delete EVS VLAN subnets on your behalf if you request environment deletion.
+ `secretsmanager` - Delete VCF passwords that Amazon EVS creates and stores in AWS Secrets Manager during environment creation. Amazon EVS deletes all secrets that the service creates in your account if environment creation fails, or if you request environment deletion. Retrieve vCenter credentials from AWS Secrets Manager when you configure a vCenter connector by providing a secret ARN. The permission is scoped with a resource tag condition `EvsAccess=true` to ensure Amazon EVS only accesses secrets explicitly tagged for Amazon EVS vCenter access.
+ `kms` - Decrypt secrets and describe KMS keys when vCenter credentials stored in Secrets Manager are encrypted with KMS keys. The permission is scoped with a resource tag condition `EvsAccess=true` to ensure Amazon EVS only accesses KMS keys explicitly tagged for vCenter access.
+ `cloudwatch` - Publish AWS usage metrics to CloudWatch for Amazon EVS resources that have quotas.
To view more details about the policy, including the latest version of the JSON policy document, see [AmazonEVSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEVSServiceRolePolicy.html) in the * AWS Managed Policy Reference Guide*.
## Amazon EVS updates to AWS managed policies
View details about updates to AWS managed policies for Amazon EVS since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the [Document history for the Amazon Elastic VMware Service User Guide](doc-history.md) page.
| Change | Description | Date |
| --- | --- | --- |
| AmazonEVSServiceRolePolicy — Policy updated | Amazon EVS updated the policy to allow the service to retrieve vCenter credentials from AWS Secrets Manager and decrypting secrets encrypted with KMS keys. To learn more, see [AWS managed policy: AmazonEVSServiceRolePolicy](#security-iam-awsmanpol-amazonevsservicerolepolicy). | March 23, 2026 |
| AmazonEVSServiceRolePolicy — Policy updated | Amazon EVS updated the policy to add comprehensive resource management capabilities including EC2 instance management, EBS volume operations, and AWS Secrets Manager integration. To learn more, see [AWS managed policy: AmazonEVSServiceRolePolicy](#security-iam-awsmanpol-amazonevsservicerolepolicy). | August 14, 2025 |
| AmazonEVSServiceRolePolicy — Policy updated | Amazon EVS updated the policy to allow the service to delete EVS VLAN subnets, as well as publish Amazon EVS usage metrics to CloudWatch. To learn more, see [AWS managed policy: AmazonEVSServiceRolePolicy](#security-iam-awsmanpol-amazonevsservicerolepolicy). | July 14, 2025 |
| AmazonEVSServiceRolePolicy — New policy added | Amazon EVS added a new policy that allow the service to connect to a VPC subnet in the customer account. This connection is required for service functionality. To learn more, see [AWS managed policy: AmazonEVSServiceRolePolicy](#security-iam-awsmanpol-amazonevsservicerolepolicy). | June 09, 2025 |
| Amazon EVS started tracking changes | Amazon EVS started tracking changes for its AWS managed policies. | June 09, 2025 |
# Using service-linked roles for Amazon EVS
Amazon Elastic VMware Service uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon EVS. Service-linked roles are predefined by Amazon EVS and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon EVS easier because you don’t have to manually add the necessary permissions. Amazon EVS defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon EVS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your Amazon EVS resources because you can’t inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Amazon EVS
Amazon EVS uses the service-linked role named `AWSServiceRoleForAmazonEVS`. The role allows Amazon EVS to manage environments in your account. The attached policy allows the role to manage the following resources: EVS elastic network interfaces, EVS VLAN subnets, EVS hosts, VPCs, and CloudWatch metrics.
The `AWSServiceRoleForAmazonEVS` service-linked role trusts the following services to assume the role:
+ `evs.amazonaws.com`
The role permissions policy allows Amazon EVS to complete the following actions on the specified resources:
+ [AmazonEVSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEVSServiceRolePolicy.html)
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon EVS
You don’t need to manually create a service-linked role. When you create an environment in the AWS Management Console, the AWS CLI, or the AWS API, Amazon EVS creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create an environment, Amazon EVS creates the service-linked role for you again.
## Editing a service-linked role for Amazon EVS
Amazon EVS does not allow you to edit the `AWSServiceRoleForAmazonEVS` service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon EVS
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role. For steps to delete an Amazon EVS environment with hosts, see [Delete the Amazon EVS hosts and environment](getting-started.md#getting-started-cleanup-env-hosts).
**Note**
If the Amazon EVS service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSServiceRoleForAmazonEVS` service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported regions for Amazon EVS service-linked roles
Amazon EVS supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon Elastic VMware Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/evs.html) in the * AWS General Reference Guide*.