# 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.