# Using Elastic Beanstalk with Amazon Identity and Access Management
IAM

Amazon Identity and Access Management (IAM) helps you securely control access to your Amazon resources. This section includes reference materials for working with IAM policies, instance profiles, and service roles.

For an overview of permissions, see [Elastic Beanstalk Service roles, instance profiles, and user policies](concepts-roles.md). For most environments, the service role and instance profile that the Elastic Beanstalk console prompts you to create when you launch your first environment have all of the permissions that you need. Likewise, the [managed policies](AWSHowTo.iam.managed-policies.md) provided by Elastic Beanstalk for full access and read-only access contain all of the user permissions required for daily use.

The [IAM User Guide](https://docs.amazonaws.cn/IAM/latest/UserGuide/IAMGettingStarted.html) provides in-depth coverage of Amazon permissions.

**Topics**
+ [

# Managing Elastic Beanstalk instance profiles
](iam-instanceprofile.md)
+ [

# Managing Elastic Beanstalk service roles
](iam-servicerole.md)
+ [

# Using service-linked roles for Elastic Beanstalk
](using-service-linked-roles.md)
+ [

# Managing Elastic Beanstalk user policies
](AWSHowTo.iam.managed-policies.md)
+ [

# Amazon resource name format for Elastic Beanstalk
](AWSHowTo.iam.policies.arn.md)
+ [

# Resources and conditions for Elastic Beanstalk actions
](AWSHowTo.iam.policies.actions.md)
+ [

# Using tags to control access to Elastic Beanstalk resources
](AWSHowTo.iam.policies.access-tags.md)
+ [

# Example policies based on managed policies
](ExamplePolicies_AEB.md)
+ [

# Example policies based on resource permissions
](AWSHowTo.iam.example.resource.md)
+ [

# Preventing cross-environment Amazon S3 bucket access
](AWSHowTo.iam.cross-env-s3-access.md)

# Managing Elastic Beanstalk instance profiles
Instance profiles

An instance profile is a container for an Amazon Identity and Access Management (IAM) role that you can use to pass role information to an Amazon EC2 instance when the instance starts. 

If your Amazon account doesn’t have an EC2 instance profile, you must create one using the IAM service. You can then assign the EC2 instance profile to new environments that you create. The **Create environment** steps in the Elastic Beanstalk console provides you access to the IAM console, so that you can create an EC2 instance profile with the required permissions.

**Note**  
Previously Elastic Beanstalk created a default EC2 instance profile named `aws-elasticbeanstalk-ec2-role` the first time an Amazon account created an environment. This instance profile included default managed policies. If your account already has this instance profile, it will remain available for you to assign to your environments.  
However, recent Amazon security guidelines don’t allow an Amazon service to automatically create roles with trust policies to other Amazon services, EC2 in this case. Because of these security guidelines, Elastic Beanstalk no longer creates a default `aws-elasticbeanstalk-ec2-role` instance profile.



**Managed policies**  
Elastic Beanstalk provides several managed policies to allow your environment to meet different use cases. To meet the default use cases for an environment, these policies must be attached to the role for the EC2 instance profile. 
+ **AWSElasticBeanstalkWebTier** – Grants permissions for the application to upload logs to Amazon S3 and debugging information to Amazon X-Ray. To view the managed policy content, see [AWSElasticBeanstalkWebTier](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkWebTier.html) in the *Amazon Managed Policy Reference Guide*. 
+ **AWSElasticBeanstalkWorkerTier** – Grants permissions for log uploads, debugging, metric publication, and worker instance tasks, including queue management, leader election, and periodic tasks. To view the managed policy content, see [AWSElasticBeanstalkWorkerTier](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkWorkerTier.html) in the *Amazon Managed Policy Reference Guide*.
+ **AWSElasticBeanstalkMulticontainerDocker** – Grants permissions for the Amazon Elastic Container Service to coordinate cluster tasks for Docker environments. To view the managed policy content, see [AWSElasticBeanstalkMulticontainerDocker](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkMulticontainerDocker.html) in the *Amazon Managed Policy Reference Guide*.



**Important**  
Elastic Beanstalk managed policies don't provide granular permissions—they grant all permissions that are potentially needed for working with Elastic Beanstalk applications. In some cases you may wish to restrict the permissions of our managed policies further. For an example of one use case, see [Preventing cross-environment Amazon S3 bucket access](AWSHowTo.iam.cross-env-s3-access.md).  
Our managed policies also don't cover permissions to custom resources that you might add to your solution, and that aren't managed by Elastic Beanstalk. To implement more granular permissions, minimum required permissions, or custom resource permissions, use [custom policies](AWSHowTo.iam.managed-policies.md#AWSHowTo.iam.policies).

**Trust relationship policy for EC2**  
To allow the EC2 instances in your environment to assume the required role, the instance profile must specify Amazon EC2 as a trusted entity in the trust relationship policy, as follows.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com.cn"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

To customize permissions, you can add policies to the role attached to the default instance profile or create your own instance profile with a restricted set of permissions.

To use the [AI-powered environment analysis](health-ai-analysis.md) feature, add the `bedrock:InvokeModel`, `bedrock:ListFoundationModels`, `elasticbeanstalk:DescribeEvents`, and `elasticbeanstalk:DescribeEnvironmentHealth` permissions to your instance profile. These permissions allow Elastic Beanstalk to use Amazon Bedrock and access environment data for analyzing logs, events, and instance health.

**Topics**
+ [

## Creating an instance profile
](#iam-instanceprofile-create)
+ [

## Adding permissions to the default instance profile
](#iam-instanceprofile-addperms)
+ [

## Verifying the permissions assigned your instance profile
](#iam-instanceprofile-verify)
+ [

## Updating an out-of-date default instance profile
](#iam-instanceprofile-update)

## Creating an instance profile


An instance profile is a wrapper around a standard IAM role that allows an EC2 instance to assume the role. You can create an instance profile with the default Elastic Beanstalk managed policies. You can also create additional instance profiles to customize permissions for different applications. Or you can create an instance profile that doesn't include the two managed policies that grant permissions for worker tier or ECS managed Docker environments, if you don't use those features.

**To create an instance profile with the default managed policies**

1. Open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles) in the IAM console.

1. Choose **Create role**.

1. For **Trusted entity type**, choose **Amazon service**.

1. For **Service or use case**, choose **Elastic Beanstalk**.

1. For **Use case**, choose** Elastic Beanstalk – Compute**. 

1. Choose **Next**.

1. Enter a **Role name**.

   You can enter the name of the default role that the Elastic Beanstalk console suggests: `aws-elasticbeanstalk-ec2-role`.

1. Verify that **Permissions policies** include the following, then choose **Next**:
   + `AWSElasticBeanstalkWebTier`
   + `AWSElasticBeanstalkWorkerTier`
   + `AWSElasticBeanstalkMulticontainerDocker`

1. Choose **Create role**.

**To create an instance profile with your specific choice of managed policies**

1. Open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles) in the IAM console.

1. Choose **Create role**.

1. Under **Trusted entity type**, choose **Amazon service**.

1. Under **Use case**, choose **EC2**.

1. Choose **Next**.

1. Attach the appropriate managed policies provided by Elastic Beanstalk and any additional policies that provide permissions that your application needs.

1. Choose **Next**.

1. Enter a name for the role.

1. (Optional) Add tags to the role.

1. Choose **Create role**.

## Adding permissions to the default instance profile


If your application accesses Amazon APIs or resources to which permissions aren't granted in the default instance profile, add policies that grant permissions in the IAM console.

**To add policies to the role attached to the default instance profile**

1. Open the [Roles page](https://console.amazonaws.cn/iam/home#roles) in the IAM console.

1. Choose the role assigned as your EC2 instance profile.

1. On the **Permissions** tab, choose **Attach policies**.

1. Select the managed policy for the additional services that your application uses. For example, `AmazonS3FullAccess` or `AmazonDynamoDBFullAccess`.

1. Choose **Attach policy**.

## Verifying the permissions assigned your instance profile


The permissions assigned to your default instance profile can vary depending on when it was created, the last time you launched an environment, and which client you used. You can verify the permissions on the default instance profile in the IAM console.

**To verify the default instance profile's permissions**

1. Open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles) in the IAM console.

1. Choose the role assigned as your EC2 instance profile.

1. On the **Permissions** tab, review the list of policies attached to the role.

1. To see the permissions that a policy grants, choose the policy.

## Updating an out-of-date default instance profile


If the default instance profile lacks the required permissions, you can add the managed policies to the role assigned as your EC2 instance profile manually.

**To add managed policies to the role attached to the default instance profile**

1. Open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles) in the IAM console.

1. Choose the role assigned as your EC2 instance profile.

1. On the **Permissions** tab, choose **Attach policies**.

1. Type **AWSElasticBeanstalk** to filter the policies.

1. Select the following policies, and then choose **Attach policy**:
   + `AWSElasticBeanstalkWebTier`
   + `AWSElasticBeanstalkWorkerTier`
   + `AWSElasticBeanstalkMulticontainerDocker`

# Managing Elastic Beanstalk service roles
Service roles

To manage and monitor your environment, Amazon Elastic Beanstalk performs actions on environment resources on your behalf. Elastic Beanstalk needs certain permissions to perform these actions, and it assumes Amazon Identity and Access Management (IAM) service roles to get these permissions.

Elastic Beanstalk needs to use temporary security credentials whenever it assumes a service role. To get these credentials, Elastic Beanstalk sends a request to Amazon Security Token Service (Amazon STS) on a Region specific endpoint. For more information, see [Temporary Security Credentials](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_credentials_temp.html) in the *IAM User Guide*.

**Note**  
If the Amazon STS endpoint for the Region where your environment is located is deactivated, Elastic Beanstalk sends the request on an alternative endpoint that can't be deactivated. This endpoint is associated with a different Region. Therefore, the request is a cross-Region request. For more information, see [Activating and Deactivating Amazon STS in an Amazon Region](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) in the *IAM User Guide*.

## Managing service roles using the Elastic Beanstalk console and EB CLI


You can use the Elastic Beanstalk console and EB CLI to set up service roles for your environment with a sufficient set of permissions. They create a default service role and use managed policies in it.

### Managed service role policies


Elastic Beanstalk provides one managed policy for [enhanced health monitoring](health-enhanced.md), and another one with additional permissions required for [managed platform updates](environment-platform-update-managed.md). The console and EB CLI assign both of these policies to the default service role that they create for you. These policies should only be used for this default service role. They should not be used with other users or roles in your accounts.

#### `AWSElasticBeanstalkEnhancedHealth`


This policy grants permissions for Elastic Beanstalk to monitor instance and environment health. It also includes Amazon SQS actions to allow Elastic Beanstalk to monitor queue activity for worker environments. To view the content of this managed policy, see the [ AWSElasticBeanstalkEnhancedHealth](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkEnhancedHealth.html) page in the *Amazon Managed Policy Reference Guide*.

#### `AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy`


This policy grants permissions for Elastic Beanstalk to update environments on your behalf to perform managed platform updates. To view the content of this managed policy, see the [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy.html) page in the *Amazon Managed Policy Reference Guide*. 

**Service-level permission groupings**

This policy is grouped into statements based on the set of permissions provided.
+ *`ElasticBeanstalkPermissions`* – This group of permissions is for calling the Elastic Beanstalk service actions (Elastic Beanstalk APIs).
+ *`AllowPassRoleToElasticBeanstalkAndDownstreamServices`* – This group of permissions allows any role to be passed to Elastic Beanstalk and to other downstream services like Amazon CloudFormation.
+ *`ReadOnlyPermissions`* – This group of permissions is for collecting information about the running environment.
+ *`*OperationPermissions`* – Groups with this naming pattern are for calling the necessary operations to perform platform updates.
+ *`*BroadOperationPermissions`* – Groups with this naming pattern are for calling the necessary operations to perform platform updates. They also include broad permissions for supporting legacy environments.
+ *`*TagResource`* – Groups with this naming pattern are for calls that use the tag-on-create APIs to attach tags on resources that are being created in an Elastic Beanstalk environment.

To view the content of a managed policy, you can also use the [**Policies** page](https://console.amazonaws.cn/iam/home#policies) in the IAM console.

**Important**  
Elastic Beanstalk managed policies don't provide granular permissions—they grant all permissions that are potentially needed for working with Elastic Beanstalk applications. In some cases you may wish to restrict the permissions of our managed policies further. For an example of one use case, see [Preventing cross-environment Amazon S3 bucket access](AWSHowTo.iam.cross-env-s3-access.md).  
Our managed policies also don't cover permissions to custom resources that you might add to your solution, and that aren't managed by Elastic Beanstalk. To implement more granular permissions, minimum required permissions, or custom resource permissions, use [custom policies](AWSHowTo.iam.managed-policies.md#AWSHowTo.iam.policies).

**Deprecated managed policies**  
In the past, Elastic Beanstalk supported the **AWSElasticBeanstalkService** managed service role policy. This policy has been replaced by **AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy**. You might still be able to see and use the earlier policy in the IAM console.

To view the managed policy content, see [AWSElasticBeanstalkService](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkService.html) in the *Amazon Managed Policy Reference Guide*.

However, we recommend that you transition to using the new managed policy (**AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy**). Add custom policies to grant permissions to custom resources, if you have any.

### Using the Elastic Beanstalk console


When you launch an environment in the Elastic Beanstalk console, the console creates a default service role that's named `aws-elasticbeanstalk-service-role`, and attaches managed policies with default permissions to this service role. 

To allow Elastic Beanstalk to assume the `aws-elasticbeanstalk-service-role` role, the service role specifies Elastic Beanstalk as a trusted entity in the trust relationship policy.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Sid": "",
        "Effect": "Allow",
        "Principal": {
          "Service": "elasticbeanstalk.amazonaws.com.cn"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "sts:ExternalId": "elasticbeanstalk"
          }
        }
      }
    ]
}
```

------

When you enable [managed platform updates](environment-platform-update-managed.md) for your environment, Elastic Beanstalk assumes a separate managed-updates service role to perform managed updates. By default, the Elastic Beanstalk console uses the same generated service role, `aws-elasticbeanstalk-service-role`, for the managed-updates service role. If you change your default service role, the console sets the managed-updates service role to use the managed-updates service-linked role, `AWSServiceRoleForElasticBeanstalkManagedUpdates`. For more information about service-linked roles, see [Using service-linked roles](#iam-servicerole-slr).

**Note**  
Because of permission issues, the Elastic Beanstalk service doesn't always successfully create this service-linked role for you. Therefore, the console tries to explicitly create it. To ensure your account has this service-linked role, create an environment at least once using the console, and configure managed updates to be enabled before you create the environment.

### Using the EB CLI


If you launch an environment using the [**eb create**](eb3-create.md) command of the Elastic Beanstalk Command Line Interface (EB CLI) and don't specify a service role through the `--service-role` option, Elastic Beanstalk creates the default service role `aws-elasticbeanstalk-service-role`. If the default service role already exists, Elastic Beanstalk uses it for the new environment. The Elastic Beanstalk console also performs similar actions in these situations.

Unlike in the console, you can't specify a managed-updates service role when using an EB CLI command option. If you enable managed updates for your environment, you must set the managed-updates service role though configuration options. The following example enables managed updates and uses the default service role as a managed-updates service role.

**Example .ebextensions/managed-platform-update.config**  

```
option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
    ServiceRoleForManagedUpdates: "aws-elasticbeanstalk-service-role"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: patch
    InstanceRefreshEnabled: true
```

## Managing service roles using the Elastic Beanstalk API


When you use the `CreateEnvironment` action of the Elastic Beanstalk API to create an environment, specify a service role using the `ServiceRole` configuration option in the `aws:elasticbeanstalk:environment` namespace. For more information about using enhanced health monitoring with the Elastic Beanstalk API, see [Using enhanced health reporting with the Elastic Beanstalk API](health-enhanced-api.md). 

In addition, if you enable [managed platform updates](environment-platform-update-managed.md) for your environment, you can specify a managed-updates service role using the `ServiceRoleForManagedUpdates` option of the `aws:elasticbeanstalk:managedactions` namespace.

## Using service-linked roles


A service-linked role is a unique type of service role that's predefined by Elastic Beanstalk to include all the permissions that the service requires to call other Amazon services on your behalf. The service-linked role is associated with your account. Elastic Beanstalk creates it once, then reuses it when creating additional environments. For more information about using service-linked roles with Elastic Beanstalk environments, see [Using service-linked roles for Elastic Beanstalk](using-service-linked-roles.md).

If you create an environment by using the Elastic Beanstalk API and don't specify a service role, Elastic Beanstalk creates a [monitoring service-linked role](using-service-linked-roles-monitoring.md) for your account, if one doesn't already exist. Elastic Beanstalk uses this role for the new environment. You can also use IAM to create a monitoring service-linked role for your account in advance. After your account has this role, you can use it to create an environment using the Elastic Beanstalk API, the Elastic Beanstalk console, or the EB CLI.

If you enable [managed platform updates](environment-platform-update-managed.md) for the environment and specify `AWSServiceRoleForElasticBeanstalkManagedUpdates` as the value for the `ServiceRoleForManagedUpdates` option of the `aws:elasticbeanstalk:managedactions` namespace, Elastic Beanstalk creates a [managed-updates service-linked role](using-service-linked-roles-managedupdates.md) for your account, if one doesn't already exist. Elastic Beanstalk uses the role to perform managed updates for the new environment.

**Note**  
When Elastic Beanstalk tries to create the monitoring and managed-updates service-linked roles for your account when you create an environment, you must have the `iam:CreateServiceLinkedRole` permission. If you don't have this permission, environment creation fails, and a message explaining the issue is displayed.  
As an alternative, another user with permission to create service-linked roles can use IAM to create the service linked-role in advance. Using this method, you don't need the `iam:CreateServiceLinkedRole` permission to create your environment.

## Verifying the default service role permissions


The permissions granted by your default service role can vary based on when they were created, the last time you launched an environment, and which client you used. In the IAM console, you can verify the permissions granted by the default service role.

**To verify the default service role's permissions**

1. In the IAM console, open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles).

1. Choose **aws-elasticbeanstalk-service-role**.

1. On the **Permissions** tab, review the list of policies attached to the role.

1. To view the permissions that a policy grants, choose the policy.

## Updating an out-of-date default service role


If the default service role lacks the required permissions, you can update it by [creating a new environment](using-features.environments.md) in the Elastic Beanstalk environment management console.

Alternatively, you can manually add the managed policies to the default service role.

**To add managed policies to the default service role**

1. In the IAM console, open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles) .

1. Choose **aws-elasticbeanstalk-service-role**.

1. On the **Permissions** tab, choose **Attach policies**.

1. Enter **AWSElasticBeanstalk** to filter the policies.

1. Select the following policies, and then choose **Attach policy**:
   + `AWSElasticBeanstalkEnhancedHealth`
   + `AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy`

## Adding permissions to the default service role


If your application includes configuration files that refer to Amazon resources that permissions aren't included in the default service role for, Elastic Beanstalk might need additional permissions. These additional permissions are needed to resolve these references when it processes the configuration files during a managed update. If the permissions are missing, the update fails, and Elastic Beanstalk returns a message indicating which permissions it needs. Follow these steps to add permissions for additional services to the default service role in the IAM console.

**To add additional policies to the default service role**

1. In the IAM console, open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles).

1. Choose **aws-elasticbeanstalk-service-role**.

1. On the **Permissions** tab, choose **Attach policies**.

1. Select the managed policy for the additional services that your application uses. For example, `AmazonAPIGatewayAdministrator` or `AmazonElasticFileSystemFullAccess`.

1. Choose **Attach policy**.

## Creating a service role


If you can't use the default service role, create a service role.

**To create a service role**

1. In the IAM console, open the [**Roles** page](https://console.amazonaws.cn/iam/home#roles).

1. Choose **Create role**.

1. Under **Amazon service**, choose **Amazon Elastic Beanstalk**, and then select your use case.

1. Choose **Next: Permissions**.

1. Attach the `AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy` and `AWSElasticBeanstalkEnhancedHealth` managed policies and any additional policies that provide permissions that your application needs.

1. Choose **Next: Tags**.

1. (Optional) Add tags to the role.

1. Choose **Next: Review**.

1. Enter a name for the role.

1. Choose **Create role**.

Apply your custom service role when you create an environment either using the [environment creation wizard](environments-create-wizard.md) or with the `--service-role` option for the `eb create` command.

# Using service-linked roles for Elastic Beanstalk
Using service-linked roles

Amazon Elastic Beanstalk uses Amazon Identity and Access Management (IAM)[ service-linked roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Elastic Beanstalk. Service-linked roles are predefined by Elastic Beanstalk and include all the permissions that the service requires to call other Amazon services on your behalf. 

Elastic Beanstalk defines a few types of service-linked roles:
+ *Monitoring service-linked role* – Allows Elastic Beanstalk to monitor the health of running environments and publish health event notifications.
+ *Maintenance service-linked role* – Allows Elastic Beanstalk to perform regular maintenance activities for your running environments.
+ *Managed-updates service-linked role* – Allows Elastic Beanstalk to perform scheduled platform updates of your running environments.

**Topics**
+ [

# The monitoring service-linked role
](using-service-linked-roles-monitoring.md)
+ [

# The maintenance service-linked role
](using-service-linked-roles-maintenance.md)
+ [

# The managed-updates service-linked role
](using-service-linked-roles-managedupdates.md)

# The monitoring service-linked role
Monitoring role

Amazon Elastic Beanstalk uses Amazon Identity and Access Management (IAM)[ service-linked roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Elastic Beanstalk. Service-linked roles are predefined by Elastic Beanstalk and include all the permissions that the service requires to call other Amazon services on your behalf. 

A service-linked role makes setting up Elastic Beanstalk easier because you don’t have to manually add the necessary permissions. Elastic Beanstalk defines the permissions of its service-linked roles, and unless defined otherwise, only Elastic Beanstalk 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 Elastic Beanstalk resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [Amazon Services That Work with IAM](https://docs.amazonaws.cn/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 Elastic Beanstalk


Elastic Beanstalk uses the service-linked role named **AWSServiceRoleForElasticBeanstalk** – Allows Elastic Beanstalk to monitor the health of running environments and publish health event notifications.

The AWSServiceRoleForElasticBeanstalk service-linked role trusts the following services to assume the role:
+ `elasticbeanstalk.amazonaws.com.cn`

The permissions policy of the AWSServiceRoleForElasticBeanstalk service-linked role contains all of the permissions that Elastic Beanstalk needs to complete actions on your behalf:

### AllowCloudformationReadOperationsOnElasticBeanstalkStacks


------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudformationReadOperationsOnElasticBeanstalkStacks",
            "Effect": "Allow",
            "Action": [
                "cloudformation:DescribeStackResource",
                "cloudformation:DescribeStackResources",
                "cloudformation:DescribeStacks"
            ],
            "Resource": [
                "arn:aws-cn:cloudformation:*:*:stack/awseb-*",
                "arn:aws-cn:cloudformation:*:*:stack/eb-*"
            ]
        },
        {
            "Sid": "AllowOperations",
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeNotificationConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:PutNotificationConfiguration",
                "ec2:DescribeInstanceStatus",
                "ec2:AssociateAddress",
                "ec2:DescribeAddresses",
                "ec2:DescribeInstances",
                "ec2:DescribeSecurityGroups",
                "elasticloadbalancing:DescribeInstanceHealth",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:DescribeTargetGroups",
                "sqs:GetQueueAttributes",
                "sqs:GetQueueUrl",
                "sns:Publish"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
```

------

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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

Alternatively, you can use an Amazon managed policy to [provide full access](AWSHowTo.iam.managed-policies.md) to Elastic Beanstalk.

## Creating a service-linked role for Elastic Beanstalk


You don't need to manually create a service-linked role. When you create an Elastic Beanstalk environment using the Elastic Beanstalk API and don't specify a service role, Elastic Beanstalk creates the service-linked role for you. 

**Important**  
 If you were using the Elastic Beanstalk service before September 27, 2017, when it began supporting the AWSServiceRoleForElasticBeanstalk service-linked role, and your account needed it, then Elastic Beanstalk created the AWSServiceRoleForElasticBeanstalk role in your account. To learn more, see [A New Role Appeared in My IAM Account](https://docs.amazonaws.cn/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).

When Elastic Beanstalk tries to create the AWSServiceRoleForElasticBeanstalk service-linked role for your account when you create an environment, you must have the `iam:CreateServiceLinkedRole` permission. If you don't have this permission, environment creation fails, and you see a message explaining the issue.

As an alternative, another user with permission to create service-linked roles can use IAM to pre-create the service linked-role in advance. You can then create your environment even without having the `iam:CreateServiceLinkedRole` permission.

You (or another user) can use the IAM console to create a service-linked role with the **Elastic Beanstalk** use case. In the IAM CLI or the IAM API, create a service-linked role with the `elasticbeanstalk.amazonaws.com.cn` service name. For more information, see [Creating a Service-Linked Role](https://docs.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. If you delete this service-linked role, you can use this same process to create the role again.

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 Elastic Beanstalk environment using the Elastic Beanstalk API and don't specify a service role, Elastic Beanstalk creates the service-linked role for you again. 

## Editing a service-linked role for Elastic Beanstalk


Elastic Beanstalk does not allow you to edit the AWSServiceRoleForElasticBeanstalk 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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.

## Deleting a service-linked role for Elastic Beanstalk


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 the resources for 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 be sure that all Elastic Beanstalk environments are either using a different service role or are terminated.

**Note**  
If the Elastic Beanstalk service is using the service-linked role when you try to terminate the environments, then the termination might fail. If that happens, wait for a few minutes and try the operation again.

**To terminate an Elastic Beanstalk environment that uses the AWSServiceRoleForElasticBeanstalk (console)**

1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. Choose **Actions**, and then choose **Terminate environment**.

1. Use the on-screen dialog box to confirm environment termination.

See [**eb terminate**](eb3-terminate.md) for details about terminating an Elastic Beanstalk environment using the EB CLI.

See [TerminateEnvironment](https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_TerminateEnvironment.html) for details about terminating an Elastic Beanstalk environment using the API.

### Manually delete the service-linked role


Use the IAM console, the IAM CLI, or the IAM API to delete the AWSServiceRoleForElasticBeanstalk service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported regions for Elastic Beanstalk service-linked roles


Elastic Beanstalk supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon Elastic Beanstalk Endpoints and Quotas](https://docs.amazonaws.cn/general/latest/gr/elasticbeanstalk.html).

# The maintenance service-linked role
Maintenance role

Amazon Elastic Beanstalk uses Amazon Identity and Access Management (IAM)[ service-linked roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Elastic Beanstalk. Service-linked roles are predefined by Elastic Beanstalk and include all the permissions that the service requires to call other Amazon services on your behalf. 

A service-linked role makes setting up Elastic Beanstalk easier because you don’t have to manually add the necessary permissions. Elastic Beanstalk defines the permissions of its service-linked roles, and unless defined otherwise, only Elastic Beanstalk 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 Elastic Beanstalk resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [Amazon Services That Work with IAM](https://docs.amazonaws.cn/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 Elastic Beanstalk


Elastic Beanstalk uses the service-linked role named **AWSServiceRoleForElasticBeanstalkMaintenance** – Allows Elastic Beanstalk to perform regular maintenance activities for your running environments.

The AWSServiceRoleForElasticBeanstalkMaintenance service-linked role trusts the following services to assume the role:
+ `maintenance.elasticbeanstalk.amazonaws.com.cn`

The permissions policy of the AWSServiceRoleForElasticBeanstalkMaintenance service-linked role contains all of the permissions that Elastic Beanstalk needs to complete actions on your behalf:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement":
        {
            "Sid": "AllowCloudformationChangeSetOperationsOnElasticBeanstalkStacks",
            "Effect": "Allow",
            "Action": [
                "cloudformation:CreateChangeSet",
                "cloudformation:DescribeChangeSet",
                "cloudformation:ExecuteChangeSet",
                "cloudformation:DeleteChangeSet",
                "cloudformation:ListChangeSets",
                "cloudformation:DescribeStacks"
            ],
            "Resource": [
                "arn:aws-cn:cloudformation:*:*:stack/awseb-*",
                "arn:aws-cn:cloudformation:*:*:stack/eb-*"
            ]
        }
}
```

------

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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

Alternatively, you can use an Amazon managed policy to [provide full access](AWSHowTo.iam.managed-policies.md) to Elastic Beanstalk.

## Creating a service-linked role for Elastic Beanstalk


You don't need to manually create a service-linked role. When you create an Elastic Beanstalk environment using the Elastic Beanstalk API and don't specify an instance profile, Elastic Beanstalk creates the service-linked role for you. 

**Important**  
 This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. If you were using the Elastic Beanstalk service before April 18, 2019, when it began supporting the AWSServiceRoleForElasticBeanstalkMaintenance service-linked role, and your account needed it, then Elastic Beanstalk created the AWSServiceRoleForElasticBeanstalkMaintenance role in your account. To learn more, see [A New Role Appeared in My IAM Account](https://docs.amazonaws.cn/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).

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 Elastic Beanstalk environment using the Elastic Beanstalk API and don't specify an instance profile, Elastic Beanstalk creates the service-linked role for you again. 

## Editing a service-linked role for Elastic Beanstalk


Elastic Beanstalk does not allow you to edit the AWSServiceRoleForElasticBeanstalkMaintenance 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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.

## Deleting a service-linked role for Elastic Beanstalk


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 the resources for 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 terminate any Elastic Beanstalk environments that uses the role.

**Note**  
If the Elastic Beanstalk service is using the service-linked role when you try to terminate the environments, then the termination might fail. If that happens, wait for a few minutes and try the operation again.

**To terminate an Elastic Beanstalk environment that uses the AWSServiceRoleForElasticBeanstalkMaintenance (console)**

1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. Choose **Actions**, and then choose **Terminate environment**.

1. Use the on-screen dialog box to confirm environment termination.

See [**eb terminate**](eb3-terminate.md) for details about terminating an Elastic Beanstalk environment using the EB CLI.

See [TerminateEnvironment](https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_TerminateEnvironment.html) for details about terminating an Elastic Beanstalk environment using the API.

### Manually delete the service-linked role


Use the IAM console, the IAM CLI, or the IAM API to delete the AWSServiceRoleForElasticBeanstalkMaintenance service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported regions for Elastic Beanstalk service-linked roles


Elastic Beanstalk supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon Elastic Beanstalk Endpoints and Quotas](https://docs.amazonaws.cn/general/latest/gr/elasticbeanstalk.html).

# The managed-updates service-linked role
Managed-updates role

Amazon Elastic Beanstalk uses Amazon Identity and Access Management (IAM)[ service-linked roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Elastic Beanstalk. Service-linked roles are predefined by Elastic Beanstalk and include all the permissions that the service requires to call other Amazon services on your behalf. 

A service-linked role makes setting up Elastic Beanstalk easier because you don’t have to manually add the necessary permissions. Elastic Beanstalk defines the permissions of its service-linked roles, and unless defined otherwise, only Elastic Beanstalk 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 Elastic Beanstalk resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [Amazon Services That Work with IAM](https://docs.amazonaws.cn/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 Elastic Beanstalk


Elastic Beanstalk uses the service-linked role named **AWSServiceRoleForElasticBeanstalkManagedUpdates** – Allows Elastic Beanstalk to perform scheduled platform updates of your running environments.

The AWSServiceRoleForElasticBeanstalkManagedUpdates service-linked role trusts the following services to assume the role:
+ `managedupdates.elasticbeanstalk.amazonaws.com.cn`

The managed policy **AWSElasticBeanstalkManagedUpdatesServiceRolePolicy** allows the AWSServiceRoleForElasticBeanstalkManagedUpdates service-linked role all of the permissions that Elastic Beanstalk needs to complete managed update actions on your behalf. To view the managed policy content, see the [AWSElasticBeanstalkManagedUpdatesServiceRolePolicy](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkManagedUpdatesServiceRolePolicy.html) page in the *Amazon Managed Policy Reference Guide*. 

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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

Alternatively, you can use an Amazon managed policy to [provide full access](AWSHowTo.iam.managed-policies.md) to Elastic Beanstalk.

## Creating a service-linked role for Elastic Beanstalk


You don't need to manually create a service-linked role. When you create an Elastic Beanstalk environment using the Elastic Beanstalk API, enable managed updates, and specify `AWSServiceRoleForElasticBeanstalkManagedUpdates` as the value for the `ServiceRoleForManagedUpdates` option of the `aws:elasticbeanstalk:managedactions` namespace, Elastic Beanstalk creates the service-linked role for you. 

When Elastic Beanstalk tries to create the AWSServiceRoleForElasticBeanstalkManagedUpdates service-linked role for your account when you create an environment, you must have the `iam:CreateServiceLinkedRole` permission. If you don't have this permission, environment creation fails, and you see a message explaining the issue.

As an alternative, another user with permission to create service-linked roles can use IAM to pre-create the service linked-role in advance. You can then create your environment even without having the `iam:CreateServiceLinkedRole` permission.

You (or another user) can use the IAM console to create a service-linked role with the **Elastic Beanstalk Managed Updates** use case. In the IAM CLI or the IAM API, create a service-linked role with the `managedupdates.elasticbeanstalk.amazonaws.com.cn` service name. For more information, see [Creating a Service-Linked Role](https://docs.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. If you delete this service-linked role, you can use this same process to create the role again.

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 Elastic Beanstalk environment using the Elastic Beanstalk API, enable managed updates, and specify `AWSServiceRoleForElasticBeanstalkManagedUpdates` as the value for the `ServiceRoleForManagedUpdates` option of the `aws:elasticbeanstalk:managedactions` namespace, Elastic Beanstalk creates the service-linked role for you again. 

## Editing a service-linked role for Elastic Beanstalk


Elastic Beanstalk does not allow you to edit the AWSServiceRoleForElasticBeanstalkManagedUpdates 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.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.

## Deleting a service-linked role for Elastic Beanstalk


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 the resources for 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 be sure that Elastic Beanstalk environments with managed updates enabled are either using a different service role or are terminated.

**Note**  
If the Elastic Beanstalk service is using the service-linked role when you try to terminate the environments, then the termination might fail. If that happens, wait for a few minutes and try the operation again.

**To terminate an Elastic Beanstalk environment that uses the AWSServiceRoleForElasticBeanstalkManagedUpdates (console)**

1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. Choose **Actions**, and then choose **Terminate Environment**.

1. Use the on-screen dialog box to confirm environment termination.

See [**eb terminate**](eb3-terminate.md) for details about terminating an Elastic Beanstalk environment using the EB CLI.

See [TerminateEnvironment](https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_TerminateEnvironment.html) for details about terminating an Elastic Beanstalk environment using the API.

### Manually delete the service-linked role


Use the IAM console, the IAM CLI, or the IAM API to delete the AWSServiceRoleForElasticBeanstalkManagedUpdates service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.amazonaws.cn/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported Regions for Elastic Beanstalk service-linked roles


Elastic Beanstalk supports using service-linked roles in all of the regions where the service is available. For more information, see [Amazon Elastic Beanstalk Endpoints and Quotas](https://docs.amazonaws.cn/general/latest/gr/elasticbeanstalk.html).

# Managing Elastic Beanstalk user policies
User policies

Amazon Elastic Beanstalk provides two managed policies that enable you to assign full access or read-only access to all resources that Elastic Beanstalk manages. You can attach the policies to Amazon Identity and Access Management (IAM) users or groups, or to roles assumed by your users.

**Managed user policies**
+ **AdministratorAccess-AWSElasticBeanstalk** – Gives the user full administrative permissions to create, modify, and delete Elastic Beanstalk applications, application versions, configuration settings, environments, and their underlying resources. To view the managed policy content, see the [AdministratorAccess-AWSElasticBeanstalk](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AdministratorAccess-AWSElasticBeanstalk.html) page in the *Amazon Managed Policy Reference Guide*.
+ **AWSElasticBeanstalkReadOnly** – Allows the user to view applications and environments, but not to perform operations that modify them. It provides read-only access to all Elastic Beanstalk resources, and to other Amazon resources that the Elastic Beanstalk console retrieves. Note that read-only access does not enable actions such as downloading Elastic Beanstalk logs so that you can read them. This is because the logs are staged in the Amazon S3 bucket, where Elastic Beanstalk would require write permission. See the example at the end of this topic for information on how to enable access to Elastic Beanstalk logs. To view the managed policy content, see the [AWSElasticBeanstalkReadOnly](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkReadOnly.html) page in the *Amazon Managed Policy Reference Guide*.

**Important**  
Elastic Beanstalk managed policies don't provide granular permissions—they grant all permissions that are potentially needed for working with Elastic Beanstalk applications. In some cases you may wish to restrict the permissions of our managed policies further. For an example of one use case, see [Preventing cross-environment Amazon S3 bucket access](AWSHowTo.iam.cross-env-s3-access.md).  
Our managed policies also don't cover permissions to custom resources that you might add to your solution, and that aren't managed by Elastic Beanstalk. To implement more granular permissions, minimum required permissions, or custom resource permissions, use [custom policies](#AWSHowTo.iam.policies).

**Deprecated managed policies**  
Previously, Elastic Beanstalk supported two other managed user policies, **AWSElasticBeanstalkFullAccess** and **AWSElasticBeanstalkReadOnlyAccess**. We plan on retiring these previous policies. You might still be able to see and use them in the IAM console. Nevertheless, we recommend that you transition to using the new managed user policies, and add custom policies to grant permissions to custom resources, if you have any.

## Policies for integration with other services


We also provide more granular policies that allow you to integrate your environment with other services, if you prefer to use those. 
+ **AWSElasticBeanstalkRoleCWL** – Allows an environment to manage Amazon CloudWatch Logs log groups.
+ **AWSElasticBeanstalkRoleRDS** – Allows an environment to integrate an Amazon RDS instance.
+ **AWSElasticBeanstalkRoleWorkerTier** – Allows a worker environment tier to create an Amazon DynamoDB table and an Amazon SQS queue.
+ **AWSElasticBeanstalkRoleECS** – Allows a multicontainer Docker environment to manage Amazon ECS clusters.
+ **AWSElasticBeanstalkRoleCore** – Allows core operations of a web service environment.
+ **AWSElasticBeanstalkRoleSNS** – Allows an environment to enable Amazon SNS topic integration.

To see the JSON source for a specific managed policy, see the [https://docs.amazonaws.cn/aws-managed-policy/latest/reference/about-managed-policy-reference.html](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/about-managed-policy-reference.html).

## Controlling access with managed policies


You can use managed policies to grant full access or read-only access to Elastic Beanstalk. Elastic Beanstalk updates these policies automatically when additional permissions are required to access new features.

**To apply a managed policy to IAM users or groups**

1. Open the [**Policies** page](https://console.amazonaws.cn/iam/home#policies) in the IAM console.

1. In the search box, type **AWSElasticBeanstalk** to filter the policies.

1. In the list of policies, select the check box next to **AWSElasticBeanstalkReadOnly** or **AdministratorAccess-AWSElasticBeanstalk**.

1. Choose **Policy actions**, and then choose **Attach**.

1. Select one or more users and groups to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities.

1. Choose **Attach policy**.

## Creating a custom user policy


You can create your own IAM policy to allow or deny specific Elastic Beanstalk API actions on specific Elastic Beanstalk resources, and to control access to custom resources that aren't managed by Elastic Beanstalk. For more information about attaching a policy to a user or group, see [Working with Policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/ManagingPolicies.html) in the *IAM User Guide*. For details about creating a custom policy, see [Creating IAM Policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

**Note**  
While you can restrict how a user interacts with Elastic Beanstalk APIs, there is not currently an effective way to prevent users who have permission to create the necessary underlying resources from creating other resources in Amazon EC2 and other services.  
Think of these policies as an effective way to distribute Elastic Beanstalk responsibilities, not as a way to secure all underlying resources.

**Important**  
If you have custom policies assigned to an Elastic Beanstalk service role, it's important that you assign it the proper permissions for launch templates. Otherwise you may not have the required permissions to update an environment or launch a new one. For more information, see [Required permissions for launch templates](environments-cfg-autoscaling-launch-templates.md#environments-cfg-autoscaling-launch-templates-permissions). 

An IAM policy contains policy statements that describe the permissions that you want to grant. When you create a policy statement for Elastic Beanstalk, you need to understand how to use the following four parts of a policy statement:
+ **Effect** specifies whether to allow or deny the actions in the statement.
+ **Action** specifies the [API operations](https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_Operations.html) that you want to control. For example, use `elasticbeanstalk:CreateEnvironment` to specify the `CreateEnvironment` operation. Certain operations, such as creating an environment, require additional permissions to perform those actions. For more information, see [Resources and conditions for Elastic Beanstalk actions](AWSHowTo.iam.policies.actions.md). 
**Note**  
To use the [https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html](https://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html) API operation, specify one of the following two virtual actions (or both) instead of the API operation name:  

`elasticbeanstalk:AddTags`  
Controls permission to call `UpdateTagsForResource` and pass a list of tags to add in the `TagsToAdd` parameter.

`elasticbeanstalk:RemoveTags`  
Controls permission to call `UpdateTagsForResource` and pass a list of tag keys to remove in the `TagsToRemove` parameter.
+ **Resource** specifies the resources that you want to control access to. To specify Elastic Beanstalk resources, list the [Amazon Resource Name](AWSHowTo.iam.policies.arn.md) (ARN) of each resource.
+ (optional) **Condition** specifies restrictions on the permission granted in the statement. For more information, see [Resources and conditions for Elastic Beanstalk actions](AWSHowTo.iam.policies.actions.md).

The following sections demonstrate a few cases in which you might consider a custom user policy.

### Enabling limited Elastic Beanstalk environment creation


The policy in the following example enables a user to call the `CreateEnvironment` action to create an environment whose name begins with **Test** with the specified application and application version.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid":"CreateEnvironmentPerm",
      "Action": [
        "elasticbeanstalk:CreateEnvironment"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My First Elastic Beanstalk Application/Test*"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My First Elastic Beanstalk Application"],
          "elasticbeanstalk:FromApplicationVersion": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/My First Elastic Beanstalk Application/First Release"]
        }
      }
    },
    {
      "Sid":"AllNonResourceCalls",
      "Action":[
        "elasticbeanstalk:CheckDNSAvailability",
        "elasticbeanstalk:CreateStorageLocation"
      ],
      "Effect":"Allow",
      "Resource":[
        "*"
      ]
    }
  ]
}
```

------

The above policy shows how to grant limited access to Elastic Beanstalk operations. In order to actually launch an environment, the user must have permission to create the Amazon resources that power the environment as well. For example, the following policy grants access to the default set of resources for a web server environment:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "ecs:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "cloudwatch:*",
        "s3:*",
        "sns:*",
        "cloudformation:*",
        "sqs:*"
        ],
      "Resource": "*"
    }
  ]
}
```

------

### Enabling access to Elastic Beanstalk logs stored in Amazon S3


The policy in the following example enables a user to pull Elastic Beanstalk logs, stage them in Amazon S3, and retrieve them.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "s3:DeleteObject",
        "s3:GetObjectAcl",
        "s3:PutObjectAcl"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws-cn:s3:::elasticbeanstalk-*"
    }
  ]
}
```

