docs.aws.amazon.com
Open in
urlscan Pro
18.66.147.89
Public Scan
Submitted URL: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html#managed-policies-cloudwatch-C...
Effective URL: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html
Submission: On October 23 via api from US — Scanned from DE
Effective URL: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html
Submission: On October 23 via api from US — Scanned from DE
Form analysis 0 forms found in the DOM
Text Content
SELECT YOUR COOKIE PREFERENCES
We use essential cookies and similar tools that are necessary to provide our
site and services. We use performance cookies to collect anonymous statistics so
we can understand how customers use our site and make improvements. Essential
cookies cannot be deactivated, but you can click “Customize cookies” to decline
performance cookies.
If you agree, AWS and approved third parties will also use cookies to provide
useful site features, remember your preferences, and display relevant content,
including relevant advertising. To continue without accepting these cookies,
click “Continue without accepting.” To make more detailed choices or learn more,
click “Customize cookies.”
Accept all cookiesContinue without acceptingCustomize cookies
CUSTOMIZE COOKIE PREFERENCES
We use cookies and similar tools (collectively, "cookies") for the following
purposes.
ESSENTIAL
Essential cookies are necessary to provide our site and services and cannot be
deactivated. They are usually set in response to your actions on the site, such
as setting your privacy preferences, signing in, or filling in forms.
PERFORMANCE
Performance cookies provide anonymous statistics about how customers navigate
our site so we can improve site experience and performance. Approved third
parties may perform analytics on our behalf, but they cannot use the data for
their own purposes.
Allow performance category
Allowed
FUNCTIONAL
Functional cookies help us provide useful site features, remember your
preferences, and display relevant content. Approved third parties may set these
cookies to provide certain site features. If you do not allow these cookies,
then some or all of these services may not function properly.
Allow functional category
Allowed
ADVERTISING
Advertising cookies may be set through our site by us or our advertising
partners and help us deliver relevant marketing content. If you do not allow
these cookies, you will experience less relevant advertising.
Allow advertising category
Allowed
Blocking some types of cookies may impact your experience of our sites. You may
review and change your choices at any time by clicking Cookie preferences in the
footer of this site. We and selected third-parties use cookies or similar
technologies as specified in the AWS Cookie Notice.
CancelSave preferences
UNABLE TO SAVE COOKIE PREFERENCES
We will only store essential cookies at this time, because we were unable to
save your cookie preferences.
If you want to change your cookie preferences, try again later using the link in
the AWS console footer, or contact support if the problem persists.
Dismiss
Contact Us
English
Create an AWS Account
1. AWS
2. ...
3. Documentation
4. Amazon CloudWatch
5. User Guide
Feedback
Preferences
AMAZON CLOUDWATCH
USER GUIDE
* What is Amazon CloudWatch?
* How CloudWatch works
* Concepts
* Resources
* Getting set up
* Getting started
* See key metrics from all AWS services
* Focus on a single service
* Focus on a resource group
* CloudWatch billing and cost
* Dashboards
* Create a dashboard
* CloudWatch cross-account observability dashboard
* Cross-account cross-Region dashboards
* Create flexible dashboards with dashboard variables
* Tutorial: Create a Lambda dashboard with function name as the variable
* Tutorial: Create a dashboard that uses a regular expression pattern to
switch between Regions
* Copy a variable to another dashboard
* Create and work with widgets on CloudWatch dashboards
* Add or remove a graph
* Graph metrics manually on a CloudWatch dashboard
* Edit a graph
* Edit a graph
* Move or resize a graph
* Rename a graph
* Add an explorer widget to a CloudWatch dashboard
* Add or remove a line widget
* Add or remove a number widget
* Add or remove a gauge widget
* Add a custom widget to a CloudWatch dashboard
* Details about custom widgets
* Security and JavaScript
* Interactivity in the custom widget
* Create a custom widget
* Sample custom widgets
* Add or remove a text widget
* Add or remove an alarm widget
* Link and unlink graphs
* Sharing dashboards
* Use live data
* Viewing an animated dashboard
* Add a dashboard to your favorites list
* Change the period override setting or refresh interval
* Change the time range or time zone format
* Metrics
* Basic monitoring and detailed monitoring
* Query your metrics with CloudWatch Metrics Insights
* Build your queries
* Query components and syntax
* Reserved keywords
* Create alarms on Metrics Insights queries
* Create a Metrics Insights alarm
* Partial data cases
* Use Metrics Insights queries with metric math
* SQL inference
* Sample queries
* Metrics Insights limits
* Metrics Insights glossary
* Troubleshooting Metrics Insights
* Use metrics explorer to monitor resources by their tags and properties
* Use metric streams
* Set up a metric stream
* Custom setup with Kinesis Data Firehose
* Use Quick Amazon S3 setup
* Quick partner setup
* Statistics that can be streamed
* Metric stream operation and maintenance
* Monitor your metric streams with CloudWatch metrics
* Trust between CloudWatch and Kinesis Data Firehose
* Metric streams output formats
* JSON format
* OpenTelemetry 0.7.0 format
* Translations with OpenTelemetry 0.7.0 format
* How to parse OpenTelemetry 0.7.0 messages
* Troubleshooting
* View available metrics
* Search for available metrics
* Graphing metrics
* Graph a metric
* Merge two graphs into one
* Use dynamic labels
* Modify the time range or time zone format for a graph
* Zooming in on a graph
* Modify the y-axis for a graph
* Create an alarm from a metric on a graph
* Using anomaly detection
* Use metric math
* Use search expressions in graphs
* Search expression syntax
* Search expression examples
* Creating a graph with a search expression
* Get statistics for a metric
* CloudWatch statistics definitions
* Get statistics for a specific resource
* Aggregate statistics across resources
* Aggregate statistics by Auto Scaling group
* Aggregating statistics by AMI
* Publish custom metrics
* Alarms
* Alarm recommendations for AWS services
* Alarming on metrics
* Create an alarm based on a static threshold
* Create an alarm based on a metric math expression
* Create an alarm based on a Metrics Insights query
* Create an alarm based on anomaly detection
* Alarming on logs
* Create an alarm based on a log group-metric filter
* Combining alarms
* Create a composite alarm
* Suppressing composite alarm actions
* Acting on alarm changes
* Notifying users on alarm changes
* Alarm events and EventBridge
* Managing alarms
* Editing or deleting a CloudWatch alarm
* Hiding Auto Scaling alarms
* Alarm use cases and examples
* Create a billing alarm
* Create a CPU usage alarm
* Create a load balancer latency alarm
* Create a storage throughput alarm
* Create an alarm on Performance Insights counter metrics from an AWS
database
* Create alarms to stop, terminate, reboot, or recover an EC2 instance
* Application monitoring
* Using ServiceLens to monitor the health of your applications
* Deploying ServiceLens
* Deploying AWS X-Ray
* Integrating with CloudWatch Logs
* Enabling segment metrics from X-Ray
* Deploying the CloudWatch agent and the X-Ray daemon
* Deploying on Amazon ECS
* Deploying on Amazon EKS or Kubernetes
* Deploying on Amazon EC2
* Using the service map
* Using the resource health view
* ServiceLens troubleshooting
* Using Internet Monitor
* Supported Regions
* Pricing
* Components
* How Internet Monitor works
* Use cases
* Getting started
* Creating a monitor
* Adding resources to your monitor
* Setting your application traffic percentage
* Choosing a city-networks maximum limit
* Publishing internet measurements to S3
* Using a monitor
* Editing or deleting a monitor
* Add or create monitor when you create a VPC
* Examples with the CLI
* Internet Monitor dashboard
* Tracking real-time performance and availability
* Exploring historical data
* Using insights to improve your network setup
* Explore data using tools
* CloudWatch Logs Insights
* CloudWatch Contributor Insights
* CloudWatch Metrics
* Athena with S3 logs
* Internet Monitor query interface
* Create alarms
* EventBridge integration
* Data protection and data privacy
* Identity and Access Management
* How Internet Monitor works with IAM
* IAM permissions
* Using a service-linked role for Internet Monitor
* Quotas
* Using synthetic monitoring
* Required roles and permissions
* Required roles and permissions for users who manage CloudWatch
canaries
* Required roles and permissions for canaries
* Limiting a user to viewing specific canaries
* Creating a canary
* Using canary blueprints
* Using the CloudWatch Synthetics Recorder for Google Chrome
* Synthetics runtime versions
* Runtime versions using Node.js and Puppeteer
* Runtime versions using Python and Selenium Webdriver
* Writing a canary script
* Writing a Node.js canary script
* Writing a Python canary script
* Library functions available for canary scripts
* Library functions available for Node.js canary scripts
* Library functions available for Python canary scripts using
Selenium
* Scheduling canary runs using cron
* Groups
* Troubleshooting a failed canary
* Troubleshooting a canary on a VPC
* Sample code for canary scripts
* Canaries and X-Ray tracing
* Running a canary on a VPC
* Encrypting canary artifacts
* Viewing canary statistics and details
* CloudWatch metrics published by canaries
* Edit or delete a canary
* Start, stop, delete, or update runtime for multiple canaries
* Monitoring canary events with Amazon EventBridge
* Perform launches and A/B experiments with CloudWatch Evidently
* IAM policies to use Evidently
* Create projects, features, launches, and experiments
* Create a new project
* Use client-side evaluation - powered by AWS AppConfig
* Add a feature to a project
* Use segments to focus your audience
* Create a launch
* Create an experiment
* Manage features, launches, and experiments
* See the current evaluation rules and audience traffic for a feature
* Modify launch traffic
* Modify a launch's future steps
* Modify experiment traffic
* Stop a launch
* Stop an experiment
* Adding code to your application
* Project data storage
* How Evidently calculates results
* View launch results in the dashboard
* View experiment results in the dashboard
* How CloudWatch Evidently collects and stores data
* Using service-linked roles
* CloudWatch Evidently quotas
* Tutorial: A/B testing with the Evidently sample application
* Use CloudWatch RUM
* IAM policies to use CloudWatch RUM
* Set up an application to use CloudWatch RUM
* Step 1: Authorize your application to send data to AWS
* Step 2: Create an app monitor
* (Optional) Step 3: Manually modify the code snippet to configure the
CloudWatch RUM web client
* Step 4: Insert the code snippet into your application
* Step 5: Test your app monitor setup by generating user events
* Configuring the CloudWatch RUM web client
* Regionalization
* Use page groups
* Specify custom metadata
* Send custom events
* Viewing the CloudWatch RUM dashboard
* How CloudWatch RUM sets Apdex scores
* CloudWatch metrics that you can collect with CloudWatch RUM
* Custom metrics and extended metrics
* Data protection and data privacy with CloudWatch RUM
* Information collected by the CloudWatch RUM web client
* Route change timing for single-page applications
* Manage your applications that use CloudWatch RUM
* How do I find a code snippet that I've already generated?
* Edit your application
* Stop using CloudWatch RUM or delete an app monitor
* CloudWatch RUM quotas
* Troubleshooting
* Insights and operational visibility
* Using Container Insights
* Setting up Container Insights
* Setting up Container Insights on Amazon ECS
* Setting up Container Insights on Amazon ECS for cluster- and
service-level metrics
* Setting up Container Insights on Amazon ECS using AWS Distro for
OpenTelemetry
* Deploying the CloudWatch agent to collect EC2 instance-level
metrics on Amazon ECS
* Deploying the AWS Distro for OpenTelemetry to collect EC2
instance-level metrics on Amazon ECS clusters
* Set up FireLens to send logs to CloudWatch Logs
* Setting up Container Insights on Amazon EKS and Kubernetes
* Verify prerequisites
* Using the CloudWatch agent
* Quick Start setup for Container Insights on Amazon EKS and
Kubernetes
* Set up the CloudWatch agent to collect cluster metrics
* Using AWS Distro for OpenTelemetry
* Send logs to CloudWatch Logs
* Set up Fluent Bit as a DaemonSet to send logs to CloudWatch
Logs
* (Optional) Set up Fluentd as a DaemonSet to send logs to
CloudWatch Logs
* (Optional) Set up Amazon EKS control plane logging
* (Optional) Enable App Mesh Envoy access logs
* (Optional) Enable the Use_Kubelet feature for large clusters
* Updating or deleting Container Insights on Amazon EKS and
Kubernetes
* Updating the CloudWatch agent container image
* Deleting the CloudWatch agent and Fluentd for Container
Insights
* Viewing Container Insights metrics
* Metrics collected by Container Insights
* Amazon ECS Container Insights metrics
* Amazon EKS and Kubernetes Container Insights metrics
* Performance log reference
* Performance log events for Amazon ECS
* Performance log events for Amazon EKS and Kubernetes
* Relevant fields in performance log events for Amazon EKS and
Kubernetes
* Container Insights Prometheus metrics monitoring
* Set up and configure on Amazon ECS clusters
* Set up on Amazon ECS clusters
* Scraping additional Prometheus sources and importing those
metrics
* Detailed guide for autodiscovery on Amazon ECS clusters
* (Optional) Set up sample containerized Amazon ECS workloads for
Prometheus metric testing
* Sample App Mesh workload for Amazon ECS clusters
* Sample Java/JMX workload for Amazon ECS clusters
* Sample NGINX workload for Amazon ECS clusters
* Sample NGINX Plus workload for Amazon ECS clusters
* Tutorial for adding a new Prometheus scrape target: Memcached
on Amazon ECS
* Tutorial for scraping Redis Prometheus metrics on Amazon ECS
Fargate
* Set up and configure on Amazon EKS and Kubernetes clusters
* Set up on Amazon EKS and Kubernetes clusters
* Scraping additional Prometheus sources and importing those
metrics
* (Optional) Set up sample containerized Amazon EKS workloads
for Prometheus metric testing
* Set up AWS App Mesh sample workload for Amazon EKS and
Kubernetes
* Set up AWS App Mesh sample workload on an Amazon EKS
cluster with the EC2 launch type or a Kubernetes cluster
* Set up AWS App Mesh sample workload on an Amazon EKS
cluster with the Fargate launch type
* Set up NGINX with sample traffic on Amazon EKS and
Kubernetes
* Set up memcached with a metric exporter on Amazon EKS and
Kubernetes
* Set up Java/JMX sample workload on Amazon EKS and
Kubernetes
* Set up HAProxy with a metric exporter on Amazon EKS and
Kubernetes
* Tutorial for adding a new Prometheus scrape target: Redis
on Amazon EKS and Kubernetes clusters
* Prometheus metric type conversion by the CloudWatch Agent
* Prometheus metrics collected by the CloudWatch agent
* Viewing your Prometheus metrics
* Prometheus metrics troubleshooting
* Prometheus metrics troubleshooting on Amazon ECS
* Prometheus metrics troubleshooting on Amazon EKS and
Kubernetes clusters
* Integration with Application Insights
* See Amazon ECS lifecycle events within Container Insights
* Troubleshooting Container Insights
* Building your own CloudWatch agent Docker image
* Deploying other CloudWatch agent features in your containers
* Using Lambda Insights
* Getting started with Lambda Insights
* Available versions of the Lambda Insights extension
* x86-64 platforms
* ARM64 platforms
* Using the console to enable Lambda Insights on an existing Lambda
function
* Using the AWS CLI to enable Lambda Insights on an existing Lambda
function
* Using the AWS SAM CLI to enable Lambda Insights on an existing
Lambda function
* Using AWS CloudFormation to enable Lambda Insights on an existing
Lambda function
* Using the AWS CDK to enable Lambda Insights on an existing Lambda
function
* Using Serverless Framework to enable Lambda Insights on an existing
Lambda function
* Enabling Lambda Insights on a Lambda container image deployment
* Viewing your Lambda Insights metrics
* Integration with Application Insights
* Metrics collected by Lambda Insights
* Troubleshooting and known issues
* Example telemetry event
* Using Contributor Insights to analyze high-cardinality data
* Create a Contributor Insights rule
* Contributor Insights rule syntax
* Example rules
* Viewing Contributor Insights reports
* Graphing metrics generated by rules
* Using Contributor Insights built-in rules
* Detect common application problems with CloudWatch Application Insights
* What is Amazon CloudWatch Application Insights?
* How Application Insights works
* Get started
* Access CloudWatch Application Insights
* Prerequisites
* IAM policy
* Permissions for account-based application onboarding
* Set up, configure, and manage your application
* Console steps
* Command line steps
* Events and notifications
* Application Insights cross-account observability
* Work with component configurations
* Template fragment
* Sections
* Example configurations for relevant services
* Amazon DynamoDB table
* Amazon EC2 Auto Scaling (ASG)
* Amazon EKS cluster
* Amazon Elastic Compute Cloud (EC2) instance
* Amazon Elastic Container Service (Amazon ECS)
* Amazon ECS services
* Amazon ECS tasks
* Amazon Elastic File System (Amazon EFS)
* Amazon FSx
* Amazon Relational Database Service (RDS) Aurora MySQL
* Amazon Relational Database Service (RDS) instance
* Amazon Route 53 health check
* Amazon Route 53 hosted zone
* Amazon Route 53 Resolver endpoint
* Amazon Route 53 Resolver query logging configuration
* Amazon S3 bucket
* Amazon Simple Queue Service (SQS)
* Amazon SNS topic
* Amazon Virtual Private Cloud (Amazon VPC)
* Amazon VPC Network Address Translation (NAT) gateways
* API Gateway REST API stages
* Application Elastic Load Balancing
* AWS Lambda Function
* AWS Network Firewall rule group
* AWS Network Firewall rule group association
* AWS Step Functions
* Customer-grouped Amazon EC2 instances
* Elastic Load Balancing
* Java
* Kubernetes on Amazon EC2
* RDS MariaDB and RDS MySQL
* RDS Oracle
* RDS PostgreSQL
* SAP HANA on Amazon EC2
* SAP HANA High Availability on Amazon EC2
* SAP NetWeaver on Amazon EC2
* SAP NetWeaver High Availability on Amazon EC2
* SQL Always On Availability Group
* SQL failover cluster instance
* Use CloudFormation templates
* Tutorial: Set up monitoring for SAP HANA
* Tutorial: Set up monitoring for SAP NetWeaver
* View and troubleshoot Application Insights
* Supported logs and metrics
* Amazon Elastic Compute Cloud (EC2)
* Elastic Block Store (EBS)
* Amazon Elastic File System (Amazon EFS)
* Elastic Load Balancer (ELB)
* Application ELB
* Amazon EC2 Auto Scaling groups
* Amazon Simple Queue Server (SQS)
* Amazon Relational Database Service (RDS)
* AWS Lambda function
* Amazon DynamoDB table
* Amazon S3 bucket
* AWS Step Functions
* API Gateway REST API stages
* SAP HANA
* SAP NetWeaver
* HA Cluster
* Java
* Amazon Elastic Container Service (Amazon ECS)
* Kubernetes on AWS
* Amazon FSx
* Amazon VPC
* Amazon VPC NAT gateways
* Amazon Route 53 health check
* Amazon Route 53 hosted zone
* Amazon Route 53 Resolver endpoint
* AWS Network Firewall rule group
* AWS Network Firewall rule group association
* Metrics with data points requirements
* Recommended metrics
* Performance Counter metrics
* CloudWatch cross-account observability
* Link monitoring accounts with source accounts
* Manage monitoring accounts and source accounts
* Collect metrics, logs, and traces with the CloudWatch agent
* Installing the CloudWatch agent
* Installing the CloudWatch agent using the command line
* Download and configure the CloudWatch agent
* Create IAM roles and users for use with CloudWatch agent
* Installing and running the CloudWatch agent on your servers
* Install the CloudWatch agent using Systems Manager
* Create IAM roles and users for use with the CloudWatch agent
* Download and configure the CloudWatch agent
* Installing the CloudWatch agent on EC2 instances
* Installing the CloudWatch agent on on-premises servers
* Installing the CloudWatch agent on new instances using AWS
CloudFormation
* Verifying the signature of the CloudWatch agent package
* Create the CloudWatch agent configuration file
* Create the CloudWatch agent configuration file with the wizard
* Manually create or edit the CloudWatch agent configuration file
* Collect network performance metrics
* Collect NVIDIA GPU metrics
* Collect process metrics with the procstat plugin
* Retrieve custom metrics with StatsD
* Retrieve custom metrics with collectd
* Set up and configure Prometheus metrics collection on Amazon EC2
instances
* Metrics collected by the CloudWatch agent
* Common scenarios with the CloudWatch agent
* Troubleshooting the CloudWatch agent
* Embedding metrics within logs
* Publishing logs with the embedded metric format
* Using the client libraries
* Specification: Embedded metric format
* Using the PutLogEvents API to send manually-created embedded metric
format logs
* Using the CloudWatch agent to send embedded metric format logs
* Using the embedded metric format with AWS Distro for OpenTelemetry
* Viewing your metrics and logs in the console
* Setting alarms on metrics created with the embedded metric format
* Services that publish CloudWatch metrics
* AWS usage metrics
* Visualizing your service quotas and setting alarms
* AWS API usage metrics
* CloudWatch usage metrics
* CloudWatch tutorials
* Scenario: Monitor estimated charges
* Scenario: Publish metrics
* Working with AWS SDKs
* Code examples
* Actions
* Create a dashboard
* Create a metric alarm
* Create an anomaly detector
* Delete alarms
* Delete an anomaly detector
* Delete dashboards
* Describe alarm history
* Describe alarms
* Describe alarms for a metric
* Describe anomaly detectors
* Disable alarm actions
* Enable alarm actions
* Get a metric data image
* Get dashboard details
* Get metric data
* Get metric statistics
* List dashboards
* List metrics
* Put a set of data into a metric
* Put data into a metric
* Scenarios
* Get started with alarms
* Get started with metrics, dashboards, and alarms
* Manage metrics and alarms
* Security
* Data protection
* Identity and access management
* How Amazon CloudWatch works with IAM
* Identity-based policy examples
* Troubleshooting
* CloudWatch dashboard permissions update
* Using condition keys to limit access to CloudWatch namespaces
* Using condition keys to limit Contributor Insights users' access to log
groups
* Using condition keys to limit alarm actions
* Using service-linked roles
* Using a service-linked role for CloudWatch RUM
* Using service-linked roles for Application Insights
* AWS managed policies for Application Insights
* Amazon CloudWatch permissions reference
* Compliance validation
* Resilience
* Infrastructure security
* AWS Security Hub
* Interface VPC endpoints
* Security considerations for Synthetics canaries
* Logging API calls with AWS CloudTrail
* Tagging your CloudWatch resources
* Grafana integration
* Cross-account cross-Region CloudWatch console
* Service quotas
* Document history
Identity and access management for Amazon CloudWatch - Amazon CloudWatch
AWSDocumentationAmazon CloudWatchUser Guide
AudienceAuthenticating with identitiesManaging access using policiesAWS managed
(predefined) policies for CloudWatchCustomer managed policy examplesPolicy
updates
IDENTITY AND ACCESS MANAGEMENT FOR AMAZON CLOUDWATCH
PDFRSS
AWS Identity and Access Management (IAM) is an AWS service that helps an
administrator securely control access to AWS resources. IAM administrators
control who can be authenticated (signed in) and authorized (have permissions)
to use CloudWatch resources. IAM is an AWS service that you can use with no
additional charge.
TOPICS
* Audience
* Authenticating with identities
* Managing access using policies
* How Amazon CloudWatch works with IAM
* Identity-based policy examples for Amazon CloudWatch
* Troubleshooting Amazon CloudWatch identity and access
* CloudWatch dashboard permissions update
* AWS managed (predefined) policies for CloudWatch
* Customer managed policy examples
* CloudWatch updates to AWS managed policies
* Using condition keys to limit access to CloudWatch namespaces
* Using condition keys to limit Contributor Insights users' access to log
groups
* Using condition keys to limit alarm actions
* Using service-linked roles for CloudWatch
* Using service-linked roles for CloudWatch RUM
* Using service-linked roles for CloudWatch Application Insights
* AWS managed policies for Amazon CloudWatch Application Insights
* Amazon CloudWatch permissions reference
AUDIENCE
How you use AWS Identity and Access Management (IAM) differs, depending on the
work that you do in CloudWatch.
Service user – If you use the CloudWatch service to do your job, then your
administrator provides you with the credentials and permissions that you need.
As you use more CloudWatch features to do your work, you might need additional
permissions. Understanding how access is managed can help you request the right
permissions from your administrator. If you cannot access a feature in
CloudWatch, see Troubleshooting Amazon CloudWatch identity and access.
Service administrator – If you're in charge of CloudWatch resources at your
company, you probably have full access to CloudWatch. It's your job to determine
which CloudWatch features and resources your service users should access. You
must then submit requests to your IAM administrator to change the permissions of
your service users. Review the information on this page to understand the basic
concepts of IAM. To learn more about how your company can use IAM with
CloudWatch, see How Amazon CloudWatch works with IAM.
IAM administrator – If you're an IAM administrator, you might want to learn
details about how you can write policies to manage access to CloudWatch. To view
example CloudWatch identity-based policies that you can use in IAM, see
Identity-based policy examples for Amazon CloudWatch.
AUTHENTICATING WITH IDENTITIES
Authentication is how you sign in to AWS using your identity credentials. You
must be authenticated (signed in to AWS) as the AWS account root user, as an IAM
user, or by assuming an IAM role.
You can sign in to AWS as a federated identity by using credentials provided
through an identity source. AWS IAM Identity Center (IAM Identity Center) users,
your company's single sign-on authentication, and your Google or Facebook
credentials are examples of federated identities. When you sign in as a
federated identity, your administrator previously set up identity federation
using IAM roles. When you access AWS by using federation, you are indirectly
assuming a role.
Depending on the type of user you are, you can sign in to the AWS Management
Console or the AWS access portal. For more information about signing in to AWS,
see How to sign in to your AWS account in the AWS Sign-In User Guide.
If you access AWS programmatically, AWS provides a software development kit
(SDK) and a command line interface (CLI) to cryptographically sign your requests
by using your credentials. If you don't use AWS tools, you must sign requests
yourself. For more information about using the recommended method to sign
requests yourself, see Signing AWS API requests in the IAM User Guide.
Regardless of the authentication method that you use, you might be required to
provide additional security information. For example, AWS recommends that you
use multi-factor authentication (MFA) to increase the security of your account.
To learn more, see Multi-factor authentication in the AWS IAM Identity Center
User Guide and Using multi-factor authentication (MFA) in AWS in the IAM User
Guide.
AWS ACCOUNT ROOT USER
When you create an AWS account, you begin with one sign-in identity that has
complete access to all AWS services and resources in the account. This identity
is called the AWS account root user and is accessed by signing in with the email
address and password that you used to create the account. We strongly recommend
that you don't use the root user for your everyday tasks. Safeguard your root
user credentials and use them to perform the tasks that only the root user can
perform. For the complete list of tasks that require you to sign in as the root
user, see Tasks that require root user credentials in the IAM User Guide.
FEDERATED IDENTITY
As a best practice, require human users, including users that require
administrator access, to use federation with an identity provider to access AWS
services by using temporary credentials.
A federated identity is a user from your enterprise user directory, a web
identity provider, the AWS Directory Service, the Identity Center directory, or
any user that accesses AWS services by using credentials provided through an
identity source. When federated identities access AWS accounts, they assume
roles, and the roles provide temporary credentials.
For centralized access management, we recommend that you use AWS IAM Identity
Center. You can create users and groups in IAM Identity Center, or you can
connect and synchronize to a set of users and groups in your own identity source
for use across all your AWS accounts and applications. For information about IAM
Identity Center, see What is IAM Identity Center? in the AWS IAM Identity Center
User Guide.
IAM USERS AND GROUPS
An IAM user is an identity within your AWS account that has specific permissions
for a single person or application. Where possible, we recommend relying on
temporary credentials instead of creating IAM users who have long-term
credentials such as passwords and access keys. However, if you have specific use
cases that require long-term credentials with IAM users, we recommend that you
rotate access keys. For more information, see Rotate access keys regularly for
use cases that require long-term credentials in the IAM User Guide.
An IAM group is an identity that specifies a collection of IAM users. You can't
sign in as a group. You can use groups to specify permissions for multiple users
at a time. Groups make permissions easier to manage for large sets of users. For
example, you could have a group named IAMAdmins and give that group permissions
to administer IAM resources.
Users are different from roles. A user is uniquely associated with one person or
application, but a role is intended to be assumable by anyone who needs it.
Users have permanent long-term credentials, but roles provide temporary
credentials. To learn more, see When to create an IAM user (instead of a role)
in the IAM User Guide.
IAM ROLES
An IAM role is an identity within your AWS account that has specific
permissions. It is similar to an IAM user, but is not associated with a specific
person. You can temporarily assume an IAM role in the AWS Management Console by
switching roles. You can assume a role by calling an AWS CLI or AWS API
operation or by using a custom URL. For more information about methods for using
roles, see Using IAM roles in the IAM User Guide.
IAM roles with temporary credentials are useful in the following situations:
* Federated user access – To assign permissions to a federated identity, you
create a role and define permissions for the role. When a federated identity
authenticates, the identity is associated with the role and is granted the
permissions that are defined by the role. For information about roles for
federation, see Creating a role for a third-party Identity Provider in the
IAM User Guide. If you use IAM Identity Center, you configure a permission
set. To control what your identities can access after they authenticate, IAM
Identity Center correlates the permission set to a role in IAM. For
information about permissions sets, see Permission sets in the AWS IAM
Identity Center User Guide.
* Temporary IAM user permissions – An IAM user or role can assume an IAM role
to temporarily take on different permissions for a specific task.
* Cross-account access – You can use an IAM role to allow someone (a trusted
principal) in a different account to access resources in your account. Roles
are the primary way to grant cross-account access. However, with some AWS
services, you can attach a policy directly to a resource (instead of using a
role as a proxy). To learn the difference between roles and resource-based
policies for cross-account access, see How IAM roles differ from
resource-based policies in the IAM User Guide.
* Cross-service access – Some AWS services use features in other AWS services.
For example, when you make a call in a service, it's common for that service
to run applications in Amazon EC2 or store objects in Amazon S3. A service
might do this using the calling principal's permissions, using a service
role, or using a service-linked role.
* Principal permissions – When you use an IAM user or role to perform
actions in AWS, you are considered a principal. Policies grant permissions
to a principal. When you use some services, you might perform an action
that then triggers another action in a different service. In this case,
you must have permissions to perform both actions. To see whether an
action requires additional dependent actions in a policy, see Actions,
resources, and condition keys for Amazon CloudWatch in the Service
Authorization Reference.
* Service role – A service role is an IAM role that a service assumes to
perform actions on your behalf. An IAM administrator can create, modify,
and delete a service role from within IAM. For more information, see
Creating a role to delegate permissions to an AWS service in the IAM User
Guide.
* Service-linked role – A service-linked role is a type of service role that
is linked to an AWS service. The service can assume the role to perform an
action on your behalf. Service-linked roles appear in your AWS account and
are owned by the service. An IAM administrator can view, but not edit the
permissions for service-linked roles.
* Applications running on Amazon EC2 – You can use an IAM role to manage
temporary credentials for applications that are running on an EC2 instance
and making AWS CLI or AWS API requests. This is preferable to storing access
keys within the EC2 instance. To assign an AWS role to an EC2 instance and
make it available to all of its applications, you create an instance profile
that is attached to the instance. An instance profile contains the role and
enables programs that are running on the EC2 instance to get temporary
credentials. For more information, see Using an IAM role to grant permissions
to applications running on Amazon EC2 instances in the IAM User Guide.
To learn whether to use IAM roles or IAM users, see When to create an IAM role
(instead of a user) in the IAM User Guide.
MANAGING ACCESS USING POLICIES
You control access in AWS by creating policies and attaching them to AWS
identities or resources. A policy is an object in AWS that, when associated with
an identity or resource, defines their permissions. AWS evaluates these policies
when a principal (user, root user, or role session) makes a request. Permissions
in the policies determine whether the request is allowed or denied. Most
policies are stored in AWS as JSON documents. For more information about the
structure and contents of JSON policy documents, see Overview of JSON policies
in the IAM User Guide.
Administrators can use AWS JSON policies to specify who has access to what. That
is, which principal can perform actions on what resources, and under what
conditions.
By default, users and roles have no permissions. To grant users permission to
perform actions on the resources that they need, an IAM administrator can create
IAM policies. The administrator can then add the IAM policies to roles, and
users can assume the roles.
IAM policies define permissions for an action regardless of the method that you
use to perform the operation. For example, suppose that you have a policy that
allows the iam:GetRole action. A user with that policy can get role information
from the AWS Management Console, the AWS CLI, or the AWS API.
IDENTITY-BASED POLICIES
Identity-based policies are JSON permissions policy documents that you can
attach to an identity, such as an IAM user, group of users, or role. These
policies control what actions users and roles can perform, on which resources,
and under what conditions. To learn how to create an identity-based policy, see
Creating IAM policies in the IAM User Guide.
Identity-based policies can be further categorized as inline policies or managed
policies. Inline policies are embedded directly into a single user, group, or
role. Managed policies are standalone policies that you can attach to multiple
users, groups, and roles in your AWS account. Managed policies include AWS
managed policies and customer managed policies. To learn how to choose between a
managed policy or an inline policy, see Choosing between managed policies and
inline policies in the IAM User Guide.
RESOURCE-BASED POLICIES
Resource-based policies are JSON policy documents that you attach to a resource.
Examples of resource-based policies are IAM role trust policies and Amazon S3
bucket policies. In services that support resource-based policies, service
administrators can use them to control access to a specific resource. For the
resource where the policy is attached, the policy defines what actions a
specified principal can perform on that resource and under what conditions. You
must specify a principal in a resource-based policy. Principals can include
accounts, users, roles, federated users, or AWS services.
Resource-based policies are inline policies that are located in that service.
You can't use AWS managed policies from IAM in a resource-based policy.
ACCESS CONTROL LISTS (ACLS)
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, AWS WAF, and Amazon VPC are examples of services that support ACLs.
To learn more about ACLs, see Access control list (ACL) overview in the Amazon
Simple Storage Service Developer Guide.
OTHER POLICY TYPES
AWS supports additional, less-common policy types. These policy types can set
the maximum permissions granted to you by the more common policy types.
* Permissions boundaries – A permissions boundary is an advanced feature in
which you set the maximum permissions that an identity-based policy can grant
to an IAM entity (IAM user or role). You can set a permissions boundary for
an entity. The resulting permissions are the intersection of an entity's
identity-based policies and its permissions boundaries. Resource-based
policies that specify the user or role in the Principal field are not limited
by the permissions boundary. An explicit deny in any of these policies
overrides the allow. For more information about permissions boundaries, see
Permissions boundaries for IAM entities in the IAM User Guide.
* Service control policies (SCPs) – SCPs are JSON policies that specify the
maximum permissions for an organization or organizational unit (OU) in AWS
Organizations. AWS Organizations is a service for grouping and centrally
managing multiple AWS accounts that your business owns. If you enable all
features in an organization, then you can apply service control policies
(SCPs) to any or all of your accounts. The SCP limits permissions for
entities in member accounts, including each AWS account root user. For more
information about Organizations and SCPs, see How SCPs work in the AWS
Organizations User Guide.
* Session policies – Session policies are advanced policies that you pass as a
parameter when you programmatically create a temporary session for a role or
federated user. The resulting session's permissions are the intersection of
the user or role's identity-based policies and the session policies.
Permissions can also come from a resource-based policy. An explicit deny in
any of these policies overrides the allow. For more information, see Session
policies in the IAM User Guide.
MULTIPLE POLICY TYPES
When multiple types of policies apply to a request, the resulting permissions
are more complicated to understand. To learn how AWS determines whether to allow
a request when multiple policy types are involved, see Policy evaluation logic
in the IAM User Guide.
AWS MANAGED (PREDEFINED) POLICIES FOR CLOUDWATCH
AWS addresses many common use cases by providing standalone IAM policies that
are created and administered by AWS. These AWS managed policies grant necessary
permissions for common use cases so that you can avoid having to investigate
what permissions are needed. For more information, see AWS managed policies in
the IAM User Guide.
The following AWS managed policies, which you can attach to users in your
account, are specific to CloudWatch.
TOPICS
* CloudWatchFullAccessV2
* CloudWatchFullAccess
* CloudWatchReadOnlyAccess
* CloudWatchActionsEC2Access
* CloudWatchAutomaticDashboardsAccess
* CloudWatchAgentServerPolicy
* CloudWatchAgentAdminPolicy
* AWS managed (predefined) policies for CloudWatch cross-account observability
* AWS managed (predefined) policies for CloudWatch Synthetics
* AWS managed (predefined) policies for Amazon CloudWatch RUM
* AWS managed (predefined) policies for CloudWatch Evidently
* AWS managed policy for AWS Systems Manager Incident Manager
CLOUDWATCHFULLACCESSV2
AWS recently added the CloudWatchFullAccessV2 manged IAM policy. This policy
grants full access to CloudWatch actions and resources and also more properly
scopes the permissions granted for other services such as Amazon SNS and Amazon
EC2 Auto Scaling. We recommend that you begin using this policy instead of using
CloudWatchFullAccess. AWS plans to deprecate CloudWatchFullAccess in the near
future.
It includes some autoscaling:Describe permissions so that users with this policy
can see the Auto Scaling actions that are associated with CloudWatch alarms. It
includes some sns permissions so that users with this policy can retrieve create
Amazon SNS topics and associate them with CloudWatch alarms. It includes IAM
permissions so that users with this policy can view information about
service-linked roles associated with CloudWatch. It includes the oam:ListSinks
and oam:ListAttachedLinks permissions so that users with this policy can use the
console to view data shared from source accounts in CloudWatch cross-account
observability.
Its contents are as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CloudWatchFullAccessPermissions",
"Effect": "Allow",
"Action": [
"application-autoscaling:DescribeScalingPolicies",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribePolicies",
"cloudwatch:*",
"logs:*",
"sns:CreateTopic",
"sns:ListSubscriptions",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"sns:Subscribe",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"oam:ListSinks"
],
"Resource": "*"
},
{
"Sid": "EventsServicePermissions",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/events.amazonaws.com/AWSServiceRoleForCloudWatchEvents*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "events.amazonaws.com"
}
}
},
{
"Sid": "OAMReadPermissions",
"Effect": "Allow",
"Action": [
"oam:ListAttachedLinks"
],
"Resource": "arn:aws:oam:*:*:sink/*"
}
]
}
CLOUDWATCHFULLACCESS
The CloudWatchFullAccess policy is on the path to deprecation. We recommend that
you stop using it, and use CloudWatchFullAccessV2 instead.
Its contents are as follows:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"autoscaling:Describe*",
"cloudwatch:*",
"logs:*",
"sns:*",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"oam:ListSinks"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/events.amazonaws.com/AWSServiceRoleForCloudWatchEvents*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "events.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"oam:ListAttachedLinks"
],
"Resource": "arn:aws:oam:*:*:sink/*"
}
]
}
CLOUDWATCHREADONLYACCESS
The CloudWatchReadOnlyAccess policy grants read-only access to CloudWatch.
It includes some logs: permissions so that users with this policy can use the
console to view CloudWatch Logs information and to use CloudWatch Logs Insights
queries. It includes autoscaling:Describe* so that users with this policy can
see the Auto Scaling actions that are associated with CloudWatch alarms. It
includes application-autoscaling:DescribeScalingPolicies so that users with this
policy can access information about Application Auto Scaling policies. It
includes sns:Get* and sns:List* so that users with this policy can retrieve
information about the Amazon SNS topics that receive notifications about
CloudWatch alarms. It includes the oam:ListSinks and oam:ListAttachedLinks
permissions so that users with this policy can use the console to view data
shared from source accounts in CloudWatch cross-account observability.
The following is the content of the CloudWatchReadOnlyAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:DescribeScalingPolicies",
"autoscaling:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"logs:Get*",
"logs:List*",
"logs:StartQuery",
"logs:StopQuery",
"logs:Describe*",
"logs:TestMetricFilter",
"logs:FilterLogEvents",
"logs:StartLiveTail",
"logs:StopLiveTail",
"oam:ListSinks",
"sns:Get*",
"sns:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"oam:ListAttachedLinks"
],
"Resource": "arn:aws:oam:*:*:sink/*"
}
]
}
CLOUDWATCHACTIONSEC2ACCESS
The CloudWatchActionsEC2Access policy grants read-only access to CloudWatch
alarms and metrics in addition to Amazon EC2 metadata. It also grants access to
the Stop, Terminate, and Reboot API actions for EC2 instances.
The following is the content of the CloudWatchActionsEC2Access policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:Describe*",
"ec2:Describe*",
"ec2:RebootInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": "*"
}
]
}
CLOUDWATCHAUTOMATICDASHBOARDSACCESS
The CloudWatch-CrossAccountAccess managed policy is used by the
CloudWatch-CrossAccountSharingRole IAM role. This role and policy enable users
of cross-account dashboards to view automatic dashboards in each account that is
sharing dashboards.
The following is the content of CloudWatchAutomaticDashboardsAccess:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"cloudfront:GetDistribution",
"cloudfront:ListDistributions",
"dynamodb:DescribeTable",
"dynamodb:ListTables",
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ecs:DescribeClusters",
"ecs:DescribeContainerInstances",
"ecs:ListClusters",
"ecs:ListContainerInstances",
"ecs:ListServices",
"elasticache:DescribeCacheClusters",
"elasticbeanstalk:DescribeEnvironments",
"elasticfilesystem:DescribeFileSystems",
"elasticloadbalancing:DescribeLoadBalancers",
"kinesis:DescribeStream",
"kinesis:ListStreams",
"lambda:GetFunction",
"lambda:ListFunctions",
"rds:DescribeDBClusters",
"rds:DescribeDBInstances",
"resource-groups:ListGroupResources",
"resource-groups:ListGroups",
"route53:GetHealthCheck",
"route53:ListHealthChecks",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"sns:ListTopics",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:ListQueues",
"synthetics:DescribeCanariesLastRun",
"tag:GetResources"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"apigateway:GET"
],
"Effect": "Allow",
"Resource": [
"arn:aws:apigateway:*::/restapis*"
]
}
]
CLOUDWATCHAGENTSERVERPOLICY
The CloudWatchAgentServerPolicy policy can be used in IAM roles that are
attached to Amazon EC2 instances to allow the CloudWatch agent to read
information from the instance and write it to CloudWatch.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeVolumes",
"ec2:DescribeTags",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:CreateLogStream",
"logs:CreateLogGroup"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
}
]
}
CLOUDWATCHAGENTADMINPOLICY
The CloudWatchAgentAdminPolicy policy can be used in IAM roles that are attached
to Amazon EC2 instances. This policy allows the CloudWatch agent to read
information from the instance and write it to CloudWatch, and also to write
information to Parameter Store.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeTags",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:CreateLogStream",
"logs:CreateLogGroup"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:PutParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
}
]
}
NOTE
You can review these permissions policies by signing in to the IAM console and
searching for specific policies there.
You can also create your own custom IAM policies to allow permissions for
CloudWatch actions and resources. You can attach these custom policies to the
IAM users or groups that require those permissions.
AWS MANAGED (PREDEFINED) POLICIES FOR CLOUDWATCH CROSS-ACCOUNT OBSERVABILITY
The policies in this section grant permissions related to CloudWatch
cross-account observability. For more information, see CloudWatch cross-account
observability.
CLOUDWATCHCROSSACCOUNTSHARINGCONFIGURATION
The CloudWatchCrossAccountSharingConfiguration policy grants access to create,
manage, and view Observability Access Manager links for sharing CloudWatch
resources between accounts. For more information, see CloudWatch cross-account
observability. The contents are as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:Link",
"oam:ListLinks"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"oam:DeleteLink",
"oam:GetLink",
"oam:TagResource"
],
"Resource": "arn:aws:oam:*:*:link/*"
},
{
"Effect": "Allow",
"Action": [
"oam:CreateLink",
"oam:UpdateLink"
],
"Resource": [
"arn:aws:oam:*:*:link/*",
"arn:aws:oam:*:*:sink/*"
]
}
]
}
OAMFULLACCESS
The OAMFullAccess policy grants access to create, manage, and view Observability
Access Manager sinks and links, which are used for CloudWatch cross-account
observability.
The OAMFullAccess policy by itself does not permit you to share observability
data across links. To create a link to share CloudWatch metrics, you also need
either CloudWatchFullAccess or CloudWatchCrossAccountSharingConfiguration. To
create a link to share CloudWatch Logs log groups, you also need either
CloudWatchLogsFullAccess or CloudWatchLogsCrossAccountSharingConfiguration. To
create a link to share X-Ray traces, you also need either AWSXRayFullAccess or
AWSXRayCrossAccountSharingConfiguration.
For more information, see CloudWatch cross-account observability. The contents
are as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oam:*"
],
"Resource": "*"
}
]
}
OAMREADONLYACCESS
The OAMReadOnlyAccess policy grants read-only access to Observability Access
Manager resources, which are used for CloudWatch cross-account observability.
For more information, see CloudWatch cross-account observability. The contents
are as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oam:Get*",
"oam:List*"
],
"Resource": "*"
}
]
}
AWS MANAGED (PREDEFINED) POLICIES FOR CLOUDWATCH SYNTHETICS
The CloudWatchSyntheticsFullAccess and CloudWatchSyntheticsReadOnlyAccess AWS
managed policies are available for you to assign to users who will manage or use
CloudWatch Synthetics. The following additional policies are also relevant:
* AmazonS3ReadOnlyAccess and CloudWatchReadOnlyAccess – These are necessary to
be able to read all Synthetics data in the CloudWatch console.
* AWSLambdaReadOnlyAccess – To be able to view the source code used by
canaries.
* CloudWatchSyntheticsFullAccess enables you to create canaries, Additionally,
to create and delete canaries that have a new IAM role created for them, you
also need the following inline policy statement:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
],
"Resource": [
"arn:aws:iam::*:role/service-role/CloudWatchSyntheticsRole*",
"arn:aws:iam::*:policy/service-role/CloudWatchSyntheticsPolicy*"
]
}
]
}
IMPORTANT
Granting a user the iam:CreateRole, iam:DeleteRole, iam:CreatePolicy,
iam:DeletePolicy, iam:AttachRolePolicy, and iam:DetachRolePolicy permissions
gives that user full administrative access to create, attach, and delete
roles and policies that have ARNs that match
arn:aws:iam::*:role/service-role/CloudWatchSyntheticsRole* and
arn:aws:iam::*:policy/service-role/CloudWatchSyntheticsPolicy*. For example,
a user with these permissions can create a policy that has full permissions
for all resources, and attach that policy to any role that matches that ARN
pattern. Be very careful about who you grant these permissions to.
For information about attaching policies and granting permissions to users,
see Changing Permissions for an IAM User and To embed an inline policy for a
user or role.
CLOUDWATCHSYNTHETICSFULLACCESS
The following is the content of the CloudWatchSyntheticsFullAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"synthetics:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::cw-syn-results-*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:ListRoles",
"s3:ListAllMyBuckets",
"xray:GetTraceSummaries",
"xray:BatchGetTraces",
"apigateway:GET"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::cw-syn-*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::aws-synthetics-library-*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/service-role/CloudWatchSyntheticsRole*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"lambda.amazonaws.com",
"synthetics.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:ListAttachedRolePolicies"
],
"Resource": [
"arn:aws:iam::*:role/service-role/CloudWatchSyntheticsRole*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricAlarm",
"cloudwatch:DeleteAlarms"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:Synthetics-*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:*"
]
},
{
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:AddPermission",
"lambda:PublishVersion",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:GetFunctionConfiguration",
"lambda:DeleteFunction"
],
"Resource": [
"arn:aws:lambda:*:*:function:cwsyn-*"
]
},
{
"Effect": "Allow",
"Action": [
"lambda:GetLayerVersion",
"lambda:PublishLayerVersion",
"lambda:DeleteLayerVersion"
],
"Resource": [
"arn:aws:lambda:*:*:layer:cwsyn-*",
"arn:aws:lambda:*:*:layer:Synthetics:*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:Subscribe",
"sns:ListSubscriptionsByTopic"
],
"Resource": [
"arn:*:sns:*:*:Synthetics-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:ListAliases"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:*:*:key/*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"s3.*.amazonaws.com"
]
}
}
}
]
}
CLOUDWATCHSYNTHETICSREADONLYACCESS
The following is the content of the CloudWatchSyntheticsReadOnlyAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"synthetics:Describe*",
"synthetics:Get*",
"synthetics:List*",
"lambda:GetFunctionConfiguration"
],
"Resource": "*"
}
]
}
AWS MANAGED (PREDEFINED) POLICIES FOR AMAZON CLOUDWATCH RUM
The AmazonCloudWatchRUMFullAccess and AmazonCloudWatchRUMReadOnlyAccess AWS
managed policies are available for you to assign to users who will manage or use
CloudWatch RUM.
AMAZONCLOUDWATCHRUMFULLACCESS
The following are the contents of the AmazonCloudWatchRUMFullAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rum:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/rum.amazonaws.com/AWSServiceRoleForRealUserMonitoring"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/RUM-Monitor*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"cognito-identity.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms"
],
"Resource": "arn:aws:cloudwatch:*:*:alarm:*"
},
{
"Effect": "Allow",
"Action": [
"cognito-identity:CreateIdentityPool",
"cognito-identity:ListIdentityPools",
"cognito-identity:DescribeIdentityPool",
"cognito-identity:GetIdentityPoolRoles",
"cognito-identity:SetIdentityPoolRoles"
],
"Resource": "arn:aws:cognito-identity:*:*:identitypool/*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:DeleteLogGroup",
"logs:PutRetentionPolicy",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:*:*:log-group:*RUMService*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:DescribeResourcePolicies"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:*:log-group::log-stream:*"
},
{
"Effect": "Allow",
"Action": [
"synthetics:describeCanaries",
"synthetics:describeCanariesLastRun"
],
"Resource": "arn:aws:synthetics:*:*:canary:*"
}
]
}
AMAZONCLOUDWATCHRUMREADONLYACCESS
The following are the contents of the AmazonCloudWatchRUMReadOnlyAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rum:GetAppMonitor",
"rum:GetAppMonitorData",
"rum:ListAppMonitors",
"rum:ListRumMetricsDestinations",
"rum:BatchGetRumMetricDefinitions"
],
"Resource": "*"
}
]
}
AMAZONCLOUDWATCHRUMSERVICEROLEPOLICY
You can't attach AmazonCloudWatchRUMServiceRolePolicy to your IAM entities. This
policy is attached to a service-linked role that allows CloudWatch RUM to
publish monitoring data to other relevant AWS services. For more information
about this service linked role, see Using service-linked roles for CloudWatch
RUM.
The complete contents of AmazonCloudWatchRUMServiceRolePolicy are as follows.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"xray:PutTraceSegments"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": "cloudwatch:PutMetricData",
"Resource": "*",
"Condition": {
"StringLike": {
"cloudwatch:namespace": [
"RUM/CustomMetrics/*",
"AWS/RUM"
]
}
}
}
]
}
AWS MANAGED (PREDEFINED) POLICIES FOR CLOUDWATCH EVIDENTLY
The CloudWatchEvidentlyFullAccess and CloudWatchEvidentlyReadOnlyAccess AWS
managed policies are available for you to assign to users who will manage or use
CloudWatch Evidently.
CLOUDWATCHEVIDENTLYFULLACCESS
The following are the contents of the CloudWatchEvidentlyFullAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"evidently:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:GetRole"
],
"Resource": [
"arn:aws:iam::*:role/service-role/CloudWatchRUMEvidentlyRole-*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:ListTagsForResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:TagResource",
"cloudwatch:UnTagResource"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudtrail:LookupEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricAlarm"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:Evidently-Alarm-*"
]
},
{
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:Subscribe",
"sns:ListSubscriptionsByTopic"
],
"Resource": [
"arn:*:sns:*:*:Evidently-*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"*"
]
}
]
}
CLOUDWATCHEVIDENTLYREADONLYACCESS
The following are the contents of the CloudWatchEvidentlyReadOnlyAccess policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"evidently:GetExperiment",
"evidently:GetFeature",
"evidently:GetLaunch",
"evidently:GetProject",
"evidently:GetSegment",
"evidently:ListExperiments",
"evidently:ListFeatures",
"evidently:ListLaunches",
"evidently:ListProjects",
"evidently:ListSegments",
"evidently:ListSegmentReferencs"
],
"Resource": "*"
}
]
}
AWS MANAGED POLICY FOR AWS SYSTEMS MANAGER INCIDENT MANAGER
The AWSCloudWatchAlarms_ActionSSMIncidentsServiceRolePolicy policy is attached
to a service-linked role that allows CloudWatch to start incidents in AWS
Systems Manager Incident Manager on your behalf. For more information, see
Service-linked role permissions for CloudWatch alarms Systems Manager Incident
Manager actions.
The policy has the following permission:
* ssm-incidents:StartIncident
CUSTOMER MANAGED POLICY EXAMPLES
In this section, you can find example user policies that grant permissions for
various CloudWatch actions. These policies work when you are using the
CloudWatch API, AWS SDKs, or the AWS CLI.
EXAMPLES
* Example 1: Allow user full access to CloudWatch
* Example 2: Allow read-only access to CloudWatch
* Example 3: Stop or terminate an Amazon EC2 instance
EXAMPLE 1: ALLOW USER FULL ACCESS TO CLOUDWATCH
To grant a user full access to CloudWatch, you can use grant them the
CloudWatchFullAccess managed policy instead of creating a customer-managed
policy. The contents of the CloudWatchFullAccess are listed in
CloudWatchFullAccess.
EXAMPLE 2: ALLOW READ-ONLY ACCESS TO CLOUDWATCH
The following policy allows a user read-only access to CloudWatch and view
Amazon EC2 Auto Scaling actions, CloudWatch metrics, CloudWatch Logs data, and
alarm-related Amazon SNS data.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"autoscaling:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"logs:Get*",
"logs:Describe*",
"logs:StartQuery",
"logs:StopQuery",
"logs:TestMetricFilter",
"logs:FilterLogEvents",
"logs:StartLiveTail",
"logs:StopLiveTail",
"sns:Get*",
"sns:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
EXAMPLE 3: STOP OR TERMINATE AN AMAZON EC2 INSTANCE
The following policy allows an CloudWatch alarm action to stop or terminate an
EC2 instance. In the sample below, the GetMetricData, ListMetrics, and
DescribeAlarms actions are optional. It is recommended that you include these
actions to ensure that you have correctly stopped or terminated the instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:PutMetricAlarm",
"cloudwatch:GetMetricData",
"cloudwatch:ListMetrics",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"*"
],
"Effect": "Allow"
},
{
"Action": [
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
CLOUDWATCH UPDATES TO AWS MANAGED POLICIES
View details about updates to AWS managed policies for CloudWatch since this
service began tracking these changes. For automatic alerts about changes to this
page, subscribe to the RSS feed on the CloudWatch Document history page.
Change Description Date
AWSServiceRoleForCloudWatchMetrics_DbPerfInsightsServiceRolePolicy – New policy
CloudWatch added a new policy
AWSServiceRoleForCloudWatchMetrics_DbPerfInsightsServiceRolePolicy.
The AWSServiceRoleForCloudWatchMetrics_DbPerfInsightsServiceRolePolicy grants
permission to CloudWatch to fetch Performance Insights metrics from databases on
your behalf.
September 20, 2023
CloudWatchReadOnlyAccess – Update to an existing policy
CloudWatch added a permission to CloudWatchReadOnlyAccess.
The application-autoscaling:DescribeScalingPolicies permission was added so that
users with this policy can access information about Application Auto Scaling
policies.
September 14, 2023
CloudWatchFullAccessV2 – New policy
CloudWatch added a new policy CloudWatchFullAccessV2.
The CloudWatchFullAccessV2 grants full access to CloudWatch actions and
resources while better scoping the permissions granted to other services such as
Amazon SNS and Amazon EC2 Auto Scaling. For more information, see
CloudWatchFullAccessV2.
August 1, 2023
AWSServiceRoleForInternetMonitor – Update to an existing policy
Amazon CloudWatch Internet Monitor added new permissions to monitor Network Load
Balancer resources.
The elasticloadbalancing:DescribeLoadBalancers and ec2:DescribeNetworkInterfaces
permissions are required so that Internet Monitor can monitor customers' Network
Load Balancer traffic by analyzing flow logs for NLB resources.
For more information, see Using Amazon CloudWatch Internet Monitor.
July 15, 2023
CloudWatchReadOnlyAccess – Update to an existing policy
CloudWatch added permissions to CloudWatchReadOnlyAccess.
The logs:StartLiveTail and logs:StopLiveTail permissions were added so that
users with this policy can use the console to start and stop CloudWatch Logs
live tail sessions. For more information, see Use live tail to view logs in near
real time.
June 6, 2023
CloudWatchCrossAccountSharingConfiguration – New policy
CloudWatch added a new policy to enable you to manage CloudWatch cross-account
observability links that share CloudWatch metrics.
For more information, see CloudWatch cross-account observability.
November 27, 2022
OAMFullAccess – New policy
CloudWatch added a new policy to enable you to fully manage CloudWatch
cross-account observability links and sinks.
For more information, see CloudWatch cross-account observability.
November 27, 2022
OAMReadOnlyAccess – New policy
CloudWatch added a new policy to enable you to view information about CloudWatch
cross-account observability links and sinks.
For more information, see CloudWatch cross-account observability.
November 27, 2022
CloudWatchFullAccess – Update to an existing policy
CloudWatch added permissions to CloudWatchFullAccess.
The oam:ListSinks and oam:ListAttachedLinks permissions were added so that users
with this policy can use the console to view data shared from source accounts in
CloudWatch cross-account observability.
November 27, 2022
CloudWatchReadOnlyAccess – Update to an existing policy
CloudWatch added permissions to CloudWatchReadOnlyAccess.
The oam:ListSinks and oam:ListAttachedLinks permissions were added so that users
with this policy can use the console to view data shared from source accounts in
CloudWatch cross-account observability.
November 27, 2022
AmazonCloudWatchRUMServiceRolePolicy – Update to an existing policy
CloudWatch RUM updated a condition key in AmazonCloudWatchRUMServiceRolePolicy.
The "Condition": { "StringEquals": { "cloudwatch:namespace": "AWS/RUM" } }
condition key was changed to the following so that CloudWatch RUM can send
custom metrics to custom metric namespaces.
"Condition": {
"StringLike": {
"cloudwatch:namespace": [
"RUM/CustomMetrics/*",
"AWS/RUM"
]
}
}
February 2, 2023
AmazonCloudWatchRUMReadOnlyAccess – Updated policy
CloudWatch added permissions the AmazonCloudWatchRUMReadOnlyAccess policy.
The rum:ListRumMetricsDestinations and rum:BatchGetRumMetricsDefinitions
permissions were added so that CloudWatch RUM can send extended metrics to
CloudWatch and Evidently.
October 27, 2022
AmazonCloudWatchRUMServiceRolePolicy – Update to an existing policy
CloudWatch RUM added permissions to AmazonCloudWatchRUMServiceRolePolicy.
The cloudwatch:PutMetricData permission was added so that CloudWatch RUM can
send extended metrics to CloudWatch.
October 26, 2022
CloudWatchEvidentlyReadOnlyAccess – Update to an existing policy
CloudWatch Evidently added permissions to CloudWatchEvidentlyReadOnlyAccess.
The evidently:GetSegment, evidently:ListSegments, and
evidently:ListSegmentReferences permissions were added so that users with this
policy can see Evidently audience segments that have been created.
August 12, 2022
CloudWatchSyntheticsFullAccess – Update to an existing policy
CloudWatch Synthetics added permissions to CloudWatchSyntheticsFullAccess.
The lambda:DeleteFunction and lambda:DeleteLayerVersion permissions were added
so that CloudWatch Synthetics can delete related resources when a canary is
deleted. The iam:ListAttachedRolePolicies was added so that customers can view
the policies that are attached to a canary's IAM role.
May 6, 2022
AmazonCloudWatchRUMFullAccess – New policy
CloudWatch added a new policy to enable full management of CloudWatch RUM.
CloudWatch RUM allows you to perform real user monitoring of your web
application. For more information, see Use CloudWatch RUM.
November 29, 2021
AmazonCloudWatchRUMReadOnlyAccess – New policy
CloudWatch added a new policy to enable read-only access to CloudWatch RUM.
CloudWatch RUM allows you to perform real user monitoring of your web
application. For more information, see Use CloudWatch RUM.
November 29, 2021
CloudWatchEvidentlyFullAccess – New policy
CloudWatch added a new policy to enable full management of CloudWatch Evidently.
CloudWatch Evidently allows you to perform A/B experiments of your web
applications, and to roll them out gradually. For more information, see Perform
launches and A/B experiments with CloudWatch Evidently.
November 29, 2021
CloudWatchEvidentlyReadOnlyAccess – New policy
CloudWatch added a new policy to enable read-only access to CloudWatch
Evidently.
CloudWatch Evidently allows you to perform A/B experiments of your web
applications, and to roll them out gradually. For more information, see Perform
launches and A/B experiments with CloudWatch Evidently.
November 29, 2021
AWSServiceRoleForCloudWatchRUM – New managed policy
CloudWatch added a policy for a new service-linked role to allow CloudWatch RUM
to pubish monitoring data to other relevant AWS services.
November 29, 2021
CloudWatchSyntheticsFullAccess – Update to an existing policy
CloudWatch Synthetics added permissions to CloudWatchSyntheticsFullAccess, and
also changed the scope of one permission.
The kms:ListAliases permission was added so that users can list available AWS
KMS keys that can be used to encrypt canary artifacts. The kms:DescribeKey
permission was added so that users can see the details of keys that will be used
to encrypt for canary artifacts. And the kms:Decrypt permission was added to
enable users to decrypt canary artifacts. This decryption ability is limited to
use on resources within Amazon S3 buckets.
The Resource scope of the s3:GetBucketLocation permission was changed from * to
arn:aws:s3:::*.
September 29, 2021
CloudWatchSyntheticsFullAccess – Update to an existing policy
CloudWatch Synthetics added a permission to CloudWatchSyntheticsFullAccess.
The lambda:UpdateFunctionCode permission was added so that users with this
policy can change the runtime version of canaries.
July 20, 2021
AWSCloudWatchAlarms_ActionSSMIncidentsServiceRolePolicy – New managed policy
CloudWatch added a new managed IAM policy to allow CloudWatch to create
incidents in AWS Systems Manager Incident Manager.
May 10, 2021
CloudWatchAutomaticDashboardsAccess – Update to an existing policy
CloudWatch added a permission to the CloudWatchAutomaticDashboardsAccess managed
policy. The synthetics:DescribeCanariesLastRun permission was added to this
policy to enable cross-account dashboard users to see details about CloudWatch
Synthetics canary runs.
April 20, 2021
CloudWatch started tracking changes
CloudWatch started tracking changes for its AWS managed policies.
April 14, 2021
Javascript is disabled or is unavailable in your browser.
To use the Amazon Web Services Documentation, Javascript must be enabled. Please
refer to your browser's Help pages for instructions.
Document Conventions
Data protection
How Amazon CloudWatch works with IAM
Did this page help you? - Yes
Thanks for letting us know we're doing a good job!
If you've got a moment, please tell us what we did right so we can do more of
it.
Did this page help you? - No
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
DID THIS PAGE HELP YOU?
Yes
No
Provide feedback
NEXT TOPIC:
How Amazon CloudWatch works with IAM
PREVIOUS TOPIC:
Data protection
NEED HELP?
* Try AWS re:Post
* Connect with an AWS IQ expert
PrivacySite termsCookie preferences
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
ON THIS PAGE
* Audience
* Authenticating with identities
* Managing access using policies
* AWS managed (predefined) policies for CloudWatch
* Customer managed policy examples
* Policy updates
DID THIS PAGE HELP YOU? - NO
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
Feedback