# Network Monitoring
The topics in this section describe CloudWatch network and internet monitoring capabilities provided by Network Flow Monitor, Internet Monitor and Network Synthetic Monitor. These services help you to gain operational visibility into the network and internet performance and availability of your applications hosted on AWS.
+ Network Flow Monitor provides near real-time visibility into network performance, such as packet loss and latency, for traffic between Amazon EC2 instances, as well as traffic toward other AWS services, such as Amazon S3 and Amazon DynamoDB. Network Flow Monitor works by using data from lightweight software agents that you install to run on your instances. These fully-managed agents gather performance statistics from TCP connections and send them to the Network Flow Monitor backend. By creating monitors for specific agents and then using Network Flow Monitor dashboards, you can quickly visualize packet loss and latency of your network connections, and use attribution information to determine where to focus your troubleshooting efforts to improve your end users’ experience.
+ Internet Monitor uses the connectivity data that AWS captures from its global networking footprint to calculate a baseline of performance and availability for internet-facing traffic. You can see a global view of traffic patterns and health events, and easily drill down into information about events. You can also get alerts for internet health events that affect your application clients. In addition, you can use insights that Internet Monitor provides to explore potential improvements to your client experience, by using Amazon CloudFront or routing through different AWS Regions.
+ Network Synthetic Monitor uses fully-managed agents to enable you to track and visualize latency and packet loss for hybrid network connections. To gather measurements and enable Network Synthetic Monitor to create health event alerts for your application, you create probes that are sent from your resources hosted on AWS to on-premises destination IP addresses. You don't need to install additional agents to monitor your network performance. As with Internet Monitor, you can set alerts and thresholds, get information to help you quickly troubleshoot issues, and then take action to improve your end user experience.
**Topics**
+ [Using Network Flow Monitor](CloudWatch-NetworkFlowMonitor.md)
+ [Using Internet Monitor](CloudWatch-InternetMonitor.md)
+ [Using Network Synthetic Monitor](what-is-network-monitor.md)
# Using Network Flow Monitor
Network Flow Monitor gives you near real-time visibility into network performance for traffic between compute resources (Amazon EC2 and Amazon Elastic Kubernetes Service), traffic to other AWS services (Amazon S3 and Amazon DynamoDB), and traffic to the edge of another AWS Region. Network Flow Monitor collects data from lightweight software agents that you install on your instances. These agents gather performance statistics from TCP connections and send this data to the Network Flow Monitor backend service, which calculates the top contributors for each metric type.
Network Flow Monitor also determines if AWS is the cause of a detected network issue, and reports that information for network flows that you choose to monitor details for.
You can view network performance information for network flows for resources in a single account, or you can configure Network Flow Monitor with AWS Organizations to view performance information for multiple accounts in an organization, by signing in with a management or delegated administrator account.
Network Flow Monitor is intended for network operators and application developers who want near real-time insights into network performance. In the Network Flow Monitor console in CloudWatch, you can see performance data for your resources' network traffic that has been aggregated from agents and grouped into different categories. For example, you can see data for flows between Availability Zones or between VPCs. Then, you can create monitors for specific flows that you want to see more details for or track more closely over time.
Using a monitor, you can quickly visualize packet loss and latency of your network connections over a time frame that you specify. For each monitor, Network Flow Monitor also generates a network health indicator (NHI). The NHI value informs you whether there were AWS network issues for the network flows tracked by your monitor during the time period that you're evaluating. Using the NHI information, you can quickly decide whether to focus troubleshooting efforts on an AWS network issue or network problems originating with your workloads.
To see an example of configuring and using Network Flow Monitor, see the following blog post: [ Visualizing network performance of your AWS Cloud workloads with Network Flow Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/visualizing-network-performance-of-your-aws-cloud-workloads-with-network-flow-monitor/).
# What is Network Flow Monitor?
Network Flow Monitor is a feature of Amazon CloudWatch Network Monitoring. Network Flow Monitor uses fully-managed agents that you install in your AWS workloads to return performance and availability metrics about network flows. Using Network Flow Monitor, you can access near real-time metrics, including retransmissions and data transferred, for your actual workloads. You can also identify whether an underlying AWS network issue occurred for the network flows tracked by a monitor, by checking network health indicator (NHI) values.
**Key features of Network Flow Monitor**
+ With Network Flow Monitor, you receive near real-time metrics for the latency and packet-loss experienced by TCP-based traffic within your VPC network, so that you can track and investigate network issues for your workload traffic.
+ When your AWS workloads experience network degradation, Network Flow Monitor helps you to determine if the problem is caused by your application workload or the underlying AWS infrastructure. Then, you can quickly focus troubleshooting on the area where the issue is occurring.
**How to use Network Flow Monitor**
With Network Flow Monitor, you install lightweight agents on your instances, which collect and aggregate performance metrics. Network Flow Monitor agents analyze TCP traffic, and then export performance metrics to the Network Flow Monitor service backend.
Agents gather the following metrics for your workloads: TCP round-trip time (RTT), TCP retransmission timeouts, TCP retransmissions, and data (bytes) transferred. After you install agents on your instances, the agents detect the corresponding workloads that are hosted by the instances. The agents then generate network performance metrics and send the metrics to the Network Flow Monitor backend. Metrics are aggregated into categories such as subnets, Availability Zones, VPCs, and AWS services.
Performance metrics for top contributors (by metric type) from all network flows that are in your Network Flow Monitor scope are shown on the **Workload insights** tab in the AWS Management Console. By reviewing the tables and graphs of top contributors, you can determine where there might be impairments that you want to troubleshoot and which workloads you want to monitor on an ongoing basis, by creating a monitor.
With a monitor, you can monitor specific workloads more closely over time and see detailed information about specific network flows. In addition to viewing performance metrics for the top contributors for the network flows that you've selected, you can view network path information with the network hops that a network flow has traversed, to help you troubleshoot issues. In addition, Network Flow Monitor generates a network health indicator (NHI) for monitors. An NHI value of **Degraded** indicates that there were AWS network issues for at least one of the network flows tracked by your monitor, during the time period that you've selected.
In addition to reviewing the information in monitors that you create, we recommend that you also check back regularly to review metrics on the **Workload insights** page, to see the latest top contributors for performance metrics for your network flows. As you review the latest information, consider if it would be helpful to add or remove workloads from your current monitors, or create new monitors.
**Topics**
+ [Supported AWS Regions](CloudWatch-NetworkFlowMonitor-Regions.md)
+ [Components](CloudWatch-NetworkFlowMonitor-components.md)
+ [How it works](CloudWatch-NetworkFlowMonitor-inside-network-flow-monitor.md)
+ [Pricing](CloudWatch-NetworkFlowMonitor.pricing.md)
# Supported AWS Regions for Network Flow Monitor
Network Flow Monitor is currently available in the following AWS Regions:
| Region name | Region |
| --- | --- |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| Canada (Central) | ca-central-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| South America (São Paulo) | sa-east-1 |
| US East (N. Virginia) | us-east-1 |
| US East (Ohio) | us-east-2 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
# Components and features of Network Flow Monitor
Network Flow Monitor uses or references the following concepts.
**Agents**
An *agent* in Network Flow Monitor is a software application that you install on your AWS compute resources (Amazon EC2 and Amazon EKS). The application has two parts:
+ The first part receives events related to TCP connections and is registered within the Linux kernel using eBPF. eBPF is the Linux extended Berkley Packet Filter (eBPF) capability that allows a designated program to receive certain events raised by the Linux kernel.
+ The second part aggregates the statistics collected by the eBPF portion. The agent sends the aggregated metrics to the Network Flow Monitor backend about every 30 seconds, with a 5 second potential jitter (in other words, 25 to 35 seconds).
For more information about agents, see [How it works](CloudWatch-NetworkFlowMonitor-inside-network-flow-monitor.md).
**Top contributors**
*Top contributors* are the network flows that have the highest values for a specific metric (such as retransmissions) in your Network Flow Monitor scope or among the network flows you're tracking in a monitor. Reviewing the flows with the highest reported numbers for performance metric measurements can help you see where there might be impairments to investigate. Network Flow Monitor returns performance metrics for top contributors in your monitoring scope for *workload insights*. In addition, if you create a monitor, Network Flow Monitor returns performance metrics for top contributors for the network flows that you choose for the monitor.
**Local and remote resources**
A *local resource* is the host location—or a location of multiple hosts—where a Network Flow Monitor agent is installed. It can be a subnet, a VPC, an Availability Zone, an Amazon EKS cluster, or an AWS Region. For example, consider a workload that consists of an interaction between a web service and a backend database, for example, DynamoDB. In this scenario, the local resource is the subnet of the EC2 instance hosting the web service, which also runs the agent. A network flow is typically directional, though it can be configured to be bi-directional.
A *remote resource* is the other end of a network flow. In this example of a web service with a backend database, DynamoDB is the remote resource. A remote resource can be a subnet, a VPC, an Availability Zone, an AWS service, or an AWS Region. If you specify a Region as a remote resource, Network Flow Monitor measures performance for the network flow up to the edge of the Region. It does not measure performance to specific endpoints within the Region.
A resource is identified by the ARN of the resource, the name of the AWS service, or, for an Availability Zone or Region, by the name of the zone or Region.
**Workload insights**
*Workload insights* includes the performance metrics returned for all the network flows in your scope. In the AWS Management Console, the **Workload insights** page provides performance data about workloads where you've installed Network Flow Monitor agents on workload instances. The **Workload insights** page provides a view into your applications that includes the amount of data transferred and several other metrics, grouped into categories of workloads. For example, you can see all the metrics for workloads with traffic between Availability Zones (AZs) or within an AZ. By using these insights, you can select workloads for which you want to create a monitor to see more details and to track network performance on an ongoing basis.
**Monitors**
You create a *monitor* so that you can monitor, on an ongoing basis, the network performance for one or several specific workloads, and see more detailed information about the network flows. For each monitor, Network Flow Monitor publishes end-to-end performance metrics, and a network health indicator (NHI), which you can use to help determine attribution for impairments. We recommend that you review information on the **Workload insights** page to see which network flows you want to focus on, and then create a monitor for those flows. Then, by regularly reviewing **Workload insights**, you can decide if you have the monitors that you need, or if creating new monitors would be helpful.
**Network health indicator (NHI)**
The *network health indicator* (NHI) is a binary value that informs you whether there were AWS network issues for one or more of the network flows tracked by a monitor, during a time period that you choose. When the NHI value is 1, or **Degraded**, there was an AWS network issue for at least one network flow. With the NHI indicator, you can quickly decide whether to focus troubleshooting efforts on an AWS network issue or network problems originating with your workloads.
For more information, see [View Network Flow Monitor metrics in CloudWatch](CloudWatch-NetworkFlowMonitor-cw-metrics.md).
**Scope**
In Network Flow Monitor, the *scope* is the account or accounts that you have observability for when you look at network performance indicators. If you sign in as a management account and configure AWS Organizations with CloudWatch, you can set your scope to more than one account in your organization (up to 100 accounts total). Otherwise, if you sign in with an AWS account that does not have management permissions in Organizations, or if you have not configured Organizations with CloudWatch, Network Flow Monitor sets your scope to the account that you're signed in with.
After you have configured Organizations, you can change your scope by adding or removing accounts. However, whenever you change the scope, Network Flow Monitor must create a new topology of the resources in the scope. For more information, see [Add multiple accounts to your scope](CloudWatch-NetworkFlowMonitor-multi-account.md#CloudWatch-NetworkFlowMonitor-multi-account.config-scope).
Network Flow Monitor generates a unique **scope ID** for the scope. Queries for metrics data use the scope ID to determine the resources that the Network Flow Monitor generates metrics for. (You must install agents to gather and submit metrics data before you can view the performance metrics for an account with Network Flow Monitor.)
**Query ID**
Network Flow Monitor generates a unique *query ID* for each query that is created to retrieve performance metrics data, such as a query for top contributors for a monitor. By using a query ID with an API call in Network Flow Monitor, you can check the status of a query, stop a query, run the query again, or work with the query in other ways.
**Performance metrics**
Network Flow Monitor gathers and calculates end-to-end *performance metrics*, including TCP round-trip time (RTT), TCP retransmissions, TCP retransmission time outs, and bytes transferred for each flow that is in your Network Flow Monitor scope. The service aggregates these metrics and returns them to the service backend. You can view top contributors by metric type. When you see an anomaly in Network Flow Monitor, you can also check the network health indicator (NHI) to see if there is an underlying AWS network issue.
Be aware that RTT data can be sparse because RTT is not always calculated.
You can also use Amazon CloudWatch features to create dashboards, alarms, and notifications based on these metrics. For example, you can learn about setting up alarms with Network Flow Monitor metrics by reviewing the information in [Create alarms with Network Flow Monitor](CloudWatch-NetworkFlowMonitor-create-alarm.md).
# How it works
This section provides information about several aspects of how Network Flow Monitor works.
**How Network Flow Monitor agents gather statistics**
Agents in Network Flow Monitor are installed on AWS compute resources (Amazon EC2 and Amazon EKS), where they gather performance metrics and send them to the Network Flow Monitor backend. Agents do not have access to the payload of your TCP connections. Agents receive only what is called the "bpf\$1sock\$1ops" structure from the Linux kernel. This structure provides the local and remote IP address and the source and destination TCP port, as well as counters and round-trip times. For list of the TCP statistics collected and published by the agent, see [View Network Flow Monitor metrics in CloudWatch](CloudWatch-NetworkFlowMonitor-cw-metrics.md).
The agent uses the Network Flow Monitor `Publish` API to send metrics to the Network Flow Monitor backend server.
*Note:* Network Flow Monitor supports up to approximately 5 million flows per minute. This is approximately 5,000 instances (Amazon EC2 and Amazon EKS nodes) with NFM agent installed. Installing agents on more than 5000 instances may affect monitoring performance until additional capacity is available.
**How network flows are categorized in Network Flow Monitor**
Network Flow Monitor categorizes network flows into classifications depending on where the flows originate and terminate.
# Pricing for Network Flow Monitor
With Network Flow Monitor, there are no upfront costs or long-term commitments. Pricing for Network Flow Monitor has two components: resources monitored (agents installed and actively sending data) and CloudWatch metrics vended. Note that you are also charged standard CloudWatch prices for any additional metrics, dashboards, alarms, or insights that you create.
For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
# Get started with Network Flow Monitor
To help you get started, the section provides a high level overview of the steps to configure, and then gain insights, with Network Flow Monitor. For details, see the additional sections in this guide about initializing Network Flow Monitor, deploying agents, and creating monitors.
+ Initialize Network Flow Monitor, to accept service-linked role permissions, create a *scope* for monitoring in Network Flow Monitor, and create an initial topology. If you want to observe network performance for network flows for instances in multiple accounts, you must integrate with AWS Organizations, and then add the accounts to your scope. To learn more, see [Initialize Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-begin.md).
+ Deploy *agents* on your instances, by using AWS Systems Manager or by configuring Kubernetes, depending on how your resources are deployed. If you install agents on VPC EC2 instances, make sure that you enable permissions for agents on each instance to send metrics to the Network Flow Monitor backend. To learn more, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
+ Review top contributor metrics for network flows returned by the agents, to gain *workload insights*. Workload insights provide a high-level view of the performance for network flows in the scope you're monitoring.
+ Based on the network flows that you want to see detailed network information about, create one or more *monitors*. For each monitor, specify the local and remote resources that you want to monitor network flows between. Using a monitor, you can see detailed metrics and information, including the network health indicator, as well as view network paths for specific network flows, over time periods that you select.
+ On a regular basis:
+ Review network flow information in the monitors that you've created, to learn about and help troubleshoot network impairments in your workloads.
+ Review workload insights for the network flows that you're monitoring, to determine if the monitors that you've created are covering the most relevant network flows or if it would be helpful to create new monitors.
# Network Flow Monitor API operations
The following table lists Network Flow Monitor API operations that you can use with Network Flow Monitor. The table also includes links to relevant documentation.
| Action | API operation | More information |
| --- | --- | --- |
| Create a flow monitor. | See [CreateMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateMonitor.html) | See [Create a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md) |
| Generate metrics for a scope of resources. | See [CreateScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateScope.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Remove a monitor. | See [DeleteMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_DeleteMonitor.html) | See [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md) |
| Delete a defined scope. | See [DeleteScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_DeleteScope.html) | See [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md) |
| Get information about a monitor. | See [GetMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetMonitor.html) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Get query data for the top contributors in a specific monitor. | See [GetQueryResultsMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsMonitorTopContributors.html) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Query the top contributors for a defined scope for workload insights. | See [GetQueryResultsWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsWorkloadInsightsTopContributors.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Query workload insights data for the top contributors in a specific scope. | See [GetQueryResultsWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsWorkloadInsightsTopContributorsData.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Check the status of a query for top contributors in a monitor to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusMonitorTopContributors.html) | N/A |
| Check the status of a query on workload insights for top contributors to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusWorkloadInsightsTopContributors.html) | N/A |
| Check the status of a query on workload insights data for top contributors to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusWorkloadInsightsTopContributorsData) | N/A |
| Get information about an account, or scope, including name, status, tags, and target details. | See [GetScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetScope) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| List all monitors in an account. | See [ListMonitors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListMonitors) | [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| List all scopes for an account. | See [ListScopes](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListScopes) | N/A |
| List all tags for a specific resource. | See [ListTagsForResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListTagsForResource) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| See query data for top contributors in a monitor. | See [StartQueryMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StartQueryMonitorTopContributors) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Start a query to gather workload insights data for top contributors. | See [StartQueryWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StartQueryWorkloadInsightsTopContributors) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Stop a query for top contributors in a monitor. | See [StopQueryMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryMonitorTopContributors) | N/A |
| Stop a query on workload insights data for top contributors. | See [StopQueryWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryWorkloadInsightsTopContributors) | N/A |
| Stop a query on workload insights data for top contributors. | See [StopQueryWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryWorkloadInsightsTopContributorsData) | N/A |
| Add a tag to a resource. | See [TagResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_TagResource) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Remove a tag from a resource. | See [UntagResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UntagResource) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Update a monitor to add or remove local or remote resources. | See [UpdateMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UpdateMonitor) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Modify a scope to add or remove resources that Network Flow Monitor will generate metrics on. | See [UpdateScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UpdateScope) | N/A |
# Examples of using the CLI with Network Flow Monitor
This section includes examples for using the AWS Command Line Interface with Network Flow Monitor operations.
Before you begin, make sure that you log in to use the AWS CLI with the AWS account that provides the scope that you want to use to monitor network flows. For more information about using API actions with Network Flow Monitor, see the [Network Flow Monitor API Reference Guide](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/Welcome.html).
**Topics**
+ [Create a monitor](#CloudWatch-NFM-get-started-CLI-create-monitor)
+ [View monitor details](#CloudWatch-NFM-get-started-CLI-mon-details)
+ [Create a scope](#CloudWatch-NFM-get-started-CLI-create-scope)
+ [Delete a monitor](#CloudWatch-NFM-get-started-CLI-delete-monitor)
+ [Delete a scope](#CloudWatch-NFM-get-started-CLI-delete-scope)
+ [Get information about a monitor](#CloudWatch-NFM-get-started-CLI-get-monitor)
+ [Retrieve data on a specific queries](#CloudWatch-NFM-get-started-CLI-get-query-results)
+ [See scope information](#CloudWatch-NFM-get-scope)
+ [See a list of monitors for an account](#CloudWatch-NFM-list-monitors)
+ [See a list of scopes for an account](#CloudWatch-NFM-list-scopes)
+ [See the list of tags for a monitor](#CloudWatch-NFM-list-tags-for-resource)
+ [Starting and stopping queries](#CloudWatch-NFM-query-monitors)
+ [Tag a monitor](#CloudWatch-NFM-tag-resource)
+ [Remove a tag from a monitor](#CloudWatch-NFM-untag-resource)
+ [Update an existing monitor](#CloudWatch-NFM-update-monitor)
## Create a monitor
To create a monitor with the AWS CLI, use the `create-monitor` command. The following example creates a monitor named `demo` in the specified account.
```
aws networkflowmonitor create-monitor \
--monitor-name demo \
--local-resources type="AWS::EC2::VPC",identifier="arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889" \
--scope-arn arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-44556677889
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/demo",
"monitorName": "demo",
"monitorStatus": "ACTIVE",
"tags": {}
}
```
For more information, see [Create a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md).
## View monitor details
To view information about a monitor with the AWS CLI, use the `get-monitor` command.
```
aws networkflowmonitor get-monitor --monitor-name "TestMonitor"
```
Output:
```
{
"ClientLocationType": "city",
"CreatedAt": "2022-09-22T19:27:47Z",
"ModifiedAt": "2022-09-22T19:28:30Z",
"MonitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/TestMonitor",
"MonitorName": "TestMonitor",
"ProcessingStatus": "OK",
"ProcessingStatusInfo": "The monitor is actively processing data",
"Resources": [
"arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
],
"MaxCityNetworksToMonitor": 10000,
"Status": "ACTIVE"
}
```
## Create a scope
The following `create-scope` example creates a scope that is the set of resources for which Network Flow Monitor will generate network traffic metrics.
```
aws networkflowmonitor create-scope \
--targets '[{"targetIdentifier":{"targetId":{"accountId":"111122223333"},"targetType":"ACCOUNT"},"region":"us-east-1"}]'
```
Output:
```
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "IN_PROGRESS",
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Delete a monitor
The following `delete-monitor` example deletes a monitor named `Demo` in your account.
```
aws networkflowmonitor delete-monitor \
--monitor-name Demo
```
This command produces no output.
For more information, see [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md).
## Delete a scope
The following `delete-scope` example deletes the specified scope.
```
aws networkflowmonitor delete-scope \
--scope-id sample-aaaa-bbbb-cccc-44556677889
```
This command produces no output.
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Get information about a monitor
The following `get-monitor` example displays information about the monitor named `demo` in the specified account.
```
aws networkflowmonitor get-monitor \
--monitor-name Demo
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE",
"localResources": [
{
"type": "AWS::EC2::VPC",
"identifier": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
],
"remoteResources": [],
"createdAt": "2024-12-09T12:21:51.616000-06:00",
"modifiedAt": "2024-12-09T12:21:55.412000-06:00",
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Retrieve data on a specific queries
The following sections provide example CLI commands to retrieve query statuses.
### get-query-results-workload-insights-top-contributors-data
The `get-query-results-workload-insights-top-contributors-data` example returns the data for the specified query.
```
aws networkflowmonitor get-query-results-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"datapoints": [
{
"timestamps": [
"2024-12-09T19:00:00+00:00",
"2024-12-09T19:05:00+00:00",
"2024-12-09T19:10:00+00:00"
],
"values": [
259943.0,
194856.0,
216432.0
],
"label": "use1-az6"
}
],
"unit": "Bytes"
}
```
### get-query-results-workload-insights-top-contributors
The following `get-query-results-workload-insights-top-contributors` example returns the data for the specified query.
```
aws networkflowmonitor get-query-results-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"topContributors": [
{
"accountId": "111122223333",
"localSubnetId": "subnet-SAMPLE1111",
"localAz": "use1-az6",
"localVpcId": "vpc-SAMPLE2222",
"localRegion": "us-east-1",
"remoteIdentifier": "",
"value": 333333,
"localSubnetArn": "arn:aws:ec2:us-east-1:111122223333:subnet/subnet-2222444455556666",
"localVpcArn": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
]
}
```
### get-query-status-monitor-top-contributors
The following `get-query-status-monitor-top-contributors` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-monitor-top-contributors \
--monitor-name Demo \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
### get-query-status-workload-insights-top-contributors-data
The following `get-query-status-workload-insights-top-contributors-data` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
### get-query-results-workload-insights-top-contributors
The following `get-query-results-workload-insights-top-contributors` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
## See scope information
The following `get-scope` example displays information about a scope, such as status, tags, name, and target details.
```
aws networkflowmonitor get-scope \
--scope-id sample-aaaa-bbbb-cccc-11112222333
```
Output:
```
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "SUCCEEDED",
"scopeArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-11112222333",
"targets": [
{
"targetIdentifier": {
"targetId": {
"accountId": "111122223333"
},
"targetType": "ACCOUNT"
},
"region": "us-east-1"
}
],
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See a list of monitors for an account
The following `list-monitors` example returns all the monitors in the specified account.
```
aws networkflowmonitor list-monitors
```
Output:
```
{
"monitors": [
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE"
}
]
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See a list of scopes for an account
The following `list-scopes` example lists all the scopes in the specified account.
```
aws networkflowmonitor list-scopes
```
Output:
```
{
"scopes": [
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "SUCCEEDED",
"scopeArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-11112222333"
}
]
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See the list of tags for a monitor
The following `list-tags-for-resource` example returns all the tags associated with the specified resource.
```
aws networkflowmonitor list-tags-for-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo
```
Output:
```
{
"tags": {
"Value": "Production",
"Key": "stack"
}
}
```
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Starting and stopping queries
The following sections provide example CLI commands for starting and stopping queries in Network Flow Monitor.
### start-query-monitor-top-contributors
The following `start-query-monitor-top-contributors` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-monitor-top-contributors \
--monitor-name Demo \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### start-query-workload-insights-top-contributors-data
The following `start-query-workload-insights-top-contributors-data` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### start-query-workload-insights-top-contributors
The following `start-query-workload-insights-top-contributors` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-monitor-top-contributors
The following `stop-query-monitor-top-contributors` example stops the query in the specified account.
```
aws networkflowmonitor stop-query-monitor-top-contributors \
--monitor-name Demo \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-workload-insights-top-contributors-data
The following `stop-query-workload-insights-top-contributors-data` stops the query in the specified account.
```
aws networkflowmonitor stop-query-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-workload-insights-top-contributors
The following `stop-query-workload-insights-top-contributors` example stops the query in the specified account.
```
aws networkflowmonitor stop-query-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
## Tag a monitor
The following `tag-resource` adds a tag to the monitor in the specified account.
```
aws networkflowmonitor tag-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo \
--tags Key=stack,Value=Production
```
This command produces no output.
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Remove a tag from a monitor
The following `untag-resource` example removes a tag to the monitor in the specified account.
```
aws networkflowmonitor untag-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo \
--tag-keys stack
```
This command produces no output.
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Update an existing monitor
The following `update-monitor` example updates the monitor named ``Demo`` in the specified account.
```
aws networkflowmonitor update-monitor \
--monitor-name Demo \
--local-resources-to-add type="AWS::EC2::VPC",identifier="arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE",
"tags": {
"Value": "Production",
"Key": "stack"
}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
# Work with EKS
Using Network Flow Monitor, you can collect performance metrics for workloads that use Amazon Elastic Kubernetes Service (Amazon EKS). This chapter shows you how to install the agent step-by-step and describes the different EKS scenarios you can monitor. You'll also find detailed descriptions of the metadata that Network Flow Monitor provides for Amazon EKS in the console to help you understand network performance.
To gain the benefits of Network Flow Monitor performance monitoring, you must first install the AWS Network Flow Monitor Agent add-on for Amazon EKS. For more information, see [Install the EKS AWS Network Flow Monitor Agent add-on](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md).
If you want to monitor a single EKS cluster with enhanced visibility of workload traffic and performance insights within the cluster and with external destinations, see [Amazon EKS Network Observability](https://docs.aws.amazon.com/eks/latest/userguide/network-observability.html).
**Topics**
+ [Install the EKS AWS Network Flow Monitor Agent add-on](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md)
+ [Additional network path metadata included for Amazon EKS](CloudWatch-NetworkFlowMonitor-work-with-eks.performance-metadata.md)
# Install the EKS AWS Network Flow Monitor Agent add-on
Follow the steps in this section to install the AWS Network Flow Monitor Agent add-on for Amazon Elastic Kubernetes Service (Amazon EKS), to send Network Flow Monitor metrics to the Network Flow Monitor backend from Kubernetes clusters. After you complete the steps, AWS Network Flow Monitor Agent pods will be running on all of your Kubernetes cluster nodes.
If you use self-managed Kubernetes clusters, the installation steps to follow are in the previous section: [Install agents for self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents-kubernetes-non-eks.md).
Be aware that Customer Managed prefix lists [Customer Managed prefix lists](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-managed-prefix-lists.html) are not supported for Network Flow Monitor.
You can install the add-on by using the console or by using API commands with the AWS Command Line Interface.
**Topics**
+ [Prerequisites for installing the add-on](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-prereq)
+ [Install the add-on by using the console](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-console)
+ [Install the add-on by using the CLI](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-cli)
+ [Configure for third party tools](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-third-party.md)
## Prerequisites for installing the add-on
Regardless of whether you use the console or the CLI to install the AWS Network Flow Monitor Agent add-on, there are several requirements for installing the add-on with Kubernetes.
**Ensure that your version of Kubernetes is supported**
Network Flow Monitor agent installation requires Kubernetes Version 1.25, or a more recent version.
**Amazon EKS Pod Identity Agent add-on installation**
You can install the Amazon EKS Pod Identity Agent add-on in the console or by using the CLI.
Amazon EKS Pod Identity associations provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Amazon EKS Pod Identity provides credentials to your workloads with an additional Amazon EKS Auth API and an agent pod that runs on each node.
To learn more and see the steps for installing the Amazon EKS Pod Identity add-on, see [Set up the Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) in the Amazon EKS User Guide.
## Install the AWS Network Flow Monitor Agent add-on by using the console
Follow the steps in this section to install and configure the AWS Network Flow Monitor Agent add-on in the Amazon EKS console.
If you have already installed the add-on and have issues upgrading to a new version, see [Troubleshoot issues in EKS agents installation](CloudWatch-NetworkFlowMonitor-troubleshooting.md#CloudWatch-NetworkFlowMonitor-troubleshooting.ec2-agent-installation).
Before you begin, make sure that you have installed the Amazon EKS Pod Identity Agent add-on. For more information, see the [previous section](#NFMPodIdentity).
**To install the add-on using the console**
1. In the AWS Management Console, navigate to the Amazon EKS console.
1. On the page for installing add-ons, in the list of add-ons, choose **AWS Network Flow Monitor Agent**.
1. Configure the add-on settings.
1. For **Add-on access**, choose **EKS Pod Identity**.
1. For the IAM role to use with the add-on, use a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). This policy gives permission for an agent to send telemetry reports to the Network Flow Monitor endpoint. If you don't already have a role with the policy attached, create a role by choosing **Create recommended role**, and following the steps in the IAM console.
1. Choose **Next**.
1. On the **Review and add** page, make sure that the add-on configuration looks correct, and then choose **Create**.
## Install the AWS Network Flow Monitor Agent add-on by using the AWS Command Line Interface
Follow the steps in this section to install the AWS Network Flow Monitor Agent add-on for Amazon EKS by using the AWS Command Line Interface.
**1. Install the EKS Pod Identity Agent add-on**
Before you begin, make sure that you have installed the Amazon EKS Pod Identity Agent add-on. For more information, see the [earlier section](#NFMPodIdentity).
**2. Create the required IAM role**
The AWS Network Flow Monitor Agent add-on must have permission to send metrics to the Network Flow Monitor backend. You must attach a role with the required permissions when you create the add-on. Create a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). You need the ARN of this IAM role to install the add-on.
**3. Install the AWS Network Flow Monitor Agent add-on**
To install the AWS Network Flow Monitor Agent add-on for your cluster, run the following command:
`aws eks create-addon --cluster-name CLUSTER NAME --addon-name aws-network-flow-monitoring-agent --region AWS REGION --pod-identity-associations serviceAccount=aws-network-flow-monitor-agent-service-account,roleArn=IAM ROLE ARN`
The result should be similar to the following:
```
{
"addon": {
"addonName": "aws-network-flow-monitoring-agent",
"clusterName": "ExampleClusterName",
"status": "CREATING",
"addonVersion": "v1.0.0-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:us-west-2:000000000000:addon/ExampleClusterName/aws-network-flow-monitoring-agent/eec11111-bbbb-EXAMPLE",
"createdAt": "2024-10-25T16:38:07.213000+00:00",
"modifiedAt": "2024-10-25T16:38:07.240000+00:00",
"tags": {},
"podIdentityAssociations": [
"arn:aws:eks:us-west-2:000000000000:podidentityassociation/ExampleClusterName/a-3EXAMPLE5555555"
]
}
}
```
**4. Make sure that the add-on is active**
Review the installed AWS Network Flow Monitor Agent add-on to ensure that it's active for your cluster. Run the following command to verify that the status is `ACTIVE`:
`aws eks describe-addon --cluster-name CLUSTER NAME --addon-name aws-network-flow-monitoring-agent --region AWS REGION`
The result should be similar to the following:
```
{
"addon": {
"addonName": "aws-network-flow-monitoring-agent",
"clusterName": "ExampleClusterName",
"status": "ACTIVE",
"addonVersion": "v1.0.0-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:us-west-2:000000000000:addon/ExampleClusterName/aws-network-flow-monitoring-agent/eec11111-bbbb-EXAMPLE",
"createdAt": "2024-10-25T16:38:07.213000+00:00",
"modifiedAt": "2024-10-25T16:38:07.240000+00:00",
"tags": {},
"podIdentityAssociations": [
"arn:aws:eks:us-west-2:000000000000:podidentityassociation/ExampleClusterName/a-3EXAMPLE5555555"
]
}
}
```
# Configure add-on for third party monitoring tools
You can configure the Network Flow Monitor add-on to expose an OpenMetrics server during installation. This enables integration with third-party monitoring tools such as Prometheus, allowing you to collect and analyze network flow metrics alongside your existing monitoring infrastructure. [Learn more about about OpenMetrics](https://openmetrics.io/). This feature is available from add-on version v1.1.0.
To enable the OpenMetrics server, add OPEN\$1METRICS, OPEN\$1METRICS\$1ADDRESS, and OPEN\$1METRICS\$1PORT to the configuration values of the EKS Network Flow Monitor add-on. This guide will explain how to do this using both CLI and Console. See [Amazon EKS add-ons advanced configuration](https://aws.amazon.com/blogs/containers/amazon-eks-add-ons-advanced-configuration/) for additional details about adding configuration values.
## CLI Configuration
When using AWS Command Line Interface, you can provide the configuration values as a parameter:
```
aws eks create-addon \
--cluster-name my-cluster-name \
--addon-name aws-network-flow-monitoring-agent \
--addon-version v1.1.0-eksbuild.1 \
--configuration-values '{"env":{"OPEN_METRICS":"on","OPEN_METRICS_ADDRESS":"0.0.0.0","OPEN_METRICS_PORT":9109}}'
```
## Console Configuration
When using the Amazon EKS Console, these values can be added under Optional configuration settings, as part of the Configuration values.
**Sample JSON:**
```
{
"env": {
"OPEN_METRICS": "on",
"OPEN_METRICS_ADDRESS": "0.0.0.0",
"OPEN_METRICS_PORT": 9109
}
}
```
**Sample YAML:**
```
env:
OPEN_METRICS: "on"
OPEN_METRICS_ADDRESS: "0.0.0.0"
OPEN_METRICS_PORT: 9109
```
## EKS Network Flow Monitor add-on OpenMetric Parameters
+ **OPEN\$1METRICS:**
+ Enable or disable open metrics. Disabled if not supplied
+ Type: String
+ Values: ["on", "off"]
+ **OPEN\$1METRICS\$1ADDRESS:**
+ Listening IP address for open metrics endpoint. Defaults to 127.0.0.1 if not supplied
+ Type: String
+ **OPEN\$1METRICS\$1PORT:**
+ Listening port for open metrics endpoint. Defaults to 80 if not supplied
+ Type: Integer
+ Range: [0..65535]
**Important:** When setting OPEN\$1METRICS\$1ADDRESS to 0.0.0.0, the metrics endpoint will be accessible from any network interface. Consider using 127.0.0.1 for localhost-only access or implement appropriate network security controls to restrict access to authorized monitoring systems only.
## Troubleshooting
If you encounter issues with the OpenMetrics server configuration, use the following information to diagnose and resolve common problems.
### Metrics not displaying
Problem: The OpenMetrics server is configured, but metrics are not appearing in your monitoring tool.
Troubleshooting Steps:
1. Verify that the OpenMetrics server is enabled in your add-on configuration:
+ Check that OPEN\$1METRICS is set to "on" in your configuration values. See [describe-addon](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-addon.html).
+ Confirm that the add-on version is v1.1.0 or later in the *Configure selected add-ons settings*.
1. Test the metrics endpoint directly:
+ Access the metrics at http://*pod-ip:port*/metrics (replace pod-ip with the actual pod IP address and port with your configured port).
+ If you can't access the endpoint, verify your network configuration and security group settings.
1. Validate your monitoring tool configuration. Consult you monitoring tools user guide for details on how to do the following:
+ Ensure your monitoring tool (such as Prometheus) is configured to scrape the correct endpoint.
+ Check that the scraping interval and timeout settings are appropriate.
+ Verify that your monitoring tool has network access to the pod IP address.
### Metrics missing from specific pods
Problem: Metrics are available from some pods but not others in your cluster.
Troubleshooting Steps:
The Network Flow Monitor add-on doesn't support pods that use hostNetwork: true. If your pod specification includes this setting, metrics won't be available from those pods.
Workaround: Remove the hostNetwork: true setting from your pod specification if possible. If you require host networking for your application, consider using alternative monitoring approaches for those specific pods.
### Connection refused errors
Problem: You receive "connection refused" errors when trying to access the metrics endpoint.
Troubleshooting Steps:
1. Verify the OPEN\$1METRICS\$1ADDRESS configuration:
+ If set to 127.0.0.1, the endpoint is only accessible from within the pod.
+ If set to 0.0.0.0, the endpoint should be accessible from other pods in the cluster.
+ Ensure your monitoring tool can reach the configured address.
1. Check the OPEN\$1METRICS\$1PORT configuration:
+ Verify that the port number is not already in use by another service.
+ Ensure the port is within the valid range (1-65535).
+ Confirm that any security groups or network policies allow traffic on this port.
### Verification steps
To confirm your OpenMetrics configuration is working correctly:
1. Check the add-on status:
```
aws eks describe-addon --cluster-name your-cluster-name --addon-name aws-network-flow-monitoring-agent
```
1. Verify pod status:
```
kubectl get pods app.kubernetes.io/name=aws-network-flow-monitoring-agent
```
1. Test the metrics endpoint from within the cluster:
```
kubectl exec add-on-pod-name -- curl localhost:9109/metrics
```
Replace 9109 with your configured port number, and the pod name with an AddOn pod name.
# Additional network path metadata included for Amazon EKS
When Network Flow Monitor gathers performance metrics for network flows between Amazon EKS components, it includes additional metadata information about the network path, to help you better understand how the network paths for your workload are performing.
You can view detailed information about Amazon EKS network flow performance by creating a monitor for the network flows that you're interested in, and then viewing details on the **Historical explorer** tab.
With Network Flow Monitor, you can measure network performance between the following Amazon EKS components, to better understand how your workload is performing with your Amazon EKS configuration and determine where there are bottlenecks or impairments.
+ Pod to pod on the same node
+ Node to node on the same cluster
+ Pod to pod on a different cluster
+ Node to node on different clusters
+ With and without Network Load Balancer
The following table lists the information that Network Flow Monitor returns for each network flow scenario.
| **Connection information** | **Metadata information** | | **Local** | **Remote** | **Scenario** | **Initiated by** | **Local** | **Remote** | **Pod name** | **Service** | **Namespace** | **Pod name** | **Service** | **Namespace** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Local pod connecting to cluster IP of another internal cluster service | Local | Local pod IP address | Remote pod IP address (through cluster IP address) | ✓ | ✓ | ✓ | ✓ ¹ | ✓ | ✓ |
| Local pod in a node network namespace connecting to cluster IP of another internal cluster service | Local | Local node IP address | Remote pod IP address (through cluster IP address) | ✓ ² | ✓ ² | ✓ ² | ✓ ¹ | ✓ | ✓ |
| Local pod connecting to individual pod IP address of another pod (headless service) | Local | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Local pod connecting to individual pod IP address of another pod in node network namespace (headless service) | Local | Local pod IP address | Remote node IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Local pod connecting to remote pod in another cluster | Local | Local pod IP address | Remote pod IP address (another cluster) | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Local pod connecting to an external network address | Local | Local pod IP address | External IP address | ✓ | ✓ | ✓ | N/A | N/A | N/A |
| Local pod operating in a node network namespace connecting to an external network IP address | Local | Local node IP address | External IP address | ✓ ² | ✓ ² | ✓ ² | N/A | N/A | N/A |
| Remote pod connecting to local pod through cluster IP address | Remote | Local pod IP address (through cluster IP address) | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Remote pod in a node network namespace connecting to local pod | Remote | Local pod IP address (through cluster IP address) | Remote node IP address | ✓ | ✓ | ✓ | ✓ ³ | ✓ ³ | ✓ ³ |
| Remote pod connecting to local pod (headless service) | Remote | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| External pod connecting to a local pod | Remote | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| External resource connecting through NodePort or a Load Balancer to a local pod | Remote | Local pod IP address | External IP address ⁴ | ✓ | ✓ | ✓ | N/A | N/A | N/A |
| External resource connecting through NodePort or a Load Balancer to a local pod operating in a node network namespace | Remote | Local node IP address | External IP address ⁴ | ✓ | ✓ | ✓ | N/A | N/A | N/A |
Be aware of the following additional information corresponding to the items marked with footnotes in the preceding table.
1. Pod name is not visible in this scenario for pods with other owners, such as a Kubernetes service managed by the EKS control plane.
1. Local pod name, service, and namespace are not resolved if other pods are present in node network namespace.
1. Remote pod name, service, and namespace are not resolved if other pods are present in node network namespace.
1. If service is using NodePort or LoadBalancer in instance mode, and `ExternalTrafficPolicy` is set to `Cluster`, then this IP address will be reported as the IP address of the node that receives the NodePort connection.
# Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances
To provide performance metrics for network flows in your AWS workloads, Network Flow Monitor relies on *agents* that you install, which send the metrics to Network Flow Monitor. You install Network Flow Monitor agents on your instances, and then set the correct permissions for the agents so that they can send metrics to the Network Flow Monitor backend.
An agent is a lightweight software application that you install on your resources, such as your VPC EC2 instances. Agents send performance metrics to the Network Flow Monitor backend on an ongoing basis. Then, you can view the metrics on the **Workload insights** page in the Network Flow Monitor console. You can also track detailed metrics for a specific network flow, or set of flows, by creating a monitor.
The steps that you follow to deploy agents in your instances depend on the type of instance: Amazon EKS Kubernetes instances, VPC EC2 instances, or self-managed (non-EKS) Kubernetes instances.
+ For information about working with Amazon EKS, including installing agents on EKS, see [Work with EKS](CloudWatch-NetworkFlowMonitor-work-with-eks.md).
+ For information about installing agents on VPC EC2 instances and self-managed Kubernetes instances, see the sections in this chapter.
You can establish a private connection between your VPC and Network Flow Monitor agents by using AWS PrivateLink. For more information, see [Using CloudWatch, CloudWatch Synthetics, and CloudWatch Network Monitoring with interface VPC endpoints](cloudwatch-and-interface-VPC.md).
**Topics**
+ [Linux versions supported for Network Flow Monitor agents](CloudWatch-NetworkFlowMonitor-agents-versions.md)
+ [Install and manage agents for EC2 instances](CloudWatch-NetworkFlowMonitor-agents-ec2.md)
+ [Install agents for self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents-kubernetes-non-eks.md)
# Linux versions supported for Network Flow Monitor agents
The instances that you install agents on must be running supported versions and distributions of Linux. Network Flow Monitor supports agents to run only on Linux, and the Linux kernel version must be 5.8 or later. The following Linux distributions are supported. Note that agents are tested to run on the latest versions of these distributions.
+ Amazon Linux
+ Ubuntu
+ Red Hat
+ Suse Linux
+ Debian distributions for both x86 and aarch64
# Install and manage agents for EC2 instances
Follow the steps in this section to install Network Flow Monitor agents for workloads on Amazon EC2 instances. You can install agents by using SSM or by downloading and installing prebuilt packages for the Network Flow Monitor agent by using the command line.
Regardless of the method that you use to install agents on EC2 instances, you must configure permissions for the agents to enable them to send performance metrics to the Network Flow Monitor backend.
**Topics**
+ [Configure permissions for agents](CloudWatch-NetworkFlowMonitor-agents-ec2-permissions.md)
+ [EC2 instance agents with SSM](CloudWatch-NetworkFlowMonitor-agents-ec2-install-ssm.md)
+ [Download and install the agent](CloudWatch-NetworkFlowMonitor-agents-download-agent-commandline.md)
# Configure permissions for agents
To enable agents to send metrics to the Network Flow Monitor ingestion backend, the EC2 instances that the agents run in must use a role that has a policy attached with the correct permissions. To provide the required permissions, use a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). Attach this policy to the IAM roles of the EC2 instances where you plan to install Network Flow Monitor agents.
We recommend that you add the permissions before you install agents on the EC2 instances. You can choose to wait until after you install agents, but the agents won't be able to send metrics to the service until the permissions are in place.
**To add permissions for Network Flow Monitor agents**
1. In the AWS Management Console, in the Amazon EC2 console, locate the EC2 instances that you plan to install Network Flow Monitor agents on.
1. Attach the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) to the IAM role for each instance.
If an instance doesn't have an IAM role attached, choose a role by doing the following:
1. Under **Actions**, choose **Security**.
1. Choose **Modify IAM role**, or create a new role by choosing **Create new IAM role**.
1. Choose a role for the instance, and attach the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) policy.
# Install agents on EC2 instances with SSM
Network Flow Monitor agents provide performance metrics about network flows. Follow the steps in this section to install and work with Network Flow Monitor agents on EC2 instances, by using AWS Systems Manager. If you use Kubernetes, skip to the next sections for information about installing agents with Amazon EKS clusters or self-managed Kubernetes clusters.
Network Flow Monitor provides a Distributor package for you in Systems Manager to use to install or uninstall agents. In addition, Network Flow Monitor provides a document to activate or deactivate agents, by using the Document Type command. Use standard Systems Manager procedures to use the package and the document, or follow the steps provided here for detailed guidance.
For more information in general about using Systems Manager, see the following documentation:
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)
+ [AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html)
Complete the steps in the following sections to configure permissions, install, and work with Network Flow Monitor agents.
**Contents**
+ [Install or uninstall agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-install)
+ [Activate or deactivate agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-manage)
## Install or uninstall agents by using Systems Manager
Network Flow Monitor provides a distributor package in AWS Systems Manager for you to install Network Flow Monitor agents: **AmazonCloudWatchNetworkFlowMonitorAgent**. To access and run the package to install agents, follow the steps provided here.
**To install agents in EC2 instances**
1. In the AWS Management Console, in AWS Systems Manager, under **Node Tools**, choose **Distributor**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor package, **AmazonCloudWatchNetworkFlowMonitorAgent**, and select it.
1. In the **Run command** flow, choose **Install one time** or **Install on schedule**.
1. In the **Target selection** section, choose how you want to select your EC2 instances to install agents on. You can select instances based on tags, choose instances manually, or base the choice on resource groups.
1. In the **Commmand parameters** section, under **Action**, choose **Install**.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
If the installation is successful and the instances have permissions to access Network Flow Monitor endpoints, the agent will start collecting metrics and send reports to the Network Flow Monitor backend.
Agents that are active (sending metrics data) incur billing costs. For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page. If you don't need metrics data temporarily, you can deactivate an agent. For more information, see [Activate or deactivate agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-manage). If you no longer need Network Flow Monitor agents, you can uninstall them from the EC2 instances.
**To uninstall agents from EC2 instances**
1. In the AWS Management Console, in AWS Systems Manager, under **Node Tools**, choose **Distributor**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor package, **AmazonCloudWatchNetworkFlowMonitorAgent**, and select it.
1. In the **Commmand parameters** section, under **Action**, choose **Uninstall**.
1. Select the EC2 instances to uninstall agents from.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
## Activate or deactivate agents by using Systems Manager
After you install a Network Flow Monitor agent with SSM, you must activate it to receive network flow metrics from the instance where it's installed. Agents that are active (sending metrics data) incur billing costs. For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page. If you don't need metrics data temporarily, you can deactivate an agent to prevent ongoing billing for the agent.
Network Flow Monitor provides a document in AWS Systems Manager that you can use activate or deactivate agents that you've installed on your EC2 instances. By running this document to manage the agents, you can activate them to begin receiving performance metrics. Or, you can deactivate them to temporarily stop metrics from being sent,without uninstalling the agents.
The document in SSM that you can use to activate or deactivate agents is called **AmazonCloudWatch-NetworkFlowMonitorManageAgent**. To access and run the document, follow the steps in the procedure.
**To activate or deactivate Network Flow Monitor agents**
1. In the AWS Management Console, in AWS Systems Manager, under **Change Management Tools**, choose **Documents**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor document, **AmazonCloudWatch-NetworkFlowMonitorManageAgent**, and select the document.
1. In the **Target selection** section, choose how you want to select your EC2 instances to install agents on. You can select instances based on tags, choose instances manually, or base the choice on resource groups.
1. In the **Command parameters** section, under **Action**, choose **Activate** or **Deactivate**, depending on the action that you want to take for the agents.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
# Download prebuilt packages of the Network Flow Monitor agent by using the command line
You can use the command line to install the Network Flow Monitor agent as a package in Amazon Linux 2023, or download and install prebuilt packages of the Network Flow Monitor agent.
Before or after you download a prebuilt package, you can optionally verify the package signature. For more information, see [ Verify the signature of the Network Flow Monitor agent package](#CloudWatch-NetworkFlowMonitor-agents-download-agent-commandline-verify-sig).
Choose from the following instructions, depending on the Linux operating system that you're using and the type of installation that you want.
**Amazon Linux AMIs**
The Network Flow Monitor agent is available as a package in Amazon Linux 2023. If you're using this operating system, you can install the package by entering the following command:
`sudo yum install network-flow-monitor-agent`
You must also make sure that the IAM role attached to the instance has the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](security-iam-awsmanpol-network-flow-monitor.md#security-iam-awsmanpol-CloudWatchNetworkFlowMonitorAgentPublishPolicy) policy attached. For more information, see [Configure permissions for agents](CloudWatch-NetworkFlowMonitor-agents-ec2-permissions.md).
**Amazon Linux 2023**
Install the package for your architecture by using one of the following commands:
+ **x86\$164**: `sudo yum install https://networkflowmonitoragent.awsstatic.com/latest/x86_64/network-flow-monitor-agent.rpm`
+ **ARM64 (Graviton)**: `sudo yum install https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm`
Verify that Network Flow Monitor agent is successfully installed by running the following command and verifying that the response shows that the agent is enabled and active:
```
service network-flow-monitor status
network-flow-monitor.service - Network Flow Monitor Agent
Loaded: loaded (/usr/lib/systemd/system/network-flow-monitor.service; enabled; preset: enabled)
Active: active (running) since Wed 2025-04-23 19:17:16 UTC; 1min 9s ago
```
**DEB-based distributions (Debian, Ubuntu)**
Install the package for your architecture by using one of the following commands:
+ **x86\$164**: `wget https://networkflowmonitoragent.awsstatic.com/latest/x86_64/network-flow-monitor-agent.deb`
+ **ARM64 (Graviton)**: `wget https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb`
Install the package by using the following command: `$ sudo apt-get install ./network-flow-monitor-agent.deb`
Verify that Network Flow Monitor agent is successfully installed by running the following command and verifying that the response shows that the agent is enabled and active:
```
service network-flow-monitor status
network-flow-monitor.service - Network Flow Monitor Agent
Loaded: loaded (/usr/lib/systemd/system/network-flow-monitor.service; enabled; preset: enabled)
Active: active (running) since Wed 2025-04-23 19:17:16 UTC; 1min 9s ago
```
## Verify the signature of the Network Flow Monitor agent package
The Network Flow Monitor agent rpm and deb installer packages for Linux instances are cryptographically signed. You can use a public key to verify that the agent package is original and unmodified. If the files are damaged or have been altered, the verification fails. You can verify the signature of the installer package using either RPM or GPG. The following information is for Network Flow Monitor agent versions 0.1.3 or later.
To find the correct signature file for each architecture and operating system, use the following table.
| Architecture | Platform | Download link | Signature file link |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.rpm | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.rpm.sig |
| ARM64 | Amazon Linux 2023 | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm.sig |
| x86-64 | Debian/Ubuntu | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.deb | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.deb.sig |
| ARM64 | Debian/Ubuntu | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb.sig |
Follow the steps here to verify the signature of the Network Flow Monitor agent.
**To verify the signature of the Network Flow Monitor agent for Amazon S3 package**
1. Install GnuPG so that you can run the gpg command. GnuPG is required to verify the authenticity and integrity of a downloaded Network Flow Monitor agent for an Amazon S3 package. GnuPG is installed by default on Amazon Linux Amazon Machine Images (AMIs).
1. Copy the following public key and save it to a file named `nfm-agent.gpg`.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGf0b5IBEAC6YQc0aYrTbcHNWWMbLuqsqfspzWrtCvoU0yQ62ld7nvCGBha9
lu4lbhtiwoDawC3h6Xsxc3Pmm6kbMQfZdbo4Gda4ahf6zDOVI5zVHs3Yu2VXC2AU
5BpKQJmYddTb7dMI3GBgEodJY05NHQhq1Qd2ptdh03rsX+96Fvi4A6t+jsGzMLJU
I+hGEKGif69pJVyptJSibK5bWCDXh3eS/+vB/CbXumAKi0sq4rXv/VPiIhn6bsCI
A2lmzFd3vMJQUM/T7m7skrqetZ4mWHr1LPDFPK/H/81s8TJawx7MACsK6kIRUxu+
oicW8Icmg9S+BpIgONT2+Io5P1tYO5a9AyVF7X7gU0VgHUA1RoLnjHQHXbCmnFtW
cYEuwhUuENMl+tLQCZ+fk0kKjOlIKqeS9AVwhks92oETh8wpTwTE+DTBvUBP9aHo
S39RTiJCnUmA6ZCehepgpwW9AYCc1lHv/xcahD418E0UHV22qIw943EwAkzMDA4Q
damdRm0Nud0OmilCjo9oogEB+NUoy//5XgQMH1hhfsHquVLU/tneYexXYMfo/Iu5
TKyWL2KdkjKKP/dMR4lMAXYi0RjTJJ5tg5w/VrHhrHePFfKdYsgN6pihWwj2Px/M
ids3W1Ce50LOEBc2MOKXYXGd9OZWyR8l15ZGkySvLqVlRGwDwKGMC/nS2wARAQAB
tEJOZXR3b3JrIEZsb3cgTW9uaXRvciBBZ2VudCA8bmV0d29yay1mbG93LW1vbml0
b3ItYWdlbnRAYW1hem9uLmNvbT6JAlcEEwEIAEEWIQR2c2ypl63T6dJ3JqjvvaTM
vJX60QUCZ/RvkgIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAK
CRDvvaTMvJX60euSD/9cIu2BDL4+MFFHhyHmG3/se8+3ibW0g8SyP3hsnq7qN+bm
ZzLAhll7DVoveNmEHI1VC7Qjwb30exgLcyK2Ld6uN6lwjjK0qiGGz943t230pJ3z
u7V2fVtAN+vgDVmD7agE6iqrRCWu3WfcgzFlEkE/7nkhtbWzlaK+NkdEBzNZ+W7/
FmLClzIbMjIBW2M8LdeZdQX0SWljy18x7NGNukWeNTJxmkDsjAeKl+zkXYk9h7ay
n3AVl1KrLZ5P9vQ5XsV5e4T6qfQ3XNY1lm54cpa+eD7NyYcTGRDK+vIxO4xD8i2M
yl1iNf2+84Tt6/SAgR/P9SJ5tbKD0iU9n4g1eBJVGmHDuXTtDR4H/Ur7xRSxtuMl
yZP/sLWm8p7+Ic7aQJ5OVw36MC7Oa7/K/zQEnLFFPmgBwGGiNiw5cUSyCBHNvmtv
FK0Q2XMXtBEBU9f44FMyzNJqVdPywg8Y6xE4wc/68uy7G6PyqoxDSP2ye/p+i7oi
OoA+OgifchZfDVhe5Ie0zKR0/nMEKTBV0ecjglb/WhVezEJgUFsQcjfOXNUBesJW
a9kDGcs3jIAchzxhzp/ViUBmTg6SoGKh3t+3uG/RK2ougRObJMW3G+DI7xWyY+3f
7YsLm0eDd3dAZG3PdltMGp0hKTdslvpws9qoY8kyR0Fau4l222JvYP27BK44qg==
=INr5
-----END PGP PUBLIC KEY BLOCK-----
```
1. Import the public key into your keyring and note the returned value.
```
PS> rpm --import nfm-agent.gpg
gpg: key 3B789C72: public key "Network Flow Monitor Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
Make a note of the key value because you need it in the next step. In this example, the key value is `3B789C72`.
1. Verify the fingerprint by running the following command. Be sure to replace *key-value* with the value from the preceding step. We recommend that you use GPG to verify the fingerprint even if you use RPM to verify the installer package.
```
PS> gpg --fingerprint key-value
pub rsa4096 2025-04-08 [SC] [expires: 2028-04-07]
7673 6CA9 97AD D3E9 D277 26A8 EFBD A4CC BC95 FAD1
uid Network Flow Monitor Agent
```
The fingerprint string should be equal to the following:
`7673 6CA9 97AD D3E9 D277 26A8 EFBD A4CC BC95 FAD1`
If the fingerprint string doesn't match, don't install the agent. Contact Amazon Web Services.
After you have verified the fingerprint, you can use it to verify the signature of the Network Flow Monitor agent package.
1. Download the package signature file, if you haven't already done so, based on your instance's architecture and operating system.
1. Verify the installer package signature. Be sure to replace the `signature-filename` and `agent-download-filename` with the values that you specified when you downloaded the signature file and agent, as shown in the table earlier in this topic.
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made Tue Apr 8 00:40:02 2025 UTC
gpg: using RSA key 77777777EXAMPLEKEY
gpg: issuer "network-flow-monitor-agent@amazon.com"
gpg: Good signature from "Network Flow Monitor Agent " [unknown]
gpg: WARNING: Using untrusted key!
```
If the output includes the phrase `BAD signature`, check to make sure that you performed the procedure correctly. If you continue to get this response, contact [AWS Support](https://aws.amazon.com/premiumsupport/) and avoid using the downloaded file.
Note the warning about trust. A key is trusted only if you or someone who you trust has signed it. This doesn't mean that the signature is invalid, only that you have not verified the public key.
Next, follow the steps here to verify the RPM package.
**To verify the signature of the RPM package**
1. Copy the following public key and save it to a file named `nfm-agent.gpg`.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGf0b5IBEAC6YQc0aYrTbcHNWWMbLuqsqfspzWrtCvoU0yQ62ld7nvCGBha9
lu4lbhtiwoDawC3h6Xsxc3Pmm6kbMQfZdbo4Gda4ahf6zDOVI5zVHs3Yu2VXC2AU
5BpKQJmYddTb7dMI3GBgEodJY05NHQhq1Qd2ptdh03rsX+96Fvi4A6t+jsGzMLJU
I+hGEKGif69pJVyptJSibK5bWCDXh3eS/+vB/CbXumAKi0sq4rXv/VPiIhn6bsCI
A2lmzFd3vMJQUM/T7m7skrqetZ4mWHr1LPDFPK/H/81s8TJawx7MACsK6kIRUxu+
oicW8Icmg9S+BpIgONT2+Io5P1tYO5a9AyVF7X7gU0VgHUA1RoLnjHQHXbCmnFtW
cYEuwhUuENMl+tLQCZ+fk0kKjOlIKqeS9AVwhks92oETh8wpTwTE+DTBvUBP9aHo
S39RTiJCnUmA6ZCehepgpwW9AYCc1lHv/xcahD418E0UHV22qIw943EwAkzMDA4Q
damdRm0Nud0OmilCjo9oogEB+NUoy//5XgQMH1hhfsHquVLU/tneYexXYMfo/Iu5
TKyWL2KdkjKKP/dMR4lMAXYi0RjTJJ5tg5w/VrHhrHePFfKdYsgN6pihWwj2Px/M
ids3W1Ce50LOEBc2MOKXYXGd9OZWyR8l15ZGkySvLqVlRGwDwKGMC/nS2wARAQAB
tEJOZXR3b3JrIEZsb3cgTW9uaXRvciBBZ2VudCA8bmV0d29yay1mbG93LW1vbml0
b3ItYWdlbnRAYW1hem9uLmNvbT6JAlcEEwEIAEEWIQR2c2ypl63T6dJ3JqjvvaTM
vJX60QUCZ/RvkgIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAK
CRDvvaTMvJX60euSD/9cIu2BDL4+MFFHhyHmG3/se8+3ibW0g8SyP3hsnq7qN+bm
ZzLAhll7DVoveNmEHI1VC7Qjwb30exgLcyK2Ld6uN6lwjjK0qiGGz943t230pJ3z
u7V2fVtAN+vgDVmD7agE6iqrRCWu3WfcgzFlEkE/7nkhtbWzlaK+NkdEBzNZ+W7/
FmLClzIbMjIBW2M8LdeZdQX0SWljy18x7NGNukWeNTJxmkDsjAeKl+zkXYk9h7ay
n3AVl1KrLZ5P9vQ5XsV5e4T6qfQ3XNY1lm54cpa+eD7NyYcTGRDK+vIxO4xD8i2M
yl1iNf2+84Tt6/SAgR/P9SJ5tbKD0iU9n4g1eBJVGmHDuXTtDR4H/Ur7xRSxtuMl
yZP/sLWm8p7+Ic7aQJ5OVw36MC7Oa7/K/zQEnLFFPmgBwGGiNiw5cUSyCBHNvmtv
FK0Q2XMXtBEBU9f44FMyzNJqVdPywg8Y6xE4wc/68uy7G6PyqoxDSP2ye/p+i7oi
OoA+OgifchZfDVhe5Ie0zKR0/nMEKTBV0ecjglb/WhVezEJgUFsQcjfOXNUBesJW
a9kDGcs3jIAchzxhzp/ViUBmTg6SoGKh3t+3uG/RK2ougRObJMW3G+DI7xWyY+3f
7YsLm0eDd3dAZG3PdltMGp0hKTdslvpws9qoY8kyR0Fau4l222JvYP27BK44qg==
=INr5
-----END PGP PUBLIC KEY BLOCK-----
```
1. Import the public key into your keyring.
```
PS> rpm --import nfm-agent.gpg
```
1. Verify the installer package signature. Be sure to replace the `agent-download-filename` with the value that you specified when you downloaded the agent, as shown in the table earlier in this topic.
```
PS> rpm --checksig agent-download-filename
```
For example, for the x86\$164 architecture on Amazon Linux 2023, use the following command:
```
PS> rpm --checksig network-flow-monitor-agent.rpm
```
This command returns output similar to the following.
```
network-flow-monitor-agent.rpm: digests signatures OK
```
If the output contains the phrase `NOT OK (MISSING KEYS: (MD5) key-id)`, check to make sure that you performed the procedure correctly. If you continue to get this response, contact [AWS Support](https://aws.amazon.com/premiumsupport/) and don't install the agent.
# Install agents for self-managed Kubernetes instances
Follow the steps in this section to install Network Flow Monitor agents for workloads on self-managed Kubernetes clusters. After you complete the steps, Network Flow Monitor agent pods will be running on all of your self-managed Kubernetes cluster nodes.
If you use Amazon Elastic Kubernetes Service (Amazon EKS), the installation steps to follow are in the following section: [Install the EKS AWS Network Flow Monitor Agent add-on](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md).
**Topics**
+ [Before you begin](CloudWatch-NetworkFlowMonitor-agents-kubernetes-before-you-begin.md)
+ [Download Helm charts and install agents](CloudWatch-NetworkFlowMonitor-agents-kubernetes-install-agents.md)
+ [Configure permissions for agents to deliver metrics](CloudWatch-NetworkFlowMonitor-agents-kubernetes-permissions.md)
# Before you begin
Before you start the installation process, follow the steps in this section to make sure that your environment is set up to successfully install agents on the right Kubernetes clusters.
**Ensure that your version of Kubernetes is supported**
Network Flow Monitor agent installation requires Kubernetes Version 1.25, or a more recent version.
**Ensure that you have installed required tools**
The scripts that you use for this installation process require that you install the following tools. If you don’t have the tools installed already, see the provided links for more information.
+ The AWS Command Line Interface (CLI). For more information, see [Installing or updating to the latest version of the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) in the AWS Command Line Interface Reference Guide.
+ The Helm package manager. For more information, see [Installing Helm](https://helm.sh/docs/intro/install/) on the Helm website.
+ The `kubectl` command line tool. For more information, see [Install kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) on the Kubernetes website.
+ The `make` Linux command dependency. For more information, see the following blog post: [ Intro to make Linux Command: Installation and Usage](https://ioflood.com/blog/install-make-command-linux/). For example, do one of the following:
+ For Debian based distributions, such as Ubuntu, use the following command: `sudo apt-get install make`
+ For RPM-based distributions, such as CentOS, use the following command: `sudo yum install make`
**Ensure that you have valid, correctly configured KubeConfig environment variables**
Network Flow Monitor agent installation uses the Helm package manager tool, which uses the kubeconfig variable, `$HELM_KUBECONTEXT`, to determine the target Kubernetes clusters to work with. Also, be aware that when Helm runs installation scripts, by default, it references the standard `~/.kube/config` file. You can change the configuration environment variables, to use a different config file (by updating `$KUBECONFIG`) or to define the target cluster you want to work with (by updating `$HELM_KUBECONTEXT`).
**Create a Network Flow Monitor Kubernetes namespace**
The Network Flow Monitor agent's Kubernetes application installs its resources into a specific namespace. The namespace must exist for the installation to succeed. To ensure that the required namespace is in place, you can do one of the following:
+ Create the default namespace, `amazon-network-flow-monitor`, before you begin.
+ Create a different namespace, and then define it in the `$NAMESPACE` environment variable when you run the installation to make targets.
# Download Helm charts and install agents
You can download the Network Flow Monitor agent Helm charts from the AWS public repository by using the following command. Make sure that you first authenticate with your GitHub account.
`git clone https://github.com/aws/network-flow-monitor-agent.git`
In the `./charts/amazon-network-flow-monitor-agent` directory, you can find the Network Flow Monitor agent Helm charts and Makefile that contain the installation make targets that you use for installing agents. You install agents for Network Flow Monitor by using the following Makefile target: `helm/install/customer`
You can customize the installation if you like, for example, by doing the following:
```
# Overwrite the kubeconfig files to use
KUBECONFIG= make helm/install/customer
# Overwrite the Kubernetes namespace to use
NAMESPACE= make helm/install/customer
```
To verify that the Kubernetes application pods for the Network Flow Monitor agents have been created and deployed successfully, check to be sure that their state is `Running`. You can check state of the agents by running the following command: `kubectl get pods -o wide -A | grep amazon-network-flow-monitor`
# Configure permissions for agents to deliver metrics
After you install agents for Network Flow Monitor, you must enable the agents to send network metrics to the Network Flow Monitor ingestion APIs. Agents in Network Flow Monitor must have permission to access the Network Flow Monitor ingestion APIs so that they can deliver network flow metrics that they've collected for each instance. You grant this access by implementing IAM roles for service accounts (IRSA).
To enable agents to deliver network metrics to Network Flow Monitor, follow the steps in this section.
1. **Implement IAM roles for service accounts**
IAM roles for service accounts provides the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Implementing IRSA is the recommended way to provide all permissions required by Network Flow Monitor agents to successfully access Network Flow Monitor ingestion APIs. For more information, see [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) in the Amazon EKS User Guide.
When you set up IRSA for Network Flow Monitor agents, use the following information:
+ **ServiceAccount: **When you define your IAM role trust policy, for `ServiceAccount`, specify `aws-network-flow-monitor-agent-service-account`.
+ **Namespace: **For the `namespace`, specify `amazon-network-flow-monitor`.
+ **Temporary credentials deployment: **When you configure permissions after you have deployed Network Flow Monitor agent pods, updating the `ServiceAccount` with your IAM role, Kubernetes does not deploy the IAM role credentials. To ensure that the Network Flow Monitor agents acquire the IAM role credentials that you've specified, you must rolling out a restart of `DaemonSet`. For example, use a command like the following:
`kubectl rollout restart daemonset -n amazon-network-flow-monitor aws-network-flow-monitor-agent`
1. **Confirm that the Network Flow Monitor agent is successfully accessing the Network Flow Monitor ingestion APIs**
You can check to make sure that your configuration for agents is working correctly by using the HTTP 200 logs for Network Flow Monitor agent pods. First, search for a Network Flow Monitor agent pod, and then search through the log files to find successful HTTP 200 requests. For example, you can do the following:
1. Locate a Network Flow Monitor agent pod name. For example, you can use the following command:
```
RANDOM_AGENT_POD_NAME=$(kubectl get pods -o wide -A | grep amazon-network-flow-monitor | grep Running | head -n 1 | tr -s ' ' | cut -d " " -f 2)
```
1. Grep all the HTTP logs for the pod name that you've located. If you've changed the NAMESPACE, make sure that you use the new one.
```
NAMESPACE=amazon-network-flow-monitor
kubectl logs $RANDOM_AGENT_POD_NAME -\-namespace ${NAMESPACE} | grep HTTP
```
If access has been granted successfully, you should see log entries similar to the following:
```
...
{"level":"INFO","message":"HTTP request complete","status":200,"target":"amzn_nefmon::reports::publisher_endpoint","timestamp":1737027525679}
{"level":"INFO","message":"HTTP request complete","status":200,"target":"amzn_nefmon::reports::publisher_endpoint","timestamp":1737027552827}
```
Note that the Network Flow Monitor agent publishes network flow reports every 30 seconds, by calling the Network Flow Monitor ingestion APIs.
# Initialize Network Flow Monitor
Before you can view performance metrics for network flows, you must initialize Network Flow Monitor, which grants required permissions and creates an initial topology for your account or accounts. If you plan to monitor resources for multiple accounts, you must also configure AWS Organizations with Amazon CloudWatch. Then, you specify accounts for your Network Flow Monitor scope, so that Network Flow Monitor can create an initial topology for all the accounts that you'll be tracking performance metrics for.
In addition, you must install agents on your instances, to send performance metrics to the Network Flow Monitor ingestion server. For more information, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
The steps that you take to initialize Network Flow Monitor vary depending on whether you are measuring performance metrics for resources in a single account, or you want to monitor metrics from resources that are owned by multiple accounts in your organization.
+ [Single account monitoring initialization](CloudWatch-NetworkFlowMonitor-single-account.md)
+ [Multi-account monitoring initialization](CloudWatch-NetworkFlowMonitor-multi-account.md)
# Initialize Network Flow Monitor for single account monitoring
To initialize Network Flow Monitor to monitor network performance metrics, you must grant permissions and Network Flow Monitor must create the initial topology for your account. When you monitor resources in just one account, Network Flow Monitor sets your account as the scope for network monitoring and creates a topology for that scope.
Initializing Network Flow Monitor does the following:
+ Grants permissions for Network Flow Monitor to use required service-linked roles with your account. Network Flow Monitor requires you to grant it specific permissions so that the feature can send metrics to Amazon CloudWatch on your behalf, as well as create topologies of network flows. For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
+ Sets your monitoring scope for Network Flow Monitor to the AWS account that you're signed in with. For more information, see **Scope** in [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
+ Creates an initial topology for your scope.
To initialize Network Flow Monitor by setting up the service-linked roles that provide the required permissions, setting the scope to your account, and creating a topology for network flow performance monitoring, follow these steps.
**To initialize Network Flow Monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. In the **Getting started with Network Flow Monitor** section, under Step 1, choose **Start initialization**.
1. On the **Configure Network Flow Monitor** page, scroll down, and then choose **Initialize Network Flow Monitor**.
Completing the initialization can take 20-30 minutes.
After you initialize Network Flow Monitor for your account, before you can view network flow performance metrics, you must also install Network Flow Monitor agents for your resources that send performance metrics to the Network Flow Monitor backed ingestion server. For more information, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
# Initialize Network Flow Monitor for multi-account monitoring
If you want to monitor network flows in Network Flow Monitor for resources that are owned by different accounts, you must first configure Amazon CloudWatch with AWS Organizations. To use multiple accounts in Network Flow Monitor, you're required to turn on trusted access for CloudWatch, and it's a best practice to also register a delegated administrator.
In addition, if you plan to create monitors for network flows from the console, you must add a Network Flow Monitor policy to the role that is attached to your resources. The policy enables you to view resources from other accounts in the console, so that you can add the resources in multiple accounts to a monitor.
To monitor network flows for resources that are owned by different accounts, there are additional configuration steps to take. First, as the management account, you must configure CloudWatch with AWS Organizations to turn on trusted access, and, typically, you'll also register a delegated administrator account. Then, using the delegated administrator account, you can add more accounts in your organization, to set the scope for your network observability to include resources in those accounts. (You can also add multiple accounts with a management account, but it's a best practice in Organizations to use the delegated administrator account when you work with resources in a service. We provide steps that follow that guidance in the instructions here for Network Flow Monitor.)
Note that if you don’t need to monitor network flows for instances from multiple accounts, you can use Network Flow Monitor with a single account. The scope for Network Flow Monitor is automatically set to the AWS account that you sign in with.
Use the guidance in the following sections to complete these steps.
**Topics**
+ [Multi-account setup overview](#CloudWatch-NetworkFlowMonitor-multi-account.overview)
+ [Configure AWS Organizations](#CloudWatch-NetworkFlowMonitor-multi-account.config-orgs)
+ [Add multiple accounts](#CloudWatch-NetworkFlowMonitor-multi-account.config-scope)
+ [Add permissions for the console](#CloudWatch-NetworkFlowMonitor-multi-account.console-perms)
## Overview of steps for using multiple accounts in Network Flow Monitor
To get started with Network Flow Monitor, any account that has not used Network Flow Monitor before must initialize Network Flow Monitor. When you initialize Network Flow Monitor for an account, Network Flow Monitor adds the required service-linked role permissions and creates a scope of the account or accounts to be included in network observability. To work with multiple accounts in Network Flow Monitor, there are additional steps, to integrate with AWS Organizations, and then add the accounts to work with.
In summary, you take the following steps:
1. Sign in to the AWS Management Console as the management account, and then do the following:
+ Complete the required steps for integrating with AWS Organizations in CloudWatch.
1. Sign in to the AWS Management Console as the delegated administrator account, and then do the following:
+ Initialize Network Flow Monitor, including adding accounts to include in your scope.
+ Add the required permissions for accessing resources that are in other accounts from the console.
If you're setting up Network Flow Monitor to work with multiple accounts and you’re not familiar with AWS Organizations, review the following resources to learn about concepts such as the management account, trusted access, and the delegated administrator account, and to learn how to integrate Organizations with CloudWatch.
+ [Managing accounts in an organization with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html) in the AWS Organizations User Guide.
+ [Amazon CloudWatch and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudwatch.html) in the AWS Organizations User Guide.
Follow the steps in the following sections for specific guidance in configuring Network Flow Monitor for multiple accounts.
## Configure AWS Organizations in CloudWatch
To configure Network Flow Monitor with AWS Organizations, sign in to the management account, and turn on trusted access for CloudWatch. Then, register a delegated administrator account to use for initializing Network Flow Monitor and adding multiple accounts.
If you’ve already configured Organizations in CloudWatch to turn on trusted access for Organizations in CloudWatch and register a delegated administrator account, you don’t need to configure anything more for Organizations that is specific to Network Flow Monitor. You can sign in with the delegated administrator account for CloudWatch, and then initialize Network Flow Monitor, including adding multiple accounts for your network observability scope.
If you haven’t yet configured Organizations in CloudWatch, follow the steps here to turn on trusted access and register a delegated administrator account.
### Turn on trusted access in CloudWatch
Before you can use Network Flow Monitor with more than one account in your organization, you must turn on trusted access for AWS Organizations in Amazon CloudWatch. Use the following steps to turn on trusted access in the CloudWatch console.
**To turn on trusted access**
1. Sign in to the console with your organization’s management account.
1. In the CloudWatch console, in the navigation pane, choose **Settings**.
1. Choose the **Organizations** tab.
1. In **Organizational Management Settings**, choose **Turn on**. The **Enable trusted access** page appears.
1. To review the role policy, choose **View permission** details to see the role policy.
1. Choose **Enable trusted access**.
Now, as CloudWatch discovers resources, it automatically updates information about accounts that you have permission to access the resources for in Network Flow Monitor.
### Register a delegated administrator account
As a best practice with AWS Organizations, the management account for your organization should register a member account as a delegated administrator account for CloudWatch. After you register a delegated administrator account in CloudWatch, members of your organization can sign in with the delegated administrator account to monitor the network performance for resources in multiple accounts in Network Flow Monitor.
Using the delegated administrator account, you can add multiple accounts for your network observability scope in Network Flow Monitor. Although the management account can also create a scope that includes multiple accounts, we recommend that you follow the best practices for AWS Organizations and use a delegated administrator account for adding multiple accounts in Network Flow Monitor. For member accounts that are not the delegated administrator account, the scope is limited to the signed-in account, which is automatically set for the scope.
A delegated administrator account for Organizations is a member account that shares administrator access for service-managed permissions. The account that you choose to register as a delegated administrator account must be a member account in your organization. A delegated administrator account for your organization can be used outside of CloudWatch, so make sure that you understand this account type before following this procedure. For more information, see [Amazon CloudWatch and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudwatch.html) in the AWS Organizations User Guide.
**To register a delegated administrator account**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Organization** tab.
1. Choose **Register delegated administrator**.
1. In the **Register delegated administrator** window, in the **Delegated administrator account ID** field, enter the 12-digit Organization member account ID.
1. Choose **Register delegated administrator**. At the top of the page, a message appears indicating the account was registered successfully. The **Organization Settings** page appears. To see information about the delegated administrator account, hover over the number below **Delegated administrators**.
To remove or change the delegated administrator account, deregister the account first. For more information, see [ Deregistering a delegated administrator account](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/telemetry-config-turn-on.html#telemetry-config-deregister-administrator).
## Add multiple accounts to your scope
To add accounts to your Network Flow Monitor scope, sign in with the delegated administrator account. (You can add accounts to a scope if you're signed in with the management account, but it's a best practice in AWS Organizations to use the delegated administrator account to work with resources.)
After you sign in, follow the steps to initialize Network Flow Monitor, a process which authorizes the required service-linked role permissions, lets you set the scope for your network observability by adding accounts, and then creates an initial topology for the accounts in the scope you've set. The account that you sign in with—in this case, the delegated administrator account—is automatically included in your Network Flow Monitor scope.
**To initialize Network Flow Monitor with multiple accounts in your scope**
1. Sign in to the console with your organization’s delegated administrator account.
1. In the navigation pane for the CloudWatch console, under **Network Monitoring**, choose **Flow monitors**.
1. Under **Getting started with Network Flow Monitor**, in Step 1, choose **Start initialization**.
1. On the **Network Flow Monitor** page, under **Add accounts**, choose **Add**. The account that you're signed in with is automatically included in the scope and already appears in the **Accounts in scope** table as **(this account)**.
1. On the **Add accounts** dialog page, optionally filter the accounts, and then select up to 99 additional accounts to add to your scope. The maximum number of accounts in a scope is 100.
1. Choose **Add**.
1. Choose **Initialize Network Flow Monitor**. Network Flow Monitor adds the required service-linked role permissions, creates a scope that includes all the accounts you specified, and then creates an initial topology of the resources in the accounts in your scope.
To add or remove accounts for your scope after you've already initialized Network Flow Monitor, follow the steps here.
Be aware that after you make a change to your scope, either to add or delete accounts, you must wait about 20 minutes before you can make another change to the scope. This delay is because Network Flow Monitor requires a brief period of time to update its topology information.
**To add or remove accounts for your scope**
1. Sign in to the console with your organization’s delegated administrator account.
1. In the navigation pane for the CloudWatch console, under **Network Monitoring**, choose **Flow monitors**.
1. Under **Monitors**, select a monitor.
1. On the **Monitor details** tab, under **Accounts in scope**, choose **Add** or **Delete**.
1. Select accounts to add to your scope, up to a total of 100 accounts, or select accounts to delete.
1. Complete the steps in the confirmation dialog.
## Set up permissions for multi-account resource access (console only)
If you plan to create monitors for network flows from the console, a specific policy is required for each member account in your scope. This policy enables you to view resources from other accounts when you add local and remote resources to a monitor.
For each of the account in your scope, create a role, **NetworkFlowMonitorAccountResourceAccess**, and attach the **AmazonEC2ReadOnlyAccess** policy. To see permission details for the policy, see [ AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html) in the AWS Managed Policy Reference Guide.
This policy is in addition to the policy that you must add to each instance so that the Network Flow Monitor agent can send performance metrics from the instance to the Network Flow Monitor ingestion backend server. For more information about requirements for agents, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
The following procedure provides a summary of the steps to create the required role for accessing resources in your scope in the Network Flow Monitor console. For general guidance on how to create a role in IAM, see [Create a role to give permissions to an IAM user ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the AWS Identity and Access Management User Guide.
**To create a role for resource access in the Network Flow Monitor console**
1. Sign in to the AWS Management Console and open the IAM console.
1. In the navigation pane of the console, choose **Roles**, and then choose **Create role**.
1. Specify the **AWS account** trusted entity. This trusted entity type enables principals in other AWS accounts to assume the role and access resources in other accounts.
1. Choose **Next**.
1. In the list of AWS managed policies, choose the **AmazonEC2ReadOnlyAccess** policy.
1. Choose **Next**.
1. For role name, enter **NetworkFlowMonitorAccountResourceAccess**.
1. Review the role, and then choose **Create role**.
## Install agents on instances
To track network performance with Network Flow Monitor, you must initialize the service, but you must also install Network Flow Monitor agents on your workload's EC2 instances and add permissions for the agents to send networking performance metrics to Network Flow Monitor. After you install the agents, wait a short period of time (about 20 minutes), for data to begin being sent to the Network Flow Monitor backend. Then, you can view network performance metrics, on the **Workload insights** tab, and also create monitors, to view detailed information.
For example, you can view the top contributor performance metrics for data transferred and retransmission timeouts, for network flows between your local and remote resources, collected by Network Flow Monitor agents. By viewing and analyzing these metrics, you can choose specific flows that you want to see more details for and track more closely with a monitor. By creating a monitor for specific flows, you can see detailed information about them, including metrics, sorted by the top contributors for each metric type and network paths for each network flow.
With a monitor, Network Flow Monitor also provides a network health indicator (NHI), which you can use to see if there have been AWS network impairments for network flows that you're tracking in the monitor, during a time period that you've selected. That information can help you decide where to focus your network troubleshooting efforts.
For more information, and instructions for how to install agents, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
# Monitor and analyze network flows in Network Flow Monitor
With Network Flow Monitor, you can learn about network flows and performance for traffic that you're monitoring with your scope. Start by reviewing top contributors information, by each metric type, in the **Workload insights** tab. Then, create monitors so that you can explore network performance in detail, over different time frames, for network flows that you select in **Workload insights**.
After you initialize Network Flow Monitor and install agents on your instances, Network Flow Monitor generates performance metrics for the network flows from those instances. Review the sections in this chapter to learn more about how to use Network Flow Monitor to evaluate network performance in Network Flow Monitor, create monitors for more in-depth information, and learn about the specific metrics provided by Network Flow Monitor.
The steps provided in these sections use the AWS Management Console. You can also use Network Flow Monitor API operations with the AWS Command Line Interface (AWS CLI) or AWS SDKs to review workload insights and top contributors metrics, and to create and configure a monitor. For more information, see the following resources:
+ If you plan to work with Network Flow Monitor with the CLI, see [Examples of using the CLI with Network Flow Monitor](CloudWatch-NFM-get-started-CLI.md).
+ For detailed information about working with Network Flow Monitor API operations, see the [ Network Flow Monitor API Reference Guide](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/Welcome.html).
**Topics**
+ [Evaluate network flows](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md)
+ [Create and work with monitors](CloudWatch-NetworkFlowMonitor-configure-monitors.md)
+ [Monitor and analyze](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md)
+ [Delete scope](CloudWatch-NetworkFlowMonitor-disable.md)
# Evaluate network flows with workload insights
Network Flow Monitor provides workload insights about the network flows in the scope that you enable monitoring for. By surfacing top contributor network flows for each metric type, you can see which flows are potentially experiencing issues. You can view these top contributor metrics in the console on the **Workload insights** tab. In Network Flow Monitor, top contributors are network flows that have the highest values for each network performance metric.
**Top contributors**
On the **Workload insights** page in the Network Flow Monitor console, Network Flow Monitor displays the top contributor network performance statistics for the network flows between all the resources in your monitoring scope where you've deployed agents.
To compile lists of top contributors, Network Flow Monitor determines the network flows in your scope that have the highest values for retransmissions, retransmission timeouts, and data transferred. These network flows are the *top contributors* for each metric type.
For workload insights, the top contributors are determined for all the network flows that you're receiving performance information for; that is, network flows for all of the resources in your scope with Network Flow Monitor agents installed.
**Network flow classifications**
Network Flow Monitor classifies metrics into designated local-remote categories. Metrics are grouped into two types of flows:
+ **Network Health Indicator (NHI) Flows:** Flows which contribute to Network Health Indicator (NHI) calculations:
+ Between AZs (`INTER_AZ`). Always within the same VPC.
+ Within AZs (`INTRA_AZ`). Always within the same VPC.
+ Between VPCs (`INTER_VPC`). Crosses the boundary between VPCs.
+ Between Regions (`INTER_REGION`). This means performance for network flows between resources in your Region and the edge of another Region.
+ Toward Amazon S3 buckets (`AMAZON_S3`)
+ Toward Amazon DynamoDB (`AMAZON_DYNAMODB`)
+ **Non Network Health Indicator (NHI) Flows:** Flows which do not contribute to Network Health Indicator (NHI) calcuations:
+ Toward the Internet (`INTERNET`). Flows that traverse an Internet Gateway and end on the public Internet.
+ Towards AWS Services (`AWS_SERVICE`). Flows that end at an AWS service that is not fully monitored (like CloudFront or API Gateway).
+ Towards a Transit Gateway (`TRANSIT_GATEWAY`). Flows in this classification are flows that arrive at a Transit Gateway, but the final destination of the flow is unknown.
+ Towards a local zone (`LOCAL_ZONE`). Flows that start or end in a local zone
+ Any other flow that cannot be otherwise classified (`UNCLASSIFIED`).
**Performance metrics**
Performance metrics on **Workload insights** are shown in separate tables for the following metric type: Retransmissions, retransmission timeouts, and data transferred. The data provided is for the top contributors for each type. Note that after you first install Network Flow Monitor agents, there is a waiting period (about 20 minutes) before you can view performance metrics, while agents gather and send data to the Network Flow Monitor backend.
**Monitor specific network flows**
As you review performance metrics, when you see specific resources or network flows that you want to explore more details for, you can create a monitor that includes just those flows.
With a monitor, you can track specific groups of network flows over a period of time, to gain insights into one aspect of your workload. You can also get helpful troubleshooting information, such as checking the network health indicator (NHI) to see if issues you see are caused by AWS impairments.
For more information, see [Create and work with monitors in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors.md)
**Multi-account coverage**
To work with multiple accounts in Network Flow Monitor, you must configure AWS Organizations integration with CloudWatch. By configuring Organizations, you can add accounts to the scope for your Network Flow Monitor coverage. Then, if you have multiple accounts in your scope that each have resources that you want to monitor network flows between, you can specify a scope that includes all of the accounts, and then view performance metrics gathered by the Network Flow Monitor agents that you've installed on your resources. For more information, see [Initialize Network Flow Monitor for multi-account monitoring](CloudWatch-NetworkFlowMonitor-multi-account.md).
# Create and work with monitors in Network Flow Monitor
You create a monitor to see details about the network performance for one or several network flows for a workload. For each monitor, Network Flow Monitor publishes end-to-end performance metrics and a network health indicator (NHI), and generates network paths of individual network flows. After you create a monitor, you can view information provided by the monitor in the console on the **Monitors** tab.
Flow monitors can help you to assess network performance issues that are impacting your workloads, including impairments within an AWS Region and issues on the AWS global network between a local and a remote Region. The network health indicator (NHI) provided by the monitor also captures the health of the AWS global network on your workload’s network paths between Regions. This helps you to quickly identify whether impairments in a local Region, in the AWS global network, or in the remote Region are affecting your workloads.
For remote Regions, monitors can provide network visibility for flows to the Region’s public IP address, and for private traffic flowing to a remote Region over VPC peering or Transit Gateway peering.
After you create a monitor, you can edit the monitor to make changes (except change the monitor name) or delete the monitor, at any time.
The following sections includes procedures for creating, editing, and deleting monitors in the Network Flow Monitor console.
**Topics**
+ [Create a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md)
+ [Edit a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md)
+ [Delete a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md)
# Create a monitor in Network Flow Monitor
As you review top contributors in the **Workload insights** tab, if you see one or several network flows that you want to follow over time, or that you want more details about, you can create a monitor directly from **Workload insights**. This simplifies the process for creating a monitor for specific network flows.
Or, if you know specific network flows that you want to track with a monitor, such as looking at performance information for all network flows to another AWS Region, you can use the ** Create monitor** wizard to create a monitor from scratch. When you create a monitor this way, you specify all of the local and remote resources that define the network flows that you want to monitor.
For specific procedures, see the following sections:
+ [Create a monitor by specifying network flows](#CloudWatch-NetworkFlowMonitor-configure-monitors-create-workload-insights)
+ [Create a monitor by specifying local and remote resources](#CloudWatch-NetworkFlowMonitor-configure-monitors-create-standalone)
## Create a monitor by specifying network flows
To create a monitor by selecting network flows, start on the **Workload insights** tab. Select one or more network flows in one of the tables, in a single Region, and then, choose to create a monitor with those flows.
When you create a monitor in this way, the **Create monitor** wizard pre-populates local and remote resources for you and displays them in a modal dialog. You can choose to create a monitor with those resources, or edit the selection of local or remote resources to add or remove resources to include.
By reviewing the top contributors on **Workload insights** on an ongoing basis, you can regularly evaluate if you have the monitors that you need, or if creating new monitors would be helpful.
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To create a monitor from **Workload insights****
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. Choose **Workload insights**.
1. In one of the **Top contributors** tables, select one or more network flows and then choose **Create monitor**.
1. In the modal window that opens, you can edit the resources that define the network flows that you chose, or choose **Create monitor**.
## Create a monitor by specifying local and remote resources
You can create a monitor at any time for specific local and remote resources that define network flows that you want to see details for.
For example, you might want to create a monitor for one of the following scenarios:
+ A monitor that includes network flows for a specific VPC in a local Region to another VPC in the same Region. (Note that you can't select a specific resource, such as a VPC, as a network flow endpoint - that is, the remote resource - in another Region.)
+ For local resource, choose **Specific resources in *Region***. Then, choose **VPC and subnets**, and then, in the table, select a specific VPC.
+ For remote resource, do the same: choose **Specific resources in *Region***, then, choose **VPC and subnets**, and finally, select a specific VPC.
+ A monitor that includes all network flows from your workload in a local Region to a specific Availability Zone.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Availability Zone**, and then choose a specific AZ
+ A monitor that includes all network flows for your workload within a local Region.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Everywhere in *Region***
+ A monitor that includes all network flows for your workload from a local Region to the edge of another Region.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Another Region**, and then choose the remote Region
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To create a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. From the Network Flow Monitor page, select the **Monitors** tab, and then choose **Create monitor**.
1. For **Monitor name**, enter the name that you want to use for the monitor. You can't change this name later.
1. Choose **Next**.
1. Select the local resources (one or more) for the network flows that you want to monitor.
+ To monitor network flows from all resources in your Region, choose **Everywhere in *Region***.
+ To choose specific local resources to monitor flows from, choose **Specific resources in *Region***. Then, under **Add resources**, choose **Availability Zones**, **EKS clusters**, or **VPCs and subnets**, and then choose resources to add.
1. Choose **Next**.
1. Select the remote resources (one or more) for the network flows that you want to monitor.
+ To monitor network flows to all resources in your Region, choose **Everywhere in *Region***.
+ To monitor flows from specific remote resources, choose **Specific resources in *Region***. Under **Add resources**, select **VPCs and subnets**, **Availability Zones**, or **AWS services**, and then choose the resources to add.
+ To monitor network flows to the edge of another Region, choose ** Another Region**.
1. Choose **Next**.
1. Review your choices to confirm the network flows to monitor, or edit the options to make changes.
1. Choose **Create monitor**.
After you create a monitor, you can edit or delete the monitor at any time to add or remove network flows. Select a monitor, and then choose **Edit** or **Delete**. Note that you can't change the name of a monitor.
**To view the Network Flow Monitor dashboard**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Network monitoring**, then **Flow monitors**.
The **Monitors** tab displays a list of the monitors that you have created.
To see more information about a specific monitor, choose a monitor.
# Edit a monitor in Network Flow Monitor
You can edit a monitor at any time, to add or remove network flows.
Note that you can't change the name of a monitor after you create it.
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To edit a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Monitors** tab, select a monitor, and then under the **Actions** menu, choose **Edit**.
1. Select the local or remote resources that you want add or remove for the monitor. If you have multiple accounts in your scope, specify the account where the resources are located, and then choose resources.
1. When you're finished updating the monitor, choose **Next**, to review and confirm the network flows to monitor.
1. Choose **Save monitor**.
# Delete a monitor in Network Flow Monitor
To delete a monitor in Network Flow Monitor, follow the steps here.
**To delete a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Monitors** tab, select a monitor, and then under the **Actions** menu, choose **Delete**.
1. In the dialog that appears, enter confirmation text, and then choose **Delete**.
# Monitor and analyze network flows with a Network Flow Monitor monitor
Network Flow Monitor data and graphs help you to visualize and track network issues. You can create monitors to see detailed information about specific network segments for your AWS workloads, including a view of the network path for individual network flows. After you create one or more monitors in Network Flow Monitor, you can observe performance and metrics, and explore historical data, to find anomalies.
To see the information provided by a monitor, on the **Monitors** tab, choose a monitor in the **Monitors** table. Then, choose one of the following tabs for more information: **Overview**, **Historical explorer**, or **Monitor details**.
**Overview tab**
On the **Overview** tab, you can review the following, for time periods that you specify. To see a broader or narrower range of historical information, including the NHI and traffic summary data, adjust the time period selection at the top of the page.
+ **Network health indicator (NHI):** NHI alerts you to whether there there were AWS network issues for one or more of the network flows tracked by your monitor, during the time frame that you've selected for viewing performance metrics. NHI is a binary value, that is, 1 or 0, which is shown in the console as **Degraded** or **Healthy**.
+ NHI is shown as **Degraded** if there were issues with the portion of the AWS network that any network flow in the monitor traversed, at any time during the time frame that you select.
+ Otherwise, NHI is shown as **Healthy**.
If the NHI is **Degraded**, you can view the **Network health indicator** bar graph for more information. The graph shows you when, during the selected time frame, there were AWS network issues for the network flows tracked by your monitor.
+ **Traffic summary:** Observe overall metrics for the flows tracked by this monitor, for the time period that you've selected. You can see average round-trip time, sums (totals) of transmission timeouts and retransmissions, and the average amount of data transferred for the flows in the monitor. Be aware that RTT data can be sparse because RTT is not always calculated.
**Historical explorer tab**
On the **Historical explorer** tab, you can dive deep into information about specific flows. You can review metrics and network paths for top contributor network flows for specified time frames. In the tables of metrics, you can filter the data by different categories of flows, such as flows between Availability Zones (`INTER_AZ`).
+ **Metrics:** View detailed information for the top contributors for each metric type that Network Flow Monitor aggregates data for. Separate tables of top contributors are provided for retransmission timeouts, retransmissions, round-trip time, and data transferred.
+ **Network paths:** To get an idea about where anomalies are occurring, you can view the network path of a network flow. When you choose a specific metric in a metrics table, the network path for that flow is displayed below the table.
**Monitor details tab**
On the **Monitor details** tab, you can see details about the monitor, including the monitor state, the ARN, when it was created and last updated, and the flows that are included.
You can choose to edit or delete a monitor from any page on the **Monitors** tab.
As part of your regular use of Network Flow Monitor, we recommend that you periodically review the data on the **Workload insights** page to determine if there are new flows that show metrics anomalies that you want to track more closely over time. When you see a set of flows on the **Workload insights** page that you want to see details about, select the flows and create a monitor for them.
# Delete scope for Network Flow Monitor
If you decide that you no longer want to monitor network flows using Network Flow Monitor, you can delete your Network Flow Monitor scope. When you delete your scope, you can no longer see network performance information.
Before you can delete your scope, you must delete all monitors. Be aware that it can take about 15 minutes to complete removing monitors after you request to delete them. For more information, see [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md).
**To delete your scope**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Settings** tab, choose **Delete scope**.
1. In the dialog box, enter confirmation text, and then choose **Delete scope**.
# View Network Flow Monitor metrics in CloudWatch
Network Flow Monitor publishes the following network flow performance metrics to your account: round-trip time, TCP retransmissions, TCP retransmission timeouts, data transferred, and network health indicator. You can view these metrics in CloudWatch Metrics in the Amazon CloudWatch console.
To find all metrics for your monitor, in the CloudWatch Metrics dashboard, see the custom namespace `AWS/NetworkFlowMonitor`. Metrics are aggregated for each monitor that is deployed and active.
Network Flow Monitor provides the following metrics. Be aware that RoundTripTime data can be sparse, as this metric is not always calculated.
| Metric | Description |
| --- | --- |
| DataTransferred | The number of bytes transferred for all flows for a monitor. |
| Retransmissions | Total number of retransmissions for a monitor. Retransmissions occur when the sender needs to resend packets that have been either damaged or lost. |
| Timeouts | Total retransmission timeouts for a monitor. This occurs when the sender is missing too many acknowledgments, and therefore decides to take a time out and stop sending altogether. |
| RoundTripTime | Average round-trip time for network flows for a monitor. This metric, measured in microseconds, is a measure of performance. It records the time it takes for traffic to be transmitted from a local resource to a remote IP address, and for the associated response to be received. The time is an average over the aggregation period. Data can be sparse, as this metric is not always calculated. |
| HealthIndicator | Network health indicator (NHI) for a monitor overall. Network health indicator (NHI) is a value that surfaces an AWS network impairment. The NHI value is 1 (degraded) if there was an AWS network issue during a specified time frame. It's set to 0 (healthy) if no AWS network issues were detected. Observing the NHI can help you to prioritize troubleshooting for either your workload or the AWS network. |
# Create alarms with Network Flow Monitor
You can create Amazon CloudWatch alarms based on Network Flow Monitor metrics, just as you can for other CloudWatch metrics.
For example, you can create an alarm based on the Network Flow Monitor metric `Retransmissions`, and configure it to send a notification when the metric is higher than a value that you choose. You configure alarms for Network Flow Monitor metrics following the same guidelines as for other CloudWatch metrics.
Following are example Network Flow Monitor metrics that you might choose to create an alarm for:
+ **Retransmissions**
+ **Timeouts**
+ **RoundTripTime**
To see all the metrics available for Network Flow Monitor see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
The following procedure provides an example of setting an alarm on **Retransmissions** by navigating to the metric in the CloudWatch dashboard. Then, you follow the standard CloudWatch steps to create an alarm based on a threshold that you choose, and set up a notification or choose other options.
**To create an alarm for **Retransmissions** in CloudWatch Metrics**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choose **Metrics**, and then choose **All metrics**.
1. Filter for Network Flow Monitor by choosing `AWS/NetworkFlowMonitor`.
1. Choose **MeasurementSource, MonitorName**.
1. In the list, select **Retransmissions**.
1. On the **GraphedMetrics** tab, under **Actions**, choose the bell icon to create an alarm based on a static threshold.
Now, follow the standard CloudWatch steps to choose options for the alarm. For example, you can choose to be notified by an Amazon SNS message if **Retransmissions** is below a specific threshold number. Alternatively, or in addition, you can add the alarm to a dashboard.
Keep in mind the following:
+ Network Flow Monitor metrics are typically aggregated and sent to the Network Flow Monitor backend every 30 seconds, with a 5 second potential jitter (in other words, 25 to 35 seconds).
+ When you create an alarm based on Network Flow Monitor metrics, make sure that you take into account the short delay before publication when you set an alarm’s lookback period. We recommend that you configure **Evaluation Periods** with lookback period that is a minimum of 25 minutes.
For more information about options when you create a CloudWatch alarm, see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
# AWS CloudTrail for Network Flow Monitor
Monitoring a service is an important part of maintaining reliability, availability, and performance. of Network Flow Monitor and your other AWS solutions. *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
For more information about Network Flow Monitor CloudTrail logging, see [Network Flow Monitor in CloudTrail](logging_cw_api_calls.md#CloudWatch-NetworkFlowMonitor-info-in-ct).
# Troubleshoot issues in Network Flow Monitor
This section provides guidance for troubleshooting errors with Network Flow Monitor, including solving issues with installing agents.
## Troubleshoot issues in EKS agents installation
When you try to upgrade the AWS Network Flow Monitor Agent add-on for EKS from v1.0.0 to v1.0.1 in AWS Management Console, you might receive the following error message:
"Service account `aws-network-flow-monitoring-agent-service-account` in pod identity configuration is not supported for addon `aws-network-flow-monitoring-agent`."
This error is returned because a resource was renamed. The EKS add-on v1.0.1 changes the service account name from `aws-network-flow-monitoring-agent-service-account` to `aws-network-flow-monitor-agent-service-account`.
Then, if **Not set** is not selected in the console, the pod identity association is not reset to the new resource name.
To fix this issue, do the following when you upgrade to the new version by using the console:
1. Under **Pod Identity IAM role for service account**, select **Not set**.
1. Select **New version (v1.0.1)**.
1. Select **Upgrade**.
1. Choose **Save changes**.
# Data security and data protection in Network Flow Monitor
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from data centers and network architectures that are built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Network Flow Monitor, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using Network Flow Monitor. The following topics show you how to configure Network Flow Monitor to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Network Flow Monitor resources.
**Topics**
+ [Data protection in Network Flow Monitor](data-protection-nfw.md)
+ [Infrastructure Security in Network Flow Monitor](infrastructure-security-nfw.md)
+ [Identity and Access Management for Network Flow Monitor](CloudWatch-NetworkFlowMonitor-security-iam.md)
# Data protection in Network Flow Monitor
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Network Flow Monitor. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Network Flow Monitor or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Infrastructure Security in Network Flow Monitor
As a managed service, Network Flow Monitor is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper.
You use AWS published API calls to access Network Flow Monitor through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
# Identity and Access Management for Network Flow Monitor
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 Network Flow Monitor resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [How Network Flow Monitor works with IAM](security_iam_service-with-iam-network-flow-monitor.md)
+ [AWS managed policies](security-iam-awsmanpol-network-flow-monitor.md)
+ [Service-linked roles](using-service-linked-roles-network-flow-monitor.md)
# How Network Flow Monitor works with IAM
Before you use IAM to manage access to Network Flow Monitor, learn what IAM features are available to use with Network Flow Monitor.
To see tables showing a similar high-level view of how AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**IAM features you can use with Network Flow Monitor**
| IAM feature | Network Flow Monitor support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies-nfm) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies-nfm) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions-nfm) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources-nfm) | Yes |
| [Policy condition keys (service-specific)](#security_iam_service-with-iam-id-based-policies-conditionkeys-nfm) | Yes |
| [ACLs](#security_iam_service-with-iam-acls-nfm) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags-nfm) | Yes |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds-nfm) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions-nfm) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service-nfm) | No |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked-nfm) | Yes |
## Identity-based policies for Network Flow Monitor
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
## Resource-based policies within Network Flow Monitor
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource.
## Policy actions for Network Flow Monitor
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of Network Flow Monitor actions, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in Network Flow Monitor use the following prefix before the action:
```
networkflowmonitor
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"networkflowmonitor:action1",
"networkflowmonitor:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "networkflowmonitor:Describe*"
```
## Policy resources for Network Flow Monitor
**Supports policy resources:** Yes
In the *Service Authorization Reference*, you can see the following information related to Network Flow Monitor:
+ To see a list of Network Flow Monitor resource types and their ARNs, see [Resources defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-resources-for-iam-policies).
+ To learn the actions that you can specify with the ARN of each resource, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions).
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
## Policy condition keys for Network Flow Monitor
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of Network Flow Monitor condition keys, see [Condition keys for Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions).
## ACLs in Network Flow Monitor
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## ABAC with Network Flow Monitor
**Supports ABAC (tags in policies):** Yes
Network Flow Monitor has *partial* support for tags in policies. It supports tagging for one resource, monitors.
To use tags with Network Flow Monitor, use the AWS Command Line Interface or an AWS SDK. Tagging for Network Flow Monitor is not supported with the AWS Management Console.
To learn more about using tags in policies in general, review the following information.
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using temporary credentials with Network Flow Monitor
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for Network Flow Monitor
**Supports forward access sessions (FAS):** Yes
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Network Flow Monitor
**Supports service roles:** No
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
## Service-linked role for Network Flow Monitor
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For more information about the service-linked role for Network Flow Monitor, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
For details about creating or managing service-linked roles in general in AWS, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# AWS managed policies for Network Flow Monitor
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
## AWS managed policy: CloudWatchNetworkFlowMonitorServiceRolePolicy
You can't attach `CloudWatchNetworkFlowMonitorServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role named **AWSServiceRoleForNetworkFlowMonitor**, which publishes network telemetry aggregation results, collected by Network Flow Monitor agents, to CloudWatch. It also allows the service to use AWS Organizations to get information for multi-account scenarios.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
## AWS managed policy: CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy
You can't attach ` CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role named **AWSServiceRoleForNetworkFlowMonitor\$1Topology**. Using these permissions, as well as internal meta data information gathering (for performance efficiencies), this service-linked role gathers meta data about resource network configurations, such as describing route tables and gateways, for resources that this service monitors network traffic for. This meta data enables Network Flow Monitor to generate topology snapshots of the resources. When there is network degradation, Network Flow Monitor uses the topologies to provide insights into the location of issues in the network and to help determine attribution for issues.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
## AWS managed policy: CloudWatchNetworkFlowMonitorAgentPublishPolicy
You can use this policy in IAM roles that are attached to Amazon EC2 and Amazon EKS instance resources to send telemetry reports (metrics) to a Network Flow Monitor endpoint.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) in the *AWS Managed Policy Reference*.
## Updates to the Network Flow Monitor service-linked roles
For updates to the AWS managed policies for the Network Flow Monitor service-linked roles, see the [AWS managed policies updates table](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates) for CloudWatch. You can also subscribe to automatic RSS alerts on the CloudWatch [Document history page](DocumentHistory.md).
# Service-linked roles for Network Flow Monitor
Network Flow Monitor uses AWS Identity and Access Management (IAM) [ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Network Flow Monitor. The service-linked role is predefined by Network Flow Monitor and includes all the permissions that the service requires to call other AWS services on your behalf.
Network Flow Monitor defines the permissions of the service-linked roles, and unless defined otherwise, only Network Flow Monitor can assume the roles. The defined permissions include the trust policies and the permissions policies, and the permissions policies cannot be attached to any other IAM entity.
You can delete the roles only after first deleting their related resources. This restriction protects your Network Flow Monitor resources because you can't inadvertently remove permissions to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Network Flow Monitor
Network Flow Monitor uses the following service-linked roles:
+ **AWSServiceRoleForNetworkFlowMonitor**
+ **AWSServiceRoleForNetworkFlowMonitor\$1Topology**
### Service-linked role permissions for AWSServiceRoleForNetworkFlowMonitor
Network Flow Monitor uses the service-linked role named **AWSServiceRoleForNetworkFlowMonitor**. This role allows Network Flow Monitor to publish CloudWatch aggregated telemetry metrics gathered for network traffic between instances, and between instances and AWS locations. It also allows the service to use AWS Organizations to get information for multi-account scenarios.
This service-linked role uses the managed policy `CloudWatchNetworkFlowMonitorServiceRolePolicy`.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
The **AWSServiceRoleForNetworkFlowMonitor** service-linked role trusts the following service to assume the role:
+ `networkflowmonitor.amazonaws.com`
### Service-linked role permissions for AWSServiceRoleForNetworkFlowMonitor\$1Topology
Network Flow Monitor uses the service-linked role named **AWSServiceRoleForNetworkFlowMonitor\$1Topology**. This role allows Network Flow Monitor to generate a topology snapshot of the resources that you use with Network Flow Monitor.
This service-linked role uses the managed policy `CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy`.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
The **AWSServiceRoleForNetworkFlowMonitor\$1Topology** service-linked role trusts the following service to assume the role:
+ `topology.networkflowmonitor.amazonaws.com`
## Creating a service-linked role for Network Flow Monitor
You do not need to manually create the service-linked roles for Network Flow Monitor. The first time that you initialize Network Flow Monitor, Network Flow Monitor creates **AWSServiceRoleForNetworkFlowMonitor** and **AWSServiceRoleForNetworkFlowMonitor\$1Topology** for you.
For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*.
## Editing a service-linked role for Network Flow Monitor
After Network Flow Monitor creates a service-linked role in your account, you cannot change the name of the role because various entities might reference the role. You can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Network Flow Monitor
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete the role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for the service-linked role before you can manually delete it.
**Note**
If the Network Flow Monitor service is using the role when you try to delete it, then the deletion might fail. If that happens, wait for a few minutes and then try again.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForNetworkFlowMonitor** or the **AWSServiceRoleForNetworkFlowMonitor\$1Topology** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Updates to the Network Flow Monitor service-linked role
For updates to `CloudWatchNetworkFlowMonitorServiceRolePolicy` or `CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy`, the AWS managed policies for the Network Flow Monitor service-linked roles, see [CloudWatch updates to AWS managed policies](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates). For automatic alerts about managed policy changes in CloudWatch, subscribe to the RSS feed on the CloudWatch [Document history](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) page.
# Using Internet Monitor
Internet Monitor provides visibility into how internet issues impact the performance and availability between your applications hosted on AWS and your end users. It can reduce the time it takes for you to diagnose internet issues from days to minutes. Internet Monitor uses the connectivity data that AWS captures from its global networking footprint to calculate a baseline of performance and availability for internet-facing traffic. This is the same data that AWS uses to monitor internet uptime and availability. With those measurements as a baseline, Internet Monitor raises awareness for you when there are significant problems for your end users (clients) in the different geographic locations where your application runs.
In the Amazon CloudWatch console, you can see a global view of traffic patterns and health events, and easily drill down into information about events, at different geographic granularities (locations). You can clearly visualize impact, and pinpoint the client locations and networks (ASNs, typically internet service providers or ISPs) that are affected. If Internet Monitor determines that an internet availability or performance issue is caused by a specific ASN or by the AWS network, it provides that information.
To get started, create a monitor that includes one or more resources, so Internet Monitor can create a traffic profile for your AWS application. Then, view information in the Internet Monitor dashboard to visualize data and get insights and suggestions about your application's internet traffic.
For information about Regional support, pricing, how Internet Monitor works, and other overview content, see [What is Internet Monitor?](CloudWatch-InternetMonitor.what-is-cwim.md). To begin working with Internet Monitor, see [Getting started with Internet Monitor using the console](CloudWatch-IM-get-started.md).
# What is Internet Monitor?
With Internet Monitor, you can monitor your application's internet performance and availability, so that you can visualize data and get insights and suggestions about your AWS application's internet traffic. You can also get suggestions for ways to reduce latency for your application, by using different Regions or AWS services, like Amazon CloudFront.
**Key features of Internet Monitor**
+ Internet Monitor suggests insights and recommendations that can help you improve your end users' experience. You can explore, in near real-time, how to improve the projected latency of your application by switching to use other services, or by rerouting traffic to your workload through different AWS Regions.
+ Internet Monitor stores internet measurements for pairs of your client locations and ASNs, or *city-networks*. Internet Monitor also creates aggregated CloudWatch metrics for traffic to your application, and to each AWS Region and edge location. With the Internet Monitor dashboard, you can quickly identify what's impacting your application's performance and availability, so that you can track down and address issues.
+ Internet Monitor also publishes internet measurements to CloudWatch Logs and CloudWatch Metrics, to support using CloudWatch tools to explore data for city-networks that are specific to your monitored application traffic. Optionally, you can also publish internet measurements to Amazon S3.
+ Internet Monitor sends overall (global) health events to Amazon EventBridge so that you can set up notifications. (Local health events are not published to EventBridge.) If an issue is caused by the AWS network, you also automatically receive an AWS Health Dashboard notification with the steps that AWS is taking to mitigate the problem.
**How to use Internet Monitor**
To use Internet Monitor, you create a *monitor* and associate your application's resources with it—VPCs, Network Load Balancers, CloudFront distributions, or WorkSpaces directories—to enable Internet Monitor to know where your application's internet-facing traffic is. Internet Monitor then publishes internet measurements from AWS that are specific to the *city-networks*, that is, the client locations and ASNs (typically internet service providers or ISPs), where clients access your application. For more information, see [How Internet Monitor works](CloudWatch-IM-inside-internet-monitor.md). To begin working with Internet Monitor, see [Getting started with Internet Monitor using the console](CloudWatch-IM-get-started.md).
**Topics**
+ [Supported Regions](CloudWatch-InternetMonitor.Regions.md)
+ [Components](CloudWatch-IM-components.md)
+ [How it works](CloudWatch-IM-inside-internet-monitor.md)
+ [Use cases](CloudWatch-IM-use-cases.md)
+ [Internet weather map](CloudWatch-InternetMonitor.outage-map.md)
+ [Cross-account observability](cwim-cross-account.md)
+ [Pricing](CloudWatch-InternetMonitor.pricing.md)
# Supported AWS Regions for Internet Monitor
The AWS Regions and AWS Local Zones where Amazon CloudWatch Internet Monitor is supported are listed in this section. For more information about Regions that Internet Monitor is supported in, including opt-in Regions, see [Amazon CloudWatch Internet Monitor endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cwim_region.html) in the *Amazon Web Services General Reference*.
Note that Internet Monitor stores data for a monitor in only the AWS Region in which you create the monitor, although a monitor can include resources in multiple Regions.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.Regions.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.Regions.html)
For Local Zones support, you must enable the Local Zone and attach it to the VPC that you want to monitor internet traffic for. Internet Monitor does not support Local Zones for other resources types. The Local Zones that are supported are listed in the following table.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.Regions.html)
# Components and terms for Internet Monitor
Internet Monitor uses or references the following concepts.
**Monitor**
A monitor includes the resources for a single application that you want to view internet performance and availability measurements for, and that you want to get health event alerts about. When you create a monitor for an application, you add resources for the application to define the cities (locations) for Internet Monitor to monitor. Internet Monitor uses the traffic patterns from the application resources that you add so that it can publish internet performance and availability measurements specific to just the locations and ASNs (typically, internet service providers or ISPs) that communicate with your application. In other words, the resources that you add create a scope of the *city-networks* that you want Internet Monitor to monitor and that you want it to publish measurements for.
**Resource added to monitor ("monitored resource")**
A resource that you add to a monitor is a "monitored resource" in Internet Monitor. That is:
+ Each VPC that you add in a Region is a monitored resource. When you add a VPC, Internet Monitor monitors the traffic for any internet-facing application in the VPC, for example, an application hosted on an Amazon EC2 instance, behind a Network Load Balancer, or an AWS Fargate container.
+ Each Network Load Balancer that you add in a Region is a monitored resource.
+ Each WorkSpaces directory that you add in a Region is a monitored resource.
+ Each CloudFront distribution that you add is a monitored resource.
**Autonomous System Number (ASN)**
In Internet Monitor, an ASN typically refers to an internet service provider (ISP), such as Verizon or Comcast. An ASN is a network provider that a client uses to access your internet application. An Autonomous System (AS) is a set of internet routable internet protocol (IP) prefixes that belong to a network or a collection of networks that are all managed, controlled, and supervised by one organization.
**City-network (location and ASN)**
A city-network is the location (such as a city) that clients access your application resources from and the ASN, typically an internet service provider (ISP), that clients access the resources through. To help control your bill, you can set a limit for the maximum number of city-networks for Internet Monitor to monitor for each monitor. You pay only for the actual number of city-networks that you monitor, up to the maximum number. For more information, see [Choosing a city-network maximum limit](IMCityNetworksMaximum.md).
**Internet measurements**
Internet Monitor also publishes internet measurements to log files in CloudWatch Logs every five minutes for the top 500 city-networks for your monitored application traffic.
These measurements quantify the performance score, availability score, bytes transferred (bytes in and bytes out), and round-trip time for your application's city-networks. These are measurements for the city-networks specific to your VPCs, Network Load Balancers, CloudFront distributions, or WorkSpaces directories. Optionally, you can choose to publish internet measurements and events for all monitored city-networks (up to the 500,000 city-networks service limit) to an Amazon S3 bucket.
**Metrics**
Internet Monitor generates aggregated metrics for CloudWatch metrics, for global traffic to your application and global traffic to each AWS Region. For more information, see [View Internet Monitor metrics or set alarms in CloudWatch Metrics](CloudWatch-IM-view-cw-tools-metrics-dashboard.md).
**Health event**
Internet Monitor creates a health event to alert you to a specific problem that affects your application. Internet Monitor detects internet issues, such as increased network latency, across the world. It then uses its historical internet measurements from across the AWS global infrastructure footprint to calculate the impact of current issues on your application, and creates health events. Internet Monitor, by default, creates health events based on both overall impact and local impact thresholds. To learn more about health events, see [ When Internet Monitor creates and resolves health events](CloudWatch-IM-inside-internet-monitor.md#IMHealthEventStartStop).
The default health event threshold, for both performance scores and availability scores, is 95%. If you like, you can specify your own custom thresholds for when Internet Monitor creates health events. For more information about configuring thresholds, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
Each health event includes information about the impacted city-networks. You can view health events in the CloudWatch console, or by using an AWS SDK or AWS CLI with Internet Monitor API actions. Internet Monitor also sends Amazon EventBridge notifications for health events. For more information, see [When Internet Monitor creates and resolves health events](CloudWatch-IM-inside-internet-monitor.md#IMHealthEventStartStop).
**Internet event**
Internet Monitor displays information about recent global health events, called internet events, on an internet weather map that is available to all AWS customers. You don't need to create a monitor in Internet Monitor to view the internet weather map. Unlike health events, internet events are not specific to individual customers or their application traffic. For more information, see [Global internet weather map in Internet Monitor](CloudWatch-InternetMonitor.outage-map.md).
**Thresholds**
Internet Monitor creates health events based on both overall thresholds and local thresholds. You can change the default thresholds and configure other options, such as turning off local thresholds. For more information about configuring thresholds, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
**Performance and availability scores**
By analyzing the data that AWS collects, Internet Monitor can detect when the performance and availability for your application has dropped, compared to estimated baselines that Internet Monitor calculates. To make it easier to see those drops, Internet Monitor reports the information to you as scores. A performance score represents the estimated percentage of traffic that is **not** seeing a performance drop. Similarly, an availability score represents the estimated percentage of traffic that is **not** seeing a availability drop. For more information, see [How AWS calculates performance and availability scores](CloudWatch-IM-inside-internet-monitor.md#IMExperienceScores).
**Bytes transferred and monitored bytes transferred**
Bytes transferred is the total number of bytes of ingress and egress traffic between an application in AWS and the city-network (that is, the location and the ASN, typically the internet service provider) where clients access an application. Monitored bytes transferred is a similar metric, but includes only bytes for monitored traffic.
**Round-trip time**
Round-trip time (RTT) is how long it takes for a request from a client user to return a response to the user. When RTT is aggregated across client locations (cities or other geographies), the value is weighted by how much of your application traffic is driven by each client location.
# How Internet Monitor works
This section provides information about how Internet Monitor works. This includes descriptions of how AWS collects the data that it uses to help detect connectivity issues across the internet, and how performance and availability scores are calculated.
**Contents**
+ [How Internet Monitor focuses on just your application traffic footprint](#IMTheAWSAdvantage)
+ [How AWS measures connectivity issues and calculates measurements](#IMHowAWSMeasuresConnectivityIssues)
+ [Geolocation accuracy in Internet Monitor](#IMGeolocationSourceAccuracy)
+ [When Internet Monitor creates and resolves health events](#IMHealthEventStartStop)
+ [Health event report timing](#IMEventDelay)
+ [How Internet Monitor works with IPv4 and IPv6 traffic](#IMIPv4IPv6)
+ [How Internet Monitor selects the subset of city-networks to include](#IM100citynetworks)
+ [How the global internet weather map is created (Frequently Asked Questions)](#IMGlobalOutagesFAQ)
**How Internet Monitor focuses on just your application traffic footprint**
Internet Monitor focuses monitoring on just the subset of the internet that's accessed by the users of your AWS resources, instead of broadly monitoring your website from every Region in the world as other tools do. It’s also a cost effective solution, affordable for large and small companies.
Internet Monitor uses the same powerful probes and issue-detection algorithms that AWS takes advantage of internally and alerts you to connectivity issues that affect your application by creating health events in Internet Monitor. Internet Monitor then gives you access to the resulting performance and availability map, by overlaying the traffic profile that it creates from your active viewers, based on your application resources.
Using this information, Internet Monitor shows you just relevant events (that is, the events from places where you have active viewers), and just the impact those events have on your overall viewer volume. So, how much impact an event has, percentage-wise, is based on your total traffic worldwide.
Internet Monitor stores internet measurements for pairs of your client locations and ASNs, or *city-networks*. Internet Monitor also creates aggregated CloudWatch metrics for traffic to your application, and to each AWS Region and edge location.
In addition, Internet Monitor publishes internet measurements to CloudWatch Logs internet every five minutes for the top 500 city-networks that send traffic to each monitor, to support using CloudWatch tools and other methods with your data. Optionally, you can choose to publish internet measurements for all monitored city-networks (up to the 500,000 city-networks service limit) to an Amazon S3 bucket. For more information, see [Publish internet measurements to Amazon S3 in Internet Monitor](CloudWatch-IM-get-started.Publish-to-S3.md).
The benefits of Internet Monitor include the following:
+ Using Internet Monitor doesn't place additional load or cost on your application that's hosted on AWS.
+ You don't need to include performance measurement code in your client-side resources, or in your application.
+ You can get visibility into performance and availability across the internet that your application is connected to, including "last mile" information.
Note that because Internet Monitor creates measurements based on your AWS resources, Internet Monitor only creates events that are specific to your application traffic. Global internet issues in general are not reported. In addition, when the service location is an AWS Region, the measurements and events emitted are designed to represent connectivity at a Regional level and don’t accurately represent connectivity between an end user location and an Availability Zone.
**How AWS measures connectivity issues and calculates measurements**
Internet Monitor uses internet connectivity data between different AWS Regions and Amazon CloudFront points of presence (POPs) to different client locations through Autonomous System Numbers (ASNs), typically internet service providers (ISPs). This is the connectivity data that is used internally by AWS operators, on a daily basis, to proactively detect connectivity issues across the global internet.
For every AWS Region, we know which portions of the internet communicate with the Region and do the following:
+ We actively monitor those portions of the internet, with a rolling 30-day window.
+ We use both network and higher-level protocol probes, including both inbound and outbound probing.
AWS has active and passive probes that measure the latency (performance) at the 90th percentile and reachability (availability) from every AWS Region and from the CloudFront service to the entire internet. Abnormal patterns in connectivity between a service and a customer location are monitored, and then reported as alerts to the customer.
See the following sections for details:
+ [Calculating availability and RTT](#IMCalculateLatency)
+ [Calculating performance and availability scores](#IMExperienceScores)
+ [Calculating TTFB and RTT (latency)](#IMCalculateTTFB)
+ [Regional and Availability Zone measurements and aggregation](#IMRegionalAZaggregation)
**Calculating availability and RTT**
Round-trip time (RTT) is how long it takes for a request from the user to return a response to the user. When round-trip time is aggregated across end user locations, the value is weighted by the amount of your traffic that is driven by each end user location.
As an example, with two end user locations, one serving 90% of traffic with a 5 ms RTT, and the other serving 10% of traffic with a 10 ms RTT, the result is an aggregated RTT of 5.5 ms (which comes from 5 ms \$1 0.9 \$1 10 ms \$1 0.1).
Note that there are differences for resources about measuring last-mile latency. For Internet Monitor latency measurements, VPCs, Network Load Balancers, and WorkSpaces directories do not include last-mile latency.
**Calculating performance and availability scores**
AWS has substantial historical data about internet performance and availability between AWS services and different city-networks (locations and ASNs). By applying statistical analysis to the data, Internet Monitor can detect when the performance and availability for your application has dropped, compared to an estimated baseline that it has calculated. To make it easier to see those drops, that information is reported to you in the form of health scores: a performance score and an availability score.
Health scores are calculated at different granularities. At the finest granularity, we compute the health score for a geographic region, such as a city or a metro area, and an ASN (a *city-network*). We also roll up the individual health scores to overall health score numbers for an application in a monitor. If you view performance or availability scores without filtering for any specific geography or service provider, Internet Monitor provides overall health scores.
Overall health scores span your whole application for the specified time period. When the performance or availability score for your application's city-network pairs across your application reaches or drops below the corresponding health event threshold for performance or availability Internet Monitor triggers a health event. By default, the threshold is 95% for both overall performance and availability. Internet Monitor also creates health events based on local thresholds—if the option is enabled, as it is by default—based on values that you configure. To learn more about configuring health event thresholds, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
When you explore information in the monitor and log files to investigate issues and learn more, you can filter by specific cities (locations), networks (ASNs or internet service providers), or both. So, you can use filters to see health scores for different cities, ASNs, or city-network pairs, depending on the filters that you choose.
+ An *availability score* represents the estimated percentage of traffic that is **not** seeing an availability drop. Internet Monitor estimates the percentage of traffic experiencing a drop from the total traffic seen and availability metrics measurements. For example, an availability score of 99% for an end user and service location pair is equivalent to 1% of the traffic experiencing an availability drop for that pair.
+ A *performance score* represents the percentage of traffic that is **not** seeing a performance drop. For example, a performance score of 99% for an end user and service location pair is equivalent to 1% of the traffic experiencing a performance drop for that pair.
**Calculating TTFB and RTT (latency)**
Time to first byte (TTFB) refers to the time between when a client makes a request and when it receives the first byte of information from the server. AWS calculations for TTFB measure the time elapsed from Amazon EC2 or Amazon CloudFront to the Internet Monitor measurement node (including the last mile of the node). That is, Internet Monitor measures time from the user to the Amazon EC2 Region for TTFB for EC2, and from the user to CloudFront for TTFB for CloudFront.
For round-trip time (RTT), Internet Monitor includes the time from the city-network (that is, the client location and ASN, typically an internet service provider), as mapped by the public IP address, to the AWS Region. This means that Internet Monitor does not have last mile visibility for users who access the internet from behind a gateway or VPN.
Note that there are differences for resources about measuring last-mile latency. For Internet Monitor latency measurements, VPCs, Network Load Balancers, and WorkSpaces directories do not include last-mile latency.
Internet Monitor includes average TTFB information in the **Traffic optimization suggestions** section of the **Traffic insights** tab on the CloudWatch dashboard, to help you evaluate options for different setups for your application that can improve performance.
**Regional and Availability Zone measurements and aggregation**
Although Internet Monitor aggregates measurements and shares impact at a Regional level, it calculates impact at an Availability Zone (AZ) level. This means that, if, for an event, only one AZ is impacted and most of your traffic flows through that AZ, you do see impact for your traffic. However, for the same event, if your application traffic does not flow through an impacted AZ, you do not see impact.
Note that this applies only to resources that aren't WorkSpaces directories. WorkSpaces directories are measured only on a Regional level.
**Geolocation accuracy in Internet Monitor**
For location information, Internet Monitor uses IP-geolocation data supplied by [MaxMind](https://dev.maxmind.com/geoip). The accuracy of the location information in Internet Monitor measurements depends on the accuracy of MaxMind's data.
Be aware that `Metro` level measurements might not be accurate for locations outside of the United States.
**When Internet Monitor creates and resolves health events**
Internet Monitor creates and closes health events for the application traffic that you monitor based on the current thresholds that are set. Internet Monitor has a default threshold configuration, and you can also set your own configuration for thresholds. Internet Monitor determines the overall impact that connectivity issues are having on your application, and the impact on local areas where your application has clients, and creates health events when the thresholds are crossed.
Internet Monitor calculates the impact of connectivity issues on a client location based on the historical data about internet performance and availability for network traffic that's available to the service through AWS. It applies the information relevant to your application, based on the geographic locations for ASNs and services where clients use your application: the city-network pairs that are affected. The locations are determined from the resources that you add to your monitor. Then Internet Monitor uses statistical analysis to detect when performance and availability has dropped, affecting the client experience for your application.
The performance and availability scores that Internet Monitor calculates are represented as the percentage of traffic that is **not** seeing a drop. Impact is the opposite of this: it's a representation of how much an issue is problematic for a customer's end users. So if there is a global availability drop of 93%, for example, the corresponding impact would be 7%.
When the performance or availability score for your application's city-network pairs globally reaches or drops below the corresponding health event threshold for performance or availability, this triggers Internet Monitor to generate a health event. By default, the threshold is 95% for both performance and availability. The values to meet, or drop below, the threshold are cumulative, so it could mean several smaller events combine to meet the threshold percentage, or that a single event meets or falls below the threshold level.
As long as performance or availability scores that triggered the event are at or below the corresponding health event threshold percentage for overall impact, the health event stays active. When the score or combined scores that triggered the event rise above the threshold, Internet Monitor resolves the health event.
Internet Monitor also creates health events based on local thresholds and the percentage of overall traffic that an issue has an impact on. You can configure options for local thresholds, or turn off local thresholds altogether.
The default health event threshold, for both performance scores and availability scores, is 95%. If you like, you can specify your own custom thresholds for when Internet Monitor creates health events. For more information about configuring thresholds, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
**Health event report timing**
Internet Monitor uses an aggregator to gather all signals about internet issues, to create health events in monitors within minutes.
When possible, Internet Monitor analyzes the origin of a health event, to determine whether it was caused by AWS or an ASN. Health event analysis continues after an event is resolved. Internet Monitor can update events with new information for up to an hour.
**How Internet Monitor works with IPv4 and IPv6 traffic**
Internet Monitor measures health toward a network over only IPv4, and shows you health events, and availability and performance metrics, if you serve traffic to that network over any IP family (IPv4 or IPv6). If you serve traffic from a dual-stack resource, such as a dual-stack CloudFront distribution, Internet Monitor raises a health event and shows a drop in a performance score or availability score only if IPv4 traffic has the same issues for the resource as IPv6 traffic does.
Note that the Internet Monitor metrics for overall bytes in and bytes out accurately reflect all internet traffic (IPv4 and IPv6).
**How Internet Monitor selects the subset of city-networks to include**
When you set a maximum limit for the number of city-networks monitored by your monitor or choose a percentage of traffic to monitor, Internet Monitor chooses the city-networks to include (monitor) based on highest recent traffic volume.
For example, if you set a maximum city-networks limit of 100, Internet Monitor monitors (up to) 100 city-networks based on your application traffic during a recent one hour period. Specifically, Internet Monitor monitors the top 100 city-networks that have had the most traffic in the most recent one hour window *before* the latest one hour window.
To illustrate this, say that the current time is 2:30 PM. In this scenario, the traffic that you see in your monitor was captured between 1:00 PM and 2:00 PM, and the traffic volume measurement that Internet Monitor uses to determine the top 100 city-networks was captured between 12:00 PM and 1:00 PM.
**How the global internet weather map is created (Frequently Asked Questions)**
The Internet Monitor internet weather map is available on the Internet Monitor console to all authenticated AWS customers. This section includes details about how the internet weather map is created and how to use it.
**What is the Internet Monitor internet weather map?**
The internet weather map provides a visual representation of internet issues across the world. It highlights impacted client locations, that is, cities plus ASN (typically internet service providers). The map shows a combination of availability and performance issues that have recently impacted clients' internet experience for top client locations and AWS services globally.
**Where does data for the map come from?**
The data is based on a combination of active and passive probing of the internet. To learn more about how Internet Monitor measures data you can read the section [How AWS measures connectivity issues](#IMHowAWSMeasuresConnectivityIssues).
**How often is the map updated?**
The internet weather map is updated every 15 minutes.
**Which networks are tracked for outages?**
AWS tracks networks all around the world that represent important IP prefixes used by customers for making internet connections to AWS. We scope outages to client locations that are top talkers for volume of traffic sent to and received from the AWS network.
**What determines whether an internet event is included on the map?**
Here are some high level criteria that we use to determine whether an internet event is included on the internet weather map:
+ AWS detects that there is an availability or performance event.
+ If the event is short lived, for example, it lasts less than 5 minutes, we ignore it.
+ Then, if the event is in a client location that is classified as a top talker, it's considered an outage.
**What thresholds are used for the internet weather map?**
Thresholds for determining outages are not static for the internet weather map. Internet Monitor determines what constitutes an event based on detecting a deviation from expected values. You can learn more about how this works by reviewing [how Internet Monitor determines when to create health events](#IMHealthEventStartStop) for monitors that you create with the service. When you create a monitor, Internet Monitor generates internet traffic health measurements that are specific to your own application traffic. Internet Monitor also alerts you to health events for issues that affect your application's internet traffic.
**What can I do with this data?**
The internet weather map provides a quick summary of key internet events that happened around the world in the last 24 hours. It helps you to get a sense of the internet monitoring experience, without needing to onboard your own internet traffic to Internet Monitor. To leverage the full potential of the internet monitoring capabilities of AWS and to personalize it for your applications and services hosted on AWS, you can create a monitor in Internet Monitor.
When you create a monitor, you enable Internet Monitor to identify the specific internet paths that affect your application clients, and you get access to features and capabilities that can help you improve your client experience. You'll also be proactively notified of new internet issues that specifically impact your application traffic and clients.
**How can I get more details about events?**
Click an outage on the map to see details that include when an event started and ended, the impacted city and ASN, and what type of issue it was (that is, a performance issue or an availability issue).
To get more detailed information about events, and to get custom measurements for your application traffic, [create a monitor in Internet Monitor](CloudWatch-IM-get-started.md).
# Internet Monitor example use cases
This section describes several specific examples of use cases for Internet Monitor, with links to blog posts with more details. These examples illustrate how you can use the capabilities of Internet Monitor to monitor your application health and improve latency to enhance your users' experience.
**Set up alerts and decide on actions to take**
You can use Internet Monitor to get insights about average internet performance metrics over time, and about health events by city-network (client location and ASN, typically an internet service provider). Using Internet Monitor, you can identify the events that are impacting end user experience for applications hosted on Amazon Virtual Private Clouds (VPCs), Network Load Balancers, Amazon WorkSpaces, or Amazon CloudFront.
After you create a monitor, you have several options for how to be alerted about Internet Monitor health events. These include notifications based on CloudWatch Alarms using event metrics or Amazon EventBridge rules to filter for health events. You can choose different options for notifications or actions based on alarms, including, for example, AWS SMS notifications or updates to a CloudWatch log group.
To see an example with detailed guidance, see the following blog post: [Introducing Internet Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-cloudwatch-internet-monitor/).
**Identify latency issues and improve TTFB to improve multiplayer gameplay experience**
Use Internet Monitor to help you to quickly identify where game players in global cloud gaming apps are experiencing latency issues globally, and provide insights into improving performance. By identifying where the most players currently have the slowest time to first byte (TTFB), you know how to improve latency to make your biggest player base happier.
Now, when you're ready to deploy the next EC2 server for your game, choose the AWS Region that Internet Monitor suggests will lower TTFB in the area with the high latency and large group of players.
For details about setting up and using Internet Monitor for this use case, see the following blog post: [Using Internet Monitor for a Better Gaming Experience](https://aws.amazon.com/blogs/gametech/using-cloudwatch-internet-monitor-for-a-better-gaming-experience/).
**Identify potential performance and internet connection issues for users on Amazon WorkSpaces**
Internet Monitor provides you with the IP prefixes and ASN (typically, the internet service provider or ISP) for your users, which can be helpful to diagnose performance and internet connection issues for users to their WorkSpaces. You can also use this data to view your fleet as a whole and monitor your WorkSpaces user connections.
For more information about how to use Internet Monitor for this use case, see the following blog post: [Using Internet Monitor with Amazon WorkSpaces Personal](https://aws.amazon.com/blogs/desktop-and-application-streaming/utilizing-cloudwatch-internet-monitor-with-amazon-workspaces-personal/).
# Global internet weather map in Internet Monitor
Internet Monitor displays a global internet weather map that is available to all AWS customers. To view the map, in the Amazon CloudWatch console, navigate to **Network Monitoring**, and then choose **Internet monitors**.
The internet weather map highlights internet events ("outages") all over the world that affect AWS customers, with the specific cities and networks (ASNs, typically internet service providers) where there are issues with performance or availability. The map includes internet events from the past 24 hours.
You don't need to create a monitor in Internet Monitor to view the internet weather map. Unlike health events in Internet Monitor, internet events are not specific to individual customers or their application traffic.
On the internet weather map, you can choose an internet event to learn details about it. For an internet event, you can see the start time, end time (if the event is over), the current status (Active or Resolved), and the outage issue type (Availability or Performance). To learn more about how the internet weather map is created and what is included, see the [global internet weather map FAQ](CloudWatch-IM-inside-internet-monitor.md#IMGlobalOutagesFAQ).
To view and work with detailed information that is specific to your application traffic and client locations, you can create a monitor in Internet Monitor for your application. Then, you'll see performance and availability patterns and events, current and historical, as well as get health event alerts, tailored to just your application footprint and customers. The internet weather map gives you an overall view, while a specific monitor filters the information to just the measurements and details that are relevant to your application. With a monitor, you can also explore historical metrics and get recommendations for improving client experience for your application. To learn more, see [Getting started with Internet Monitor using the console](CloudWatch-IM-get-started.md).
# Internet Monitor cross-account observability
With Internet Monitor cross-account observability, you can monitor your applications that span multiple AWS accounts within a single AWS Region.
You can use Amazon CloudWatch Observability Access Manager to set up one or more of your AWS accounts as a monitoring account. You’ll provide the monitoring account with the ability to view data in your source account by creating a *sink* in your monitoring account. A sink is a resource that represents an attachment point in a monitoring account. For Internet Monitor, the resource attachment point is a monitor. You use the sink to create a link from your source account to your monitoring account. For more information, see [CloudWatch cross-account observability](CloudWatch-Unified-Cross-Account.md).
**Required resources**
For proper functionality of CloudWatch Application Insights cross-account observability, ensure that the following telemetry types are shared through the CloudWatch Observability Access Manager.
+ Monitors in Internet Monitor
+ Metrics in Amazon CloudWatch
+ Log groups in Amazon CloudWatch Logs
# Pricing for Internet Monitor
With Internet Monitor, there are no upfront costs or long-term commitments. Pricing for Internet Monitor has two components: a per monitored resource fee and a per city-network fee. A *city-network* is the location where clients access your application resources from and the network (ASN, such as an internet service provider or ISP) that clients access the resources through. Note that you are also charged standard CloudWatch prices for logs and any additional metrics, dashboards, alarms, or insights that you create.
You choose a percentage of traffic to monitor when you create a monitor. To help control your bill, you can also set a limit for the maximum number of city-networks to monitor. You can update the percentage of traffic to monitor or the maximum city-networks limit at any time by editing your monitor. The first 100 city-networks (across all monitors per account) are included. After that, you only pay for the actual additional number of city-networks that you monitor, up to the maximum number.
You pay only the actual additional number of city-networks that you monitor, up to the maximum number, with no charge for the first 100 city-networks (across all monitors per account). A flat amount equivalent to the cost of 100 city-networks is deducted from your monthly bill.
For example, a large global company could choose to monitor 100% of its internet-facing traffic, and set a city-networks maximum of 50,000, for one monitor with one resource. Assuming the traffic reached 50,000 city-networks, that portion of its bill would be around 2,700 USD/month. For another company, in fewer geographic areas, with one monitor with one resource and 200 city-networks, this portion of the bill would be around 13 USD/month. For more information, see [Choose a city-networks maximum limit](IMCityNetworksMaximum.md).
You can try out different options with the pricing calculator. To explore pricing options, on the [Pricing calculator for CloudWatch page](https://calculator.aws/#/addService/CloudWatch), scroll down to Internet Monitor.
For more information about Internet Monitor and CloudWatch pricing, see the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
# Getting started with Internet Monitor using the console
To help you get started with Internet Monitor, this chapter provides the steps for creating and configuring a *monitor*. You create a monitor in Internet Monitor for your application by naming it, and then adding AWS resources that your application uses.
You create a monitor in Internet Monitor for your application by adding AWS resources that it uses, and then setting several configuration options. The resources that you add, Amazon Virtual Private Cloud VPCs, Network Load Balancers (NLBs), CloudFront distributions, or WorkSpaces directories, provide the information for Internet Monitor to map internet traffic information for your application. After you create your monitor, wait 15-30 minutes to generate the traffic profile specific to where your application is used.
Then, use the Internet Monitor dashboard, or other tools, to visualize and explore performance and availability about your client usage. These tools provide insights for you using your application traffic's measurements gathered for you by the monitor.
The steps here walk you through setting up your monitor by using the console. To see examples of using the AWS Command Line Interface with the Internet Monitor API actions, to create a monitor, view events, and so on, see [Examples of using the CLI with Internet Monitor](CloudWatch-IM-get-started-CLI.md).
**Tasks**
+ [Step 1: Create a monitor](#CloudWatch-IM-get-started.create)
+ [Step 2: Configure the monitor](#CloudWatch-IM-get-started.configure)
+ [Step 3: View metrics and explore history](#CloudWatch-IM-get-started.explore)
+ [Step 4: Get suggestions to improve latency](#CloudWatch-IM-get-started.suggestions)
+ [Step 5 (Optional): Delete the monitor](#CloudWatch-IM-get-started.delete)
## Step 1: Create a monitor
**To create a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose **Create monitor**.
1. For **Monitor name**, enter the name you want to use for this monitor in Internet Monitor.
1. Choose **Add resources**, and then select the resources to set the monitoring boundaries for Internet Monitor to use for this monitor.
**Note**
Be aware of the following:
To generate meaningful output with Internet Monitor, VPCs that you add must be connected to the internet by having an Internet Gateway configured.
You can add only one type of resource to a single monitor. For example, VPCs or CloudFront distributions or WorkSpaces directories, but not a combination of different types.
1. Leave the default percentage of traffic as 100%, or choose another percentage of your internet traffic to monitor.
1. Choose **Create monitor**.
## Step 2: Configure the monitor
After you create a monitor, you can edit the monitor at any time, for example, to change the application traffic percentage, update the maximum city-networks limit or add or remove resources. To make updates in the Internet Monitor console, follow the procedure in this section. Note that you can’t change the name of a monitor.
For more information about configuring a monitor, see [Edit a monitor in Internet Monitor](CloudWatch-IM-get-started.edit-monitor.md).
**To configure a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Update monitor**.
1. Make the desired updates. For example, to change the percentage of traffic to monitor, under **Application traffic to monitor**, select or enter a percentage.
1. Choose **Update**.
## Step 3: View metrics and explore history
Visualize data about your internet traffic, from an overview perspective or by drilling down into details.
**To visualize data and get insights for application traffic using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose a monitor to work with.
1. Choose from the following tabs:
+ **Overview** — Review a general summary of your monitor and your application traffic performance.
+ **Health events** — View current and historical health events that currently impact, or previously impacted, locations where clients access your application.
+ **Analyze** — See information about top monitored traffic in client locations (by traffic volume), summarized in several customizable ways. Visualize metrics and historical trends for health scores and metrics.
In the next section, learn about how Internet Monitor provides suggestions for improving latency for your application traffic.
## Step 4: Get suggestions to improve latency
Get suggestions for how to optimize latency, so that your clients experience the best internet performance for your application.
Internet Monitor evaluates your monitored application traffic, and then makes suggestion about whether you can reduce latency, for example, by changing the AWS Regions that you've configured for your application.
For more information, see [Get suggestions to optimize application performance in Internet Monitor (Optimize page)](CloudWatch-IM-insights.md).
**To get suggestions for improving application latency using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose a monitor to work with.
1. Choose **Optimize**, and then view the top suggestions.
## Step 5 (Optional): Delete the monitor
If you created a monitor as a test or if you're no longer using a monitor, you can delete it. Before you can delete a monitor, you must disable it.
**To delete a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Disable**.
1. Choose the **Action** menu again, and then choose **Delete**.
1. Follow the guidance in the modal dialog to confirm deleting the monitor.
# Configure a monitor using the console
This chapter includes procedures and recommendations for creating and configuring monitors in Internet Monitor.
The steps provided in these sections primarily use the AWS Management Console. You can also use Internet Monitor API operations with the AWS Command Line Interface (AWS CLI) or AWS SDKs to create and configure a monitor. For detailed information about working with Internet Monitor API operations, see the following resources:
+ If you plan to work with Internet Monitor with the CLI, see [Examples of using the CLI with Internet Monitor](CloudWatch-IM-get-started-CLI.md).
+ For detailed information about working with Internet Monitor API operations, see the [ Internet Monitor API Reference](https://docs.aws.amazon.com/internet-monitor/latest/api/Welcome.html).
**Topics**
+ [Create a monitor](CloudWatch-IM-working-with.create.md)
+ [Add resources to your monitor](IMMonitorResources.md)
+ [Set your application traffic percentage](IMTrafficPercentage.md)
+ [Use a monitor](IMWhyCreateMonitor.md)
+ [Edit a monitor](CloudWatch-IM-get-started.edit-monitor.md)
+ [Delete a monitor](CloudWatch-IM-get-started.delete-monitor.md)
+ [Advanced options](CloudWatch-IM-get-started.advanced-options.md)
# Create a monitor in Internet Monitor using the console
You create a monitor in Internet Monitor to visualize and explore performance and availability data about your application's client traffic. You create a monitor by adding AWS resources that your application uses, and then setting several configuration options. The resources that you add to the monitor provide the information — for example, through resource flow logs — for Internet Monitor to learn which internet traffic is specific to your AWS application.
After you create your monitor, wait 15 to 30 minutes before reviewing the monitor dashboard. Internet Monitor needs a few minutes to generate a traffic profile for where your application is used by your end users, and then to begin publishing data for your traffic.
Typically, it's simplest to create one monitor in Internet Monitor for one application. Within the same monitor, you can search through and sort measurements and metrics by different locations and ASNs, or other information. You don't need to create separate monitors for applications in different areas.
The steps provided here walk you through setting up your monitor by using the console. To work with Internet Monitor API actions using the AWS Command Line Interface, see [Examples of using the CLI with Internet Monitor](CloudWatch-IM-get-started-CLI.md).
**To create a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose **Create monitor**.
1. For **Monitor name**, enter the name that you want to use for this monitor.
1. Choose **Add resources**, and then select the resources that will determine the internet traffic profile for this monitor.
**Note**
Be aware of the following:
To generate meaningful output with Internet Monitor, VPCs that you add must be connected to the internet by having an Internet Gateway configured.
You can specify only one type of resource for each monitor.
1. Choose a percentage of your application's internet traffic to monitor.
1. Optionally, under **Advanced settings**, specify one or more of the following additional options.
+ **City-networks maximum** — The default city-networks maximum value is `500000`. If you like, you can lower this limit, to restrict the number of city-networks (locations and ASNs) that Internet Monitor will monitor traffic for. You can change the city-networks maximum at any time by editing your monitor. For more information, see [Choose a city-networks maximum limit](IMCityNetworksMaximum.md).
+ **Amazon S3 bucket storage** — You can specify an Amazon S3 bucket name and custom prefix to publish internet measurements for your application's internet traffic to Amazon S3, for all monitored city-networks.
Internet Monitor stores internet measurements for pairs of your client locations and ASNs, or *city-networks*. Internet Monitor also creates aggregated CloudWatch metrics for traffic to your application, and to each AWS Region and edge location. In addition, Internet Monitor publishes internet measurements for your application traffic to CloudWatch Logs every five minutes, to support using CloudWatch tools and other methods with your data. If you choose to publish measurements to S3, measurements are still published to CloudWatch Logs. For more information, see [Publish internet measurements to Amazon S3 in Internet Monitor](CloudWatch-IM-get-started.Publish-to-S3.md).
+ **Tags** — Add one or more tags for your monitor.
1. Choose **Create monitor**.
After you create a monitor, wait about 15-30 minutes for Internet Monitor to create a traffic profile and begin publishing your data. Then, you can view information about your application's internet traffic performance by navigating to the monitor dashboard in the console.
**To view the Internet Monitor dashboard**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Network Monitoring**, then **Internet monitors**.
1. To see more information about a specific monitor, on the **Monitors** tab, choose a monitor.
# Add resources to your monitor
When you create a monitor, you must associate your application's resources with it: Amazon Virtual Private Clouds (VPCs), Network Load Balancers, Amazon CloudFront distributions, Network Load Balancers (NLBs), or Amazon WorkSpaces directories. Then, Internet Monitor knows where your application's internet-facing traffic and clients are located, and it can create and maintain a traffic profile that determines the relevant measurements to publish for your monitor.
You can add the following types of resources to a monitor in Internet Monitor as *monitored resources*.
+ **VPCs:** Each VPC that you add in a Region is a monitored resource. When you add a VPC, Internet Monitor monitors the traffic for any internet-facing application in the VPC, for example, an application hosted on an Amazon EC2 instance, behind a Network Load Balancer, or in an AWS Fargate container.
+ **Network Load Balancers:** Each NLB that you add is a monitored resource.
+ **CloudFront distributions:** Each CloudFront distribution that you add is a monitored resource.
+ **WorkSpaces directories:** Each WorkSpaces directory that you add in a Region is a monitored resource.
When you monitor traffic for VPCs, traffic for applications that are hosted on load balancers behind the VPC is monitored. You can choose to monitor traffic for individual Network Load Balancer load balancers instead of monitoring a VPC with multiple load balancers. This can be helpful, for example, if you need to understand and configure features for better performance or efficiencies at the load balancer level. Or, you might need compliance information at the Network Load Balancer level.
When you add resources to a monitor in Internet Monitor, be aware of the following:
+ Internet Monitor doesn't support adding different types of resources together in one monitor.
+ To generate meaningful output with Internet Monitor, VPCs that you add must be connected to the internet by having an Internet Gateway configured.
+ Internet Monitor doesn't support adding different types of resources together in one monitor.
+ There are Regional differences for opt-in Regions to keep in mind when you add VPCs or NLBs as resources. For more information, see [Supported AWS Regions for Internet Monitor](CloudWatch-InternetMonitor.Regions.md).
+ In addition, there are differences for resources about measuring last-mile latency. For Internet Monitor latency measurements, VPCs, NLBs, and WorkSpaces directories do not include last-mile latency.
# Choose a percentage of traffic to monitor for your application
The coverage that you choose for the percentage of application traffic to monitor determines how many city-networks (client locations and ASNs, typically internet service providers) for your application are monitored, up to an optional city-networks maximum limit that you can also set.
You can choose the percentage of traffic to monitor when you create a monitor, or, with an existing monitor, by choosing **Edit monitor** on any Internet Monitor dashboard page in the console.
If you choose to monitor less than 100% of your application traffic, you might have an observability gap in with your monitor. That's because if there are health events that Internet Monitor creates where you aren't monitoring traffic, you won't be aware of those issues. With a traffic percentage set to less than 100%, you might also have less coverage for the performance and availability score information about client access to your application.
The following sections describe options to explore traffic percentage settings and coverage, and to get an idea about the impact of increasing or decreasing coverage.
+ [Explore changing your application traffic percentage](#IMExploreTrafficPercentage)
+ [View the number of city-networks monitored at different traffic percentage settings](#IMExploreTrafficGraphs)
## Explore changing your application traffic percentage
You can explore values that you might want to change your application traffic percentage to, by viewing the number of city-networks monitored when you change the percentage. The procedure in this section provides step-by-step information.
In the Internet Monitor console, you can try increasing or decreasing the application traffic percentage for your monitor, and view the estimated number of your city-networks that would be covered as a result. With this option, you can quickly see how changing your traffic percentage affects the number of city-monitors are monitored. This can help you to get a feel for what a good application traffic percentage to choose might be, for your application.
**To explore monitoring coverage and update percentage of traffic monitored**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. In your list of monitors, choose a monitor.
1. On the **Configure** tab, in the **View and evaluate traffic coverage** section, you can evaluate the impact on the total number of city-networks that are monitored, depending on a traffic percentage that you choose. You can also update the percentage of traffic that you monitor or change the city-networks limit for your monitor.
+ **Explore traffic percentage options:** Under **Compare options for traffic coverage**, in the drop-down menu, choose one or more traffic percentages to graph and compare. For each traffic percentage that you choose, you can see the number of city-networks that will be monitored when you set that traffic percentage coverage.
To learn more, see [View number of city-networks monitored at different percentages](#IMExploreTrafficGraphs).
+ **Change monitoring coverage:** Under **Explore other traffic coverage options**, choose **Update monitoring coverage**.
In the **Explore and set traffic monitoring coverage** dialog, click the arrows to increase or decrease the percentage of traffic to monitor. By choosing 100% traffic, you can see how many city-networks are monitored with full coverage for monitoring your application.
Note: To learn more about how the number of city-networks monitored (estimated here) might affect your costs, choose the link to the [CloudWatch Pricing calculator](https://calculator.aws/#/addService/CloudWatch), and then scroll down to Internet Monitor.
To set a new percentage of traffic to monitor, choose **Update monitor coverage**. Or, to keep the current coverage level, choose **Cancel**.
## View the number of city-networks monitored at different traffic percentage settings
You can view the number of city-networks that would be monitored for your application at different application traffic percentages. The procedure in this section provides step-by-step information.
In the Internet Monitor console, you can view graphs that show how coverage for your city-networks would change at different of application traffic percentages, over a time interval that you specify. This is a quick way to visualize and compare the monitoring coverage for your application at specific traffic percentages, all on one graph.
**To view graphs of application traffic percentage and corresponding city-networks coverage**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. In your list of monitors, choose a monitor.
1. Choose the **Configure** page, and scroll down to **Traffic coverage**.
1. Under **Compare options for traffic coverage**, in the drop-down list, select one or more percentages. You can choose one or more application traffic percentages, and the graph of **Total monitored city-networks** is updated to display the monitoring coverage Internet Monitor provides for that traffic percentage. By choosing **City-networks at 100% traffic**, you can see how many city-networks are monitored with full coverage for monitoring your application.
Keep in mind the following:
+ Traffic coverage is computed based on the number of city-networks in the previous hour of your application traffic. This means that, after you choose a specific percentage of traffic to monitor, fewer city-networks might be monitored for your application than is shown here in a traffic coverage comparison graph.
+ To make sure that all your application traffic is monitored, set `TrafficPercentageToMonitor` to 100 and don’t set `MaxCityNetworksToMonitor`. Alternatively, you can set `MaxCityNetworksToMonitor` to 500,000, the upper limit in Internet Monitor.
+ If you set a city-networks maximum limit, the total number of monitored city-networks never exceeds that limit, regardless of the application traffic percentage option that you select.
+ You can learn more about how the number of city-networks monitored might affect your costs. On the [Pricing calculator for CloudWatch page](https://calculator.aws/#/addService/CloudWatch), scroll down to Internet Monitor.
To set a new percentage of traffic to monitor, under **Explore other traffic coverage options**, choose **Update monitoring coverage**. In the dialog, choose a percentage of traffic, and then choose **Update monitor coverage**.
# Use a monitor in Internet Monitor
There are several ways to use an Internet Monitor monitor after you create it: for example, you can view information in the CloudWatch dashboard, get information by using the AWS Command Line Interface, and set health alerts.
Your monitor provides information about your application and configuration preferences so that Internet Monitor can customize measurements and metrics to publish in events for you. Internet Monitor collects measurements from the global infrastructure footprint for AWS. These measurements are a tremendous amount of network performance and availability information, from all over the world. By using information from the resources that you add for your application, Internet Monitor publishes performance and availability measurements for you that is scoped to the city-networks (that is, client locations and ASNs, typically internet service providers or ISPs) where your application is active. So, the measurements and metrics in the Internet Monitor dashboard and in CloudWatch Logs —about availability, performance, monitored bytes transferred, and round-trip time—are specific to your client locations and ASNs.
Internet Monitor also determines when there are anomalies in performance and availability. By default, Internet Monitor overlays your traffic with the availability and performance measurements that AWS has collected for each source-destination pair in your client locations, to determine when there are notable drops in performance or availability. When there's significant degradation for your application's locations and scope, Internet Monitor generates a *health event*, and publishes information about the issue to your monitor.
After you create a monitor, you can use it to access or be alerted to the information that Internet Monitor provides, in the following ways:
+ **Use the CloudWatch dashboard** to view and explore performance, availability, and health events; explore your application's historical data; and get insights into new ways to configure your application for better performance. To learn more, see the following:
+ [Track real-time performance and availability in Internet Monitor (Overview page)](CloudWatch-IM-overview.md)
+ [Analyze historical data in Internet Monitor (Analyze page)](CloudWatch-IM-historical-explorer.md)
+ [Get suggestions to optimize application performance in Internet Monitor (Optimize page)](CloudWatch-IM-insights.md)
+ **Configure health event thresholds** to change what triggers Internet Monitor to create a health event for your application. You can configure overall thresholds and local (city-network) thresholds. To learn more, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
+ **Use AWS CLI commands** with Internet Monitor API actions to view traffic profile information, view measurements, list health events, and so on. To learn more, see [Examples of using the CLI with Internet Monitor](CloudWatch-IM-get-started-CLI.md).
+ **Use standard CloudWatch tools,** such as CloudWatch Contributor Insights, CloudWatch Metrics explorer, and CloudWatch Logs Insights to visualize the data in CloudWatch. To learn more, see [Exploring your data with CloudWatch tools and the Internet Monitor query interface](CloudWatch-IM-view-cw-tools.md).
+ **Use Athena with S3 logs** to access and analyze Internet Monitor internet measurements for your application, if you turned on publishing measurements to S3.
+ **Create Amazon EventBridge notifications** to alert you when Internet Monitor determines there is a health event. To learn more, see [Using Internet Monitor with Amazon EventBridge](CloudWatch-IM-EventBridge-integration.md).
+ **Receive an AWS Health Dashboard notification** automatically, when Internet Monitor determines that an issue is caused by the AWS network. The notification includes the steps that AWS is taking to mitigate the problem.
# Edit a monitor in Internet Monitor
Using the **Action** menu, you can edit a monitor in Amazon CloudWatch Internet Monitor after you create it. For example, you can edit a monitor to do the following:
+ Change the percentage of application traffic to monitor
+ Set or update the city-networks maximum limit
+ Change health event thresholds for availability or performance scores
+ Add or remove resources
+ Enable or update publishing events to Amazon S3
Note that you can't change the name of a monitor after you create it.
To make changes to a monitor, use the following procedure.
**To edit a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Update monitor**.
1. Make the desired updates. For example, to change the percentage of traffic to monitor, under **Application traffic to monitor**, select or enter a percentage.
1. Choose **Update**.
For more information about the options that you can update, see the following:
+ To learn more about resources that you add in Internet Monitor, see [Add resources to your monitor](IMMonitorResources.md).
+ To learn more about the application traffic percentage, see [Choose a percentage of traffic to monitor for your application](IMTrafficPercentage.md).
+ To learn more about changing the threshold for health events, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
+ To learn more about the city-networks maximum limit, see [Choose a city-networks maximum limit](IMCityNetworksMaximum.md).
+ To learn more about opting to publish events to S3, see [Publish internet measurements to Amazon S3 in Internet Monitor](CloudWatch-IM-get-started.Publish-to-S3.md).
# Delete a monitor in Internet Monitor
Using the **Action** menu, you can delete a monitor in Amazon CloudWatch Internet Monitor. You first disable the monitor, and then delete it.
**To delete a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network monitoring**, choose **Internet Monitor**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Disable**.
1. Choose the **Action** menu again, and then choose **Delete**.
# Advanced configuration options for a monitor
This section provides the steps for configuring advanced options for a monitor in Internet Monitor. These configuration options are optional but can be useful in some scenarios.
For example, you might choose to set a city-network maximum limit if traffic for the application that you monitor with Internet Monitor occasionally spikes, and you want to help make sure that your bill for Internet Monitor is predictable.
Or, you might want to set custom or local thresholds for health events, because you want to pay close attention to issues in specific geographies where you have a concentration of clients.
The topics in this section provide detailed descriptions of each feature, and list the steps to configure options for your needs.
**Topics**
+ [Choose a city-networks limit](IMCityNetworksMaximum.md)
+ [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md)
+ [Publish internet measurements to S3](CloudWatch-IM-get-started.Publish-to-S3.md)
# Choose a city-networks maximum limit
In addition to setting a traffic percentage for your monitor in Internet Monitor, you can also set a maximum limit for the number of city-networks monitored. This section describes how the city-networks limit can help you manage billing costs, and provides information and an example to help you determine a limit to set, if you choose to set one.
Internet Monitor can monitor traffic for some or all of the locations where clients access your AWS application resources. You can set a monitoring limit for the number of *city-networks*, that is, the client locations and the ASNs (typically internet service providers) that clients access your application through.
You choose a [percentage of application traffic](IMTrafficPercentage.md) to monitor when you create your monitor. The default percentage is 100%. You can update the percentage at any time, by editing the monitor.
The maximum limit that you set for the number of city-networks helps to make sure that your bill is predictable. For more information, see [Amazon CloudWatch Pricing](https://aws.amazon.com//cloudwatch/pricing/). You can also learn how different values for the number of city-networks actually monitored can affect your bill by using the CloudWatch price calculator. To explore options, on the [Pricing calculator for CloudWatch page](https://calculator.aws/#/addService/CloudWatch), scroll down to Internet Monitor.
To update your monitor and change the maximum city-networks limit, see [Edit a monitor in Internet Monitor](CloudWatch-IM-get-started.edit-monitor.md).
## How billing works with city-networks maximum limits
Setting a maximum limit for the number of city-networks monitored can help prevent unexpected costs in your bill. This is useful, for example, if your traffic patterns vary widely. Billing costs increase for each city-network that is monitored after the first 100 city-networks, which are included (across all monitors per account). If you set a city-networks maximum limit, it caps the number of city-networks that Internet Monitor monitors for your application, regardless of the percentage of traffic that you choose to monitor.
You only pay for the number of city-networks that are actually monitored. The city-network maximum limit that you choose lets you set a cap on the total that can be included when Internet Monitor monitors traffic with your monitor. You can change the maximum limit at any time by editing your monitor.
To explore options, on the [Pricing calculator for CloudWatch](https://calculator.aws/#/addService/CloudWatch) page, scroll down to Internet Monitor. For more information on Internet Monitor pricing, see the Internet Monitor section on the [Amazon CloudWatch Pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
## How to choose a city-networks maximum limit
Optionally, you can set a city-networks maximum limit. To help you decide on a maximum limit that you might want to select, consider how much traffic you want to monitor for your application. Be aware that if you choose 100% for the *traffic percentage to monitor* for your monitor, and then specify a city-networks maximum limit, depending on the limit that you choose, you might not monitor 100% of your application traffic. The city-networks maximum that you set takes precedence over the traffic percentage to monitor that you set.
To view how the percentage of traffic to monitor that you choose affects the number of city-monitors that are included for your application monitoring, which can help you decide whether to set a city-networks maximum limit, follow the steps in [View the number of city-networks monitored at different traffic percentage settings](IMTrafficPercentage.md#IMExploreTrafficGraphs).
To explore your options in more detail, you can use Internet Monitor metrics, as described in the following examples. These examples show how to select a maximum city-networks limit that is best for you, depending on the breadth of application internet traffic coverage you want. Using the [queries for Internet Monitor metrics in CloudWatch Metrics](CloudWatch-IM-view-cw-tools-metrics-dashboard.md) can help you understand more about your application internet traffic coverage.
## Example of determining a city-networks maximum limit
As an example, say that you've set a monitoring maximum limit of 100 city-networks and that your application is accessed by clients across 2637 city-networks. In CloudWatch Metrics, you'd see the following Internet Monitor metrics returned:
```
CityNetworksMonitored 100
TrafficMonitoredPercent 12.5
CityNetworksFor90PercentTraffic 2143
CityNetworksFor100PercentTraffic 2637
```
From this example, you can see that you're currently monitoring 12.5% of your internet traffic, with the maximum limit set to 100 city-networks. If you want to monitor 90% of your traffic, the next metric provides information about that: `CityNetworksFor90PercentTraffic` indicates that you would need to monitor 2,143 city-networks for 90% coverage. To do that, you would update your monitor and set the maximum city-networks limit to 2,143.
Similarly, say you'd like to have 100% internet traffic monitoring for your application. The next metric, `CityNetworksFor100PercentTraffic`, indicates that to do this, you should update your monitor to set the maximum city-networks limit to 2,637.
If you now set the maximum to 5,000 city-networks, since that's greater than 2,637, you see the following metrics returned:
```
CityNetworksMonitored 2637
TrafficMonitoredPercent 100
CityNetworksFor90PercentTraffic 2143
CityNetworksFor100PercentTraffic 2637
```
From these metrics, you can see that with the higher limit, you monitor all 2,637 city-networks, which is 100% of your internet traffic.
# Change health event thresholds for a monitor
Internet Monitor uses a default threshold to determine when to create a health event for your monitor. Optionally, you can change that default global threshold, to set another value. You can also set local threshold. This section describes how global and local thresholds work together, and provides steps for setting custom thresholds.
You can change the overall threshold that triggers Internet Monitor to create a health event. The default health event threshold, for both performance scores and availability scores, is 95%. That is, when the overall performance or availability score for your application falls to 95% or below, Internet Monitor creates a health event. For the overall threshold, the health event can be triggered by a single large issue, or by the combination of multiple smaller issues.
You can also change the local—that is, city-network—threshold, combined with a percentage of the overall level of impact, that—in combination—will trigger a health event. By setting a threshold that creates a health event when a score drops below the threshold for one or more city-networks (locations and ASNs, typically ISPs), you can get insights into when there are issues in locations with lower traffic, for example.
An additional local threshold option works together with the local threshold for availability or performance scores. The second factor is the percentage of your overall traffic that must be impacted before Internet Monitor creates a health event based on the local threshold.
By configuring the threshold options for overall traffic and local traffic, you can fine-tune how frequently health events are created, to align with your application usage and your needs. Be aware that when you set the local threshold to be lower, typically more health events are created, depending on your application and the other threshold configuration values that you set.
In summary, you can configure health event thresholds—for performance scores, availability scores, or both—in the following ways:
+ Choose different global thresholds for triggering a health event.
+ Choose different local thresholds for triggering a health event. With this option, you can also change the percentage of impact on your overall application that must be exceeded before Internet Monitor creates an event.
+ Choose to turn off triggering a health event based on local thresholds, or enable local threshold options.
To update health event thresholds for performance scores, availability scores, or both, follow these steps.
**To change threshold configuration options**
1. In the AWS Management Console, navigate to CloudWatch, and then, in the left navigation pane, choose Internet Monitor.
1. On the **Configure** page, in the **Health event thresholds** section, choose **Update thresholds**.
1. On the **Set health event threshold**page, choose the new values and options that you want for thresholds and other options that trigger Internet Monitor to create a health event. You can do any of the following:
+ Choose a new value for **Availability score threshold**, **Performance score threshold**, or both.
The graphs in the sections for each setting display the current threshold setting and the actual recent health event scores, for availability or performance, for your application. By viewing the typical values, you can get an idea of values that you might want to change a threshold to.
Tip: To view a larger graph and change the timeframe, choose the expander in the upper right corner of the graph.
+ Choose to turn on or off a local threshold for availability or performance, or both. When an option is enabled, you can set the threshold and impact level for when you want Internet Monitor to create a health event.
1. After you configure threshold options, save your updates by choosing **Update health event thresholds**.
To learn more about how health events work, see [When Internet Monitor creates and resolves health events](CloudWatch-IM-inside-internet-monitor.md#IMHealthEventStartStop).
# Publish internet measurements to Amazon S3 in Internet Monitor
You can choose to have Internet Monitor publish internet measurements to Amazon S3 for your internet-facing traffic to the monitored city-networks (client locations and ASNs, typically internet service providers) in your monitor, up to the 500,000 city-networks service limit. Internet Monitor automatically publishes internet measurements to CloudWatch Logs every five minutes for the top 500 (by traffic volume) city-networks for each monitor. Measurements that it publishes to S3 include the top 500 that are published to CloudWatch Logs.
You can choose the option to publish to S3, and specify the bucket to publish the measurements, to when you create or update your monitor. The bucket must already be created in S3 before you can specify it in Internet Monitor. There's a service limit of 500,000 city-networks for internet measurements published to S3. Internet Monitor publishes internet measurements to S3 as events, a series of compressed log file objects that are stored in the bucket.
When you create the S3 bucket for Internet Monitor to publish measurements to, make sure that you follow the permissions guidance provided by CloudWatch Logs. Doing so ensures that Internet Monitor can publish logs directly to S3, and that AWS can, if needed, create and change the resource policies associated with the log group receiving the logs. For more information, see [ Logs sent to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-CWL) in the Amazon CloudWatch Logs User Guide.
The published log files are compressed. If you open the log files using the Amazon S3 console, they are decompressed and the internet measurement events are displayed. If you download the files, you must decompress them to view the events.
You can also query the internet measurements in the log files using Amazon Athena. Amazon Athena is an interactive query service that makes it easier to analyze data in Amazon S3, by using standard SQL. For more information, see [Use Amazon Athena to query internet measurements in Amazon S3 log files](CloudWatch-IM-view-cw-tools.S3_athena.md).
# Examples of using the CLI with Internet Monitor
This section includes examples for using the AWS Command Line Interface with Internet Monitor operations.
Before you begin, make sure that you log in to use the AWS CLI with the same AWS account that has the Amazon VPC VPCs, Network Load Balancers, Amazon CloudFront distributions, or Amazon WorkSpaces directories that you want to monitor. Internet Monitor doesn't support accessing resources across accounts. For more information about using the AWS CLI, see the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/index.html). For more information about using API actions with Internet Monitor, see the [Internet Monitor API Reference Guide](https://docs.aws.amazon.com/internet-monitor/latest/api/Welcome.html).
**Topics**
+ [Create a monitor](#CloudWatch-IM-get-started-CLI-create-mon)
+ [View monitor details](#CloudWatch-IM-get-started-CLI-mon-details)
+ [List health events](#CloudWatch-IM-get-started-CLI-list-events)
+ [View specific health event](#CloudWatch-IM-get-started-CLI-view-event-specific)
+ [View monitor list](#CloudWatch-IM-get-started-CLI-monitor-list)
+ [Edit monitor](#CloudWatch-IM-get-started-CLI-edit-monitor)
+ [Delete monitor](#CloudWatch-IM-get-started-CLI-delete-monitor)
## Create a monitor
When you create a monitor in Internet Monitor, you provide a name and associate resources with the monitor to show where your application's internet traffic is. You specify a traffic percentage that defines how much of your application traffic is monitored. That also determines the number of city-networks, that is, client locations and ASNs, typically internet service providers or ISPs, that are monitored. You can also opt to set a limit for the maximum number of city-networks to monitor for your application resources, to help control your bill. For more information, see [Choose a city-networks maximum limit](IMCityNetworksMaximum.md).
Finally, you can choose if you want to publish all internet measurements for your application to Amazon S3. Internet measurements for the top 500 city-networks (by traffic volume) are automatically published to CloudWatch Logs by Internet Monitor, but you can choose to publish all measurements to S3 as well.
To create a monitor with the AWS CLI, you use the `create-monitor` command. The following command creates a monitor that monitors 100% of traffic but sets a maximum city-networks limit of 10,000, adds a VPC resource, and opts to publish internet measurements to Amazon S3.
**Note**
Internet Monitor publishes to CloudWatch Logs internet measurements every five minutes for the top 500 city-networks (client locations and ASNs, typically internet service providers or ISPs) that send traffic to each monitor. Optionally, you can choose to publish internet measurements for all monitored city-networks (up to the 500,000 city-networks service limit) to an Amazon S3 bucket. For more information, see [Publish internet measurements to Amazon S3 in Internet Monitor](CloudWatch-IM-get-started.Publish-to-S3.md).
```
aws internetmonitor create-monitor --monitor-name "TestMonitor" \
--traffic-percentage-to-monitor 100 \
--max-city-networks-to-monitor 10000 \
--resources "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889" \
--internet-measurements-log-delivery S3Config="{BucketName=amzn-s3-demo-bucket,LogDeliveryStatus=ENABLED}"
```
```
{
"Arn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor",
"Status": "ACTIVE"
}
```
**Note**
You can't change the name of a monitor.
## View monitor details
To view information about a monitor with the AWS CLI, you use the `get-monitor` command.
```
aws internetmonitor get-monitor --monitor-name "TestMonitor"
```
```
{
"ClientLocationType": "city",
"CreatedAt": "2022-09-22T19:27:47Z",
"ModifiedAt": "2022-09-22T19:28:30Z",
"MonitorArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor",
"MonitorName": "TestMonitor",
"ProcessingStatus": "OK",
"ProcessingStatusInfo": "The monitor is actively processing data",
"Resources": [
"arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
],
"MaxCityNetworksToMonitor": 10000,
"Status": "ACTIVE"
}
```
## List health events
When performance degrades for your application's internet traffic, Internet Monitor creates health events in your monitor. To see a list of current health events with the AWS CLI, use the `list-health-events` command.
```
aws internetmonitor list-health-events --monitor-name "TestMonitor"
```
```
{
"HealthEvents": [
{
"EventId": "2022-06-20T01-05-05Z/latency",
"Status": "RESOLVED",
"EndedAt": "2022-06-20T01:15:14Z",
"ServiceLocations": [
{
"Name": "us-east-1"
}
],
"PercentOfTotalTrafficImpacted": 1.21,
"ClientLocations": [
{
"City": "Lockport",
"PercentOfClientLocationImpacted": 60.370000000000005,
"PercentOfTotalTraffic": 2.01,
"Country": "United States",
"Longitude": -78.6913,
"AutonomousSystemNumber": 26101,
"Latitude": 43.1721,
"Subdivision": "New York",
"NetworkName": "YAHOO-BF1"
}
],
"StartedAt": "2022-06-20T01:05:05Z",
"ImpactType": "PERFORMANCE",
"EventArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor/health-event/2022-06-20T01-05-05Z/latency"
},
{
"EventId": "2022-06-20T01-17-56Z/latency",
"Status": "RESOLVED",
"EndedAt": "2022-06-20T01:30:23Z",
"ServiceLocations": [
{
"Name": "us-east-1"
}
],
"PercentOfTotalTrafficImpacted": 1.29,
"ClientLocations": [
{
"City": "Toronto",
"PercentOfClientLocationImpacted": 75.32,
"PercentOfTotalTraffic": 1.05,
"Country": "Canada",
"Longitude": -79.3623,
"AutonomousSystemNumber": 14061,
"Latitude": 43.6547,
"Subdivision": "Ontario",
"CausedBy": {
"Status": "ACTIVE",
"Networks": [
{
"AutonomousSystemNumber": 16509,
"NetworkName": "Amazon.com"
}
],
"NetworkEventType": "AWS"
},
"NetworkName": "DIGITALOCEAN-ASN"
},
{
"City": "Lockport",
"PercentOfClientLocationImpacted": 22.91,
"PercentOfTotalTraffic": 2.01,
"Country": "United States",
"Longitude": -78.6913,
"AutonomousSystemNumber": 26101,
"Latitude": 43.1721,
"Subdivision": "New York",
"NetworkName": "YAHOO-BF1"
},
{
"City": "Hangzhou",
"PercentOfClientLocationImpacted": 2.88,
"PercentOfTotalTraffic": 0.7799999999999999,
"Country": "China",
"Longitude": 120.1612,
"AutonomousSystemNumber": 37963,
"Latitude": 30.2994,
"Subdivision": "Zhejiang",
"NetworkName": "Hangzhou Alibaba Advertising Co.,Ltd."
}
],
"StartedAt": "2022-06-20T01:17:56Z",
"ImpactType": "PERFORMANCE",
"EventArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor/health-event/2022-06-20T01-17-56Z/latency"
},
{
"EventId": "2022-06-20T01-34-20Z/latency",
"Status": "RESOLVED",
"EndedAt": "2022-06-20T01:35:04Z",
"ServiceLocations": [
{
"Name": "us-east-1"
}
],
"PercentOfTotalTrafficImpacted": 1.15,
"ClientLocations": [
{
"City": "Lockport",
"PercentOfClientLocationImpacted": 39.45,
"PercentOfTotalTraffic": 2.01,
"Country": "United States",
"Longitude": -78.6913,
"AutonomousSystemNumber": 26101,
"Latitude": 43.1721,
"Subdivision": "New York",
"NetworkName": "YAHOO-BF1"
},
{
"City": "Toronto",
"PercentOfClientLocationImpacted": 29.770000000000003,
"PercentOfTotalTraffic": 1.05,
"Country": "Canada",
"Longitude": -79.3623,
"AutonomousSystemNumber": 14061,
"Latitude": 43.6547,
"Subdivision": "Ontario",
"CausedBy": {
"Status": "ACTIVE",
"Networks": [
{
"AutonomousSystemNumber": 16509,
"NetworkName": "Amazon.com"
}
],
"NetworkEventType": "AWS"
},
"NetworkName": "DIGITALOCEAN-ASN"
},
{
"City": "Hangzhou",
"PercentOfClientLocationImpacted": 2.88,
"PercentOfTotalTraffic": 0.7799999999999999,
"Country": "China",
"Longitude": 120.1612,
"AutonomousSystemNumber": 37963,
"Latitude": 30.2994,
"Subdivision": "Zhejiang",
"NetworkName": "Hangzhou Alibaba Advertising Co.,Ltd."
}
],
"StartedAt": "2022-06-20T01:34:20Z",
"ImpactType": "PERFORMANCE",
"EventArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor/health-event/2022-06-20T01-34-20Z/latency"
}
]
}
```
## View specific health event
To see a more detailed information about a specific health event with the CLI, run the `get-health-event` command with your monitor name and a health event ID.
```
aws internetmonitor get-monitor --monitor-name "TestMonitor" --event-id "health-event/TestMonitor/2021-06-03T01:02:03Z/latency"
```
```
{
"EventId": "2022-06-20T01-34-20Z/latency",
"Status": "RESOLVED",
"EndedAt": "2022-06-20T01:35:04Z",
"ServiceLocations": [
{
"Name": "us-east-1"
}
],
"EventArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor/health-event/2022-06-20T01-34-20Z/latency",
"LastUpdatedAt": "2022-06-20T01:35:04Z",
"ClientLocations": [
{
"City": "Lockport",
"PercentOfClientLocationImpacted": 39.45,
"PercentOfTotalTraffic": 2.01,
"Country": "United States",
"Longitude": -78.6913,
"AutonomousSystemNumber": 26101,
"Latitude": 43.1721,
"Subdivision": "New York",
"NetworkName": "YAHOO-BF1"
},
{
"City": "Toronto",
"PercentOfClientLocationImpacted": 29.770000000000003,
"PercentOfTotalTraffic": 1.05,
"Country": "Canada",
"Longitude": -79.3623,
"AutonomousSystemNumber": 14061,
"Latitude": 43.6547,
"Subdivision": "Ontario",
"CausedBy": {
"Status": "ACTIVE",
"Networks": [
{
"AutonomousSystemNumber": 16509,
"NetworkName": "Amazon.com"
}
],
"NetworkEventType": "AWS"
},
"NetworkName": "DIGITALOCEAN-ASN"
},
{
"City": "Shenzhen",
"PercentOfClientLocationImpacted": 4.07,
"PercentOfTotalTraffic": 0.61,
"Country": "China",
"Longitude": 114.0683,
"AutonomousSystemNumber": 37963,
"Latitude": 22.5455,
"Subdivision": "Guangdong",
"NetworkName": "Hangzhou Alibaba Advertising Co.,Ltd."
},
{
"City": "Hangzhou",
"PercentOfClientLocationImpacted": 2.88,
"PercentOfTotalTraffic": 0.7799999999999999,
"Country": "China",
"Longitude": 120.1612,
"AutonomousSystemNumber": 37963,
"Latitude": 30.2994,
"Subdivision": "Zhejiang",
"NetworkName": "Hangzhou Alibaba Advertising Co.,Ltd."
}
],
"StartedAt": "2022-06-20T01:34:20Z",
"ImpactType": "PERFORMANCE",
"PercentOfTotalTrafficImpacted": 1.15
}
```
## View monitor list
To see a list of all monitors in your account with the CLI, run the `list-monitors` command.
```
aws internetmonitor list-monitors
```
```
{
"Monitors": [
{
"MonitorName": "TestMonitor",
"ProcessingStatus": "OK",
"Status": "ACTIVE"
}
],
"NextToken": " zase12"
}
```
## Edit monitor
To update information about your monitor by using the CLI, use the `update-monitor` command and specify the name of the monitor to update. For example, you can update the percentage of traffic to monitor, the limit of the maximum number of city-networks to monitor, add or remove the resources that Internet Monitor uses to monitor traffic, and change the monitor status from `ACTIVE` to `INACTIVE`, or vice versa. Note that you can't change the name of the monitor.
The response for an `update-monitor` call returns just the `MonitorArn` and the `Status`.
The following example shows how to use the `update-monitor` command to change the maximum number of city-networks to monitor to `50000`:
```
aws internetmonitor update-monitor --monitor-name "TestMonitor" --max-city-networks-to-monitor 50000
```
```
{
"MonitorArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor",
"Status": " ACTIVE "
}
```
The following example shows how to add and remove resources:
```
aws internetmonitor update-monitor --monitor-name "TestMonitor" \
--resources-to-add "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889" \
--resources-to-remove "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-2222444455556666"
```
```
{
"MonitorArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor",
"Status": "ACTIVE"
}
```
The following example shows how to use the `update-monitor` command to change the monitor status to `INACTIVE`:
```
aws internetmonitor update-monitor --monitor-name "TestMonitor" --status "INACTIVE"
```
```
{
"MonitorArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/TestMonitor",
"Status": "INACTIVE"
}
```
## Delete monitor
You can delete a monitor with the CLI by using the `delete-monitor` command. First, you must set the monitor to be inactive. To do that, use the `update-monitor` command to change the status to `INACTIVE`. Confirm that the monitor is inactive by using the `get-monitor` command and checking the status.
When the monitor status is `INACTIVE`, then you can use the CLI to run the `delete-monitor` command to delete the monitor. The response for a successful `delete-monitor` call is empty.
```
aws internetmonitor delete-monitor --monitor-name "TestMonitor"
```
```
{}
```
# Monitor and optimize with the Internet Monitor dashboard
Using the Internet Monitor dashboard in the AWS Management Console, you can visualize data and get insights and suggestions about your AWS application's internet traffic, and configure options for your monitor.
After you create a monitor to monitor your application's internet performance and availability, Internet Monitor stores internet measurements for pairs of your client locations and ASNs, or *city-networks*. Internet Monitor also creates aggregated CloudWatch metrics for traffic to your application, and to each AWS Region and edge location. You can filter, explore, and get action-oriented suggestions from your monitor's information in several different ways. The Internet Monitor dashboard guides you through viewing and getting insights about the data for your monitored traffic.
To get started, on the CloudWatch console, under **Network Monitoring**, choose **Internet monitors**. Then, select a monitor to work with.
**Note**
This section primarily describes how to filter and view Internet Monitor metrics using the AWS Management Console. Alternatively, you can use Internet Monitor API operations with the AWS CLI or an SDK to work directly with Internet Monitor events stored in CloudWatch Logs files. For more information, see [Using your monitor and measurements information](IMWhyCreateMonitor.md#IMAccessIMInformation). For more information about using API operations, see [Examples of using the CLI with Internet Monitor](CloudWatch-IM-get-started-CLI.md) and the [Internet Monitor API Reference](https://docs.aws.amazon.com/internet-monitor/latest/api/Welcome.html).
There are five pages (tabs) in the Internet Monitor dashboard:
+ On the **Overview** page, you can get an overall view of your monitored traffic, including current performance and availability information, a summary of recent and current health events, and the top suggestion for potentially improving performance for your clients.
+ On the **Health events** page, you can see current and historical health events that currently impact, or previously impacted, locations where clients access your application.
+ On the **Analyze** page, you can view information about top monitored traffic in client locations (by traffic volume), summarized in several customizable ways. You can also see historical trends for health scores and metrics. You can filter by location, ASN, date, and so on, and visualize metrics for your internet traffic over time.
+ On the **Optimize** page, Internet Monitor predicts your application's performance improvement for top AWS Regions (or Amazon CloudFront), based on your traffic patterns and past performance. For each top configuration, associated tables provide a breakdown of reduced latency by client location. On a second page, you can select multiple Regions (and, if you like, include CloudFront configurations) to compare latency reductions. For each configuration (Region) that you selected, the page displays an associated table of latency details, listed by city location.
+ On the **Configure** page, you can see monitor details and configure options, such as the percentage of traffic to monitor.
In addition to these dashboard options, you can use tools for deeper dives into details of the metrics that Internet Monitor collects with your monitor. Internet Monitor generates and publishes log files with the measurements about your traffic, so you can use other CloudWatch tools in the console to further visualize the data published by Internet Monitor, including CloudWatch Contributor Insights, CloudWatch Metrics, and CloudWatch Logs Insights. For more information, see [Exploring your data with CloudWatch tools and the Internet Monitor query interface](CloudWatch-IM-view-cw-tools.md).
Learn about using Internet Monitor to explore your performance and availability measurements in the following sections.
**Topics**
+ [Track real-time performance and availability in Internet Monitor (Overview page)](CloudWatch-IM-overview.md)
+ [View health events and metrics in Internet Monitor (Health events page)](CloudWatch-IM-Health-events.md)
+ [Analyze historical data in Internet Monitor (Analyze page)](CloudWatch-IM-historical-explorer.md)
+ [Get suggestions to optimize application performance in Internet Monitor (Optimize page)](CloudWatch-IM-insights.md)
+ [Monitoring details in Internet Monitor (Configure page)](CloudWatch-IM-configure.md)
# Track real-time performance and availability in Internet Monitor (Overview page)
The **Overview** page in the Internet Monitor console shows you a high-level view of performance and availability for the traffic that your monitor tracks, and a timeline of when health events have impacted your monitored traffic. The page also provides the top suggestion for a configuration change that could reduce latency for clients who use your application in your top client location (by traffic volume).
**Traffic overview and Status**
The **Traffic overview** section provides an overall look at your application's availability and performance. Note that this section shows *aggregated* overall performance and availability scores that consider all of the traffic for applications towards all end users and service locations. You can see health scores for specific client locations and service locations by searching and filtering measurements information on the **Analyze** tab.
Under **Status**, you can see if your monitor is actively creating data for your monitor or is waiting for data to be available. You can also see the percentage of your application's traffic that you're monitoring. If you want to change the percentage, see the **Configure** page.
Internet Monitor uses a statistical process to create availability and performance scores for your monitored traffic. AWS has substantial historical data about internet performance and availability for network traffic between geographic locations for different ASNs and AWS services. Internet Monitor uses the connectivity data that AWS has captured from its global networking footprint to calculate a baseline of availability and performance for internet traffic. This is the same data that we use at AWS to monitor our own internet uptime and availability.
With those measurements as a baseline, Internet Monitor can detect when the performance and availability for your application has dropped, compared to the baseline. To make it easier to see those drops, we report that information to you as a performance score and an availability score.
For more information, see [How AWS calculates performance and availability scores](CloudWatch-IM-inside-internet-monitor.md#IMExperienceScores).
**Health events timeline**
The **Health events timeline** graph displays health events that have occurred during the past 24 hours. A summary below the graph shows your application's current and recent impact. For details, you can choose **See more health events**.
To change the thresholds for health events, go to the **Configure** page.
**Reduce latency for your top Region**
Internet Monitor automatically evaluates the AWS Region that your current application configuration uses most (that is, the Region with the highest client volume), and determines if another Region could provide a better aggregate time to first byte (TTFB) for your clients.
Note that because this is the aggregate TTFB, if you move traffic from one Region to another, TTFB for most locations is expected to improve but clients in some Regions could see no change or reduced performance..
To explore more latency improvement suggestions, including details at more granular levels (such as by client location), see the **Optimize** page.
# View health events and metrics in Internet Monitor (Health events page)
The **Health events** page in the Internet Monitor console provides a map of health events that impact the client locations and ASNs for your application. You can click circles on the map for more details about an event. The **Health events** tables lists locations that have been impacted by an event, and specifics about the impact.
**Internet traffic overview**
The **Internet traffic overview** map shows you the internet traffic and health events that are specific to the locations and ASNs that your clients access your application from. The countries that are gray on the map are those that include traffic for your application.
Each circle on the map indicates a health event in an area, for a time period that you select. Internet Monitor creates health events when it detects a problem, at a specific (but customizable) threshold, with connectivity between one of your resources hosted in AWS and a city-network where a client is accessing your application.
Choose a circle on the map to display more details about the health event for that location. In addition, for clusters that have health events, you can see detailed information in the **Health events** table below the map.
Note that Internet Monitor creates health events in a monitor when it determines that an event has significant impact on your application. The map is blank if there aren't any health events that exceed the threshold for impact on traffic for your client locations in the time period that you've selected. For more information, see [When Internet Monitor creates and resolves health events](CloudWatch-IM-inside-internet-monitor.md#IMHealthEventStartStop).
**Health events**
The **Health events** table lists client locations that have been affected by health events, along with information about the events. The following columns are included in the table.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-IM-Health-events.html)
If you choose one of the client locations in the **Health events** table, you can see more details about the health event at that location. For example, you can see when the event started, when it ended, and the local traffic impact.
**Network path visualization**
If Internet Monitor has finished impairment analysis for an event, you can view **Network path visualization** to see the full network path for traffic to a client location. The full path shows you each node along the network path for your application for the health event, between the AWS location and the client, for a client-location pair.
When Internet Monitor has determined the cause of an impairment, Internet Monitor adds a dashed red circle around the node. Impairments can be caused by ASNs, typically internet service providers (ISPs), or the cause can be AWS. If there were multiple causes for an impairment, multiple nodes are circled.
# Analyze historical data in Internet Monitor (Analyze page)
On the **Analyze** page in the Internet Monitor console, you can view your application's the top client locations for the traffic that you monitor, by traffic volume. You can also view graphs showing performance and availability scores for your traffic over time, as well as graphs of other internet traffic metrics for your application's monitored traffic.
To start exploring Internet Monitor data for your application traffic, select a time period. Then, choose a specific geographical location, such a city, and (optionally) other filters. Internet Monitor applies the filters to your data, and then you can see graphs of the data that show measurements for your application. The graphs included on the **Analyze** page include your application's performance score, availability score, monitored bytes transferred (for VPCs, Network Load Balancers, and CloudFront distributions) or client connection counts (for WorkSpaces directories), and round-trip time (RTT) for your application over time.
The options at the top of the **Analyze** page determine the timeframe and types of traffic shown in the graphs on the page. You can filter by client locations or ASN, or choose to show traffic graphs at a specific granularity (the default is city level).
**Top client locations**
The **Top client locations** graph displays your top monitored traffic locations, by default. You can choose another field to sort the graph by, or you can sort the graph in other ways, for example, by lowest traffic locations.
The filters that you choose for the page determine the Regions, timeframe, and so on for the locations.
**Traffic health scores**
This section shows you graphs of traffic health scores and metrics for your monitored traffic. These graphs reflect data for the filters that you choose at the top of the page.
The **Traffic health scores** graph shows you performance and availability information for your local and overall traffic by calling out health events that have impacted your monitored client traffic. AWS has substantial historical data about internet performance and availability for network traffic between geographic locations for different ASNs and AWS services. Internet Monitor uses the connectivity data that AWS has captured from its global networking footprint to calculate a baseline of performance and availability for internet traffic. This is the same data that we use at AWS to monitor our own internet uptime and availability.
With those measurements as a baseline, Internet Monitor can detect when the performance and availability for your application has dropped, compared to the baseline. To make it easier to see those drops, we report that information to you as a performance score and an availability score. For more information, see [How AWS calculates performance and availability scores](CloudWatch-IM-inside-internet-monitor.md#IMExperienceScores).
Additional graphs show the monitored bytes transferred (for VPCs, Network Load Balancers, and CloudFront distributions) or client connection counts (for WorkSpaces directories), and round-trip time (RTT) for your application traffic.
Note that when round-trip time (RTT) is aggregated across end-user locations, the value is weighted by the amount of your traffic that is driven by each client location. For example, with two client locations, one serving 90% of traffic with a 5 ms RTT, and the other serving 10% of traffic with a 10 ms RTT, the result is an aggregated RTT of 5.5 ms (which comes from 5 ms \$1 0.9 \$1 10 ms \$1 0.1).
You can also explore the internet measurements that Internet Monitor stores for your monitored traffic by using CloudWatch tools or other methods. For more information, see [Exploring your data with CloudWatch tools and the Internet Monitor query interface](CloudWatch-IM-view-cw-tools.md). In addition, you can create CloudWatch alarms based on Internet Monitor data, for example, to notify you of health events. For more information, see [Create alarms with Internet Monitor](CloudWatch-IM-create-alarm.md).
# Get suggestions to optimize application performance in Internet Monitor (Optimize page)
Use the **Optimize** page in the Internet Monitor console to get suggestions for how to optimize application performance for your clients. Internet Monitor evaluates your monitored application traffic, and determines if you can reduce latency by changing the AWS Regions that you've configured for your application. Optionally, you can also view latency changes if you choose to include Amazon CloudFront in the suggestions.
You can review suggestions for your application's top Regions by traffic volume, or for top client locations, also by traffic volume.
****Suggestions to reduce latency for top Regions****
To help you quickly understand your best options for reducing latency for your clients, Internet Monitor automatically provides suggestions for improving latency in your application for your top Regions (by traffic volume).
You can also explore configuration changes for all the Regions where your application serves clients. This includes getting details about each suggested change at deeper levels of granularity, for example, by specific client location. To explore all Regional configurations and expected latency changes for your application, choose **Optimization suggestions for all Regions**.
****Suggestions to reduce latency for all Regions****
To explore suggestions for reducing latency for all Regions where clients access your application, choose **Optimization suggestions for all Regions** to open a new dashboard page. On this page, you can select different Regions to configure, with the option of including CloudFront as a configuration comparison, and then compare the times to first byte (TTFBs) for each selected configuration.
Then, for each comparison, you can also see a table with at a more granular level (by client location), with the average expected TTFB for each one.
****Suggestions to reduce latency for top locations****
Internet Monitor also provides suggestions for reducing application latency for your clients by specific location. When the table lists multiple suggestions for the same location, expand the city location for that row to see details.
Be aware that if you change a configuration to use a different Region or to use CloudFront, latency improvements can vary by client location. For example, latency might improve for some locations, but stay the same or worsen for others.
****Suggestions to reduce latency by updating routing configurations****
Note: These suggestions are only relevant for application traffic to Regional load balancers. The table is not shown for monitors that you create for CloudFront distributions or WorkSpaces resources.
With Internet Monitor, you can view information about latency toward AWS locations for IPv4 IP prefixes that access your application using different DNS resolvers (typically ISPs). Using this information, you can take steps to reduce latency for specific groups of users by routing a set of IP address prefixes, specified by a CIDR collection, to your endpoints in a Region that results in lower latency for your users. If you don't already have a CIDR collection for the prefixes, you can go to Amazon Route 53 to create one. Then, you can update your routing in Route 53 to route IP addresses in the collection to a specific Region.
If you want to create a CIDR collection for a set of IP address prefixes, you can easily do so by selecting a row or rows that includes the IP prefixes that you want, and then choosing **Add to CIDR collection**. Then, in the Route 53 console, you can configure a routing policy that routes IP addresses in the collection to the Region with lower latency for your application.
To learn more about IP-based routing in Route 53, see [IP-based routing](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-ipbased.html).
By viewing the suggestions on this page, you can start planning configurations and deployments that can improve performance for your clients. Note that you might see a dash (-) instead of a value in a column, when data is not available to display.
For more information about TTFB calculations, see [AWS calculations for TTFB and latency](CloudWatch-IM-inside-internet-monitor.md#IMCalculateTTFB). To review a specific example of how to improve performance, see [ Using Internet Monitor for a Better Gaming Experience](https://aws.amazon.com/blogs/gametech/using-cloudwatch-internet-monitor-for-a-better-gaming-experience/).
# Monitoring details in Internet Monitor (Configure page)
On the **Configure** page, you can see details about your monitor, including a list of resources that you monitor traffic for and the thresholds for when health events are triggered. You can also explore and compare values for the traffic percentage for your monitor, and its impact on how many city-networks are included for (monitored by) your monitor. Finally, you can view information about measurements that are published to an Amazon S3 bucket.
You can configure a monitor to change most options, such as the percentage of traffic to monitor. For more information, see [Configure your monitor](#IMUpdateMonitorConfig).
## Monitor details
The **Monitor details** section includes basic information about your monitor, including the name, the percentage of traffic currently being monitored for your application, a city-networks maximum limit (if you've set one), and status information about the monitor.
The following explains the values that you might see for **Status** and **Status info** (data processing status).
| Status | Description |
| --- | --- |
| Active | Monitor is created and active. |
| Pending | Monitor is currently being created and is not yet active. |
| Inactive | Monitor is created but has been set to inactive. |
| Error | Monitor is in an error state. |
| Status details (Data processing status) | Description |
| --- | --- |
| OK | Monitor is actively processing data. |
| Inactive | Monitor is inactive and is not processing data. |
| Collecting data | Monitor is actively collecting data. |
| Insufficient data | Monitor is actively processing data, but there aren't enough datapoints to produce insights. |
| Fault access CloudWatch | Monitor has encountered a problem delivering CloudWatch metrics data and log events. |
## Health event thresholds
In this section, you can see the current thresholds for health events that are configured for this monitor. If you haven't configured any custom thresholds, the values shown here are the default values.
By default, health events are not triggered based on local thresholds. If local health event thresholds would be useful for your Internet Monitor scenario, you can enable the option and specify the thresholds to use.
You can learn more about how health event thresholds work, and review the potential impact of adding local thresholds or changing existing thresholds. For more information, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
## Traffic coverage
In this section, you can explore options for the traffic coverage for your monitor. When you change the traffic percentage for a monitor, Internet Monitor monitors different amounts of application traffic. If you set a traffic percentage to less than 100% (100% is the default value), some portion of the city-networks that your clients use to access your application might not be monitored. By exploring the impact of different traffic percentage values, you can see how different values that you might set would impact your city-networks coverage.
The **Total monitored city-networks** graph shows you how many city-networks are currently monitored, and how many would be monitored if you set the traffic percentage to 100%. To view different traffic percentage values on the graph, select percentages in the drop-down menu.
After you explore the options, you can change the traffic percentage to monitor by choosing **Update monitoring coverage**.
If you want to set a maximum city-networks limit, at the top of the page, choose **Edit monitor**. Then, under **Advanced options**, set a maximum city-networks value.
## Configure your monitor
As on every page in the Internet Monitor dashboard, you can choose **Edit monitor** to change options for your monitor, including adding or removing resources. For details about how to update the following configuration options, see the provided links.
**View health event thresholds**
In this section, you can see the current thresholds for health events that are configured for this monitor.
To update health thresholds, see [Change health event thresholds](CloudWatch-IM-get-started.change-threshold.md#IMUpdateThresholdFromOverview).
**View and evaluate traffic coverage**
In this section, you can compare the effect of changing the percentage of traffic that you monitor for your application on the number of city-networks that are included (for monitoring) when you choose different percentage values.
You can also change the percentage of traffic that you monitor, or change the limit for the number of city-networks your monitor includes. To change the percentage of traffic, choose **Update monitoring coverage**.
For detailed steps and information, see [Explore changing your application traffic percentage](IMTrafficPercentage.md#IMExploreTrafficPercentage).
**Configuration details for publishing internet measurements to Amazon S3**
If you have configured Internet Monitor to publish internet measurements for your monitor to an Amazon S3 bucket, the information about your configuration is shown here.
To configure this option, see [Publishing internet measurements to S3](CloudWatch-IM-get-started.Publish-to-S3.md#IMPublishToS3).
# Exploring your data with CloudWatch tools and the Internet Monitor query interface
In addition to visualizing your performance and availability for your application with the Internet Monitor dashboard, there are several methods that you can use to dive deeper into the data that Internet Monitor generates for you. These methods include using CloudWatch tools with Internet Monitor data stored in CloudWatch Log files and using the Internet Monitor query interface. The tools that you can use include CloudWatch Logs Insights, CloudWatch Metrics, CloudWatch Contributor Insights, and Amazon Athena. You can use some or all these tools, as well as the dashboard, to explore Internet Monitor data, depending on your needs.
Internet Monitor aggregates CloudWatch metrics about traffic to your application and to each AWS Region, and includes data such as total traffic impact, availability, and round-trip time. This data is published to CloudWatch Logs and is also available to use with the Internet Monitor query interface. Details about geo-granularity and other aspects of the information available to explore for each one varies.
Internet Monitor publishes data for your monitor at 5 minute intervals, and then makes the data available in several ways. The following table lists scenarios for accessing Internet Monitor data, and describes features of the data that is collected for each one.
****
| Feature | CloudWatch Logs | Export to S3 | Query interface | CloudWatch dashboard |
| --- | --- | --- | --- | --- |
| Enabled by default | Yes | No | Yes | Yes |
| Number of city-networks that data is collected for | Top 500 (see note below) | All | All | All |
| Data retention | User controlled | User controlled | 30 days | 30 days |
| Geo-granularities that data is collected for | All (city-network, metro\$1network, subdivision\$1network, country\$1network) | City-network | All (city-network, metro\$1network, subdivision\$1network, country\$1network) | All (city-network, metro\$1network, subdivision\$1network, country\$1network) |
| How to query and filter data | [Use CloudWatch Logs Insights to explore Internet Monitor measurements](CloudWatch-IM-view-cw-tools-logs-insights.md) | [Use Amazon Athena to query internet measurements in Amazon S3 log files](CloudWatch-IM-view-cw-tools.S3_athena.md) | [Use the Internet Monitor query interface](CloudWatch-IM-view-cw-tools-cwim-query.md) | [Monitor and optimize with the Internet Monitor dashboard](CloudWatch-IM-monitor-and-optimize.md) |
Note: Top 500 measurements are captured for city-networks; top 250 for metro\$1networks, top 100 for subdivision\$1networks, top 50 for country\$1networks.
This chapter describes how to query and explore your data by using CloudWatch tools or the Internet Monitor query interface, together with examples for each method.
**Topics**
+ [CloudWatch Logs Insights](CloudWatch-IM-view-cw-tools-logs-insights.md)
+ [CloudWatch Contributor Insights](CloudWatch-IM-view-cw-tools-contributor-insights.md)
+ [CloudWatch Metrics](CloudWatch-IM-view-cw-tools-metrics-dashboard.md)
+ [Athena with S3 logs](CloudWatch-IM-view-cw-tools.S3_athena.md)
+ [Internet Monitor query interface](CloudWatch-IM-view-cw-tools-cwim-query.md)
# Use CloudWatch Logs Insights to explore Internet Monitor measurements
You can use CloudWatch Logs Insights queries to filter a subset of logs for a specific city or geography (client location), client ASN (ISP), and AWS source location. Internet Monitor publishes granular measurements of availability and round-trip time to CloudWatch Logs that you can explore using CloudWatch Logs Insights.
To learn more about client location accuracy in Internet Monitor, see [ Geolocation information and accuracy in Internet Monitor](CloudWatch-IM-inside-internet-monitor.md#IMGeolocationSourceAccuracy).
The examples in this section can help you create CloudWatch Logs Insights queries to learn more about your own application traffic measurements and metrics. If you use these examples in CloudWatch Logs Insights, replace *monitorName* with your own monitor name.
**View traffic optimization suggestions**
On the **Traffic insights** tab in Internet Monitor, you can view traffic optimization suggestions, filtered by a location. To see the same information that is displayed in the **Traffic optimization suggestions** section on that tab, but without the location granularity filter, you can use the following CloudWatch Logs Insights query.
1. In the AWS Management Console, navigate to CloudWatch Logs Insights.
1. For **Log Group**, select `/aws/internet-monitor/monitorName/byCity` and `/aws/internet-monitor/monitorName/byCountry`, and then specify a time range.
1. Add the following query, and then run the query.
```
fields @timestamp,
clientLocation.city as @city, clientLocation.subdivision as @subdivision, clientLocation.country as @country,
`trafficInsights.timeToFirstByte.currentExperience.serviceName` as @serviceNameField,
concat(@serviceNameField, ` (`, `serviceLocation`, `)`) as @currentExperienceField,
concat(`trafficInsights.timeToFirstByte.ec2.serviceName`, ` (`, `trafficInsights.timeToFirstByte.ec2.serviceLocation`, `)`) as @ec2Field,
`trafficInsights.timeToFirstByte.cloudfront.serviceName` as @cloudfrontField,
concat(`clientLocation.networkName`, ` (AS`, `clientLocation.asn`, `)`) as @networkName
| filter ispresent(`trafficInsights.timeToFirstByte.currentExperience.value`)
| stats avg(`trafficInsights.timeToFirstByte.currentExperience.value`) as @averageTTFB,
avg(`trafficInsights.timeToFirstByte.ec2.value`) as @ec2TTFB,
avg(`trafficInsights.timeToFirstByte.cloudfront.value`) as @cloudfrontTTFB,
sum(`bytesIn` + `bytesOut`) as @totalBytes,
latest(@ec2Field) as @ec2,
latest(@currentExperienceField) as @currentExperience,
latest(@cloudfrontField) as @cloudfront,
count(*) by @networkName, @city, @subdivision, @country
| display @city, @subdivision, @country, @networkName, @totalBytes, @currentExperience, @averageTTFB, @ec2, @ec2TTFB, @cloudfront, @cloudfrontTTFB
| sort @totalBytes desc
```
**View internet availability and RTT (p50, p90, and p95)**
To view the internet availability and round-trip time (p50, p90, and p95) for traffic, you can use the following CloudWatch Logs Insights query.
**End user geography: ** Chicago, IL, United States
**End user network (ASN): ** AS7018
**AWS service location: ** US East (N. Virginia) Region
To view the logs, do the following:
1. In the AWS Management Console, navigate to CloudWatch Logs Insights.
1. For **Log Group**, select `/aws/internet-monitor/monitorName/byCity` and `/aws/internet-monitor/monitorName/byCountry`, and then specify a time range.
1. Add the following query, and then run the query.
The query returns all the performance data for users connecting from AS7018 in Chicago, IL towards US East (N. Virginia) Region over the selected time period.
```
fields @timestamp,
internetHealth.availability.experienceScore as availabilityExperienceScore,
internetHealth.availability.percentageOfTotalTrafficImpacted as percentageOfTotalTrafficImpacted,
internetHealth.performance.experienceScore as performanceExperienceScore,
internetHealth.performance.roundTripTime.p50 as roundTripTimep50,
internetHealth.performance.roundTripTime.p90 as roundTripTimep90,
internetHealth.performance.roundTripTime.p95 as roundTripTimep95
| filter clientLocation.country == `United States`
and clientLocation.city == `Chicago`
and serviceLocation == `us-east-1`
and clientLocation.asn == 7018
```
For more information, see [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).
# Use Contributor Insights to identify top locations and ISPs
CloudWatch Contributor Insights can help you identify top client locations and ASNs (typically, internet service providers or ISPs) for your AWS application. Use the following sample Contributor Insights rules to get started with rules that are useful with Internet Monitor. For more information, see [Create a Contributor Insights rule in CloudWatch](ContributorInsights-CreateRule.md).
To learn more about client location accuracy in Internet Monitor, see [ Geolocation information and accuracy in Internet Monitor](CloudWatch-IM-inside-internet-monitor.md#IMGeolocationSourceAccuracy).
**Note**
Internet Monitor stores internet measurements data every five minutes, so after you set up a Contributor Insights rule, you must adjust the period to five minutes to see a graph.
**View top locations and ASNs impacted by an availability impact**
To view top client locations and ASNs impacted by a drop in availability, you can use the following Contributor Insights rule in the Syntax editor. Replace *monitor-name* with your own monitor name.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Sum",
"Contribution": {
"Filters": [
{
"Match": "$.clientLocation.city",
"IsPresent": true
}
],
"Keys": [
"$.clientLocation.city",
"$.clientLocation.networkName"
],
"ValueOf": "$.awsInternetHealth.availability.percentageOfTotalTrafficImpacted"
},
"LogFormat": "JSON",
"LogGroupNames": [
"/aws/internet-monitor/monitor-name/byCity"
]
}
```
**View top client locations and ASNs impacted by a latency impact**
To view top client locations and ASNs impacted by an increase in round-trip time (latency), you can use the following Contributor Insights rule in the Syntax editor. Replace *monitor-name* with your own monitor name.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Sum",
"Contribution": {
"Filters": [ {
"Match": "$.clientLocation.city",
"IsPresent": true
}
],
"Keys": [
"$.clientLocation.city",
"$.clientLocation.networkName"
],
"ValueOf": "$.awsInternetHealth.performance.percentageOfTotalTrafficImpacted"
},
"LogFormat": "JSON",
"LogGroupNames": [
"/aws/internet-monitor/monitor-name/byCity"
]
}
```
**View top client locations and ASNs impacted by total percentage of traffic**
To view top client locations and ASNs impacted by total percentage of traffic, you can use the following Contributor Insights rule in the Syntax editor. Replace *monitor-name* with your own monitor name.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Sum",
"Contribution": {
"Filters": [
{
"Match": "$.clientLocation.city",
"IsPresent": true
}
],
"Keys": [
"$.clientLocation.city",
"$.clientLocation.networkName"
],
"ValueOf": "$.percentageOfTotalTraffic"
},
"LogFormat": "JSON",
"LogGroupNames": [
"/aws/internet-monitor/monitor-name/byCity"
]
}
```
# View Internet Monitor metrics or set alarms in CloudWatch Metrics
You can view or set alarms on Internet Monitor metrics by using CloudWatch alarms and CloudWatch Metrics in the CloudWatch console. Internet Monitor publishes metrics to your account, including metrics for performance, availability, round-trip time, and throughput (bytes per second). To find all metrics for your monitor, in the CloudWatch Metrics dashboard, see the custom namespace `AWS/InternetMonitor`.
To see examples for using several of these metrics to help determine values to choose for a city-networks maximum limit for your monitor, see [Choosing a city-network maximum value](IMCityNetworksMaximum.md). To learn more about setting alarms for Internet Monitor, see [Create alarms with Internet Monitor](CloudWatch-IM-create-alarm.md).
Metrics are aggregated across all internet traffic to your VPCs, Network Load Balancers, CloudFront distributions, or WorkSpaces directories in the monitor, and to all traffic to each AWS Region and internet edge location that is monitored. Regions are defined by the service location, which can either be all locations or a specific Region, such as `us-east-1`.
Note: *city-networks* are pairs of client locations and the ASNs the clients use (typically internet service providers or ISPs).
Internet Monitor provides the following metrics.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-IM-view-cw-tools-metrics-dashboard.html)
For more information, see [Metrics in Amazon CloudWatch](working_with_metrics.md).
# Use Amazon Athena to query internet measurements in Amazon S3 log files
You can use Amazon Athena to query and view the internet measurements that Internet Monitor publishes to an Amazon S3 bucket. There's an option in Internet Monitor to publish internet measurements for your application to an S3 bucket for internet-facing traffic for your monitored city-networks (client locations and ASNs, typically internet service providers or ISPs). Regardless of whether you choose to publish measurements to S3, Internet Monitor automatically publishes internet measurements to CloudWatch Logs every five minutes for the top 500 (by traffic volume) city-networks for each monitor.
This chapter includes steps for how to create a table in Athena for internet measurements located in an S3 log file, and then provides [example queries](#CloudWatch-IM-view-cw-tools.S3_athena.athena-sample-queries) to see different views of the measurements. For example, you can query for your top 10 impacted city-networks by latency impact.
## Using Amazon Athena to create a table for internet measurements in Internet Monitor
To start using Athena with your Internet Monitor S3 log files, you first create a table for the internet measurements.
Follow the steps in this procedure to create a table in Athena based on the S3 log files. Then, you can run Athena queries on the table, such as [these example internet measurements queries](#CloudWatch-IM-view-cw-tools.S3_athena.athena-sample-queries), to get information about your measurements.
**To create an Athena table**
1. Open the Athena console at [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/).
1. In the Athena query editor, enter a query statement to generate a table with Internet Monitor internet measurements. Replace the value for the LOCATION parameter with the location of S3 bucket where your Internet Monitor internet measurements are stored.
```
CREATE EXTERNAL TABLE internet_measurements (
version INT,
timestamp INT,
clientlocation STRING,
servicelocation STRING,
percentageoftotaltraffic DOUBLE,
bytesin INT,
bytesout INT,
clientconnectioncount INT,
internethealth STRING,
trafficinsights STRING
)
PARTITIONED BY (year STRING, month STRING, day STRING)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION
's3://amzn-s3-demo-bucket/bucket_prefix/AWSLogs/account_id/internetmonitor/AWS_Region/'
TBLPROPERTIES ('skip.header.line.count' = '1');
```
1. Enter a statement to create a partition to read the data. For example, the following query creates a single partition for a specified date and location:
```
ALTER TABLE internet_measurements
ADD PARTITION (year = 'YYYY', month = 'MM', day = 'dd')
LOCATION
's3://amzn-s3-demo-bucket/bucket_prefix/AWSLogs/account_id/internetmonitor/AWS_Region/YYYY/MM/DD';
```
1. Choose **Run**.
**Example Athena statements for internet measurements**
The following is an example of a statement to generate a table:
```
CREATE EXTERNAL TABLE internet_measurements (
version INT,
timestamp INT,
clientlocation STRING,
servicelocation STRING,
percentageoftotaltraffic DOUBLE,
bytesin INT,
bytesout INT,
clientconnectioncount INT,
internethealth STRING,
trafficinsights STRING
)
PARTITIONED BY (year STRING, month STRING, day STRING)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://internet-measurements/TestMonitor/AWSLogs/1111222233332/internetmonitor/us-east-2/'
TBLPROPERTIES ('skip.header.line.count' = '1');
```
The following is an example of a statement to create a partition to read the data:
```
ALTER TABLE internet_measurements
ADD PARTITION (year = '2023', month = '04', day = '07')
LOCATION 's3://internet-measurements/TestMonitor/AWSLogs/1111222233332/internetmonitor/us-east-2/2023/04/07/'
```
## Sample Amazon Athena queries to use with internet measurements in Internet Monitor
This section includes example queries that you can use with Amazon Athena to get information about your application's internet measurements published to Amazon S3.
**Query your top 10 impacted (by total percentage of traffic) client locations and ASNs**
Run this Athena query to return your top 10 impacted (by total percentage of traffic) city-networks—that is, client locations and ASNs, typically internet service providers.
```
SELECT json_extract_scalar(clientLocation, '$.city') as city,
json_extract_scalar(clientLocation, '$.networkname') as networkName,
sum(percentageoftotaltraffic) as percentageoftotaltraffic
FROM internet_measurements
GROUP BY json_extract_scalar(clientLocation, '$.city'),
json_extract_scalar(clientLocation, '$.networkname')
ORDER BY percentageoftotaltraffic desc
limit 10
```
**Query your top 10 impacted (by availability) client locations and ASNs **
Run this Athena query to return your top 10 impacted (by total percentage of traffic) city-networks—that is, client locations and ASNs, typically internet service providers.
```
SELECT json_extract_scalar(clientLocation, '$.city') as city,
json_extract_scalar(clientLocation, '$.networkname') as networkName,
sum(
cast(
json_extract_scalar(
internetHealth,
'$.availability.percentageoftotaltrafficimpacted'
)
as double )
) as percentageOfTotalTrafficImpacted
FROM internet_measurements
GROUP BY json_extract_scalar(clientLocation, '$.city'),
json_extract_scalar(clientLocation, '$.networkname')
ORDER BY percentageOfTotalTrafficImpacted desc
limit 10
```
**Query your top 10 impacted (by latency) client locations and ASNs **
Run this Athena query to return your top 10 impacted (by latency impact) city-networks—that is, client locations and ASNs, typically internet service providers.
```
SELECT json_extract_scalar(clientLocation, '$.city') as city,
json_extract_scalar(clientLocation, '$.networkname') as networkName,
sum(
cast(
json_extract_scalar(
internetHealth,
'$.performance.percentageoftotaltrafficimpacted'
)
as double )
) as percentageOfTotalTrafficImpacted
FROM internet_measurements
GROUP BY json_extract_scalar(clientLocation, '$.city'),
json_extract_scalar(clientLocation, '$.networkname')
ORDER BY percentageOfTotalTrafficImpacted desc
limit 10
```
**Query traffic highlights for your client locations and ASNs **
Run this Athena query to return traffic highlights, including availability score, performance score, and time to first byte for your city-networks—that is, client locations and ASNs, typically internet service providers. .
```
SELECT json_extract_scalar(clientLocation, '$.city') as city,
json_extract_scalar(clientLocation, '$.subdivision') as subdivision,
json_extract_scalar(clientLocation, '$.country') as country,
avg(cast(json_extract_scalar(internetHealth, '$.availability.experiencescore') as double)) as availabilityScore,
avg(cast(json_extract_scalar(internetHealth, '$.performance.experiencescore') as double)) performanceScore,
avg(cast(json_extract_scalar(trafficinsights, '$.timetofirstbyte.currentexperience.value') as double)) as averageTTFB,
sum(bytesIn) as bytesIn,
sum(bytesOut) as bytesOut,
sum(bytesIn + bytesOut) as totalBytes
FROM internet_measurements
where json_extract_scalar(clientLocation, '$.city') != 'N/A'
GROUP BY
json_extract_scalar(clientLocation, '$.city'),
json_extract_scalar(clientLocation, '$.subdivision'),
json_extract_scalar(clientLocation, '$.country')
ORDER BY totalBytes desc
limit 100
```
For more information about using Athena, see the [Amazon Athena User Guide](https://docs.aws.amazon.com/athena/latest/ug/).
# Use the Internet Monitor query interface
An option for understanding more about internet traffic for your AWS application is to use the Internet Monitor *query interface*. To use the query interface, you create a query with data filters that you choose, and then run the query to return a subset of your Internet Monitor data. Exploring the data that the query returns can give you insights into how your application is performing on the internet.
You can query and explore all the metrics that Internet Monitor captures with your monitor, including availability and performance scores, bytes transferred, round-trip times, and time to first byte (TTFB).
Internet Monitor uses the query interface to provide the data that you can explore in the Internet Monitor console dashboard. By using search options in the dashboard—on the **Analyze** page or the **Optimize** page—you can query and filter internet data for your application.
If you'd like more flexibility to explore and filter your data than the dashboard provides, you can use the query interface yourself, by using Internet Monitor API operations with the AWS Command Line Interface or with an AWS SDK. This section introduces the types of queries that you can use with the query interface, and the filters that you can specify to create a subset of data, to get insights about internet traffic for your application.
**Topics**
+ [How to use the query interface](#CloudWatch-IM-view-cw-tools-cwim-query-use-query)
+ [Query examples](#CloudWatch-IM-view-cw-tools-cwim-query-example-queries)
+ [Get query results](#CloudWatch-IM-view-cw-tools-cwim-query-get-data)
+ [Troubleshooting](#CloudWatch-IM-view-cw-tools-cwim-query-troubleshooting)
## How to use the query interface
You create a query with the query interface by choosing a *query type*, and then specifying filter values, to return a specific desired subset of your log file data. Then, you can work with the data subset, to further filter and sort, create reports, and so on.
The query process works like this:
1. When you run a query, Internet Monitor returns a `query ID` that is unique to the query. This section describes the query types that are available, and options for filtering data in queries. To understand how this works, you can also review the section on [query examples](#IMQueryInterfaceExamples).
1. You specify the query ID with your monitor name with the [GetQueryResults](https://docs.aws.amazon.com/internet-monitor/latest/api/API_GetQueryResults.html) API operation to return data results for the query. Each query type returns a different set of data fields. To learn more, see [Get query results](#IMGetQueryData).
The query interface provides the following query types. Each query type returns a different set of information about your traffic from the log files, as shown.
+ **Measurements:** Provides availability score, performance score, total traffic, and round-trip times, at 5 minute intervals.
+ **Top locations:** Provides availability score, performance score, total traffic, and time to first byte (TTFB) information, for the top location and ASN combinations that you're monitoring, by traffic volume.
+ **Top locations details:** Provides TTFB for Amazon CloudFront, your current configuration, and the best performing Amazon EC2 configuration, at 1 hour intervals.
+ **Overall traffic suggestions:** Provides TTFB, using a 30-day weighted average, for all traffic in each AWS location that is monitored.
+ **Overall traffic suggestions details:** Provides TTFB, using a 30-day weighted average, for each top location, for a proposed AWS location.
+ **Routing suggestions:** Provides the predicted average round-trip time (RTT) from an IP prefix toward an AWS location for a DNS resolver. The RTT is calculated at one hour intervals, over a one hour period.
You can filter the data more by using specific criteria. With most query types, except routing suggestions, you can filter by specifying one or more of the following criteria:
+ **AWS location:** For AWS location, you can specify CloudFront or an AWS Region, such as `us-east-2`.
+ **ASN:** Specify the autonomous system number (ASN) of a DNS resolver (typically, an ISP), for example, 4225.
+ **Client location:** For location, specify a city, metro, subdivision, or country.
+ **Proposed AWS location:** Specify an AWS Region, such as `us-east-2`, or an AWS Local Zone. You can use this filter with the overall traffic suggestions details query type.
+ **Geo:** Specify `geo` for some queries. This is required for queries that use the `Top locations` query type, but not allowed for other query types. To understand when to specify `geo` for filter parameters, see the [query examples](#IMQueryInterfaceExamples) section.
For the routing suggestions query type, you can filter the data more by specifying one or more of the following criteria:
+ **Current AWS location:** Specify an AWS Region, such as `us-east-2`.
+ **Proposed AWS location:** Specify an AWS Region, such as `us-east-2`, or an AWS Local Zone.
+ **IPv4 prefix:** Specify an IPv4 prefix in the standard format, similar to `192.0.2.0/24`.
+ **Monitor ARN:** Specify the ARN for a specific monitor.
+ **DNS resolver IP:** Specify the IP address of a DNS resolver.
+ **DNS resolver ISP:** Specify the name of a DNS resolver (typically an ISP), for example, `Cloudflare`.
+ **DNS resolver ASN:** Specify the autonomous system number (ASN) of a DNS resolver, for example, 4225.
The operators that you can use for filtering your data are `EQUALS` and `NOT_EQUALS`. For details about filtering parameters, see the [FilterParameter](https://docs.aws.amazon.com/internet-monitor/latest/api/API_FilterParameter.html) API operation.
To see details about the query interface operations, see the following API operations in the Internet Monitor API Reference Guide:
+ To create and run a query, see the [StartQuery](https://docs.aws.amazon.com/internet-monitor/latest/api/API_StartQuery.html) API operation.
+ To stop a query, see the [StopQuery](https://docs.aws.amazon.com/internet-monitor/latest/api/API_StopQuery.html) API operation.
+ To return data for a query that you've created, see the [GetQueryResults](https://docs.aws.amazon.com/internet-monitor/latest/api/API_GetQueryResults.html) API operation.
+ To retrieve the status of a query, see the [GetQueryStatus](https://docs.aws.amazon.com/internet-monitor/latest/api/API_GetQueryStatus.html) API operation.
## Query examples
To create a query that you can use to retrieve a filtered set of data from your monitor's log file, you use the [StartQuery](https://docs.aws.amazon.com/internet-monitor/latest/api/API_StartQuery.html) API operation. You specify a query type and filter parameters for the query. Then, when you use the Internet Monitor query interface API operation to get query results using the query, it will retrieve the subset of your data that you want to work with.
To illustrate how query types and filter parameters work, let's look at some examples.
**Example 1**
Let's say that you want to retrieve all of your monitor's log file data for a specific country, except for one city. The following example shows filter parameters for a query that you could create with the `StartQuery` operation for this scenario.
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "MEASUREMENTS"
FilterParameters: [
{
Field: "country",
Operator: "EQUALS",
Values: ["Germany"]
},
{
Field: "city",
Operator: "NOT_EQUALS",
Values: ["Berlin"]
},
]
}
```
**Example 2**
As another example, let's say that you want to see your top locations by metropolitan area. You could use the following example query for this scenario.
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "TOP_LOCATIONS"
FilterParameters: [
{
Field: "geo",
Operator: "EQUALS",
Values: ["metro"]
},
]
}
```
**Example 3**
Now, let's say that you want to see the top city-network combinations in the Los Angeles metro area. To do this, specify `geo=city`, and then set `metro` to Los Angeles. Now, the query returns the top city-networks in the Los Angeles metro area instead of the top metro\$1networks overall.
Here's the example query that you could use:
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "TOP_LOCATIONS"
FilterParameters: [
{
Field: "geo",
Operator: "EQUALS",
Values: ["city"]
},
{
Field: "metro",
Operator: "EQUALS",
Values: ["Los Angeles"]
}
]
}
```
**Example 4**
Next, let's say that you want to retrieve TTFB data for a specific subdivision (for example, a U.S. state).
The following is an example query for this scenario:
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "TOP_LOCATION_DETAILS"
FilterParameters: [
{
Field: "subdivision",
Operator: "EQUALS",
Values: ["California"]
},
]
}
```
**Example 5**
Now, let's say that you want to retrieve TTFB data for every location where your application has client traffic.
The following is an example query for this scenario:
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "OVERALL_TRAFFIC_SUGGESTIONS"
FilterParameters: []
}
Results:
[us-east-1, 40, us-west-2, 30],
[us-east-1, 40, us-west-1, 35],
[us-east-1, 40, us-east-1, 44],
[us-east-1, 40, CloudFront, 22],
...
[us-east-2, 44, us-west-2, 30],
[us-east-2, 44, us-west-1, 35],
...
```
**Example 6**
Let's say that you want to retrieve TTFB data for a specific new AWS Region.
The following is an example query for this scenario:
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "OVERALL_TRAFFIC_SUGGESTIONS_DETAILS"
FilterParameters: [
{
Field: "proposed_aws_location",
Operator: "EQUALS",
Values: ["us-west-2"]
},
]
}
Results:
[San Jose, San Jose-Santa Clara, California, United States, 7922, us-east-1, 40, 350, 350, us-west-2, 45]
[San Jose, San Jose-Santa Clara, California, United States, 7922, us-west-1, 35, 450, 450, us-west-2, 45]
```
**Example 7**
A final example is to retrieve data for specific DNS resolvers.
The following is an example query for this scenario:
```
{
MonitorName: "TestMonitor"
StartTime: "2023-07-12T20:00:00Z"
EndTime: "2023-07-12T21:00:00Z"
QueryType: "ROUTING_SUGGESTIONS"
FilterParameters: [
{
Field: "proposed_aws_location",
Operator: "EQUALS",
Values: ["us-east-1"]
},
]
}
Results:
[162.158.180.245, 13335, Cloudflare, [5.4.0.0/14], us-east-2, 200.0, us-east-1, 160.0]
[162.158.180.243, 13313, Cloudflare, [5.4.0.0/10], us-east-2, 150.0, us-east-1, 125.0]
```
## Get query results
After you define a query, you can return a set of results with the query by running another Internet Monitor API operation, [GetQueryResults](https://docs.aws.amazon.com/internet-monitor/latest/api/API_GetQueryResults.html). When you run `GetQueryResults`, you specify the query ID for the query that you've defined, along with the name of your monitor. `GetQueryResults` retrieves data for the specified query into a result set.
When you run a query, make sure that the query has finished running before you use `GetQueryResults` to look at the results. You can determine if the query has completed by using the [GetQueryStatus](https://docs.aws.amazon.com/internet-monitor/latest/api/API_GetQueryStatus.html) API operation. When the `Status` for the query is `SUCCEEDED`, you can go ahead with reviewing the results.
When your query completes, you can use the following information to help you review the results. Each query type that you use to create a query includes a unique set of data fields from the log files, as described in the following list:
**Measurements**
The `measurements` query type returns the following data:
`timestamp, availability, performance, bytes_in, bytes_out, rtt_p50, rtt_p90, rtt_p95`
**Top locations**
The `top locations` query type groups data by location, and provides the data averaged over the time period. The data that it returns includes the following:
`aws_location, city, metro, subdivision, country, asn, availability, performance, bytes_in, bytes_out, current_fbl, best_ec2, best_ec2_region, best_cf_fbl`
Note that `city`, `metro`, and `subdivision` are only returned if you choose that location type for the `geo` field. The following location fields are returned, depending on the location type that you specify for `geo`:
```
city = city, metro, subdivision, country
metro = metro, subdivision, country
subdivision = subdivision, country
country = country
```
**Top locations details**
The `top locations details` query type returns data grouped hour by hour. The query returns the following data:
`timestamp, current_service, current_fbl, best_ec2_fbl, best_ec2_region, best_cf_fbl`
**Overall traffic suggestions**
The `overall traffic suggestions` query type returns data grouped hour by hour. The query returns the following data:
`current_aws_location, proposed_aws_location, average_fbl, traffic, optimized_traffic_excluding_cf, optimized_traffic_including_cf`
**Overall traffic suggestions details**
The `overall traffic suggestions details` query type returns data grouped hour by hour. The query returns the following data:
`aws_location, city, metro, subdivision, country, asn, traffic, current_aws_location, fbl_data`
**Routing suggestions**
The `routing suggestions` query type returns data grouped hour by hour. The query returns the following data:
`dns_resolver_ip, dns_resolver_asn, dns_resolver_isp, ipv4_prefixes, current_aws_location, current_latency, proposed_aws_location, proposed_latency`
When you run the `GetQueryResults` API operation, Internet Monitor returns the following in the response:
+ A *data string array* that contains the results that the query returns. The information is returned in arrays that are aligned with the `Fields` field, also returned by the API call. Using the `Fields` field, you can parse the information from the `Data` repository and then further filter or sort it for your purposes.
+ An *array of fields* that lists the fields that the query returned data for (in the `Data` field response). Each item in the array is a name-datatype pair, such as `availability_score`-`float`.
## Troubleshooting
If errors are returned when you use query interface API operations, verify that you have the required permissions to use Internet Monitor. Specifically, make sure that you have the following permissions:
```
internetmonitor:StartQuery
internetmonitor:GetQueryStatus
internetmonitor:GetQueryResults
internetmonitor:StopQuery
```
These permissions are included in the recommended AWS Identity and Access Management policy to use the Internet Monitor dashboard in the console. For more information, see [AWS managed policies for Internet Monitor](CloudWatch-IM-permissions.md).
# Add a monitor using other AWS services
A simple way to add monitoring with Internet Monitor is to choose to create a monitor when you add a supported resource when you create a resource—or use monitoring for the resource—in console.
Resources with an integrated option for adding Internet Monitor include the following:
+ VPCs
+ Network Load Balancers
+ Amazon CloudFront distributions
The following sections provide more information about Internet Monitor integrations in the service consoles for supported resources.
**Topics**
+ [Add monitor when you create an NLB](CloudWatch-IM-get-started.nlb-monitor.md)
+ [Add monitor when you create a VPC](CloudWatch-IM-get-started.vpc-monitor.md)
+ [Add monitor from the CloudFront console](CloudWatch-IM-get-started.cf-monitor.md)
# Add a monitor with a Network Load Balancer
When you create a Network Load Balancer in the AWS Management Console, you can optionally choose to also set up monitoring for traffic to and from the Network Load Balancer using a monitor in Internet Monitor. You can add the Network Load Balancer to an existing monitor, or you can opt to create a new monitor for your Network Load Balancer traffic.
By using Internet Monitor with your Network Load Balancer, you can view and evaluate measurements and metrics about availability, performance, monitored bytes transferred, and round-trip times that are specific to your application's client locations and ASNs (typically, internet service providers). Internet Monitor also determines when there are anomalies in performance and availability, and then creates health events in your monitor, which you can choose to be notified about. To learn more about how you can use a monitor to manage and improve your clients' experience with your application, see [Use a monitor in Internet Monitor](IMWhyCreateMonitor.md).
**Important**
To create a monitor, or add a Network Load Balancer to an existing monitor, you must have the correct permissions in place. For more information, see [Identity and Access Management for Internet Monitor](security-iam.md).
## Add a Network Load Balancer to an existing monitor
When you create the Network Load Balancer in the AWS Management Console, you can choose to have Internet Monitor add the new Network Load Balancer to an existing monitor. Under **Integrations**, choose Internet Monitor, and then choose **Add monitor**. Choose **Select an existing monitor**, and then enter a monitor name. Or choose **View monitors** to go to the Internet Monitor console, and then scroll down to see a list of available monitors.
After you add the Network Load Balancer to a monitor, wait a few minutes, and then metrics for traffic to and from the load balancer will start being shown on the Internet Monitor console. To learn more about the **Status** and **Data processing status** values, see [Monitoring details in Internet Monitor (Configure page)Monitor details](CloudWatch-IM-configure.md).
You can edit the monitor at any time, to remove the load balancer or add another Network Load Balancer, or other resources. You can also change the percentage of traffic that you're monitoring, or make other changes. If you choose to remove the Network Load Balancer from the monitor, traffic from clients to that load balancer is no longer monitored by Internet Monitor.
To learn more about updating a monitor, see [Edit a monitor in Internet Monitor](CloudWatch-IM-get-started.edit-monitor.md).
## Create a monitor for a Network Load Balancer
Under **Integrations**, choose Internet Monitor, and then choose **Monitor resource traffic**. Choose **Create a new monitor**, and then enter a monitor name. Leave the default traffic percentage to monitor, 100%, or specify a custom percentage, and then choose **Create monitor**.
After you create the monitor, wait a few minutes, and then metrics for traffic to and from the Network Load Balancer will start being shown on the Internet Monitor console. If you like, you can also choose a percentage of client traffic that you want to monitor for your application (the default is 100%).
You can learn more by reviewing the information in [Step 1: Create a monitor](CloudWatch-IM-get-started.md#CloudWatch-IM-get-started.create).
## Pricing
With Internet Monitor, you pay only for what you use. Pricing for Internet Monitor has two components: a per monitored resource fee and a per city-network fee. A city-network is the location that clients access your application resources from and the network (an ASN, such as an internet service provider or ISP) that clients access the resources through.
For more information, including pricing examples, see [Pricing for Internet Monitor](CloudWatch-InternetMonitor.pricing.md).
## Stop monitoring a Network Load Balancer
If you'd like to stop monitoring your Network Load Balancer resource with Internet Monitor, do the following in the Internet Monitor console:
**To remove a resource from a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Update monitor**.
1. Under **Added resources**, choose **Remove resources**.
1. Choose the Network Load Balancer to remove, and then choose **Remove**.
1. Choose **Update**.
# Add an Internet Monitor monitor with Amazon VPC
When you create a Amazon Virtual Private Cloud VPC in the AWS Management Console, you can optionally choose to also set up monitoring for it in Internet Monitor. You can add the VPC to an existing monitor, or you can opt to create a new monitor for the VPC in the Amazon VPC console.
By using Internet Monitor with your VPC, you can view and evaluate measurements and metrics about availability, performance, monitored bytes transferred, and round-trip times that are specific to your application's client locations and ASNs (typically internet service providers). Internet Monitor also determines when there are anomalies in performance and availability and creates health events in your monitor, which you can choose to be notified about. To learn more about how you can use a monitor to manage and improve your clients' experience with your application, see [Use a monitor in Internet Monitor](IMWhyCreateMonitor.md).
**Important**
To create a monitor, or add a VPC to an existing monitor, you must have the correct permissions in place. For more information, see [Identity and Access Management for Internet Monitor](security-iam.md).
## Add a VPC to an existing monitor
You can choose to have Internet Monitor add a new VPC to an existing monitor for you when you create the VPC in the AWS Management Console. After you add the VPC, wait a few minutes, and then metrics for the VPC will start being shown on the Internet Monitor console.
You can edit the monitor at any time, to remove the VPC or add another VPC or other resources. You can also change the percentage of traffic that you're monitoring, or make other changes. If you choose to remove the VPC from the monitor, traffic from clients to that VPC is no longer monitored by Internet Monitor.
To learn more about updating a monitor, see [Edit a monitor in Internet Monitor](CloudWatch-IM-get-started.edit-monitor.md).
## Create a monitor for a VPC
If you opt to create a monitor for a VPC, the **Create monitor** wizard walks you through the steps. You add the VPC as a monitored resource when you create the monitor. If you like, you can also choose a percentage of client traffic that you want to monitor for your application (the default is 100%).
You can learn more by reviewing the information in [Step 1: Create a monitor](CloudWatch-IM-get-started.md#CloudWatch-IM-get-started.create).
## Pricing
With Internet Monitor, you pay only for what you use. Pricing for Internet Monitor has two components: a per monitored resource fee and a per city-network fee. A city-network is the location that clients access your application resources from and the network (an ASN, such as an internet service provider or ISP) that clients access the resources through.
For more information, including pricing examples, see [Pricing for Internet Monitor](CloudWatch-InternetMonitor.pricing.md)
## Stop monitoring a VPC
If you'd like to stop monitoring your VPC resource with Internet Monitor, do the following in the Internet Monitor console:
**To remove a resource from a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Update monitor**.
1. Under **Added resources**, choose **Remove resources**.
1. Choose the VPC to remove, and then choose **Remove**.
1. Choose **Update**.
# Add an Internet Monitor monitor with CloudFront
On the metrics dashboard for a distribution in Amazon CloudFront console, you can set up additional monitoring for a distribution in Internet Monitor. You can add the distribution to an existing monitor, or you can create a new monitor for the distribution.
By using Internet Monitor with your CloudFront distribution, you can view and evaluate measurements and metrics about availability, performance, monitored bytes transferred, and round-trip times that are specific to your application's client locations and ASNs (typically internet service providers). Internet Monitor also determines when there are anomalies in performance and availability and creates health events in your monitor, which you can choose to be notified about. To learn more about how you can use a monitor to manage and improve your clients' experience with your application, see [Use a monitor in Internet Monitor](IMWhyCreateMonitor.md).
**Important**
To create a monitor, or add a distribution to an existing monitor, you must have the correct permissions in place. For more information, see [Identity and Access Management for Internet Monitor](security-iam.md).
## Add a distribution to an existing monitor
You can choose to have Internet Monitor add a distribution to an existing monitor directly from the CloudFront metrics dashboard in the AWS Management Console. After you add the distribution, wait a few minutes, and then metrics for the distribution will start being shown on the Internet Monitor console.
You can edit the monitor at any time, to remove the distribution or add another distribution or other resources. You can also change the percentage of traffic that you're monitoring, or make other changes. If you choose to remove the distribution from the monitor, traffic from clients to that distribution is no longer monitored by Internet Monitor.
To learn more about updating a monitor, see [Edit a monitor in Internet Monitor](CloudWatch-IM-get-started.edit-monitor.md).
## Create a monitor for a distribution
If you opt to create a monitor for a distribution, the **Create monitor** wizard walks you through the steps. You add the distribution as a monitored resource when you create the monitor. If you like, you can also choose a percentage of client traffic that you want to monitor for your application (the default is 100%).
You can learn more by reviewing the information in [Step 1: Create a monitor](CloudWatch-IM-get-started.md#CloudWatch-IM-get-started.create).
## Pricing
With Internet Monitor, you pay only for what you use. Pricing for Internet Monitor has two components: a per monitored resource fee and a per city-network fee. A city-network is the location that clients access your application resources from and the network (an ASN, such as an internet service provider or ISP) that clients access the resources through.
For more information, including pricing examples, see [Pricing for Internet Monitor](CloudWatch-InternetMonitor.pricing.md).
## Stop monitoring a distribution
If you'd like to stop monitoring your distribution resource with Internet Monitor, do the following in the Internet Monitor console:
**To remove a resource from a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Internet monitors**.
1. Choose your monitor, and then choose the **Action** menu.
1. Choose **Update monitor**.
1. Under **Added resources**, choose **Remove resources**.
1. Choose the distribution to remove, and then choose **Remove**.
1. Choose **Update**.
# Create alarms with Internet Monitor
You can create Amazon CloudWatch alarms based on Internet Monitor metrics, just as you can for other Amazon CloudWatch metrics.
For example, you can create an alarm based on the Internet Monitor metric `PerformanceScore`, and configure it to send a notification when the metric is lower than a value that you choose. You configure alarms for Internet Monitor metrics following the same guidelines as for other CloudWatch metrics.
Following are the example Internet Monitor metrics that you might choose to create an alarm for:
+ **PerformanceScore**
+ **AvailabilityScore**
+ **RoundtripTime**
To see all the metrics available for Internet Monitor, see [View Internet Monitor metrics or set alarms in CloudWatch Metrics](CloudWatch-IM-view-cw-tools-metrics-dashboard.md).
The following procedure provides an example of setting an alarm on **PerformanceScore** by navigating to the metric in the CloudWatch dashboard. Then, you follow the standard CloudWatch steps to create an alarm based on a threshold that you choose, and set up a notification or choose other options.
**To create an alarm for **PerformanceScore** in CloudWatch Metrics**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choose **Metrics**, and then choose **All metrics**.
1. Filter for Internet Monitor by choosing `AWS/InternetMonitor`.
1. Choose **MeasurementSource, MonitorName**.
1. In the list, select **PerformanceScore**.
1. On the **GraphedMetrics** tab, under **Actions**, choose the bell icon to create an alarm based on a static threshold.
Now, follow the standard CloudWatch steps to choose options for the alarm. For example, you can choose to be notified by an Amazon SNS message if **PerformanceScore** is below a specific threshold number. Alternatively, or in addition, you can add the alarm to a dashboard.
Keep in mind the following:
+ Internet Monitor metrics are typically calculated and published within 20 minutes.
+ When you create an alarm based on Internet Monitor metrics, make sure that you take into account the short delay before publication when you set an alarm’s lookback period. We recommend that you configure **Evaluation Periods** with lookback period that is a minimum of 25 minutes.
To learn more about using CloudWatch alarms with Internet Monitor, see the following blog post: [ Using Internet Monitor for enhanced internet observability](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-cloudwatch-internet-monitor-for-enhanced-internet-observability).
For more information about options when you create a CloudWatch alarm, see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
# Using Internet Monitor with Amazon EventBridge
Overall (global) health events that Internet Monitor creates for networking issues are published with Amazon EventBridge, so that you can send notifications about a degradation in end users' experience for your application due to a global health event.
**Note**
Local health events are not published with EventBridge.
To use EventBridge to work with Internet Monitor health events, follow the guidance here.
**To set up a rule for Internet Monitor in EventBridge**
1. In the AWS Management Console, in EventBridge, choose **Rules**, then enter a name and a description. Create the rule on the **Default** event bus.
1. In Step 2, select **Other** for the event source, and then, under **Event pattern**, match the following source.
```
{
"source": ["aws.internetmonitor"]
}
```
1. In Step 3, for the target, select **AWS Service** and **CloudWatch Logs Group**, then select an existing log group or create a new one.
1. Add any desired tags, and then create the rule. This should populate your selected CloudWatch Logs Group with events from EventBridge.
For more information about how EventBridge rules work with event patterns, see [Amazon EventBridge event patterns](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) in the Amazon EventBridge User Guide.
# Troubleshoot CloudWatch logs and metrics access errors
To support some features, Internet Monitor must interact with certain Amazon CloudWatch resources, including logs and metrics. If Internet Monitor can't access the CloudWatch resources that it requires access to, Internet Monitor sets a status code of `FAULT_ACCESS_CLOUDWATCH` for the monitor.
There are several reasons that your monitor might have the state `FAULT_ACCESS_CLOUDWATCH`. The following sections list possible causes for these errors, and suggested troubleshooting steps.
## Internet Monitor couldn't access CloudWatch logs in your account
Internet Monitor publishes diagnostic logs about your monitored application traffic. It publishes these logs to log groups in CloudWatch Logs in the following location: `/aws/internet-monitor/monitor_name/[byCity|byMetro|bySubdivision|byCountry]`. Internet Monitor was unable to access these log groups.
**Error states and potential solutions:**
+ **PutLogEvents throttling error:** The Internet Monitor service might have been throttled when it tried to publish your monitor's logs to CloudWatch. Review the throttling limits for your account, and, if necessary, request an increase in the limit.
+ **Log group not found:** Disable, and then re-enable your monitor. Enabling a monitor restarts log group creation, which might correct the problem.
+ **PutLogEvents access denied error:** Contact AWS support for assistance.
+ **PutLogEvents unknown or general error:** Contact AWS support for assistance.
## Internet Monitor couldn't access CloudWatch metrics in your account
Internet Monitor delivers specific CloudWatch metrics about the application traffic that is tracked by a monitor. An error occurred when Internet Monitor tried to deliver these metrics to CloudWatch.
**Error states and potential solutions:**
+ **PutMetricData throttling error:** The Internet Monitor service might have been throttled when it tried to publish your monitor's metrics to CloudWatch. Review the throttling limits for your account, and, if necessary, request an increase in the limit.
+ **PutMetricData access denied error:** Contact AWS support for assistance.
+ **PutMetricData unknown or general error:** Contact AWS support for assistance.
# Data protection and data privacy with Internet Monitor
The AWS [ shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection and data privacy in Internet Monitor. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. For more information about data privacy, see the [ Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see [ The AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the AWS Security Blog. For more resources about complying with GDPR requirements, see the [ General Data Protection Regulation (GDPR) Center](https://aws.amazon.com/compliance/gdpr-center/).
We strongly recommend that you never put sensitive identifying information, such as your end users’ account numbers, email addresses, or other personal information, into free-form fields. Any data that you enter into Internet Monitor or other services might be included in diagnostic logs.
# Identity and Access Management for Internet Monitor
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 Internet Monitor resources. IAM is an AWS service that you can use with no additional charge.
**Important**
**Internet Monitor resource changes on July 8, 2024**
If you created IAM policies that included Internet Monitor resources before July 8, 2024, be aware of the following change to Internet Monitor resources and resource types:
Resource-level permissions for the **GetHealthEvent** action are now supported only on the **Monitor** resource type. The permissions are not supported on the **HealthEvent** resource.
To see more information about the actions, resources, and condition keys that you can specify in policies to manage access to AWS resources in Internet Monitor, see [Actions, resources, and condition keys for Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html).
**Topics**
+ [Upgrade IAM policies to IPv6](security_iam_cwim_security-ipv6-upgrade.md)
+ [How Internet Monitor works with IAM](security_iam_service-with-iam-cwim.md)
+ [Confused deputy prevention](security-iam-cwim-confused-deputy.md)
+ [AWS managed policies](CloudWatch-IM-permissions.md)
+ [Service-linked role](using-service-linked-roles-CWIM.md)
# Upgrade IAM policies to IPv6
Internet Monitor customers use IAM policies to set an allowed range of IP addresses, to prevent any IP addresses outside the configured range from being able to access Internet Monitor APIs.
The *internetmonitor.*region*.api.aws* endpoint, where you access Internet Monitor APIs, is being upgraded to support dual-stack (IPv4 and IPv6).
IP address filtering policies that are not updated to handle IPv6 addresses might result in clients losing access to Internet Monitor APIs.
## Customers impacted by the upgrade to include IPv6
Customers who are using dual-stack with policies that contain the *aws:sourceIp* filter are impacted by this upgrade. Dual-stack means that the network supports both IPv4 and IPv6.
If you use dual-stack, you must update your IAM policies that are currently configured with IPv4 format addresses to include IPv6 format addresses.
The following summarizes recommended actions, depending on your scenario. To confirm the endpoint that your SDK uses, see [Identify the Internet Monitor endpoint used by your code](#IMConfirmSDKEndpoint).
| Endpoint | Using IAM policy with `aws:sourceIp` condition? | Recommended action |
| --- | --- | --- |
| `internetmonitor.region.amazonaws.com` (not dual-stack) | Yes | To restrict access to IPv4 only, take no further action. Or, if you anticipate that you will need IPv6 support in the future, you can take action to ensure compatibility with both IPv4 and IPv6. To ensure future compatibility, on or after November 1, 2024, update your SDK, and then update your application to use the dual-stack endpoint by setting `useDualstackEndpoint=true`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). If you choose to use both IPv4 and IPv6, you must also update the IP address filtering condition (`aws:sourceIp`) in your IAM policies to include IPv6 addresses. |
| `internetmonitor.region.amazonaws.com` (not dual-stack) | No | To restrict access to IPv4 only, take no further action. Or, if you anticipate that you will need IPv6 support in the future, you can take action to ensure compatibility with both IPv4 and IPv6. To ensure future compatibility, on or after November 1, 2024, update your SDK, and then update your application to use the dual-stack endpoint by setting `useDualstackEndpoint=true`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). |
| `internetmonitor.region.api.aws` | Yes | To ensure future compatibility with both IPv4 and IPv6, update your SDK, and then update your application to use the dual-stack endpoint by setting `useDualstackEndpoint=true`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). When you make the change to use both IPv4 and IPv6, you must also update the IP address filtering condition (`aws:sourceIp`) in your IAM policies to include IPv6 addresses. If you instead want to restrict access to IPv4 only, set `useDualstackEndpoint=false`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). |
| `internetmonitor.region.api.aws` | No | To ensure future compatibility with both IPv4 and IPv6, update your SDK, and then update your application to use the dual-stack endpoint by setting `useDualstackEndpoint=true`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). If you instead want to restrict access to IPv4 only, set `useDualstackEndpoint=false`. For more information, see [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html). |
For help with access issues, contact [Support](https://support.console.aws.amazon.com/support/home/?nc1=f_dr#/case/create).
## What is IPv6?
IPv6 is the next generation IP standard intended to eventually replace IPv4. IPv4 uses a 32-bit addressing scheme, to support 4.3 billion devices. IPv6 instead uses 128-bit addressing, to support approximately 340 trillion trillion trillion (or 2 to the 128th power) devices.
The following are examples of IPv6 addresses:
```
2001:cdba:0000:0000:0000:0000:3257:9652
2001:cdba:0:0:0:0:3257:9652
2001:cdba::3257:965
```
IPv6 offers a larger address space, improved routing efficiency, and better support for new internet services. By updating to dual-stack and supporting IPv6, Internet Monitor enables improved performance and scalability. Follow the steps in this section to update your configurations and take advantage of dual-stack support.
## Identify the Internet Monitor endpoint used by your code
If you use an Internet Monitor SDK, start by verifying which endpoint your code is using: the IPv4 endpoint or the dual-stack (IPv4 and IPv6) endpoint. If you don’t use an SDK with Internet Monitor, you can skip this section.
You can run the following code example to determine the Internet Monitor endpoint that you're using. For this example, we’re using the Internet Monitor SDK for Go in the US East (N. Virginia) Region.
```
package main
import (
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws"
"github.com/aws/aws-sdk-go/aws/session"
"github.com/aws/aws-sdk-go/service/internetmonitor"
)
func main() {
// Create a new session with the default configuration
sess := session.Must(session.NewSession(&aws.Config{
Region: aws.String("us-east-1"),
}))
// Create a new Internet Monitor client
internetMonitorClient := internetmonitor.New(sess)
// Get the endpoint URL
endpoint := internetMonitorClient.Endpoint
fmt.Printf("Internet Monitor endpoint URL: %s\n", endpoint)
}
```
When you run this code, it returns the Internet Monitor endpoint. If you see the following response, you’re using the Internet Monitor domain that supports only IPv4. You can tell because the format of the endpoint URL includes `amazonaws.com`.
```
Internet Monitor endpoint URL: https://internetmonitor.us-east-1.amazonaws.com
```
If you see the following response instead, then you’re using the domain which is being upgraded to support dual-stack (IPv4 and IPv6). Here, you can tell because the endpoint URL includes `api.aws`. However, note that until the upgrade is complete, this endpoint supports only IPv4.
```
Internet Monitor endpoint URL: https://internetmonitor.us-east-1.api.aws
```
## Update an IAM policy for IPv6
IAM policies use the `aws:SourceIp` filter to set an allowed range of IP addresses.
Dual-stack supports both IPv4 and IPV6 traffic. If your network uses dual-stack, you must ensure that any IAM polices that are used for IP address filtering are updated to include IPv6 address ranges.
For example, this policy allows IPv4 address ranges `192.0.2.0.*` and `203.0.113.0.*`, identified in the `Condition` element.
```
# https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"*aws:SourceIp*": [
"*192.0.2.0/24*",
"*203.0.113.0/24*"
]
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
}
```
To update this policy, we'll change the policy's `Condition` element to add IPv6 address ranges, as shown in the following example:
```
"Condition": {
"NotIpAddress": {
"*aws:SourceIp*": [
"*192.0.2.0/24*", <>
"*203.0.113.0/24*", <>
"*2001:DB8:1234:5678::/64*", <>
"*2001:cdba:3257:8593::/64*" <>
]
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
```
**Important**
Do not remove the existing IPv4 addresses in the policy. They are required for backward compatibility.
For more information about managing access permissions with IAM, see [Managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) in the *AWS Identity and Access Management User Guide*.
## Test the network after updating policies
After you update your IAM policies to include support for IPv6 addresses, we recommend that you test that your network can access an IPv6 endpoint. This section provides several examples, depending on the operating system that you use.
### Test network with Linux/Unix or Mac OS X
If you use Linux/Unix or Mac OS X, you can test that your network can access the IPv6 endpoint by using the following curl command.
`curl -v -s -o /dev/null http://ipv6.ec2-reachability.amazonaws.com/`
If you are connected over IPv6, the connected IP address displays information similar to the following:
```
* About to connect() to aws.amazon.com port 443 (#0)
* Trying IPv6 address... connected
* Connected to aws.amazon.com (IPv6 address) port 443 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.1 OpenSSL/1.0.1t zlib/1.2.3
> Host: aws.amazon.com
```
### Test network with Windows
If you use Windows, you can test that your network can access a dual-stack endpoint over IPv6 or IPv4 by using a `ping` command, such as the following:
`ping aws.amazon.com`
If `ping` accesses the endpoint over IPv6, the command returns IPv6 addresses.
## Verify that clients can support IPv6
We recommend that before you switch to using the *internetmonitor.\$1region\$1.api.aws* endpoint, that you first verify that your clients can access other AWS service endpoints that are already IPv6-enabled. The following steps describe how to verify this by using an existing IPv6 endpoint.
This example uses Linux and curl version 8.6.0, and uses the [Amazon Athena service](https://docs.aws.amazon.com/general/latest/gr/athena.html), which has IPv6-enabled endpoints located at the *api.aws* domain.
**Note**
Switch your AWS Region to the same Region where the client is located. In this example, we use the US East (N. Virginia) – `us-east-1` endpoint.
Use the following example to verify that your clients can access an IPv6-enabled AWS endpoint.
1. Verify that the Athena endpoint resolves with an IPv6 address by using the following command.
```
dig +short AAAA athena.us-east-1.api.aws
2600:1f18:e2f:4e05:1a8a:948e:7c08:d2d6
2600:1f18:e2f:4e03:4a1e:83b0:8823:4ce5
2600:1f18:e2f:4e04:34c3:6e9a:2b0d:dc79
```
1. Now, determine if your client network can make a connection using IPv6 by using the following command:
```
curl --ipv6 -o /dev/null --silent -w "\nremote ip: %{remote_ip}\nresponse code: %{response_code}\n" https://athena.us-east-1.api.aws
remote ip: 2600:1f18:e2f:4e05:1a8a:948e:7c08:d2d6
response code: 404
```
If the remote IP address was identified **and** the response code is not `0`, a network connection was successfully made to the endpoint using IPv6.
If the remote IP address is blank or the response code is `0`, the client network or the network path to the endpoint is IPv4-only. You can verify this with the following curl command:
```
curl -o /dev/null --silent -w "\nremote ip: %{remote_ip}\nresponse code: %{response_code}\n" https://athena.us-east-1.api.aws
remote ip: 3.210.103.49
response code: 404
```
If you run this command, and a remote IP address was identified **and** the response code is not `0`, a network connection was successfully made to the endpoint using IPv4.
# How Internet Monitor works with IAM
Before you use IAM to manage access to Internet Monitor, learn what IAM features are available to use with Internet Monitor.
To see tables showing a similar high-level view of how AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**IAM features you can use with Internet Monitor**
| IAM feature | Internet Monitor support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes |
| [Policy condition keys (service-specific)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Partial |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service) | No |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | Yes |
## Identity-based policies for Internet Monitor
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
## Resource-based policies within Internet Monitor
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource.
## Policy actions for Internet Monitor
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of Internet Monitor actions, see [Actions defined by Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html#amazoncloudwatchinternetmonitor-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in Internet Monitor use the following prefix before the action:
```
internetmonitor
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"internetmonitor:action1",
"internetmonitor:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "internetmonitor:Describe*"
```
## Policy resources for Internet Monitor
**Supports policy resources:** Yes
In the *Service Authorization Reference*, you can see the following information related to Internet Monitor:
+ To see a list of Internet Monitor resource types and their ARNs, see [Resources defined by Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html#amazoncloudwatchinternetmonitor-resources-for-iam-policies).
+ To learn the actions that you can specify with the ARN of each resource, see [Actions defined by Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html#amazoncloudwatchinternetmonitor-actions-as-permissions).
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
## Policy condition keys for Internet Monitor
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of Internet Monitor condition keys, see [Condition keys for Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html#amazoncloudwatchinternetmonitor-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by Internet Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchinternetmonitor.html#amazoncloudwatchinternetmonitor-actions-as-permissions).
## ACLs in Internet Monitor
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## ABAC with Internet Monitor
**Supports ABAC (tags in policies):** Partial
Internet Monitor has *partial* support for tags in policies. It supports tagging for one resource, monitors.
To use tags with Internet Monitor, use the AWS Command Line Interface or an AWS SDK. Tagging for Internet Monitor is not supported with the AWS Management Console.
To learn more about using tags in policies in general, review the following information.
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using temporary credentials with Internet Monitor
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for Internet Monitor
**Supports forward access sessions (FAS):** Yes
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Internet Monitor
**Supports service roles:** No
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
## Service-linked role for Internet Monitor
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For more information about the service-linked role for Internet Monitor, see [Service-linked role for Internet Monitor](using-service-linked-roles-CWIM.md).
For details about creating or managing service-linked roles in general in AWS, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# Cross-service confused deputy prevention
A confused deputy is an entity (a service or an account) that is coerced by a different entity to perform an action. This type of impersonation can happen cross-account and cross-service.
To prevent confused deputies, AWS provides tools that help you protect your data for all services using service principals that have been given access to resources in your AWS account. This section focuses on cross-service confused deputy prevention specific to Internet Monitor; however, you can learn more about this topic in the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) section of the *IAM User Guide*.
To limit the permissions that IAM gives to Internet Monitor to access your resources, we recommend using the global condition context keys [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) in your resource policies.
If you use both of these global condition context keys, and the `aws:SourceArn` value contains the AWS account ID, the `aws:SourceAccount` value and the AWS account in `aws:SourceArn` must use the same AWS account ID when used in the same policy statement.
For Internet Monitor, you specify your account ID for `aws:SourceAccount` and your monitor ARN for `aws:SourceArn`. For cross-service access, you also use your monitor ARN for `aws:SourceArn`.
**Note**
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the **full ARN** of the resource. If you don’t know the full ARN, or if you're specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws:internetmonitor:us-east-1:111122223333:*`.
The following is an example of an assume role policy that shows how you can prevent a confused deputy issue.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "internetmonitor.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:internetmonitor:us-east-1:111122223333:monitor/confused-deputy-monitor"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
}
```
------
# AWS managed policies for Internet Monitor
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
## AWS managed policy: CloudWatchInternetMonitorServiceRolePolicy
This policy is attached to the service-linked role named **AWSServiceRoleForInternetMonitor** to allow Internet Monitor to access resources in your account, such as Amazon Virtual Private Cloud resources or Network Load Balancers, so that you can select them when you create a monitor. For more information, see [Service-linked role for Internet Monitor](using-service-linked-roles-CWIM.md).
## AWS managed policy: CloudWatchInternetMonitorReadOnlyAccess
You can attach `CloudWatchInternetMonitorReadOnlyAccess` to your IAM entities. This policy grants access to read-only actions to work with monitors and data in with Internet Monitor. Attach it to IAM users and other principals who need access to only read-only actions.
Specifically, the scope of this policy includes `internetmonitor:` so that users can use read-only Internet Monitor actions and resources. It includes some `cloudwatch:` policies to retrieve information on CloudWatch metrics. It includes some `logs:` policies to manage log queries.
To view the permissions for this policy, see [CloudWatchInternetMonitorReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchInternetMonitorReadOnlyAccess.html) in the *AWS Managed Policy Reference*.
## AWS managed policy: CloudWatchInternetMonitorFullAccess
You can attach `CloudWatchInternetMonitorFullAccess` to your IAM entities. This policy grants full access to [ Actions for Internet Monitor](https://docs.aws.amazon.com/internet-monitor/latest/api/API_Operations.html) for working with Internet Monitor. Attach it to IAM users and other principals who need full access to Internet Monitor actions.
Specifically, scope of this policy includes `internetmonitor:` so that users can use Internet Monitor actions and resources. It includes some `cloudwatch:` policies to retrieve information on CloudWatch alarms and metrics. It includes some `logs:` policies to manage log queries. It includes some `ec2:`, `cloudfront:`, `elasticloadbalancing:`, and `workspaces:` policies to work with resources that you add to monitors so that Internet Monitor can create a traffic profile for your application. It contains some `iam:` policies to manage IAM roles.
To view the permissions for this policy, see [CloudWatchInternetMonitorFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchInternetMonitorFullAccess.html) in the *AWS Managed Policy Reference*.
## Internet Monitor updates to AWS managed policies
To view details about updates to AWS managed policies for Internet Monitor since this service began tracking these changes, see [CloudWatch updates to AWS managed policies](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates). For automatic alerts about managed policy changes in CloudWatch, subscribe to the RSS feed on the CloudWatch [Document history](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) page.
# Service-linked role for Internet Monitor
Internet Monitor uses an AWS Identity and Access Management (IAM)[ service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Internet Monitor. The service-linked role is predefined by Internet Monitor and includes all the permissions that the service requires to call other AWS services on your behalf.
Internet Monitor defines the permissions of the service-linked role, and unless defined otherwise, only Internet Monitor can assume the role. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete the role only after first deleting its related resources. This restriction protects your Internet Monitor resources because you can't inadvertently remove permissions to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Internet Monitor
Internet Monitor uses the service-linked role named **AWSServiceRoleForInternetMonitor**. This role allows Internet Monitor to access resources in your account, such as Amazon Virtual Private Cloud resources, Amazon CloudFront distributions, Amazon WorkSpaces directories, and Network Load Balancers, so that you can select them when you create a monitor.
This service-linked role uses the managed policy `CloudWatchInternetMonitorServiceRolePolicy`.
The **AWSServiceRoleForInternetMonitor** service-linked role trusts the following service to assume the role:
+ `internetmonitor.amazonaws.com`
To view the permissions for this policy, see [CloudWatchInternetMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchInternetMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
## Creating a service-linked role for Internet Monitor
You do not need to manually create the service-linked role for Internet Monitor. The first time that you create a monitor, Internet Monitor creates **AWSServiceRoleForInternetMonitor** for you.
For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*.
## Editing a service-linked role for Internet Monitor
After Internet Monitor creates a service-linked role in your account, you cannot change the name of the role because various entities might reference the role. You can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Internet Monitor
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete the role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for the service-linked role before you can manually delete it.
After you've removed your resources from your monitors in Internet Monitor and then deleted the monitors, you can delete the service-linked role **AWSServiceRoleForInternetMonitor**.
**Note**
If the Internet Monitor service is using the role when you try to delete it, then the deletion might fail. If that happens, wait for a few minutes and then try again.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForInternetMonitor** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Updates to the Internet Monitor service-linked role
For updates to **AWSServiceRoleForInternetMonitor**, the AWS managed policy for the Internet Monitor service-linked role, see [CloudWatch updates to AWS managed policies](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates). For automatic alerts about managed policy changes in CloudWatch, subscribe to the RSS feed on the CloudWatch [Document history](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) page.
# Using Network Synthetic Monitor
Network Synthetic Monitor provides visibility into the performance of the network connecting your AWS hosted applications to your on-premises destinations, and allows you to identify the source of any network performance degradation within minutes. Network Synthetic Monitor is fully managed by AWS, and doesn't require separate agents on monitored resources. Use Network Synthetic Monitor to visualize packet loss and latency of your hybrid network connections, and set alerts and thresholds. Then, based on this information, you can take action to improve your end users’ experience.
Network Synthetic Monitor is intended for network operators and application developers who want real-time insights into network performance.
## Network Synthetic Monitor key features
+ Use Network Synthetic Monitor to benchmark your changing hybrid network environment with continuous real-time packet loss and latency metrics.
+ When you connect by using AWS Direct Connect, Network Synthetic Monitor can help you to rapidly diagnose network degradation within the AWS network with the network health indicator (NHI), which Network Synthetic Monitor writes to your Amazon CloudWatch account. The NHI metric is a binary value, based on a probabilistic score about whether network degradation is within AWS.
+ Network Synthetic Monitor provides a fully-managed agent approach to monitoring, so you don’t need to install agents either on VPCs or on-premises. To get started, you just need to specify a VPC subnet and an on-premises IP address. You can establish a private connection between your VPC and Network Synthetic Monitor resources by using AWS PrivateLink. For more information, see [Using CloudWatch, CloudWatch Synthetics, and CloudWatch Network Monitoring with interface VPC endpoints](cloudwatch-and-interface-VPC.md).
+ Network Synthetic Monitor publishes metrics to CloudWatch Metrics. You can create dashboards to view your metrics, and also create actionable thresholds and alarms on the metrics that are specific to your application.
For more information, see [How Network Synthetic Monitor works](nw-monitor-how-it-works.md).
## Network Synthetic Monitor terminology and components
+ **Probes** — A probe is the traffic that's sent from an AWS-hosted resource to an on-premises destination IP address. Network Synthetic Monitor metrics measured by the probe are written into your CloudWatch account for every probe that's configured in a monitor.
+ **Monitor** — A monitor displays network performance and other health information for traffic that you have created Network Synthetic Monitor *probes* for. You add probes as part of creating a monitor, and then you can view network performance metrics information using the monitor. When you create a monitor for an application, you add an AWS hosted resource as the network source. Network Synthetic Monitor then creates a list of all possible probes between the AWS hosted resource and your destination IP addresses. You select the destinations that you want to monitor traffic for.
+ **AWS network source** — An AWS network source is a monitor probe's originating AWS source, which is a subnet in one of your VPCs.
+ **Destination** — A destination is the target in your on-premises network for the AWS network source. A destination is a combination of your on-premises IP addresses, network protocols, ports, and network packet size. IPv4 and IPv6 addresses are both supported.
## Network Synthetic Monitor requirements and limitations
The following summarizes requirements and limitations for Network Synthetic Monitor. For specific quotas (or limits), see [Network Synthetic Monitor](cloudwatch_limits.md#nw-monitor-quotas).
+ Monitor subnets must be owned by the same account as the monitor.
+ Network Synthetic Monitor doesn't provide automatic network failover in the event of an AWS network issue.
+ There's a charge for each probe that you create. For pricing details, see [Pricing for Network Synthetic Monitor](pricing-nw.md).
# How Network Synthetic Monitor works
Network Synthetic Monitor is fully managed by AWS, and doesn't require separate agents on monitored resources. Instead, you specify *probes* by providing a VPC subnet and on-premises IP addresses.
When you create a monitor in Network Synthetic Monitor for AWS-hosted resources, AWS creates and manages the infrastructure in the background that is required to perform round-trip time and packet loss measurements. Because AWS manages the required configurations, you can scale your monitoring rapidly, without needing to install or uninstall agents within your AWS infrastructure.
When probes are created, customized elastic network interfaces (ENIs) are created and attached to probe instances and customer subnets. If Network Synthetic Monitor replaces a probe instance, for example, if it becomes unhealthy, Network Synthetic Monitor detaches the ENIs and reattaches them to the probe replacement. This means that ENI IP addresses are not changed after they are created, unless you delete a probe and create a new one for the same source and destination.
Network Synthetic Monitor focuses monitoring on the routes taken by flows from your AWS-hosted resources instead of broadly monitoring all flows from your AWS Region. If your workloads spread across multiple Availability Zones, Network Synthetic Monitor can monitor routes from each of your private subnets.
Network Synthetic Monitor publishes round-trip time and packet loss metrics to your Amazon CloudWatch account, based on the aggregation interval that you set when you create a monitor. You can also use CloudWatch to set individual latency and packet loss thresholds for each monitor. For example, you might create an alarm for a packet loss sensitive workload to notify you if the packet loss average is higher than a static 0.1% threshold. You can also use CloudWatch anomaly detection to alarm on packet loss or latency metrics that are outside your desired ranges.
## Availability and performance measurements
Network Synthetic Monitor sends periodic active probes from your AWS resource to your on-premises destinations. When you create a monitor, you specify the following:
+ **Aggregation interval:** The time, in seconds, that CloudWatch receives the measured results. This will be either every 30 or 60 seconds. The aggregation period you choose for the monitor applies to all probes in that monitor.
+ **Probe sources (AWS resources):** A source for a probe is a VPC and associated subnets, or just a VPC subnet, in the Regions where your network operates.
+ **Probe destinations (customer resources):** A destination for a probe is the combination of on-premises IP addresses, network protocols, ports, and network packet size.
+ **Probe protocol:** One of the supported protocols, ICMP or TCP. For more information, see [Supported communication protocols](#nw-monitor-protocol).
+ **Port (for TCP):** The port that your network uses to connect.
+ **Packet size (for TCP):** The size, in bytes, of each packet transmitted between your AWS hosted resource and your destination on a single probe. You can specify a different packet size for each probe in a monitor.
A monitor publishes the following metrics:
+ **Round-trip time:** This metric, measured in microseconds, is a measure of performance. It records the time it takes for the probe to be transmitted to the destination IP address and for the associated response to be received. The round-trip time is the average time observed during the aggregation interval.
+ **Packet loss:** This metric measures the percentage of total packets sent and records the number of transmissions that didn't receive an associated response. No response implies that the packets were lost along the network path.
## Supported communication protocols
Network Synthetic Monitor supports two protocols for probes: ICMP and TCP.
ICMP-based probes carry ICMP echo requests from your AWS hosted resources to the destination address, and expect an ICMP echo reply in response. Network Synthetic Monitor uses the information on the ICMP echo request and reply messages to calculate round-trip time and packet loss metrics.
TCP-based probes carry TCP SYN packets from your AWS hosted resources to the destination address and port, and expect a TCP SYN\$1ACK packet in response. Network Synthetic Monitor uses the information on the TCP SYN and TCP SYN\$1ACK messages to calculate round-trip time and packet loss metrics. Network Synthetic Monitor periodically switches source TCP ports to increase network coverage, which increases the probability of detecting packet loss.
## Network health indicator for AWS
Network Synthetic Monitor publishes a network health indicator (NHI) metric that provides information on issues with the AWS network for paths that include destinations connected through Direct Connect.
The NHI binary value is based on a statistical measure of the health of the AWS-controlled network path from the AWS hosted resource, where the monitor is deployed, to the Direct Connect location. Network Synthetic Monitor uses anomaly detection to calculate availability drops or lower performance along the network paths.
NHI is not accurate for Direct Connect attachments that use intermediary routing with Cloud WAN. When you have a hybrid network that includes Cloud WAN, do not use the NHI value as an indication of a performance issue.
**Note**
Each time that you create a new monitor, add a probe, or re-activate a probe, the NHI for the monitor is delayed by a few hours while AWS collects data to perform anomaly detection.
To provide the NHI value, Network Synthetic Monitor applies statistical correlation across AWS sample datasets, as well as to the packet loss and round-trip latency metrics for traffic simulating your network path. NHI can be one of two values: 1 or 0. A value of 1 indicates that Network Synthetic Monitor observed a network degradation within the AWS controlled network path. A value of 0 indicates that Network Synthetic Monitor did not observe any network degradation for the AWS network along the path. Using the NHI value enables you to more quickly gain awareness of the cause of network issues. For example, you can set alerts on the NHI metric so you're notified about ongoing issues with the AWS network along your network paths.
## Support for IPv4 and IPv6 addresses
Network Synthetic Monitor provides availability and performance metrics over IPv4 or IPv6 networks, and can monitor either IPv4 or IPv6 addresses from dual-stack VPCs. Network Synthetic Monitor doesn’t allow both IPv4 and IPv6 destinations to be configured in the same monitor; you can create separate monitors for IPv4-only and IPv6-only destinations.
# Supported AWS Regions for Network Synthetic Monitor
The AWS Regions where Network Synthetic Monitor is supported are listed in this section. For more information about Regions that Network Synthetic Monitor is supported in, including opt-in Regions, see [Network Synthetic Monitor endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cwnm_region.html) in the *Amazon Web Services General Reference*.
| Region name | Region |
| --- | --- |
| Africa (Cape Town) | af-south-1 |
| Asia Pacific (Hong Kong) | ap-east-1 |
| Asia Pacific (Hyderabad) | ap-south-2 |
| Asia Pacific (Jakarta) | ap-southeast-3 |
| Asia Pacific (Malaysia) | ap-southeast-5 |
| Asia Pacific (Melbourne) | ap-southeast-4 |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Thailand) | ap-southeast-7 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| Canada (Central) | ca-central-1 |
| Canada West (Calgary) | ca-west-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Milan) | eu-south-1 |
| Europe (Paris) | eu-west-3 |
| Europe (Spain) | eu-south-2 |
| Europe (Stockholm) | eu-north-1 |
| Europe (Zurich) | eu-central-2 |
| Israel (Tel Aviv) | il-central-1 |
| Mexico (Central) | mx-central-1 |
| Middle East (Bahrain) | me-south-1 |
| Middle East (UAE) | me-central-1 |
| South America (São Paulo) | sa-east-1 |
| US East (N. Virginia) | us-east-1 |
| US East (Ohio) | us-east-2 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
# Pricing for Network Synthetic Monitor
With Network Synthetic Monitor, there are no upfront costs or long-term commitments. Pricing for Network Synthetic Monitor has the following two components:
+ An hourly fee per monitored AWS resource
+ CloudWatch metrics fees
When you create a monitor in Network Synthetic Monitor, you associate AWS resources (sources) with it to be monitored. For Network Synthetic Monitor, these resources are subnets in Amazon Virtual Private Cloud (VPC). For each resource, you can create up to four probes, each of which is for traffic from a subnet in the VPC to four of your destination IP addresses. To help control your bill, you can adjust your subnet coverage and on-premises IP address destination coverage by reducing the number of resources that you monitor.
For more information about pricing, see the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
# Network Synthetic Monitor API operations
The following table lists Network Synthetic Monitor API operations that you can use with Amazon CloudWatch. Refer to this table for links to relevant documentation.
| Action | API reference | More information |
| --- | --- | --- |
| Create a monitor between a source subnet and destination IP address. | See [CreateMonitor](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_CreateMonitor.html) | See [Create a monitor](getting-started-nw.md) |
| Create a probe within a monitor. | See [CreateProbe](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_CreateProbe.html) | See [Activate or deactivate a probe](nw-monitor-probe-status.md) |
| Remove a monitor. | See [DeleteMonitor](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_DeleteMonitor.html) | See [Delete a monitor](nw-monitor-delete.md) |
| Delete a specific probe. | See [DeleteProbe](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_DeleteProbe.html) | See [Delete a probe](nw-monitor-probe-delete.md) |
| Get information about a monitor. | See [GetMonitor](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_GetMonitor.html) | See [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md) |
| Get information about a specific probe. | See [GetProbe](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_GetProbe.html) | See [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md) |
| Get a list of all your monitors. | See [ListMonitors](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_ListMonitors.html) | See [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md) |
| List tags assigned to a resource. | See [ListTagsForResource](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_ListTagsForResource.html) | See [Tag or untag resources](nw-monitor-tags-cli.md) |
| Add key-value pairs, or tags, to a monitor or probe. | See [TagResource](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_TagResource.html) | See [Tag or untag resources](nw-monitor-tags-cli.md) |
| Remove a key-value pair, or tag, from a monitor or probe. | See [UntagResource](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_UntagResource.html) | See [Tag or untag resources](nw-monitor-tags-cli.md) |
| Update an aggregation period for a monitor. | See [UpdateMonitor](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_UpdateMonitor) | See [Edit a monitor](nw-monitor-edit.md) |
| Update a probe in a monitor. | See [UpdateProbe](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/API_UpdateProbe) | See [Edit a probe](nw-monitor-probe-edit.md) |
# Working with monitors and probes in Network Synthetic Monitor
To get started, create a monitor with probes in Network Synthetic Monitor to measure network performance over a specified aggregation period. Then, you can update a monitor to make desired changes, for example, to change the aggregation period, deactivate or activate probes, or add or remove tags.
The following sections provide step-by-step instructions for completing these tasks for your monitors and probes by using the Amazon CloudWatch console. You can also make changes to your monitor by using the AWS Command Line Interface.
**Topics**
+ [Create a monitor](getting-started-nw.md)
+ [Edit a monitor](nw-monitor-edit.md)
+ [Delete a monitor](nw-monitor-delete.md)
+ [Activate or deactivate a probe](nw-monitor-probe-status.md)
+ [Add a probe to a monitor](nw-monitor-add-probe.md)
+ [Edit a probe](nw-monitor-probe-edit.md)
+ [Delete a probe](nw-monitor-probe-delete.md)
+ [Tag or untag resources](nw-monitor-tags-cli.md)
# Create a monitor
The following sections describe how to create a monitor in Network Synthetic Monitor, including the required probes. When you create a monitor, you specify probes by choosing source subnets, and then adding up to four destinations for each one. Each source-destination pair is a probe.
You can make changes to a monitor after you create it, for example, to add, remove, or deactivate probes. For more information, see [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md).
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
The following procedures provide step-by-step instructions for how to create a monitor by using the Amazon CloudWatch console.
+ [Define monitor details](#NWDefineDetails)
+ [Choose sources and destinations](#NWSourceDestination)
+ [Confirm probes](#NWConfirmProbes)
+ [Review and create monitor](#NWReviewCreate)
**Important**
These steps are designed to be completed all at once. You can't save in-process work to continue later.
## Define monitor details
The first step to create a monitor is to define the basic details, by giving the monitor a name and defining the aggregation period. Optionally, you can also add tags.
**To define monitor details**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. Choose **Create monitor**.
1. For **Monitor name**, enter a name for the monitor.
1. For **Aggregation period**, choose how often you want to send metrics to CloudWatch: **30 seconds** or **60 seconds**.
**Note**
A shorter aggregation period provides faster detection of network issues. However, the aggregation period that you choose can affect your billing costs. For more information about pricing, see the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
1. (Optional) For **Tags**, add **Key** and **Value** pairs to help identify this resource, so that you can search or filter on specific information.
1. Choose **Add new tag**.
1. Enter a **Key** name and associated **Value**.
1. Choose **Add new tag** to add the new tag.
You can add multiple tags by choosing **Add new tag**, or you can remove a tag by choosing **Remove**.
1. If you want to associate your tags with the probes for the monitor, keep **Add tags to probes created by monitor** selected. This adds the tags to the monitor probes, which can be helpful for tag-based authentication or metering.
1. Choose **Next**. On the next page, you'll specify sources and destinations, to create probes for the monitor.
## Choose sources and destinations
For each monitor in Network Synthetic Monitor, you specify one or more probes, which are a combination of an AWS source and a destination.
+ A source for a probe is a VPC and associated subnets (or just a VPC subnet) in the Regions where your network operates.
+ A destination is the combination of on-premises IP addresses, network protocols, ports, and network packet size.
**Important**
These steps are designed to be completed all at once. You can't save in-process work to continue later.
**To choose sources and destinations**
1. Prerequisite: [Define monitor details](#define-details-nw).
1. Under **AWS** **network source**, choose one or more subnets to include in the monitor. To choose all subnets within a VPC, choose the VPC. Or, choose specific subnets within a VPC. The subnets that you choose are the monitor sources.
1. For **Destination 1**, enter a destination IP address of the on-premises network. IPv4 and IPv6 addresses are both supported.
1. Choose **Advanced settings**.
1. For **Protocol**, choose the network protocol for the on-premises destination. The protocol can be either **ICMP** or **TCP**.
1. If you choose **TCP**, enter the following information:
1. Enter the **Port** that your network uses to connect. The port must be a number from **1** to **65535**.
1. Enter the **Packet size**. This is the size, in bytes, of each packet that's sent on the probe, between the source and destination. Packet size must be a number from **56** to **8500**.
1. Choose **Add destination** to add another on-premises destination to the monitor. Repeat these steps for each destination that you want to add.
1. When you're finished adding sources and destinations, choose **Next** to confirm the probes for the monitor.
## Confirm probes
On the **Confirm probes** page, review all the probes that will be created for the monitor, to make sure that they're the correct set of sources and destinations.
The **Confirm probes** page shows all the possible combinations of the sources and destinations for the probe specifications that you provided in the previous step. For example, if you have six source subnets and four destination IP addresses, there are 24 possible probe combinations, so 24 probes will be created.
**Important**
These steps are intended to be completed in one session. You can't save in-process work to continue later.
The **Confirm probes** page does not indicate whether a probe is valid. We recommend that you review this page carefully, and then delete any probes that aren't valid. You might be charged for probes that aren't valid if you don't remove them.
**To confirm monitor probes**
1. Prerequisite: [Choose sources and destinations](#source-destination-nw).
1. On the **Confirm probes** page, review the list of source and destination probe combinations.
1. Choose any probes that you want to remove from the monitor, and then choose **Remove**.
**Note**
You are not prompted to confirm deleting a probe. If you delete a probe and want to restore it, you must set it up again. You can add a probe to an existing monitor by following the steps in [Add a probe to a monitor](nw-monitor-add-probe.md).
1. Choose **Next**, and then review the monitor details.
## Review and create monitor
The final step is to review the details of the monitor and the probes for the monitor, and then create the monitor. You can change any information about the monitor at this point.
When you have finished reviewing and updating any information that isn't correct, create the monitor.
As soon as you create the monitor, Network Synthetic Monitor begins tracking metrics and you'll start being charged for probes in the monitor.
**Important**
This step is intended to be completed in one session. You can't save in-process work to continue later.
If you choose to edit a section, you must step through the process to create a monitor from the point that you make the edits. Earlier monitor creation pages maintain the information that you already entered.
**To review and create a monitor**
1. On the **Review and create probes** page, choose **Edit** for any section where you want to make changes.
1. Make changes in that section, and then choose **Next**.
1. When you're finished making edits, choose **Create monitor**.
The Network Synthetic Monitor page displays the current state of monitor creation in the **Monitors** section. When Network Synthetic Monitor is still creating the monitor, the **State** is **Pending**. When the **State** changes to **Active**, you can view CloudWatch metrics in the monitor dashboard.
For information on working with the monitor dashboard, see [Network Synthetic Monitor dashboards](nw-monitor-dashboards.md).
**Note**
It can take several minutes for a newly-added monitor to begin collecting network metrics.
# Edit a monitor
You can edit information for a Network Synthetic Monitor, including change the name, setting a new aggregation period, or adding or removing tags. Changing a monitor's information does not change any of its associated probes.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To edit a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, choose the monitor that you want to edit.
1. On the monitor dashboard page, choose **Edit**.
1. For the **Monitor name**, enter the new name for the monitor.
1. For the **Aggregation period**, choose how often you want to send metrics to CloudWatch. Valid periods are:
+ **30 seconds**
+ **60 seconds**
**Note**
A shorter aggregation period provides faster detection of network issues. However, the aggregation period that you choose can affect your billing costs. For more information about pricing, see the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
1. (Optional) In the **Tags** section, add **Key** and **Value** pairs to further help identify this resource, allowing you to search or filter on specific information. You can also just change the **Value** of any current **Key**.
1. Choose **Add new tag**.
1. Enter a **Key** name and associated **Value**.
1. Choose **Add new tag** to add the new tag.
You can add multiple tags by choosing **Add new tag**, or you can remove a tag by choosing **Remove**.
1. If you want to associate your tags with the monitor, keep **Add tags to probes created by monitor** checked. This adds the tags to the monitor probes, which can be helpful if you're using tag-based authentication or metering.
1. Choose **Save changes**.
# Delete a monitor
Before you can delete a monitor in Network Synthetic Monitor, you must deactivate or delete all probes associated with the monitor, regardless of the monitor **State**. After a monitor is deleted, you are no longer be charged for probes in the monitor. Be aware that you can't restore a deleted monitor.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To delete a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, choose the monitor that you want to delete.
1. Choose **Actions**, and then choose **Delete**.
1. If you have any active probes for the monitor, you're prompted to deactivate them. Choose **Deactivate probes**.
**Note**
You can't cancel or undo this action after you choose **Deactivate probes**. Deactivated probes, however, aren't removed from the monitor. If you like, you can reactivate them later. For more information, see [Activate or deactivate a probe](nw-monitor-probe-status.md).
1. Enter **confirm** in the confirmation field, and then choose **Delete**.
Alternatively, you can delete a monitor programmatically, for example, by using the AWS Command Line Interface.
**To delete a monitor by using the CLI**
1. To delete a monitor, you need the monitor name. If you don't know the name, get a list of your monitors by running the [list-monitors](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/list-monitors.html) command. Note the name of the monitor that you want to delete.
1. Verify whether the monitor contains any active probes. Use [get-monitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/get-monitor.html) with the monitor name from the previous step. This returns a list of any probes associated with that monitor.
1. If the monitor contains active probes, you must first either set the probes to inactive or delete them.
+ To set a probe to inactive, use [update-probe](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/update-probe.html), and set the state to `INACTIVE`.
+ To delete a probe, use [delete-probe](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/delete-probe.html).
1. After the probes are set to `INACTIVE` or deleted, you can delete the monitor by running the [delete-monitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/create-probe.html) command. Inactive probes are not deleted when you delete the monitor.
# Activate or deactivate a probe
You can activate or deactivate a probe in a monitor in Network Synthetic Monitor. You might want to deactivate a probe, for example, if you aren't currently using it but might want to use it again in the future. By deactivating a probe instead of deleting it, you won't need to spend time setting it up again. You are not billed for deactivated probes.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To set a probe to active or inactive by using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. Choose the **Monitor details** tab.
1. In the **Probes** section, choose the probe that you want to activate or deactivate.
1. Choose **Actions**, and then choose **Activate** or **Deactivate**.
**Note**
When you reactivate a probe, you begin incurring billing charges on the probe again.
# Add a probe to a monitor
You can add a probe to an existing monitor in Network Synthetic Monitor. Note that when you add probes to a monitor, your billing structure is updated to include the new probe.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To add a probe to a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, do one of the following:
+ Choose the **Name** link of the monitor that you want to add a probe to. Choose the **Monitor details** tab, and then in the **Probes** section, choose **Add probe**.
+ Choose the monitor check box, choose **Actions**, and then choose **Add probe**.
1. On the **Add probe** page, do the following:
1. Under **AWS** **network source**, choose a subnet to add to the monitor.
**Note**
You can only add one probe at a time and up to four probes per monitor.
1. Enter the destination **IP address** of the on-premises network. Both IPv4 and IPv6 addresses are supported.
1. Choose **Advanced settings**.
1. Choose the network **Protocol** for the destination. It can be either **ICMP** or **TCP**.
1. If the **Protocol** is **TCP**, enter the following information. Otherwise, skip to the next step:
+ Enter the **Port** that your network uses to connect. The port must be a number from **1** to **65535**.
+ Enter the **Packet size**. This is the size, in bytes, of each packet sent along the probe between the source and destination. Packet size must be a number from **56** to **8500**.
1. (Optional) In the **Tags** section, add **Key** and **Value** pairs to further help identify this resource, allowing you to search or filter on specific information.
1. Choose **Add new tag**.
1. Enter a **Key** name and associated **Value**.
1. Choose **Add new tag** to add the new tag.
You can add multiple tags by choosing **Add new tag**, or you can remove any tag by choosing **Remove**.
1. Choose **Add probe**.
While the probe is being activated, the **State** shows **Pending**. It might take several minutes for the probe to become **Active**.
# Edit a probe
You can change any information for an existing probe, regardless of whether that probe is active or inactive.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To edit a probe by using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
Under **Name**, choose a monitor link to open the monitor dashboard.
1. Choose the **Monitor details** tab.
1. In the **Probes** section, choose the link for the probe that you want to edit.
1. On the probe details page, choose **Edit**.
1. On the **Edit *probe*** page, enter the new destination **IP address** for the probe. IPv4 and IPv6 addresses are both supported.
1. Choose **Advanced settings**.
1. Choose a network **Protocol**, **ICMP** or **TCP**.
1. If the **Protocol** is **TCP**, enter the following information:
+ Enter the **Port** that your network uses to connect. The port must be a number from **1** to **65535**.
+ Enter the **Packet size**. This is the size, in bytes, of each packet sent along the probe between the source and destination. Packet size must be a number from **56** to **8500**.
1. (Optional) Add, change, or remove Tags for the probe.
1. Choose **Save changes**.
# Delete a probe
You can delete a probe rather than deactivating it if you know that you won't need it again later. You can't recover a deleted probe; instead, you must recreate it. Billing charges end for a probe when the probe is deleted.
You can work with monitors and probes by using either the Amazon CloudWatch console or the AWS Command Line Interface. To work with Network Synthetic Monitor programmatically, see the [Network Synthetic Monitor API Reference](https://docs.aws.amazon.com/networkmonitor/latest/APIReference/Welcome.html) and [networkmonitor](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/) in the AWS Command Line Interface Command Reference.
**To delete a probe using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, under **Name**, choose a monitor link to open the monitor dashboard.
1. Choose the **Monitor details** tab.
1. Choose the monitor check box, choose **Actions**, and then choose **Delete**.
1. In the **Delete probe** dialog box, do the following:
1. Choose **Delete** to confirm that you want to delete the probe.
The **State** of the probe in the **Probes** section shows **Deleting**. After it's deleted, the probe is removed from the **Probes** section.
# Tag or untag resources
You can work with resource tags in Network Synthetic Monitor, to add or remove tags.
You can update tags by updating monitors or probes in the console. Or, you can work with tags programmatically, for example, by using the AWS Command Line Interface.
**To update monitor tags by using the CLI**
+ To list resource tags, use [list-tags-for-resources](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/list-tags-for-resources.html).
+ To tag a resource, use [tag-resource](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/tag-resource.html).
+ To untag a resource, use [untag-resource](https://docs.aws.amazon.com/cli/latest/reference/networkmonitor/untag-resource.html).
# Network Synthetic Monitor dashboards
You can use dashboards in Network Synthetic Monitor to determine if a network issue is caused by AWS, by using the network health indicator (NHI), and view probe round-trip time and packet loss. You can view this information and metrics for monitors, as well as for individual probes.
Network Synthetic Monitor creates several metrics that you can view in CloudWatch Metrics. You can specify alarms for the metrics that Network Synthetic Monitor returns. For more information, see [Probe alarms](cw-nwm-create-alarm.md).
**Topics**
+ [Monitor dashboards](nw-monitor-db.md)
+ [Probe dashboards](nw-probe-db.md)
+ [Specify metrics time frame](nw-monitor-time-frame.md)
# Monitor dashboards
You can use the monitor dashboard in Network Synthetic Monitor to view the network health indicator (NHI), as well as probe round-trip time and packet loss at a monitor level. That is, a monitor dashboard shows this information for all the probes created for the monitor.
Network Synthetic Monitor also has dashboards for probes, to view the information at a probe level. For more information, see [Probe dashboards](nw-probe-db.md).
**To access a monitor dashboard**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, choose the **Name** link to open the monitor dashboard.
## Overview page
The **Overview** page displays the following information for a monitor:
+ **Network health** — Network health displays the network health indicator (NHI) value, which pertains to health of only the AWS network. The NHI status is displayed as **Healthy** or **Degraded**. A **Healthy** status indicates that Network Synthetic Monitor did not observe issues with the AWS network. A **Degraded** status indicates that Network Synthetic Monitor observed an issue with the AWS network. The status bar in this section shows the status of the network health indicator over a default time of one hour. Hover over any point in the status bar to view additional details.
+ **Probe traffic summary** — Displays the current state of the traffic between the source AWS subnets specified for the probes in the monitor and the probes' destination IP addresses. This summary displays the following:
+ **Probes in alarm** — This number indicates how many of your probes in this monitor are in a degraded state. An alarm is triggered when a metric that you've set up as an alarm is triggered. For information on creating alarms for metrics in Network Synthetic Monitor, see [Probe alarms](cw-nwm-create-alarm.md).
+ **Packet loss** — The number of packets that were lost from the source subnet to the destination IP address. This is represented as a percentage of the total packets sent.
+ **Round-trip time** — The time it takes, displayed in milliseconds, for a packet from the source subnet to reach the destination IP address, and then come back again. Round-trip time is the average RTT observed during the aggregation period.
The data is represented on an interactive graph, so you can explore to learn details.
By default, data is displayed for a two-hour time frame, calculated from the current date and time. However, you can change the range to fit your needs. For more information, see [Specify metrics time frame](nw-monitor-time-frame.md).
### Tracking metrics
The **Overview** dashboard in Network Synthetic Monitor displays a graphical representation of a monitor and probes. The following graphs are shown:
+ **Network health indicator** — This represents the the NHI values over a specified period. NHI indicates whether a network issue is due to problems with the AWS network. NHI is displayed as **Healthy** (no issue with the AWS network) or **Degraded** (there is an issue with the AWS network).
In the following example, you can see that from 15:00 UTC until 15:05 UTC, there was a network issue that was due to an AWS network issue (**Degraded**). After 15:05, the network issue with the AWS network ended, so the value returned to **Healthy**. You can hover over any section of the graph to see additional details.
![\[AWS network health indicator showing both a healthy and degraded state.\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/images/nwm_network_health.png)
**Note**
The NHI indicates that an issue is due to the AWS network. It does not describe the overall health of the AWS network nor the health of Network Synthetic Monitor probes.
+ **Packet loss** — This graph displays a line that shows the percentage of packet loss for each probe in a monitor. The legend at the bottom of the page displays each of the probes in the monitor, color-coded for uniqueness. You can hover over a probe in the chart to see the source subnet, the destination IP address, and the percentage of packet loss.
In the following example, a packet loss alarm was created for a probe from a subnet to IP address 127.0.0.1. The alarm was triggered when the packet loss threshold was exceeded for the probe. If you hover over the graph, you can see the probe source and destination, and that there was a 30.97% packet loss for this probe on November 21 at 02:41:30.
![\[Packet loss showing an example probe with a 30.97% packet loss.\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/images/nwm_packet_loss.png)
+ **Round-trip time** — This graph displays a line that shows the round-trip time for each probe. The legend at the bottom of the page displays each of the probes in the monitor, color-coded for uniqueness. You can hover over a probe in the chart to see the source subnet, the destination IP address, and the round-trip time.
The following example shows that on Tuesday, Nov 21, at 21:45:30, the round-trip time for a probe from a subnet to IP address 127.0.0.1 was 0.075 seconds.
![\[Example showing the round-trip time for a probe.\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/images/nwm_rtt.png)
## Monitor details
The **Monitor details** page displays details about your monitor, including a list of the probes for the monitor. You can update or add tags, or add a probe. The page includes the following sections:
+ **Monitor details ** — This page provides details about your monitor. You can't edit information in this section. However, you can view details of the Network Synthetic Monitor service-linked role: choose the **Role name** link to see details.
+ **Probes** — This section displays a list of all probes associated with the monitor. Choose a **VPC** or **Subnet ID** link to open the VPC or subnet details in the Amazon VPC Console. You can modify a probe, to activate or deactivate it. For more information, see [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md).
The **Probes** section displays information about each probe set up for that monitor, including the probe **ID**, the **VPC ID**, the** Subnet ID**, **IP address**, **Protocol**, and whether the probe is **Active** or **Inactive**.
If you've created an alarm for a probe, the current **Status** of the alarm is shown. A status of **OK** indicates that there are no metrics events have triggered any alarms. A status of **In alarm** indicates that a metric that you created in CloudWatch triggered an alarm. If no status is displayed for a probe, then there isn't a CloudWatch alarm for it. For information on the types of Network Synthetic Monitor probe alarms that you can create, see [Probe alarms](cw-nwm-create-alarm.md).
+ **Tags** — View the current tags for a monitor. You can add or remove tags by choosing **Manage tags**. This opens the **Edit probe** page. For more information on editing tags, see [Edit a monitor](nw-monitor-edit.md).
# Probe dashboards
You can use a **Probe** dashboard in Network Synthetic Monitor to view the network health indicator (NHI) for a probe, as well as information about round-trip time and packet loss for specific probes. There are two dashboards for probes: an **Overview** page and** Probe details** page.
You can create CloudWatch alarms to set packet loss and round-trip time metric thresholds. When a threshold is reached for a metric, a CloudWatch alarm notifies you. For information on creating probe alarms, see [Probe alarms](cw-nwm-create-alarm.md).
**To access a probe dashboard**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/), and then, under **Network Monitoring**, choose **Synthetic monitors**.
1. In the **Monitors** section, choose the **Name** link to open the dashboard for a specific monitor.
1. To view the dashboard for a specific probe, choose the **ID** link for the probe.
## Overview page
The **Overview** page displays the following information for a probe:
+ **Network health** — Network health displays the network health indicator (NHI) value, which pertains only to health of the AWS network. The NHI status is provided as **Healthy** or **Degraded**. A **Healthy** status indicates that Network Synthetic Monitor did not observe issues with the AWS network for a probe. A **Degraded** status indicates that Network Synthetic Monitor observed an issue with the AWS network. The status bar in this section shows the status of the network health indicator over a default time of one hour. Hover over any point in the status bar to view additional details.
+ **Packet loss** — The number of packets that were lost from the source subnet to the destination IP address for this probe.
+ **Round-trip time** — The time it takes, in milliseconds, for a packet from the source subnet to reach the destination IP address, and then come back again. Round-trip time (RTT) is the average RTT observed during the aggregation period.
## Probe details
The **Probe details** page displays information about a probe, including the source and destination. You can also edit the probe, for example, to activate or deactivate it. For more information, see [Working with monitors and probes in Network Synthetic Monitor](nw-monitor-working-with.md).
+ **Probe details** — This section provides general information about the probe, which can't be edited.
+ **Probe source and destination** — This section displays details about the probe. Choose a **VPC** or **Subnet ID** link to open the VPC or subnet details in the Amazon VPC Console. You can modify a probe, for example, to activate or deactivate it.
+ **Tags** — View the current tags for a monitor. You can add or remove tags by choosing **Manage tags**. This opens the **Edit probe** page. For more information on editing tags, see [Edit a probe](nw-monitor-probe-edit.md).
# Specify metrics time frame
Metrics and events on the dashboards in Network Synthetic Monitor use a default time of two hours, calculated from the current time, but you can set a custom metrics default time frame to use. You can change the default to one of the following presets for the metrics time frame:
+ **1h** — one hour
+ **2h** — two hours
+ **1d** — one day
+ **1w** — one week
You can also set a custom time frame. Choose **Custom**, choose an **Absolute** or **Relative** time, and then set the time frame to a time of your own choosing. Relative time supports only 15 days back from today's date, following CloudWatch guidelines.
Additionally, you can choose the time displayed in the charts to be based on either the UTC time zone or a local time zone.
For more information, see [Changing the time range or time zone format of a CloudWatch dashboard](change_dashboard_time_format.md).
# Probe alarms
You can create Amazon CloudWatch alarms based on Network Synthetic Monitor metrics, just as you can for other Amazon CloudWatch metrics. Any alarm that you create will appear in the probe's **Status** column of the **Monitor details** section of the Network Synthetic Monitor dashboard when the alarm is triggered. The status will either be **OK** or **In Alarm**. If no status displays for a probe, then no alarm was created for that probe.
For example, you can create an alarm based on the Network Synthetic Monitor metric `PacketLoss`, and configure it to send a notification when the metric is higher than a value that you choose. You configure alarms for Network Synthetic Monitor metrics following the same guidelines as for other CloudWatch metrics.
The following metrics are available under `AWS/NetworkMonitor` when creating a CloudWatch alarm for Network Synthetic Monitor.
+ **HealthIndicator**
+ **PacketLoss**
+ **RTT (Round-trip time)**
For the steps to create a Network Synthetic Monitor alarm in CloudWatch, see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
# Data security and data protection in Network Synthetic Monitor
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from data centers and network architectures that are built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Network Synthetic Monitor, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using Network Synthetic Monitor. The following topics show you how to configure Network Synthetic Monitor to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Network Synthetic Monitor resources.
**Topics**
+ [Data protection in Network Synthetic Monitor](data-protection-nw.md)
+ [Infrastructure Security in Network Synthetic Monitor](infrastructure-security-nw.md)
# Data protection in Network Synthetic Monitor
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Network Synthetic Monitor. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Network Synthetic Monitor or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Infrastructure Security in Network Synthetic Monitor
As a managed service, Network Synthetic Monitor is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper.
You use AWS published API calls to access Network Synthetic Monitor through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
# Identity and access management for Network Synthetic Monitor
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 Network Synthetic Monitor resources. IAM is an AWS service that you can use with no additional charge. You can use features of IAM to allow other users, services, and applications to use your AWS resources fully or in a limited way, without sharing your security credentials.
By default, IAM users don't have permission to create, view, or modify AWS resources. To allow an IAM user to access resources, such as a global network, and perform tasks, you must:
+ Create an IAM policy that grants the user permission to use the specific resources and API actions they need
+ Attach the policy to the IAM user or to the group to which the user belongs
When you attach a policy to a user or group of users, it allows or denies the user permissions to perform the specified tasks on the specified resources.
## Condition keys
The `Condition` element (or Condition block) lets you specify conditions in which a statement is in effect. The Condition element is optional. You can build conditional expressions that use condition operators, such as equals or less than, to match the condition in the policy with values in the request. For more information, see [IAM JSON policy elements: Condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) in the *AWS Identity and Access Management User Guide*.
If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, AWS evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement's permissions are granted.
You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name.
You can attach tags to Network Synthetic Monitor resources or pass tags in a request to Cloud WAN. To control access based on tags, you provide tag information in the condition element of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. See [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *AWS Identity and Access Management User Guide* for more information.
To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *AWS Identity and Access Management User Guide*.
## Tag core network resources
A tag is a metadata label that either you or AWS assigns to an AWS resource. Each tag consists of a key and a value. For tags that you assign, you define the key and the value. For example, you might define the key as `purpose` and the value as `test` for one resource. Tags help you do the following:
+ Identify and organize your AWS resources. Many AWS services support tagging, so you can assign the same tag to resources from different services to indicate that the resources are related.
+ Control access to your AWS resources. For more information, see [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *AWS Identify and Access Management User Guide*.
# How Network Synthetic Monitor works with IAM
Before you use IAM to manage access to Network Synthetic Monitor, learn what IAM features are available to use with Network Synthetic Monitor.
**IAM features you can use with Network Synthetic Monitor**
| IAM feature | Network Synthetic Monitor support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies-nw) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies-nw) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions-nw) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources-nw) | Yes |
| [Policy condition keys](#security_iam_service-with-iam-id-based-policies-conditionkeys-nw) | Yes |
| [ACLs](#security_iam_service-with-iam-acls-nw) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags-nw) | Partial |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds-nw) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions-nw) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service-nw) | No |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked-nw) | Yes |
To get a high-level view of how Network Synthetic Monitor and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Identity-based policies for Network Synthetic Monitor
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Identity-based policy examples for Network Synthetic Monitor
To view examples of Network Synthetic Monitor identity-based policies, see [Identity-based policy examples for Amazon CloudWatch](security_iam_id-based-policy-examples.md).
## Resource-based policies within Network Synthetic Monitor
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Policy actions for Network Synthetic Monitor
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of Network Synthetic Monitor actions, see [Actions defined by Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html#amazoncloudwatchnetworkmonitor-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in Network Synthetic Monitor use the following prefix before the action:
```
networkmonitor
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"networkmonitor:action1",
"networkmonitor:action2"
]
```
To view examples of Network Synthetic Monitor identity-based policies, see [Identity-based policy examples for Amazon CloudWatch](security_iam_id-based-policy-examples.md).
## Policy resources for Network Synthetic Monitor
**Supports policy resources:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
To see a list of Network Synthetic Monitor resource types and their ARNs, see [Resources defined by Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html#amazoncloudwatchnetworkmonitor-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html#amazoncloudwatchnetworkmonitor-actions-as-permissions).
## Policy condition keys for Network Synthetic Monitor
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of Network Synthetic Monitor condition keys, see [Condition keys for Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html#amazoncloudwatchnetworkmonitor-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html#amazoncloudwatchnetworkmonitor-actions-as-permissions).
## ACLs in Network Synthetic Monitor
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## ABAC with Network Synthetic Monitor
**Supports ABAC (tags in policies):** Partial
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using temporary credentials with Network Synthetic Monitor
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for Network Synthetic Monitor
**Supports forward access sessions (FAS):** Yes
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Network Synthetic Monitor
**Supports service roles:** No
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
**Warning**
Changing the permissions for a service role might break Network Synthetic Monitor functionality. Edit service roles only when Network Synthetic Monitor provides guidance to do so.
## Using a service-linked role for Network Synthetic Monitor
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about creating or managing service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam-nw.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# Identity-based policy examples for Network Synthetic Monitor
By default, users and roles don't have permission to create or modify Network Synthetic Monitor resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.
To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.
For details about actions and resource types defined by Network Synthetic Monitor, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for Network Synthetic Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkmonitor.html) in the *Service Authorization Reference*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices-nw)
+ [Using the Network Synthetic Monitor console](#security_iam_id-based-policy-examples-console-nw)
+ [Allow users to view their own permissions](#security_iam_id-based-policy-examples-view-own-permissions-nw)
+ [Troubleshooting Network Synthetic Monitor identity and access](security_iam_troubleshoot-nw.md)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Network Synthetic Monitor resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Using the Network Synthetic Monitor console
To access the Network Synthetic Monitor console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Network Synthetic Monitor resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.
To ensure that users and roles can still use the Network Synthetic Monitor console, also attach the Network Synthetic Monitor `ConsoleAccess` or `ReadOnly` AWS managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console-nw) in the *IAM User Guide*.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Troubleshooting Network Synthetic Monitor identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Network Synthetic Monitor and IAM.
**Topics**
+ [I am not authorized to perform an action in Network Synthetic Monitor](#security_iam_troubleshoot-no-permissions-nw)
+ [I am not authorized to perform iam:PassRole](#security_iam_troubleshoot-passrole-nw)
+ [I want to allow people outside of my AWS account to access my Network Synthetic Monitor resources](#security_iam_troubleshoot-cross-account-access-nw)
## I am not authorized to perform an action in Network Synthetic Monitor
If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a fictional `my-example-widget` resource but doesn't have the fictional `networkmonitor:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: networkmonitor:GetWidget on resource: my-example-widget
```
In this case, the policy for the `mateojackson` user must be updated to allow access to the `my-example-widget` resource by using the `networkmonitor:GetWidget` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I am not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Network Synthetic Monitor.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Network Synthetic Monitor. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to allow people outside of my AWS account to access my Network Synthetic Monitor resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Network Synthetic Monitor supports these features, see [How Amazon CloudWatch works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
# AWS managed policies for Network Synthetic Monitor
To add permissions to users, groups, and roles, it is easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an AWS managed policy, so policy updates won't break your existing permissions.
Additionally, AWS supports managed policies for job functions that span multiple services. For example, the `ReadOnlyAccess` AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
## AWS managed policy: CloudWatchNetworkMonitorServiceRolePolicy
The `CloudWatchNetworkMonitorServiceRolePolicy` is attached to a service-linked role that allows the service to perform actions on your behalf and access resources associated with CloudWatch Network Synthetic Monitor. You cannot attach this policy to your IAM identities. For more information, see [Using a service-linked role for Network Synthetic Monitor](monitoring-using-service-linked-roles-nw.md).
## Network Synthetic Monitor updates to AWS managed policies
To view details about updates to AWS managed policies for Network Synthetic Monitor since this service began tracking these changes, see [CloudWatch updates to AWS managed policies](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates). For automatic alerts about managed policy changes in CloudWatch, subscribe to the RSS feed on the CloudWatch [Document history](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) page.
# IAM permissions for Network Synthetic Monitor
To use Network Synthetic Monitor users must have the correct permissions.
For more information about security in Amazon CloudWatch, see [Identity and access management for Amazon CloudWatch](auth-and-access-control-cw.md).
## Permissions required to view a monitor
To view a monitor for Network Synthetic Monitor in the AWS Management Console, you must be signed in as a user or role that has the following permissions:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"networkmonitor:Get*",
"networkmonitor:List*"
],
"Resource": "*"
}
]
}
```
------
## Permissions required to create a monitor
To create a monitor in Network Synthetic Monitor, users must have permission to create a service-linked role that is associated with Network Synthetic Monitor. To learn more about the service-linked role, see [Using a service-linked role for Network Synthetic Monitor](monitoring-using-service-linked-roles-nw.md).
To create a monitor for Network Synthetic Monitor in the AWS Management Console, you must be signed in as a user or role that has the permissions included in the following policy.
**Note**
If you create an identity-based permissions policy that is more restrictive, users with that policy won't be able to create a monitor.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"networkmonitor:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/networkmonitor.amazonaws.com/AWSServiceRoleForNetworkMonitor",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "networkmonitor.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:GetRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/networkmonitor.amazonaws.com/AWSServiceRoleForNetworkMonitor"
},
{
"Action": [
"ec2:CreateSecurityGroup",
"ec2:CreateNetworkInterface",
"ec2:CreateTags"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# Using a service-linked role for Network Synthetic Monitor
Network Synthetic Monitor uses the following service-linked role for the permissions that it requires to call other AWS services on your behalf:
+ [`AWSServiceRoleForNetworkMonitor`](#security-iam-awsmanpol-AWSServiceRoleForNetworkMonitor)
## `AWSServiceRoleForNetworkMonitor`
Network Synthetic Monitor uses the service-linked role named `AWSServiceRoleForNetworkMonitor` to update and manage monitors.
The `AWSServiceRoleForNetworkMonitor` service-linked role trusts the following service to assume the role:
+ `networkmonitor.amazonaws.com`
The `CloudWatchNetworkMonitorServiceRolePolicy` is attached to the service linked role and grants access for the service to access VPC and EC2 resources in your account, as well as manage the monitors that you create.
### Permissions groupings
The policy is grouped into the following sets of permissions:
+ `cloudwatch` - This allows the service principal to publish network monitoring metrics to CloudWatch resources.
+ `ec2` - This allows the service principal to describe VPCs and subnets in your account to create or update monitors and probes. This also allows the service principal to create, modify, and delete security groups, network interfaces, and their associated permissions to configure the monitor or probe to send monitoring traffic to your endpoints.
To view the permissions for this policy, see [CloudWatchNetworkMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
## Create the service-linked role
`AWSServiceRoleForNetworkMonitor`
You don't need to manually create the `AWSServiceRoleForNetworkMonitor` role.
+ Network Synthetic Monitor creates the `AWSServiceRoleForNetworkMonitor` role when you create your first monitor with the feature. This role then applies to all additional monitors that you create.
To create a service-linked role on your behalf, you must have the required permissions. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Edit the service-linked role
You can edit the `AWSServiceRoleForNetworkMonitor ` descriptions using IAM. For more information, see [Editing a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Delete the service-linked role
If you no longer need to use Network Synthetic Monitor, we recommend that you delete the `AWSServiceRoleForNetworkMonitor` role.
You can delete these service-linked roles only after you delete your monitors. For more information, see [Delete a monitor](https://docs.aws.amazon.com/ ).
You can use the IAM console, the IAM CLI, or the IAM API to delete service-linked roles. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
After you delete `AWSServiceRoleForNetworkMonitor ` Network Synthetic Monitor will create the role again when you create a new monitor.
## Supported Regions for the Network Synthetic Monitor service-linked role
Network Synthetic Monitor supports the service-linked role in all of AWS Regions where the service is available. For more information, see [AWS endpoints](https://docs.aws.amazon.com//general/latest/gr/rande.html) in the *AWS General Reference*.
## Delete the service-linked role
If you no longer need to use Network Synthetic Monitor, we recommend that you delete the `AWSServiceRoleForNetworkMonitor` role.
You can delete these service-linked roles only after you delete your monitors. For more information, see [Delete a monitor](https://docs.aws.amazon.com/ ).
You can use the IAM console, the IAM CLI, or the IAM API to delete service-linked roles. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
After you delete `AWSServiceRoleForNetworkMonitor ` Network Synthetic Monitor will create the role again when you create a new monitor.