------

**Note**  
To restrict these permissions to only the logs path, use the following resource format.   

```
"arn:aws-cn:s3:::elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/*"
```

### Enabling management of a specific Elastic Beanstalk application


The policy in the following example enables a user to manage environments and other resources within one specific Elastic Beanstalk application. The policy denies Elastic Beanstalk actions on resources of other applications, and also denies creation and deletion of Elastic Beanstalk applications.

**Note**  
The policy doesn't deny access to any resources through other services. It demonstrates an effective way to distribute responsibilities for managing Elastic Beanstalk applications among different users, not as a way to secure the underlying resources.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "elasticbeanstalk:CreateApplication",
        "elasticbeanstalk:DeleteApplication"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "elasticbeanstalk:CreateApplicationVersion",
        "elasticbeanstalk:CreateConfigurationTemplate",
        "elasticbeanstalk:CreateEnvironment",
        "elasticbeanstalk:DeleteApplicationVersion",
        "elasticbeanstalk:DeleteConfigurationTemplate",
        "elasticbeanstalk:DeleteEnvironmentConfiguration",
        "elasticbeanstalk:DescribeApplicationVersions",
        "elasticbeanstalk:DescribeConfigurationOptions",
        "elasticbeanstalk:DescribeConfigurationSettings",
        "elasticbeanstalk:DescribeEnvironmentResources",
        "elasticbeanstalk:DescribeEnvironments",
        "elasticbeanstalk:DescribeEvents",
        "elasticbeanstalk:DeleteEnvironmentConfiguration",
        "elasticbeanstalk:RebuildEnvironment",
        "elasticbeanstalk:RequestEnvironmentInfo",
        "elasticbeanstalk:RestartAppServer",
        "elasticbeanstalk:RetrieveEnvironmentInfo",
        "elasticbeanstalk:SwapEnvironmentCNAMEs",
        "elasticbeanstalk:TerminateEnvironment",
        "elasticbeanstalk:UpdateApplicationVersion",
        "elasticbeanstalk:UpdateConfigurationTemplate",
        "elasticbeanstalk:UpdateEnvironment",
        "elasticbeanstalk:RetrieveEnvironmentInfo",
        "elasticbeanstalk:ValidateConfigurationSettings"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEquals": {
          "elasticbeanstalk:InApplication": [
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/myapplication"
          ]
        }
      }
    }
  ]
}
```

------

# Amazon resource name format for Elastic Beanstalk
ARN format

You specify a resource for an IAM policy using that resource's Amazon Resource Name (ARN). For Elastic Beanstalk, the ARN has the following format.

```
arn:aws-cn:elasticbeanstalk:region:account-id:resource-type/resource-path
```

Where:
+ `region` is the region the resource resides in (for example, **us-west-2**).
+ `account-id` is the Amazon account ID, with no hyphens (for example, **123456789012**)
+ `resource-type` identifies the type of the Elastic Beanstalk resource—for example, `environment`. See the table below for a list of all Elastic Beanstalk resource types.
+ `resource-path` is the portion that identifies the specific resource. An Elastic Beanstalk resource has a path that uniquely identifies that resource. See the table below for the format of the resource path for each resource type. For example, an environment is always associated with an application. The resource path for the environment **myEnvironment** in the application **myApp** would look like this:

  ```
  myApp/myEnvironment
  ```

Elastic Beanstalk has several types of resources you can specify in a policy. The following table shows the ARN format for each resource type and an example.


****  

| Resource type | Format for ARN | 
| --- | --- | 
|  `application`  |  `arn:aws-cn:elasticbeanstalk:region:account-id:application/application-name` Example: **arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App**   | 
|  `applicationversion`  |  `arn:aws-cn:elasticbeanstalk:region:account-id:applicationversion/application-name/version-label` Example: **arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/My App/My Version**   | 
|  `configurationtemplate`  |  `arn:aws-cn:elasticbeanstalk:region:account-id:configurationtemplate/application-name/template-name` Example: **arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:configurationtemplate/My App/My Template**   | 
|  `environment`  |  `arn:aws-cn:elasticbeanstalk:region:account-id:environment/application-name/environment-name` Example: **arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/MyEnvironment**   | 
|  `platform`  |  `arn:aws-cn:elasticbeanstalk:region:account-id:platform/platform-name/platform-version` Example: **arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:platform/MyPlatform/1.0**   | 
|  `solutionstack`  |  `arn:aws-cn:elasticbeanstalk:region::solutionstack/solutionstack-name` Example: **arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/32bit Amazon Linux running Tomcat 7**   | 

An environment, application version, and configuration template are always contained within a specific application. You'll notice that these resources all have an application name in their resource path so that they are uniquely identified by their resource name and the containing application. Although solution stacks are used by configuration templates and environments, solution stacks are not specific to an application or Amazon account and do not have the application or Amazon account in their ARNs.

# Resources and conditions for Elastic Beanstalk actions
Resources and conditions

This section describes the resources and conditions that you can use in policy statements to grant permissions that allow specific Elastic Beanstalk actions to be performed on specific Elastic Beanstalk resources.

Conditions enable you to specify permissions to resources that the action needs to complete. For example, when you can call the `CreateEnvironment` action, you must also specify the application version to deploy as well as the application that contains that application name. When you set permissions for the `CreateEnvironment` action, you specify the application and application version that you want the action to act upon by using the `InApplication` and `FromApplicationVersion` conditions. 

In addition, you can specify the environment configuration with a solution stack (`FromSolutionStack`) or a configuration template (`FromConfigurationTemplate`). The following policy statement allows the `CreateEnvironment` action to create an environment with the name **myenv** (specified by `Resource`) in the application **My App** (specified by the `InApplication` condition) using the application version **My Version** (`FromApplicationVersion`) with a **32bit Amazon Linux running Tomcat 7** configuration (`FromSolutionStack`):

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:CreateEnvironment"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/myenv"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App"],
          "elasticbeanstalk:FromApplicationVersion": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/My App/My Version"],
          "elasticbeanstalk:FromSolutionStack": ["arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/32bit Amazon Linux running Tomcat 7"]
        }
      }
    }
  ]
}
```

