# Monitoring an Amplify application
AWS Amplify provides the following features for monitoring your hosted applications:
+ **CloudWatch metrics** – Amplify emits metrics through Amazon CloudWatch that you can use to monitor traffic, errors, data transfer, and latency for your applications.
+ **Access logs** – Amplify provides access logs with detailed information about requests made to your application.
+ **CloudTrail logging** – Amplify is integrated with AWS CloudTrail which provides a record of actions taken by a user, role, or an AWS service in Amplify. You can view these events in the CloudTrail console.
**Topics**
+ [
# Monitoring an Amplify application with Amazon CloudWatch
](monitoring-with-cloudwatch.md)
+ [
# Retrieving and analyzing access logs for an Amplify application
](using-access-logs.md)
+ [
# Logging Amplify API calls using AWS CloudTrail
](logging-using-cloudtrail.md)
# Monitoring an Amplify application with Amazon CloudWatch
AWS Amplify is integrated with Amazon CloudWatch, enabling you to monitor metrics for your Amplify applications in near real-time, and create alarms that send notifications when a metric exceeds a threshold you set. For more information about how the CloudWatch service works, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
## Supported CloudWatch metrics
Amplify supports seven CloudWatch metrics in the `AWS/AmplifyHosting` namespace for monitoring traffic, errors, data transfer, latency, and request tokens for your apps. These metrics are aggregated at one minute intervals. CloudWatch monitoring metrics are free of charge and don't count against the [CloudWatch service quotas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html).
The following table describes each supported metric and lists the most relevant statistics. Not all available statistics are applicable for every metric.
| Metric | Description |
| --- | --- |
| Requests | The total number of viewer requests received by your app. The most relevant statistic is `Sum`. Use the `Sum` statistic to get the total number of requests. |
| BytesDownloaded | The total amount of data transferred out of your app (downloaded) in bytes by viewers for `GET`, `HEAD`, and `OPTIONS` requests. The most relevant statistic is `Sum`. |
| BytesUploaded | The total amount of data transferred into your app (uploaded) in bytes for any request, including headers. Amplify doesn't charge you for data uploaded in your applications. The most relevant statistic is `Sum`. |
| 4xxErrors | The number of requests that returned an error in the HTTP status code 400-499 range. The most relevant statistic is `Sum`. Use the `Sum` statistic to get the total occurrences of these errors. |
| 5xxErrors | The number of requests that returned an error in the HTTP status code 500-599 range. The most relevant statistic is `Sum`. Use the `Sum` statistic to get the total occurrences of these errors. |
| Latency | The time to first byte in seconds. This is the total time between when Amplify Hosting receives a request and when it returns a response to the network. This doesn't include the network latency encountered for a response to reach the viewer's device. The most relevant statistics are `Average`, `Maximum`, `Minimum`, `p10`, `p50`, `p90`, `p95`, and `p100`. Use the `Average` statistic to evaluate expected latencies. |
| TokensConsumed | The request tokens consumed by your app. The `Sum` statistic represents total request token consumption. You can compare this statistic to your current `Request tokens per second` service quota to determine whether you need to request a quota increase to avoid potential throttling during a future high traffic event. The `Average` statistic represents request token consumption across normal and peak times. Higher token consumption typically leads to longer time to first byte (TTFB). Therefore, you can use this statistic when evaluating your application's latency. If your latency is poor, you can improve your downstream APIs to reduce your token consumption and avoid the throttling that can occur when token consumption exceeds your application's `Request tokens per second` service quota. For more information about the `Request tokens per second` service quota, see [Amplify Hosting service quotas](quotas-chapter.md). |
Amplify provides the following CloudWatch metric dimensions.
| Dimension | Description |
| --- | --- |
| App | Metric data is provided by app. |
| AWS account | Metric data is provided across all apps in the AWS account. |
## Accessing CloudWatch metrics
You can access CloudWatch metrics directly from the Amplify console using the following procedure.
**Note**
You can also access CloudWatch metrics in the AWS Management Console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
**To access metrics in the Amplify console**
1. Sign in to the AWS Management Console and open the [Amplify console](https://console.aws.amazon.com/amplify/).
1. Choose the app that you want to view metrics for.
1. In the navigation pane, choose **Monitoring**, then choose **Metrics**.
## Creating CloudWatch alarms
You can create CloudWatch alarms in the Amplify console that send notifications when specific criteria are met. An alarm watches a single CloudWatch metric and sends an Amazon Simple Notification Service notification when the metric breaches the threshold for a specified number of evaluation periods.
You can create more advanced alarms that use metric math expressions in the CloudWatch console or using the CloudWatch APIs. For example, you can create an alarm that notifies you when the percentage of 4xxErrors exceeds 15% for three consecutive periods. For more information, see [Creating a CloudWatch Alarm Based on a Metric Math Expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) in the *Amazon CloudWatch User Guide*.
Standard CloudWatch pricing applies to alarms. For more information, see [Amazon CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/).
Use the following procedure to create an alarm in the Amplify console.
**To create a CloudWatch alarm for an Amplify metric**
1. Sign in to the AWS Management Console and open the [Amplify console](https://console.aws.amazon.com/amplify/).
1. Choose the app that you want to set an alarm on.
1. In the navigation pane, choose **Monitoring**, then choose **Alarms**.
1. On the **Alarms** page, choose **Create alarm**.
1. In the **Create alarm** window, configure your alarm as follows:
1. For **Metric**, choose the name of the metric to monitor from the list.
1. For **Name of alarm**, enter a meaningful name for the alarm. For example, if you are monitoring *Requests*, you could name the alarm **HighTraffic**. The name must contain only ASCII characters.
1. For **Set up notifications**, do one of the following:
+
1. Choose **New** to set up a new Amazon SNS topic.
1. For **Email address**, enter the email address for the recipient of the notifications.
1. Choose **Add new email address** to add additional recipients.
+
1. Choose **Existing** to reuse an Amazon SNS topic.
1. For **SNS topic**, select the name of an existing Amazon SNS topic from the list.
1. For **Whenever the *Statistic* of *Metric***, set the conditions for your alarm as follows:
1. Specify whether the metric must be greater than, less than, or equal to the threshold value.
1. Specify the threshold value.
1. Specify the number of consecutive evaluation periods that must be in the alarm state to invoke the alarm.
1. Specify the length of time of the evaluation period.
1. Choose **Confirm**.
**Note**
Each Amazon SNS recipient that you specify receives a confirmation email from AWS Notifications. The email contains a link that the recipient must follow to confirm their subscription and receive notifications.
## Accessing CloudWatch Logs for SSR apps
Amplify sends information about your SSR runtime to Amazon CloudWatch Logs in your AWS account. When you deploy an SSR app to Amplify Hosting compute, the app requires an IAM service role that Amplify assumes when calling other services on your behalf. You can either allow Amplify Hosting compute to automatically create a service role for you or you can specify a role that you have created.
If you choose to allow Amplify to create an IAM role for you, the role will already have the permissions to create CloudWatch Logs. If you create your own IAM role, you will need to add the following permissions to your policy to allow Amplify to access Amazon CloudWatch Logs.
```
logs:CreateLogStream
logs:CreateLogGroup
logs:DescribeLogGroups
logs:PutLogEvents
```
For more information about adding a service role, see [Adding a service role with permissions to deploy backend resources](amplify-service-role.md). For more information about deploying server-side rendered apps, see [Deploying server-side rendered applications with Amplify Hosting](server-side-rendering-amplify.md).
You can view the Amplify Hosting compute logs for an SSR application in the CloudWatch console or in the Amplify console. Use the following instructions to view the logs in the Amplify console.
**To view CloudWatch logs for an SSR application in the Amplify console**
1. Sign in to the AWS Management Console and open the [Amplify console](https://console.aws.amazon.com/amplify/).
1. Choose the SSR app to view the CloudWatch logs for.
1. In the navigation pane, choose **Monitoring**, then choose **Hosting compute logs**.
1. On the **Hosting compute logs** page, search and select a CloudWatch log group for a specific branch.
# Retrieving and analyzing access logs for an Amplify application
Amplify stores access logs for all of the apps you host in Amplify. Access logs contain information about requests that are made to your hosted apps. Amplify retains all access logs for an app until you delete the app. All access logs for an app are available in the Amplify console. However, each individual request for access logs is limited to a two week time period that you specify.
**Warning**
Don’t include secrets, credentials, or sensitive data in URLs as path or query parameters. These values are viewable in plain text in your Amplify application’s access logs.
Amplify never reuses CloudFront distributions between customers. Amplify creates CloudFront distributions in advance so that you don't have to wait for a CloudFront distribution to be created when you deploy a new app. Before these distributions are assigned to an Amplify app, they might receive traffic from bots. However, they're configured to always respond as *Not found* before they're assigned. If your app's access logs contain entries for a time period before you created your app, these entries are related to this activity.
**Important**
We recommend that you use the logs to understand the nature of the requests for your content, not as a complete accounting of all requests. Amplify delivers access logs on a best-effort basis. The log entry for a particular request might be delivered long after the request was actually processed and, in rare cases, a log entry might not be delivered at all. When a log entry is omitted from access logs, the number of entries in the access logs won't match the usage that appears in the AWS billing and usage reports.
## Retrieving an app's access logs
Use the following procedure to retrieve access logs for an Amplify app.
**To view access logs**
1. Sign in to the AWS Management Console and open the [Amplify console](https://console.aws.amazon.com/amplify/).
1. Choose the app that you want to view access logs for.
1. In the navigation pane, choose **Monitoring**, then choose **Access logs**.
1. Choose **Edit time range**.
1. In the **Edit time range** window do the following.
1. For **Start date**, specify the first day of the two week interval to retrieve logs for.
1. For **Start time**, choose the time on the first day to start the log retrieval.
1. Choose **Confirm**.
1. The Amplify console displays the logs for your specified time range in the **Access logs** section. Choose **Download** to save the logs in a CSV format.
## Analyzing access logs
To analyze access logs you can store the CSV files in an Amazon S3 bucket. One way to analyze your access logs is to use Athena. Athena is an interactive query service that can help you analyze data for AWS services. You can follow the [step-by-step instructions here](https://docs.aws.amazon.com/athena/latest/ug/cloudfront-logs.html#create-cloudfront-table) to create a table. Once your table has been created, you can query data as follows.
```
SELECT SUM(bytes) AS total_bytes
FROM logs
WHERE "date" BETWEEN DATE '2018-06-09' AND DATE '2018-06-11'
LIMIT 100;
```
# Logging Amplify API calls using AWS CloudTrail
AWS Amplify is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amplify. CloudTrail captures all API calls for Amplify as events. The calls captured include calls from the Amplify console and code calls to the Amplify API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amplify. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information that CloudTrail collects, you can determine the request that was made to Amplify, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).
## Amplify information in CloudTrail
CloudTrail is enabled on your AWS account by default. When activity occurs in Amplify, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in the *AWS CloudTrail User Guide*.
For an ongoing record of events in your AWS account, including events for Amplify, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following in the *AWS CloudTrail User Guide*:
+ [Creating a trail for your AWS account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+ [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Receiving CloudTrail log files from multiple regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All Amplify operations are logged by CloudTrail and are documented in the [AWS Amplify Console API Reference](https://docs.aws.amazon.com/amplify/latest/APIReference/Welcome.html), the [AWS Amplify Admin UI API Reference](https://docs.aws.amazon.com/amplify-admin-ui/latest/APIReference/what-is-admin-ui.html), and the [Amplify UI Builder API Reference](https://docs.aws.amazon.com/amplifyuibuilder/latest/APIReference/Welcome.html). For example, calls to the `CreateApp`, `DeleteApp` and `DeleteBackendEnvironment` operations generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Was the request made with root or AWS Identity and Access Management (IAM) user credentials.
+ Was the request made with temporary security credentials for a role or federated user.
+ Was the request made by another AWS service.
For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html) in the *AWS CloudTrail User Guide*.
## Understanding Amplify log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the AWS Amplify Console API Reference [https://docs.aws.amazon.com/amplify/latest/APIReference/API_ListApps.html](https://docs.aws.amazon.com/amplify/latest/APIReference/API_ListApps.html) operation.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Mary_Major",
"accountId": "444455556666",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "Mary_Major",
"sessionContext": {
"sessionIssuer": {},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-01-12T05:48:10Z"
}
}
},
"eventTime": "2021-01-12T06:47:29Z",
"eventSource": "amplify.amazonaws.com",
"eventName": "ListApps",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "aws-internal/3 aws-sdk-java/1.11.898 Linux/4.9.230-0.1.ac.223.84.332.metal1.x86_64 OpenJDK_64-Bit_Server_VM/25.275-b01 java/1.8.0_275 vendor/Oracle_Corporation",
"requestParameters": {
"maxResults": "100"
},
"responseElements": null,
"requestID": "1c026d0b-3397-405a-95aa-aa43aexample",
"eventID": "c5fca3fb-d148-4fa1-ba22-5fa63example",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "444455556666"
}
```
The following example shows a CloudTrail log entry that demonstrates the AWS Amplify Admin UI API Reference [https://docs.aws.amazon.com/amplify-admin-ui/latest/APIReference/backend-appid-job-backendenvironmentname.html#backend-appid-job-backendenvironmentnamepost](https://docs.aws.amazon.com/amplify-admin-ui/latest/APIReference/backend-appid-job-backendenvironmentname.html#backend-appid-job-backendenvironmentnamepost) operation.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Mary_Major",
"accountId": "444455556666",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "Mary_Major",
"sessionContext": {
"sessionIssuer": {},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-01-13T00:47:25Z"
}
}
},
"eventTime": "2021-01-13T01:15:43Z",
"eventSource": "amplifybackend.amazonaws.com",
"eventName": "ListBackendJobs",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "aws-internal/3 aws-sdk-java/1.11.898 Linux/4.9.230-0.1.ac.223.84.332.metal1.x86_64 OpenJDK_64-Bit_Server_VM/25.275-b01 java/1.8.0_275 vendor/Oracle_Corporation",
"requestParameters": {
"appId": "d23mv2oexample",
"backendEnvironmentName": "staging"
},
"responseElements": {
"jobs": [
{
"appId": "d23mv2oexample",
"backendEnvironmentName": "staging",
"jobId": "ed63e9b2-dd1b-4bf2-895b-3d5dcexample",
"operation": "CreateBackendAuth",
"status": "COMPLETED",
"createTime": "1610499932490",
"updateTime": "1610500140053"
},
{
"appId": "d23mv2oexample",
"backendEnvironmentName": "staging",
"jobId": "06904b10-a795-49c1-92b7-185dfexample",
"operation": "CreateBackend",
"status": "COMPLETED",
"createTime": "1610499657938",
"updateTime": "1610499704458"
}
],
"appId": "d23mv2oexample",
"backendEnvironmentName": "staging"
},
"requestID": "7adfabd6-98d5-4b11-bd39-c7deaexample",
"eventID": "68769310-c96c-4789-a6bb-68b52example",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "444455556666"
}
```