

• The Amazon Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

# Identity and access management for Amazon Systems Manager
<a name="security-iam"></a>

Amazon Identity and Access Management (IAM) is an Amazon Web Services service that helps an administrator securely control access to Amazon resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Systems Manager resources. IAM is an Amazon Web Services service that you can use with no additional charge.

**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How Amazon Systems Manager works with IAM](security_iam_service-with-iam.md)
+ [Amazon Systems Manager identity-based policy examples](security_iam_id-based-policy-examples.md)
+ [Amazon managed policies for Amazon Systems Manager](security-iam-awsmanpol.md)
+ [Troubleshooting Amazon Systems Manager identity and access](security_iam_troubleshoot.md)

## Audience
<a name="security_iam_audience"></a>

How you use Amazon Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting Amazon Systems Manager identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How Amazon Systems Manager works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [Amazon Systems Manager identity-based policy examples](security_iam_id-based-policy-examples.md))

## Authenticating with identities
<a name="security_iam_authentication"></a>

Authentication is how you sign in to Amazon using your identity credentials. You must be authenticated as the Amazon Web Services account root user, an IAM user, or by assuming an IAM role.

For programmatic access, Amazon provides an SDK and CLI to cryptographically sign requests. For more information, see [Amazon Signature Version 4 for API requests](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.

### Amazon Web Services account root user
<a name="security_iam_authentication-rootuser"></a>

 When you create an Amazon Web Services account, you begin with one sign-in identity called the Amazon Web Services account *root user* that has complete access to all Amazon Web Services services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. 

### IAM users and groups
<a name="security_iam_authentication-iamuser"></a>

An *[IAM user](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access Amazon using temporary credentials](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.

An [https://docs.amazonaws.cn/IAM/latest/UserGuide/id_groups.html](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.amazonaws.cn/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.

### IAM roles
<a name="security_iam_authentication-iamrole"></a>

An *[IAM role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an Amazon CLI or Amazon API operation. For more information, see [Methods to assume a role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.

IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

## Managing access using policies
<a name="security_iam_access-manage"></a>

You control access in Amazon by creating policies and attaching them to Amazon identities or resources. A policy defines permissions when associated with an identity or resource. Amazon evaluates these policies when a principal makes a request. Most policies are stored in Amazon as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.

Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.

By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.

### Identity-based policies
<a name="security_iam_access-manage-id-based-policies"></a>

Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.

For information about Amazon managed policies for Systems Manager, see [Amazon Systems Manager managed policies](security_iam_service-with-iam.md#managed-policies).

### Resource-based policies
<a name="security_iam_access-manage-resource-based-policies"></a>

Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.

Resource-based policies are inline policies that are located in that service. You can't use Amazon managed policies from IAM in a resource-based policy.

### Policy condition keys
<a name="policy-condition-keys"></a>

The actions that users and roles can perform and the resources on which they can take those actions can be further restricted by specific *conditions*. 

In JSON policy documents, the `Condition` element (or `Condition` block) lets you specify conditions in which a statement is in effect. The `Condition` element is optional. You can create conditional expressions that use [condition operators](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as `StringEquals` or `StringNotLike`, to match the condition in the policy with values in the request. 

If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, Amazon evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, Amazon evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement's permissions are granted.

You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see [IAM policy elements: variables and tags](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_variables.html) in the *IAM User Guide*. 

Amazon supports global condition keys and service-specific condition keys. For more information, see [Amazon global condition context keys](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.

**Important**  
If you use Systems Manager Automation, we recommend you don't use the [aws:SourceIp](https://docs.amazonaws.cn//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip) condition key in your policies. The behavior of this condition key is dependent on multiple factors, including whether an IAM role for Automation runbook execution is supplied and the Automation actions used in the runbook. As a result, the condition key can produce unexpected behavior. For this reason, we recommend you don't use it.

Systems Manager supports a number of its own condition keys. For more information, see [Condition Keys for Amazon Systems Manager](https://docs.amazonaws.cn/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) in the *Service Authorization Reference*. The actions and resources you can use a Systems Manager-specific condition key with are listed in [Resource types defined by Amazon Systems Manager](https://docs.amazonaws.cn/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys) in the *Service Authorization Reference*.

If your policy must depend on a service principal name owned by the Systems Manager service, we recommend you check for its existence or non-existence using the `aws:PrincipalServiceNamesList` [multivalued condition key](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-single-vs-multi-valued-context-keys.html#reference_policies_condition-multi-valued-context-keys), rather than the `aws:PrincipalServiceName` condition key. The `aws:PrincipalServiceName` condition key contains only one entry from the list of service principal names and it may not always be the service principal name you expect. The following `Condition` block demonstrates checking for the existence of `ssm.amazonaws.com`. 

```
{
    "Condition": {
        "ForAnyValue:StringEquals": {
            "aws:PrincipalServiceNamesList": "ssm.amazonaws.com"
        }
    }
}
```

To view examples of Systems Manager identity-based policies, see [Amazon Systems Manager identity-based policy examples](security_iam_id-based-policy-examples.md).

### Access control lists (ACLs)
<a name="security_iam_access-manage-acl"></a>

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

Amazon S3, Amazon WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.amazonaws.cn/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.

### Other policy types
<a name="security_iam_access-manage-other-policies"></a>

Amazon supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in Amazon Organizations. For more information, see [Service control policies](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *Amazon Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *Amazon Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.

### Multiple policy types
<a name="security_iam_access-manage-multiple-policies"></a>

When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how Amazon determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.