------

**Note**  
Most condition keys mentioned in this topic are specific to Elastic Beanstalk, and their names contain the `elasticbeanstalk:` prefix. For brevity, we omit this prefix from the condition key names when we mention them in the following sections. For example, we mention `InApplication` instead of its full name `elasticbeanstalk:InApplication`.  
In contrast, we mention a few condition keys used across Amazon services, and we include their `aws:` prefix to highlight the exception.  
Policy examples always show full condition key names, including the prefix.

**Topics**
+ [

## Policy information for Elastic Beanstalk actions
](#AWSHowTo.iam.policies.actions.table)
+ [

## Condition keys for Elastic Beanstalk actions
](#AWSHowTo.iam.policies.conditions)

## Policy information for Elastic Beanstalk actions


The following table lists all Elastic Beanstalk actions, the resource that each action acts upon, and the additional contextual information that can be provided using conditions.


**Policy information for Elastic Beanstalk actions, including resources, conditions, examples, and dependencies**  

| Resource | Conditions | Example statement | 
| --- | --- | --- | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_AbortEnvironmentUpdate.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_AbortEnvironmentUpdate.html) | 
|  `application` `environment`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows a user to abort environment update operations on environments in an application named `My App`. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CheckDNSAvailability.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CheckDNSAvailability.html) | 
|  `"*"`  |  N/A  |  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ComposeEnvironments.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ComposeEnvironments.html) | 
|  `application`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows a user to compose environments that belong to an application named `My App`. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateApplication.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateApplication.html) | 
|  `application`  |  `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  This example allows the `CreateApplication` action to create applications whose names begin with **DivA**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateApplicationVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateApplicationVersion.html) | 
|  `applicationversion`  |  `InApplication` `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  This example allows the `CreateApplicationVersion` action to create application versions with any name (**\$1**) in the application **My App**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateConfigurationTemplate.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateConfigurationTemplate.html) | 
|  `configurationtemplate`  |  `InApplication` `FromApplication` `FromApplicationVersion` `FromConfigurationTemplate` `FromEnvironment` `FromSolutionStack` `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `CreateConfigurationTemplate` action to create configuration templates whose name begins with **My Template** (`My Template*`) in the application **My App**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateEnvironment.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateEnvironment.html) | 
|  `environment`  |  `InApplication` `FromApplicationVersion` `FromConfigurationTemplate` `FromSolutionStack` `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `CreateEnvironment` action to create an environment whose name is **myenv** in the application **My App** and using the solution stack **32bit Amazon Linux running Tomcat 7**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreatePlatformVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreatePlatformVersion.html) | 
|  `platform`  |  `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  This example allows the `CreatePlatformVersion` action to create platform versions targeting the `us-west-2` region, whose names begin with **us-west-2\$1**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateStorageLocation.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_CreateStorageLocation.html) | 
|  `"*"`  |  N/A  |  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteApplication.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteApplication.html) | 
|  `application`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DeleteApplication` action to delete the application **My App**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteApplicationVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteApplicationVersion.html) | 
|  `applicationversion`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DeleteApplicationVersion` action to delete an application version whose name is **My Version** in the application **My App**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteConfigurationTemplate.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteConfigurationTemplate.html) | 
|  `configurationtemplate`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DeleteConfigurationTemplate` action to delete a configuration template whose name is **My Template** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteEnvironmentConfiguration.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeleteEnvironmentConfiguration.html) | 
|  `environment`  |  `InApplication` (Optional)  |  The following policy allows the `DeleteEnvironmentConfiguration` action to delete a draft configuration for the environment **myenv** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeletePlatformVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DeletePlatformVersion.html) | 
|  `platform`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DeletePlatformVersion` action to delete platform versions targeting the `us-west-2` region, whose names begin with **us-west-2\$1**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeApplications.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeApplications.html) | 
|  `application`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeApplications` action to describe the application My App. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeApplicationVersions.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeApplicationVersions.html) | 
|  `applicationversion`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeApplicationVersions` action to describe the application version **My Version** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeConfigurationOptions.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeConfigurationOptions.html) | 
|  `environment` `configurationtemplate` `solutionstack`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeConfigurationOptions` action to describe the configuration options for the environment **myenv** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeConfigurationSettings.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeConfigurationSettings.html) | 
|  `environment` `configurationtemplate`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeConfigurationSettings` action to describe the configuration settings for the environment **myenv** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironmentHealth.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironmentHealth.html) | 
|  `environment`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows use of `DescribeEnvironmentHealth` to retrieve health information for an environment named **myenv**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironmentResources.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironmentResources.html) | 
|  `environment`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeEnvironmentResources` action to return list of Amazon resources for the environment **myenv** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironments.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEnvironments.html) | 
|  `environment`  |  `InApplication` (Optional) `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeEnvironments` action to describe the environments **myenv** and **myotherenv** in the application **My App**. Specifying the application name as a condition is optional. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEvents.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeEvents.html) | 
|  `application` `applicationversion` `configurationtemplate` `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribeEvents` action to list event descriptions for the environment **myenv** and the application version **My Version** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeInstancesHealth.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribeInstancesHealth.html) | 
|  `environment`  |  N/A  |  The following policy allows use of `DescribeInstancesHealth` to retrieve health information for instances in an environment named **myenv**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribePlatformVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_DescribePlatformVersion.html) | 
|  `platform`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `DescribePlatformVersion` action to describe platform versions targeting the `us-west-2` region, whose names begin with **us-west-2\$1**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListAvailableSolutionStacks.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListAvailableSolutionStacks.html) | 
|  `solutionstack`  |  N/A  |  The following policy allows the `ListAvailableSolutionStacks` action to return only the solution stack **32bit Amazon Linux running Tomcat 7**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListPlatformVersions.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListPlatformVersions.html) | 
|  `platform`  |  `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  This example allows the `CreatePlatformVersion` action to create platform versions targeting the `us-west-2` region, whose names begin with **us-west-2\$1**: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListTagsForResource.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ListTagsForResource.html) | 
|  `application` `applicationversion` `configurationtemplate` `environment` `platform`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `ListTagsForResource` action to list tags of existing resources only if they have a tag named `stage` with the value `test`: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RebuildEnvironment.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RebuildEnvironment.html) | 
|  `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `RebuildEnvironment` action to rebuild the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html) | 
|  `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `RequestEnvironmentInfo` action to compile information about the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RestartAppServer.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RestartAppServer.html) | 
|  `environment`  |  `InApplication`  |  The following policy allows the `RestartAppServer` action to restart the application container server for the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html) | 
|  `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `RetrieveEnvironmentInfo` action to retrieve the compiled information for the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_SwapEnvironmentCNAMEs.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_SwapEnvironmentCNAMEs.html) | 
|  `environment`  |  `InApplication` (Optional) `FromEnvironment` (Optional)  |  The following policy allows the `SwapEnvironmentCNAMEs` action to swap the CNAMEs for the environments **mysrcenv** and **mydestenv**.  [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_TerminateEnvironment.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_TerminateEnvironment.html) | 
|  `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `TerminateEnvironment` action to terminate the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[UpdateApplication](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateApplication.html) | 
|  `application`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `UpdateApplication` action to update properties of the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[UpdateApplicationResourceLifecycle](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateApplicationResourceLifecycle.html) | 
|  `application`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `UpdateApplicationResourceLifecycle` action to update lifecycle settings of the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateApplicationVersion.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateApplicationVersion.html) | 
|  `applicationversion`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `UpdateApplicationVersion` action to update the properties of the application version **My Version** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateConfigurationTemplate.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateConfigurationTemplate.html) | 
|  `configurationtemplate`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `UpdateConfigurationTemplate` action to update the properties or options of the configuration template **My Template** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateEnvironment.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateEnvironment.html) | 
|  `environment`  |  `InApplication` `FromApplicationVersion` `FromConfigurationTemplate` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `UpdateEnvironment` action to update the environment **myenv** in the application **My App** by deploying the application version **My Version**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html) – `AddTags` | 
|  `application` `applicationversion` `configurationtemplate` `environment` `platform`  |  `aws:ResourceTag/key-name` (Optional) `aws:RequestTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The `AddTags` action is one of two virtual actions associated with the [http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html) API. The following policy allows the `AddTags` action to modify tags of existing resources only if they have a tag named `stage` with the value `test`: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html) – `RemoveTags` | 
|  `application` `applicationversion` `configurationtemplate` `environment` `platform`  |  `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The `RemoveTags` action is one of two virtual actions associated with the [http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_UpdateTagsForResource.html) API. The following policy denies the `RemoveTags` action to request the removal of a tag named `stage` from existing resources: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 
| **Action: **[http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ValidateConfigurationSettings.html](http://docs.amazonaws.cn/elasticbeanstalk/latest/api/API_ValidateConfigurationSettings.html) | 
|  `template` `environment`  |  `InApplication` `aws:ResourceTag/key-name` (Optional) `aws:TagKeys` (Optional)  |  The following policy allows the `ValidateConfigurationSettings` action to validates configuration settings against the environment **myenv** in the application **My App**. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/elasticbeanstalk/latest/dg/AWSHowTo.iam.policies.actions.html)  | 

## Condition keys for Elastic Beanstalk actions


Keys enable you to specify conditions that express dependencies, restrict permissions, or specify constraints on the input parameters for an action. Elastic Beanstalk supports the following keys.

`InApplication`  
Specifies the application that contains the resource that the action operates on.  
The following example allows the `UpdateApplicationVersion` action to update the properties of the application version **My Version**. The `InApplication` condition specifies **My App** as the container for **My Version**.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:UpdateApplicationVersion"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/My App/My Version"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App"]
        }
      }
    }
  ]
}
```

`FromApplicationVersion`  
Specifies an application version as a dependency or a constraint on an input parameter.  
The following example allows the `UpdateEnvironment` action to update the environment **myenv** in the application **My App**. The `FromApplicationVersion` condition constrains the `VersionLabel` parameter to allow only the application version **My Version** to update the environment.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:UpdateEnvironment"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/myenv"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App"],
          "elasticbeanstalk:FromApplicationVersion": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/My App/My Version"]
        }
      }
    }
  ]
}
```

`FromConfigurationTemplate`  
Specifies a configuration template as a dependency or a constraint on an input parameter.  
The following example allows the `UpdateEnvironment` action to update the environment **myenv** in the application **My App**. The `FromConfigurationTemplate` condition constrains the `TemplateName` parameter to allow only the configuration template **My Template** to update the environment.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:UpdateEnvironment"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/myenv"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App"],
          "elasticbeanstalk:FromConfigurationTemplate": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:configurationtemplate/My App/My Template"]
        }
      }
    }
  ]
}
```

`FromEnvironment`  
Specifies an environment as a dependency or a constraint on an input parameter.  
The following example allows the `SwapEnvironmentCNAMEs` action to swap the CNAMEs in **My App** for all environments whose names begin with **mysrcenv** and **mydestenv** but not those environments whose names begin with **mysrcenvPROD\$1** and **mydestenvPROD\$1**.     
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:SwapEnvironmentCNAMEs"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/mysrcenv*",
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/mydestenv*"
      ],
      "Condition": {
        "ArnNotLike": {
          "elasticbeanstalk:FromEnvironment": [
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/mysrcenvPROD*",
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/My App/mydestenvPROD*"
          ]
        }
      }
    }
  ]
}
```

`FromSolutionStack`  
Specifies a solution stack as a dependency or a constraint on an input parameter.  
The following policy allows the `CreateConfigurationTemplate` action to create configuration templates whose name begins with **My Template** (`My Template*`) in the application **My App**. The `FromSolutionStack` condition constrains the `solutionstack` parameter to allow only the solution stack **32bit Amazon Linux running Tomcat 7** as the input value for that parameter.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "elasticbeanstalk:CreateConfigurationTemplate"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:configurationtemplate/My App/My Template*"
      ],
      "Condition": {
        "StringEquals": {
          "elasticbeanstalk:InApplication": ["arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/My App"],
          "elasticbeanstalk:FromSolutionStack": ["arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/32bit Amazon Linux running Tomcat 7"]
        }
      }
    }
  ]
}
```

`aws:ResourceTag/key-name``aws:RequestTag/key-name``aws:TagKeys`  
Specify tag-based conditions. For details, see [Using tags to control access to Elastic Beanstalk resourcesExamples of tag conditions in policies](AWSHowTo.iam.policies.access-tags.md).

# Using tags to control access to Elastic Beanstalk resources
Tag-based access control

This topic explains how tag-based access control can help you create and manage IAM policies.

We can use conditions in IAM user policy statements to configure permissions for Elastic Beanstalk's access to resources. To learn more about policy statement conditions, see [Resources and conditions for Elastic Beanstalk actions](AWSHowTo.iam.policies.actions.md). Using tags in conditions is one way to control access to resources and requests. For information about tagging Elastic Beanstalk resources, see [Tagging Elastic Beanstalk application resources](applications-tagging-resources.md).

When you design IAM policies, you might be setting granular permissions by granting access to specific resources. As the number of resources that you manage grows, this task becomes more difficult. Tagging resources and using tags in policy statement conditions can make this task easier. You grant access in bulk to any resource with a certain tag. Then you repeatedly apply this tag to relevant resources, during creation or later.

Tags can be attached to the resource or passed in the request to services that support tagging. In Elastic Beanstalk, resources can have tags, and some actions can include tags. When you create an IAM policy, you can use tag condition keys to control the following conditions:
+ Which users can perform actions on an environment, based on tags that it already has.
+ What tags can be passed in an action's request.
+ Whether specific tag keys can be used in a request.

For the complete syntax and semantics of tag condition keys, see [Controlling Access Using Tags](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*.

## Examples of tag conditions in policies
Examples

The following examples demonstrate how to specify tag conditions in policies for Elastic Beanstalk users.

**Example 1: Limit actions based on tags in the request**  <a name="example_policy_tags.deny_by_request_tag"></a>
The Elastic Beanstalk **AdministratorAccess-AWSElasticBeanstalk** managed user policy gives users unlimited permission to perform any Elastic Beanstalk action on any Elastic Beanstalk-managed resource.   
The following policy limits this power and denies unauthorized users permission to create Elastic Beanstalk production environments. To do that, it denies the `CreateEnvironment` action if the request specifies a tag named `stage` with one of the values `gamma` or `prod`. In addition, the policy prevents these unauthorized users from tampering with the stage of production environments by not allowing tag modification actions to include these same tag values or to completely remove the `stage` tag. A customer's administrator must attach this IAM policy to unauthorized IAM users, in addition to the managed user policy.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "elasticbeanstalk:CreateEnvironment",
        "elasticbeanstalk:AddTags"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/stage": ["gamma", "prod"]
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "elasticbeanstalk:RemoveTags"
      ],
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:TagKeys": ["stage"]
        }
      }
    }
  ]
}
```

**Example 2: Limit actions based on resource tags**  <a name="example_policy_tags.deny_by_resource_tag"></a>
The Elastic Beanstalk **AdministratorAccess-AWSElasticBeanstalk** managed user policy gives users unlimited permission to perform any Elastic Beanstalk action on any Elastic Beanstalk-managed resource.   
The following policy limits this power and denies unauthorized users permission to perform actions on Elastic Beanstalk production environments. To do that, it denies specific actions if the environment has a tag named `stage` with one of the values `gamma` or `prod`. A customer's administrator must attach this IAM policy to unauthorized IAM users, in addition to the managed user policy.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "elasticbeanstalk:AddTags",
        "elasticbeanstalk:RemoveTags",
        "elasticbeanstalk:DescribeEnvironments",
        "elasticbeanstalk:TerminateEnvironment",
        "elasticbeanstalk:UpdateEnvironment",
        "elasticbeanstalk:ListTagsForResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/stage": ["gamma", "prod"]
        }
      }
    }
  ]
}
```

**Example 3: Allow actions based on tags in the request**  <a name="example_policy_tags.allow_by_request_tag"></a>
The following policy grants users permission to create Elastic Beanstalk development applications.   
To do that, it allows the `CreateApplication`and `AddTags` actions if the request specifies a tag named `stage` with the value `development`. The `aws:TagKeys` condition ensures that the user can't add other tag keys. In particular, it ensures case sensitivity of the `stage` tag key. Notice that this policy is useful for IAM users that don't have the Elastic Beanstalk **AdministratorAccess-AWSElasticBeanstalk** managed user policy attached. The managed policy gives users unlimited permission to perform any Elastic Beanstalk action on any Elastic Beanstalk-managed resource.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticbeanstalk:CreateApplication",
        "elasticbeanstalk:AddTags"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/stage": "development"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["stage"]
        }
      }
    }
  ]
}
```

**Example 4: Allow actions based on resource tags**  <a name="example_policy_tags.allow_by_resource_tag"></a>
The following policy grants users permission to perform actions on, and get information about, Elastic Beanstalk development applications.   
To do that, it allows specific actions if the application has a tag named `stage` with the value `development`. The `aws:TagKeys` condition ensures that the user can't add other tag keys. In particular, it ensures case sensitivity of the `stage` tag key. Notice that this policy is useful for IAM users that don't have the Elastic Beanstalk **AdministratorAccess-AWSElasticBeanstalk** managed user policy attached. The managed policy gives users unlimited permission to perform any Elastic Beanstalk action on any Elastic Beanstalk-managed resource.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticbeanstalk:UpdateApplication",
        "elasticbeanstalk:DeleteApplication",
        "elasticbeanstalk:DescribeApplications"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/stage": "development"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["stage"]
        }
      }
    }
  ]
}
```

# Example policies based on managed policies
Example managed policies

This section demonstrates how to control user access to Amazon Elastic Beanstalk and includes example policies that provide the required access for common scenarios. These policies are derived from the Elastic Beanstalk managed policies. For information about attaching managed policies to users and groups, see [Managing Elastic Beanstalk user policies](AWSHowTo.iam.managed-policies.md). 

In this scenario, Example Corp. is a software company with three teams responsible for the company website: administrators who manage the infrastructure, developers who build the software for the website, and a QA team that tests the website. To help manage permissions to their Elastic Beanstalk resources, Example Corp. creates three groups to which members of each respective team belong: Admins, Developers, and Testers. Example Corp. wants the Admins group to have full access to all applications, environments, and their underlying resources so that they can create, troubleshoot, and delete all Elastic Beanstalk assets. Developers require permissions to view all Elastic Beanstalk assets and to create and deploy application versions. Developers should not be able to create new applications or environments or terminate running environments. Testers need to view all Elastic Beanstalk resources to monitor and test applications. The Testers should not be able to make changes to any Elastic Beanstalk resources.

The following example policies provide the required permissions for each group.

## Example 1: Admins group – All Elastic Beanstalk and related service APIs


The following policy gives users permissions for all actions required to use Elastic Beanstalk. This policy also allows Elastic Beanstalk to provision and manage resources on your behalf in the following services. Elastic Beanstalk relies on these additional services to provision underlying resources when creating an environment. 
+ Amazon Elastic Compute Cloud
+ Elastic Load Balancing
+ Auto Scaling
+ Amazon CloudWatch
+ Amazon Simple Storage Service
+ Amazon Simple Notification Service
+ Amazon Relational Database Service
+ Amazon CloudFormation

Note that this policy is an example. It gives a broad set of permissions to the Amazon services that Elastic Beanstalk uses to manage applications and environments. For example, `ec2:*` allows an Amazon Identity and Access Management (IAM) user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "elasticbeanstalk:*",
        "ec2:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "cloudwatch:*",
        "s3:*",
        "sns:*",
        "rds:*",
        "cloudformation:*"
      ],
      "Resource" : "*"
    }
  ]
}
```

------

## Example 2: Developers group – All but highly privileged operations


The following policy denies permission to create applications and environments, and allows all other Elastic Beanstalk actions.

Note that this policy is an example. It gives a broad set of permissions to the Amazon products that Elastic Beanstalk uses to manage applications and environments. For example, `ec2:*` allows an IAM user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement" : [
    {
      "Action" : [
        "elasticbeanstalk:CreateApplication",
        "elasticbeanstalk:CreateEnvironment",
        "elasticbeanstalk:DeleteApplication",
        "elasticbeanstalk:RebuildEnvironment",
        "elasticbeanstalk:SwapEnvironmentCNAMEs",
        "elasticbeanstalk:TerminateEnvironment"],
      "Effect" : "Deny",
      "Resource" : "*"
    },
    {
      "Action" : [
        "elasticbeanstalk:*",
        "ec2:*",
        "elasticloadbalancing:*",
        "autoscaling:*",
        "cloudwatch:*",
        "s3:*",
        "sns:*",
        "rds:*",
        "cloudformation:*"],
      "Effect" : "Allow",
      "Resource" : "*"
    }
  ]
}
```

------



## Example 3: Testers – View only


The following policy allows read-only access to all applications, application versions, events, and environments. It doesn't allow performing any actions.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "elasticbeanstalk:Check*",
        "elasticbeanstalk:Describe*",
        "elasticbeanstalk:List*",
        "elasticbeanstalk:RequestEnvironmentInfo",
        "elasticbeanstalk:RetrieveEnvironmentInfo",
        "ec2:Describe*",
        "elasticloadbalancing:Describe*",
        "autoscaling:Describe*",
        "cloudwatch:Describe*",
        "cloudwatch:List*",
        "cloudwatch:Get*",
        "s3:Get*",
        "s3:List*",
        "sns:Get*",
        "sns:List*",
        "rds:Describe*",
        "cloudformation:Describe*",
        "cloudformation:Get*",
        "cloudformation:List*",
        "cloudformation:Validate*",
        "cloudformation:Estimate*"
      ],
      "Resource" : "*"
    }
  ]
}
```

------

# Example policies based on resource permissions
Example resource-specific policies

This section walks through a use case for controlling user permissions for Elastic Beanstalk actions that access specific Elastic Beanstalk resources. We'll walk through the sample policies that support the use case. For more information policies on Elastic Beanstalk resources, see [Creating a custom user policy](AWSHowTo.iam.managed-policies.md#AWSHowTo.iam.policies). For information about attaching policies to users and groups, go to [Managing IAM Policies](http://docs.amazonaws.cn/IAM/latest/UserGuide/ManagingPolicies.html) in *Using Amazon Identity and Access Management*. 

In our use case, Example Corp. is a small consulting firm developing applications for two different customers. John is the development manager overseeing the development of the two Elastic Beanstalk applications, app1 and app2. John does development and some testing on the two applications, and only he can update the production environment for the two applications. These are the permissions that he needs for app1 and app2:
+ View application, application versions, environments, and configuration templates
+ Create application versions and deploy them to the staging environment
+ Update the production environment
+ Create and terminate environments

Jill is a tester who needs access to view the following resources in order to monitor and test the two applications: applications, application versions, environments, and configuration templates. However, she should not be able to make changes to any Elastic Beanstalk resources.

Jack is the developer for app1 who needs access to view all resources for app1 and also needs to create application versions for app1 and deploy them to the staging environment.

Judy is the administrator of the Amazon account for Example Corp. She has created IAM users for John, Jill, and Jack and attaches the following policies to those users to grant the appropriate permissions to the app1 and app2 applications.

## Example 1: John – Development manager for app1, app2


We have broken down John's policy into three separate policies so that they are easier to read and manage. Together, they give John the permissions he needs to perform development, testing, and deployment actions on the two applications.

The first policy specifies actions for Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation. Elastic Beanstalk relies on these additional services to provision underlying resources when creating an environment.

Note that this policy is an example. It gives a broad set of permissions to the Amazon products that Elastic Beanstalk uses to manage applications and environments. For example, `ec2:*` allows an IAM user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [
   {
   "Effect": "Allow",
   "Action": [
   "ec2:*",
   "ecs:*",
   "ecr:*",
   "elasticloadbalancing:*",
   "autoscaling:*",
   "cloudwatch:*",
   "s3:*",
   "sns:*",
   "cloudformation:*",
   "dynamodb:*",
   "rds:*",
   "sqs:*",
   "logs:*",
   "iam:GetPolicyVersion",
   "iam:GetRole",
   "iam:ListRolePolicies",
   "iam:ListAttachedRolePolicies",
   "iam:ListInstanceProfiles",
   "iam:ListRoles",
   "iam:ListServerCertificates",
   "acm:DescribeCertificate",
   "acm:ListCertificates",
   "codebuild:CreateProject",
   "codebuild:DeleteProject",
   "codebuild:BatchGetBuilds",
   "codebuild:StartBuild"
   ],
   "Resource": "*"
   },
   {
   "Effect": "Allow",
   "Action": [
   "iam:PassRole"
   ],
   "Resource": "arn:aws-cn:iam::111122223333:role/MyRole"
   }
   ]
   }
```

------

The second policy specifies the Elastic Beanstalk actions that John is allowed to perform on the app1 and app2 resources. The `AllCallsInApplications` statement allows all Elastic Beanstalk actions (`"elasticbeanstalk:*"`) performed on all resources within app1 and app2 (for example, `elasticbeanstalk:CreateEnvironment`). The `AllCallsOnApplications` statement allows all Elastic Beanstalk actions (`"elasticbeanstalk:*"`) on the app1 and app2 application resources (for example, `elasticbeanstalk:DescribeApplications`, `elasticbeanstalk:UpdateApplication`, etc.). The `AllCallsOnSolutionStacks` statement allows all Elastic Beanstalk actions (`"elasticbeanstalk:*"`) for solution stack resources (for example, `elasticbeanstalk:ListAvailableSolutionStacks`). 

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllCallsInApplications",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ],
         "Condition":{
            "StringEquals":{
               "elasticbeanstalk:InApplication":[
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1",
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2"
               ]
            }
         }
      },
      {
         "Sid":"AllCallsOnApplications",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1",
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2"
         ]
      },
      {
         "Sid":"AllCallsOnSolutionStacks",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*"
         ]
      }
   ]
}
```

------

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The `AllNonResourceCalls` statement allows the `elasticbeanstalk:CheckDNSAvailability` action, which is required to call `elasticbeanstalk:CreateEnvironment` and other actions. It also allows the `elasticbeanstalk:CreateStorageLocation` action, which is required for `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, and other actions. 

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability",
            "elasticbeanstalk:CreateStorageLocation"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}
```

------

## Example 2: Jill – Tester for app1, app2


We have broken down Jill's policy into three separate policies so that they are easier to read and manage. Together, they give Jill the permissions she needs to perform testing and monitoring actions on the two applications.

The first policy specifies `Describe*`, `List*`, and `Get*` actions on Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation (for non-legacy container types) so that the Elastic Beanstalk actions are able to retrieve the relevant information about the underlying resources of the app1 and app2 applications.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "ec2:Describe*",
            "elasticloadbalancing:Describe*",
            "autoscaling:Describe*",
            "cloudwatch:Describe*",
            "cloudwatch:List*",
            "cloudwatch:Get*",
            "s3:Get*",
            "s3:List*",
            "sns:Get*",
            "sns:List*",
            "rds:Describe*",
            "cloudformation:Describe*",
        	"cloudformation:Get*",
        	"cloudformation:List*",
        	"cloudformation:Validate*",
        	"cloudformation:Estimate*"
         ],
         "Resource":"*"
      }
   ]
}
```

------

The second policy specifies the Elastic Beanstalk actions that Jill is allowed to perform on the app1 and app2 resources. The `AllReadCallsInApplications` statement allows her to call the `Describe*` actions and the environment info actions. The `AllReadCallsOnApplications` statement allows her to call the `DescribeApplications` and `DescribeEvents` actions on the app1 and app2 application resources. The `AllReadCallsOnSolutionStacks` statement allows viewing actions that involve solution stack resources (`ListAvailableSolutionStacks`, `DescribeConfigurationOptions`, and `ValidateConfigurationSettings`). 

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllReadCallsInApplications",
         "Action":[
            "elasticbeanstalk:Describe*",
            "elasticbeanstalk:RequestEnvironmentInfo",
            "elasticbeanstalk:RetrieveEnvironmentInfo"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ],
         "Condition":{
            "StringEquals":{
               "elasticbeanstalk:InApplication":[
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1",
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2"
               ]
            }
         }
      },
      {
         "Sid":"AllReadCallsOnApplications",
         "Action":[
            "elasticbeanstalk:DescribeApplications",
            "elasticbeanstalk:DescribeEvents"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1",
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2"
         ]
      },
      {
         "Sid":"AllReadCallsOnSolutionStacks",
         "Action":[
            "elasticbeanstalk:ListAvailableSolutionStacks",
            "elasticbeanstalk:DescribeConfigurationOptions",
            "elasticbeanstalk:ValidateConfigurationSettings"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*"
         ]
      }
   ]
}
```

------

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The `AllNonResourceCalls` statement allows the `elasticbeanstalk:CheckDNSAvailability` action, which is required for some viewing actions.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}
```

------

## Example 3: Jack – Developer for app1


We have broken down Jack's policy into three separate policies so that they are easier to read and manage. Together, they give Jack the permissions he needs to perform testing, monitoring, and deployment actions on the app1 resource.

The first policy specifies the actions on Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation (for non-legacy container types) so that the Elastic Beanstalk actions are able to view and work with the underlying resources of app1. For a list of supported non-legacy container types, see [Why are some platform versions marked legacy?](using-features.migration.md#using-features.migration.why)

Note that this policy is an example. It gives a broad set of permissions to the Amazon products that Elastic Beanstalk uses to manage applications and environments. For example, `ec2:*` allows an IAM user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "ec2:*",
            "elasticloadbalancing:*",
            "autoscaling:*",
            "cloudwatch:*",
            "s3:*",
            "sns:*",
            "rds:*",
            "cloudformation:*"
         ],
         "Resource":"*"
      }
   ]
}
```

------

The second policy specifies the Elastic Beanstalk actions that Jack is allowed to perform on the app1 resource.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllReadCallsAndAllVersionCallsInApplications",
         "Action":[
            "elasticbeanstalk:Describe*",
            "elasticbeanstalk:RequestEnvironmentInfo",
            "elasticbeanstalk:RetrieveEnvironmentInfo",
            "elasticbeanstalk:CreateApplicationVersion",
            "elasticbeanstalk:DeleteApplicationVersion",
            "elasticbeanstalk:UpdateApplicationVersion"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ],
         "Condition":{
            "StringEquals":{
               "elasticbeanstalk:InApplication":[
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1"
               ]
            }
         }
      },
      {
         "Sid":"AllReadCallsOnApplications",
         "Action":[
            "elasticbeanstalk:DescribeApplications",
            "elasticbeanstalk:DescribeEvents"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1"
         ]
      },
      {
         "Sid":"UpdateEnvironmentInApplications",
         "Action":[
            "elasticbeanstalk:UpdateEnvironment"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/app1/app1-staging*"
         ],
         "Condition":{
            "StringEquals":{
               "elasticbeanstalk:InApplication":[
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1"
               ]
            },
            "ArnLike":{
               "elasticbeanstalk:FromApplicationVersion":[
                  "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/app1/*"
               ]
            }
         }
      },
      {
         "Sid":"AllReadCallsOnSolutionStacks",
         "Action":[
            "elasticbeanstalk:ListAvailableSolutionStacks",
            "elasticbeanstalk:DescribeConfigurationOptions",
            "elasticbeanstalk:ValidateConfigurationSettings"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*"
         ]
      }
   ]
}
```

------

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The `AllNonResourceCalls` statement allows the `elasticbeanstalk:CheckDNSAvailability` action, which is required to call `elasticbeanstalk:CreateEnvironment` and other actions. It also allows the `elasticbeanstalk:CreateStorageLocation` action, which is required for `elasticbeanstalk:CreateEnvironment`, and other actions. 

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability",
            "elasticbeanstalk:CreateStorageLocation"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}
```

------

# Preventing cross-environment Amazon S3 bucket access
Cross-environment S3 bucket access

This topic explains how managed policies may allow cross-environment S3 bucket access and how you can create custom policies to manage this type of access.

Elastic Beanstalk provides managed polices to handle the Amazon resources required by the Elastic Beanstalk environments in your Amazon account. The permissions provided by default to one application in your Amazon account have access to S3 resources that belong to other applications in the same Amazon account.

If your Amazon account runs multiple Beanstalk applications, you can scope down the security of your policies by creating your own [custom policy](AWSHowTo.iam.managed-policies.md#AWSHowTo.iam.policies) to attach to your own [service role](iam-servicerole.md#iam-servicerole-create) or [instance profile](iam-instanceprofile.md#iam-instanceprofile-create) for each environment. You can then limit the S3 permissions in your custom policy to a specific environment.

**Note**  
Be aware that you’re responsible for maintaining your custom policy. If an Elastic Beanstalk managed policy on which your custom policy is based changes, you’ll need to modify your custom policy with the respective changes to the base policy. For a change history of Elastic Beanstalk managed policies, see [Elastic Beanstalk updates to Amazon managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates).

## Example of scoped down permissions


The following example is based on the [AWSElasticBeanstalkWebTier](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkWebTier.html) managed policy.

The default policy includes the following lines for permissions to S3 buckets. This default policy doesn’t limit the S3 bucket actions to specific environments or applications.

```
{
   "Sid" : "BucketAccess", 
   "Action" : [ 
      "s3:Get*",
      "s3:List*", 
      "s3:PutObject"
     ], 
   "Effect" : "Allow",
   "Resource" : [ 
      "arn:aws:s3:::elasticbeanstalk-*", 
      "arn:aws:s3:::elasticbeanstalk-*/*" 
     ] 
}
```

You can scope down the access by qualifying specific resources to a service role specified as a `Principal`. The following example provides the custom service role `aws-elasticbeanstalk-ec2-role-my-example-env` permissions to S3 buckets in the environment with id `my-example-env-ID`.

**Example Grant permissions to only a specific environment's S3 buckets**  

```
{
   "Sid": "BucketAccess",
   "Action": [
      "s3:Get*",
      "s3:List*",
      "s3:PutObject"
    ],
   "Effect": "Allow",
   "Principal": {
      "AWS": "arn:aws:iam::...:role/aws-elasticbeanstalk-ec2-role-my-example-env"
     },
   "Resource": [
      "arn:aws:s3:::elasticbeanstalk-my-region-account-id-12345",
      "arn:aws:s3:::elasticbeanstalk-my-region-account-id-12345/resources/environments/my-example-env-ID/*"
    ]
}
```

**Note**  
The Resource ARN must include the Elastic Beanstalk environment ID, (not the environment name). You can obtain the environment id from the Elastic Beanstalk console on the [Environment overview](environments-dashboard.md) page. You can also use the Amazon CLI [ describe-environments](https://docs.amazonaws.cn/cli/latest/reference/elasticbeanstalk/describe-environments.html) command to obtain this information.

For more information to help you update S3 bucket permissions for your Elastic Beanstalk environments, see the following resources:
+ [Using Elastic Beanstalk with Amazon S3](AWSHowTo.S3.md) in this guide
+ [Resource types defined by Amazon S3](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazons3.html#amazons3-resources-for-iam-policies) in the *Service Authorization Reference* guide
+ [ARN format](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference-arns.html) in the *IAM User Guide*