# Using Network Flow Monitor
Network Flow Monitor gives you near real-time visibility into network performance for traffic between compute resources (Amazon EC2 and Amazon Elastic Kubernetes Service), traffic to other AWS services (Amazon S3 and Amazon DynamoDB), and traffic to the edge of another AWS Region. Network Flow Monitor collects data from lightweight software agents that you install on your instances. These agents gather performance statistics from TCP connections and send this data to the Network Flow Monitor backend service, which calculates the top contributors for each metric type.
Network Flow Monitor also determines if AWS is the cause of a detected network issue, and reports that information for network flows that you choose to monitor details for.
You can view network performance information for network flows for resources in a single account, or you can configure Network Flow Monitor with AWS Organizations to view performance information for multiple accounts in an organization, by signing in with a management or delegated administrator account.
Network Flow Monitor is intended for network operators and application developers who want near real-time insights into network performance. In the Network Flow Monitor console in CloudWatch, you can see performance data for your resources' network traffic that has been aggregated from agents and grouped into different categories. For example, you can see data for flows between Availability Zones or between VPCs. Then, you can create monitors for specific flows that you want to see more details for or track more closely over time.
Using a monitor, you can quickly visualize packet loss and latency of your network connections over a time frame that you specify. For each monitor, Network Flow Monitor also generates a network health indicator (NHI). The NHI value informs you whether there were AWS network issues for the network flows tracked by your monitor during the time period that you're evaluating. Using the NHI information, you can quickly decide whether to focus troubleshooting efforts on an AWS network issue or network problems originating with your workloads.
To see an example of configuring and using Network Flow Monitor, see the following blog post: [ Visualizing network performance of your AWS Cloud workloads with Network Flow Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/visualizing-network-performance-of-your-aws-cloud-workloads-with-network-flow-monitor/).
# What is Network Flow Monitor?
Network Flow Monitor is a feature of Amazon CloudWatch Network Monitoring. Network Flow Monitor uses fully-managed agents that you install in your AWS workloads to return performance and availability metrics about network flows. Using Network Flow Monitor, you can access near real-time metrics, including retransmissions and data transferred, for your actual workloads. You can also identify whether an underlying AWS network issue occurred for the network flows tracked by a monitor, by checking network health indicator (NHI) values.
**Key features of Network Flow Monitor**
+ With Network Flow Monitor, you receive near real-time metrics for the latency and packet-loss experienced by TCP-based traffic within your VPC network, so that you can track and investigate network issues for your workload traffic.
+ When your AWS workloads experience network degradation, Network Flow Monitor helps you to determine if the problem is caused by your application workload or the underlying AWS infrastructure. Then, you can quickly focus troubleshooting on the area where the issue is occurring.
**How to use Network Flow Monitor**
With Network Flow Monitor, you install lightweight agents on your instances, which collect and aggregate performance metrics. Network Flow Monitor agents analyze TCP traffic, and then export performance metrics to the Network Flow Monitor service backend.
Agents gather the following metrics for your workloads: TCP round-trip time (RTT), TCP retransmission timeouts, TCP retransmissions, and data (bytes) transferred. After you install agents on your instances, the agents detect the corresponding workloads that are hosted by the instances. The agents then generate network performance metrics and send the metrics to the Network Flow Monitor backend. Metrics are aggregated into categories such as subnets, Availability Zones, VPCs, and AWS services.
Performance metrics for top contributors (by metric type) from all network flows that are in your Network Flow Monitor scope are shown on the **Workload insights** tab in the AWS Management Console. By reviewing the tables and graphs of top contributors, you can determine where there might be impairments that you want to troubleshoot and which workloads you want to monitor on an ongoing basis, by creating a monitor.
With a monitor, you can monitor specific workloads more closely over time and see detailed information about specific network flows. In addition to viewing performance metrics for the top contributors for the network flows that you've selected, you can view network path information with the network hops that a network flow has traversed, to help you troubleshoot issues. In addition, Network Flow Monitor generates a network health indicator (NHI) for monitors. An NHI value of **Degraded** indicates that there were AWS network issues for at least one of the network flows tracked by your monitor, during the time period that you've selected.
In addition to reviewing the information in monitors that you create, we recommend that you also check back regularly to review metrics on the **Workload insights** page, to see the latest top contributors for performance metrics for your network flows. As you review the latest information, consider if it would be helpful to add or remove workloads from your current monitors, or create new monitors.
**Topics**
+ [Supported AWS Regions](CloudWatch-NetworkFlowMonitor-Regions.md)
+ [Components](CloudWatch-NetworkFlowMonitor-components.md)
+ [How it works](CloudWatch-NetworkFlowMonitor-inside-network-flow-monitor.md)
+ [Pricing](CloudWatch-NetworkFlowMonitor.pricing.md)
# Supported AWS Regions for Network Flow Monitor
Network Flow Monitor is currently available in the following AWS Regions:
| Region name | Region |
| --- | --- |
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Osaka) | ap-northeast-3 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| Canada (Central) | ca-central-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Paris) | eu-west-3 |
| Europe (Stockholm) | eu-north-1 |
| South America (São Paulo) | sa-east-1 |
| US East (N. Virginia) | us-east-1 |
| US East (Ohio) | us-east-2 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
# Components and features of Network Flow Monitor
Network Flow Monitor uses or references the following concepts.
**Agents**
An *agent* in Network Flow Monitor is a software application that you install on your AWS compute resources (Amazon EC2 and Amazon EKS). The application has two parts:
+ The first part receives events related to TCP connections and is registered within the Linux kernel using eBPF. eBPF is the Linux extended Berkley Packet Filter (eBPF) capability that allows a designated program to receive certain events raised by the Linux kernel.
+ The second part aggregates the statistics collected by the eBPF portion. The agent sends the aggregated metrics to the Network Flow Monitor backend about every 30 seconds, with a 5 second potential jitter (in other words, 25 to 35 seconds).
For more information about agents, see [How it works](CloudWatch-NetworkFlowMonitor-inside-network-flow-monitor.md).
**Top contributors**
*Top contributors* are the network flows that have the highest values for a specific metric (such as retransmissions) in your Network Flow Monitor scope or among the network flows you're tracking in a monitor. Reviewing the flows with the highest reported numbers for performance metric measurements can help you see where there might be impairments to investigate. Network Flow Monitor returns performance metrics for top contributors in your monitoring scope for *workload insights*. In addition, if you create a monitor, Network Flow Monitor returns performance metrics for top contributors for the network flows that you choose for the monitor.
**Local and remote resources**
A *local resource* is the host location—or a location of multiple hosts—where a Network Flow Monitor agent is installed. It can be a subnet, a VPC, an Availability Zone, an Amazon EKS cluster, or an AWS Region. For example, consider a workload that consists of an interaction between a web service and a backend database, for example, DynamoDB. In this scenario, the local resource is the subnet of the EC2 instance hosting the web service, which also runs the agent. A network flow is typically directional, though it can be configured to be bi-directional.
A *remote resource* is the other end of a network flow. In this example of a web service with a backend database, DynamoDB is the remote resource. A remote resource can be a subnet, a VPC, an Availability Zone, an AWS service, or an AWS Region. If you specify a Region as a remote resource, Network Flow Monitor measures performance for the network flow up to the edge of the Region. It does not measure performance to specific endpoints within the Region.
A resource is identified by the ARN of the resource, the name of the AWS service, or, for an Availability Zone or Region, by the name of the zone or Region.
**Workload insights**
*Workload insights* includes the performance metrics returned for all the network flows in your scope. In the AWS Management Console, the **Workload insights** page provides performance data about workloads where you've installed Network Flow Monitor agents on workload instances. The **Workload insights** page provides a view into your applications that includes the amount of data transferred and several other metrics, grouped into categories of workloads. For example, you can see all the metrics for workloads with traffic between Availability Zones (AZs) or within an AZ. By using these insights, you can select workloads for which you want to create a monitor to see more details and to track network performance on an ongoing basis.
**Monitors**
You create a *monitor* so that you can monitor, on an ongoing basis, the network performance for one or several specific workloads, and see more detailed information about the network flows. For each monitor, Network Flow Monitor publishes end-to-end performance metrics, and a network health indicator (NHI), which you can use to help determine attribution for impairments. We recommend that you review information on the **Workload insights** page to see which network flows you want to focus on, and then create a monitor for those flows. Then, by regularly reviewing **Workload insights**, you can decide if you have the monitors that you need, or if creating new monitors would be helpful.
**Network health indicator (NHI)**
The *network health indicator* (NHI) is a binary value that informs you whether there were AWS network issues for one or more of the network flows tracked by a monitor, during a time period that you choose. When the NHI value is 1, or **Degraded**, there was an AWS network issue for at least one network flow. With the NHI indicator, you can quickly decide whether to focus troubleshooting efforts on an AWS network issue or network problems originating with your workloads.
For more information, see [View Network Flow Monitor metrics in CloudWatch](CloudWatch-NetworkFlowMonitor-cw-metrics.md).
**Scope**
In Network Flow Monitor, the *scope* is the account or accounts that you have observability for when you look at network performance indicators. If you sign in as a management account and configure AWS Organizations with CloudWatch, you can set your scope to more than one account in your organization (up to 100 accounts total). Otherwise, if you sign in with an AWS account that does not have management permissions in Organizations, or if you have not configured Organizations with CloudWatch, Network Flow Monitor sets your scope to the account that you're signed in with.
After you have configured Organizations, you can change your scope by adding or removing accounts. However, whenever you change the scope, Network Flow Monitor must create a new topology of the resources in the scope. For more information, see [Add multiple accounts to your scope](CloudWatch-NetworkFlowMonitor-multi-account.md#CloudWatch-NetworkFlowMonitor-multi-account.config-scope).
Network Flow Monitor generates a unique **scope ID** for the scope. Queries for metrics data use the scope ID to determine the resources that the Network Flow Monitor generates metrics for. (You must install agents to gather and submit metrics data before you can view the performance metrics for an account with Network Flow Monitor.)
**Query ID**
Network Flow Monitor generates a unique *query ID* for each query that is created to retrieve performance metrics data, such as a query for top contributors for a monitor. By using a query ID with an API call in Network Flow Monitor, you can check the status of a query, stop a query, run the query again, or work with the query in other ways.
**Performance metrics**
Network Flow Monitor gathers and calculates end-to-end *performance metrics*, including TCP round-trip time (RTT), TCP retransmissions, TCP retransmission time outs, and bytes transferred for each flow that is in your Network Flow Monitor scope. The service aggregates these metrics and returns them to the service backend. You can view top contributors by metric type. When you see an anomaly in Network Flow Monitor, you can also check the network health indicator (NHI) to see if there is an underlying AWS network issue.
Be aware that RTT data can be sparse because RTT is not always calculated.
You can also use Amazon CloudWatch features to create dashboards, alarms, and notifications based on these metrics. For example, you can learn about setting up alarms with Network Flow Monitor metrics by reviewing the information in [Create alarms with Network Flow Monitor](CloudWatch-NetworkFlowMonitor-create-alarm.md).
# How it works
This section provides information about several aspects of how Network Flow Monitor works.
**How Network Flow Monitor agents gather statistics**
Agents in Network Flow Monitor are installed on AWS compute resources (Amazon EC2 and Amazon EKS), where they gather performance metrics and send them to the Network Flow Monitor backend. Agents do not have access to the payload of your TCP connections. Agents receive only what is called the "bpf\$1sock\$1ops" structure from the Linux kernel. This structure provides the local and remote IP address and the source and destination TCP port, as well as counters and round-trip times. For list of the TCP statistics collected and published by the agent, see [View Network Flow Monitor metrics in CloudWatch](CloudWatch-NetworkFlowMonitor-cw-metrics.md).
The agent uses the Network Flow Monitor `Publish` API to send metrics to the Network Flow Monitor backend server.
*Note:* Network Flow Monitor supports up to approximately 5 million flows per minute. This is approximately 5,000 instances (Amazon EC2 and Amazon EKS nodes) with NFM agent installed. Installing agents on more than 5000 instances may affect monitoring performance until additional capacity is available.
**How network flows are categorized in Network Flow Monitor**
Network Flow Monitor categorizes network flows into classifications depending on where the flows originate and terminate.
# Pricing for Network Flow Monitor
With Network Flow Monitor, there are no upfront costs or long-term commitments. Pricing for Network Flow Monitor has two components: resources monitored (agents installed and actively sending data) and CloudWatch metrics vended. Note that you are also charged standard CloudWatch prices for any additional metrics, dashboards, alarms, or insights that you create.
For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page.
# Get started with Network Flow Monitor
To help you get started, the section provides a high level overview of the steps to configure, and then gain insights, with Network Flow Monitor. For details, see the additional sections in this guide about initializing Network Flow Monitor, deploying agents, and creating monitors.
+ Initialize Network Flow Monitor, to accept service-linked role permissions, create a *scope* for monitoring in Network Flow Monitor, and create an initial topology. If you want to observe network performance for network flows for instances in multiple accounts, you must integrate with AWS Organizations, and then add the accounts to your scope. To learn more, see [Initialize Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-begin.md).
+ Deploy *agents* on your instances, by using AWS Systems Manager or by configuring Kubernetes, depending on how your resources are deployed. If you install agents on VPC EC2 instances, make sure that you enable permissions for agents on each instance to send metrics to the Network Flow Monitor backend. To learn more, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
+ Review top contributor metrics for network flows returned by the agents, to gain *workload insights*. Workload insights provide a high-level view of the performance for network flows in the scope you're monitoring.
+ Based on the network flows that you want to see detailed network information about, create one or more *monitors*. For each monitor, specify the local and remote resources that you want to monitor network flows between. Using a monitor, you can see detailed metrics and information, including the network health indicator, as well as view network paths for specific network flows, over time periods that you select.
+ On a regular basis:
+ Review network flow information in the monitors that you've created, to learn about and help troubleshoot network impairments in your workloads.
+ Review workload insights for the network flows that you're monitoring, to determine if the monitors that you've created are covering the most relevant network flows or if it would be helpful to create new monitors.
# Network Flow Monitor API operations
The following table lists Network Flow Monitor API operations that you can use with Network Flow Monitor. The table also includes links to relevant documentation.
| Action | API operation | More information |
| --- | --- | --- |
| Create a flow monitor. | See [CreateMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateMonitor.html) | See [Create a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md) |
| Generate metrics for a scope of resources. | See [CreateScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateScope.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Remove a monitor. | See [DeleteMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_DeleteMonitor.html) | See [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md) |
| Delete a defined scope. | See [DeleteScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_DeleteScope.html) | See [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md) |
| Get information about a monitor. | See [GetMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetMonitor.html) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Get query data for the top contributors in a specific monitor. | See [GetQueryResultsMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsMonitorTopContributors.html) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Query the top contributors for a defined scope for workload insights. | See [GetQueryResultsWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsWorkloadInsightsTopContributors.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Query workload insights data for the top contributors in a specific scope. | See [GetQueryResultsWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryResultsWorkloadInsightsTopContributorsData.html) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Check the status of a query for top contributors in a monitor to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusMonitorTopContributors.html) | N/A |
| Check the status of a query on workload insights for top contributors to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusWorkloadInsightsTopContributors.html) | N/A |
| Check the status of a query on workload insights data for top contributors to ensure that it has succeeded before reviewing the results. | See [GetQueryStatusWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetQueryStatusWorkloadInsightsTopContributorsData) | N/A |
| Get information about an account, or scope, including name, status, tags, and target details. | See [GetScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_GetScope) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| List all monitors in an account. | See [ListMonitors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListMonitors) | [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| List all scopes for an account. | See [ListScopes](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListScopes) | N/A |
| List all tags for a specific resource. | See [ListTagsForResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_ListTagsForResource) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| See query data for top contributors in a monitor. | See [StartQueryMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StartQueryMonitorTopContributors) | See [Monitor and analyze network flows with a Network Flow Monitor monitor](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md) |
| Start a query to gather workload insights data for top contributors. | See [StartQueryWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StartQueryWorkloadInsightsTopContributors) | See [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md) |
| Stop a query for top contributors in a monitor. | See [StopQueryMonitorTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryMonitorTopContributors) | N/A |
| Stop a query on workload insights data for top contributors. | See [StopQueryWorkloadInsightsTopContributors](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryWorkloadInsightsTopContributors) | N/A |
| Stop a query on workload insights data for top contributors. | See [StopQueryWorkloadInsightsTopContributorsData](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_StopQueryWorkloadInsightsTopContributorsData) | N/A |
| Add a tag to a resource. | See [TagResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_TagResource) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Remove a tag from a resource. | See [UntagResource](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UntagResource) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Update a monitor to add or remove local or remote resources. | See [UpdateMonitor](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UpdateMonitor) | See [Edit a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md) |
| Modify a scope to add or remove resources that Network Flow Monitor will generate metrics on. | See [UpdateScope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_UpdateScope) | N/A |
# Examples of using the CLI with Network Flow Monitor
This section includes examples for using the AWS Command Line Interface with Network Flow Monitor operations.
Before you begin, make sure that you log in to use the AWS CLI with the AWS account that provides the scope that you want to use to monitor network flows. For more information about using API actions with Network Flow Monitor, see the [Network Flow Monitor API Reference Guide](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/Welcome.html).
**Topics**
+ [
## Create a monitor
](#CloudWatch-NFM-get-started-CLI-create-monitor)
+ [
## View monitor details
](#CloudWatch-NFM-get-started-CLI-mon-details)
+ [
## Create a scope
](#CloudWatch-NFM-get-started-CLI-create-scope)
+ [
## Delete a monitor
](#CloudWatch-NFM-get-started-CLI-delete-monitor)
+ [
## Delete a scope
](#CloudWatch-NFM-get-started-CLI-delete-scope)
+ [
## Get information about a monitor
](#CloudWatch-NFM-get-started-CLI-get-monitor)
+ [
## Retrieve data on a specific queries
](#CloudWatch-NFM-get-started-CLI-get-query-results)
+ [
## See scope information
](#CloudWatch-NFM-get-scope)
+ [
## See a list of monitors for an account
](#CloudWatch-NFM-list-monitors)
+ [
## See a list of scopes for an account
](#CloudWatch-NFM-list-scopes)
+ [
## See the list of tags for a monitor
](#CloudWatch-NFM-list-tags-for-resource)
+ [
## Starting and stopping queries
](#CloudWatch-NFM-query-monitors)
+ [
## Tag a monitor
](#CloudWatch-NFM-tag-resource)
+ [
## Remove a tag from a monitor
](#CloudWatch-NFM-untag-resource)
+ [
## Update an existing monitor
](#CloudWatch-NFM-update-monitor)
## Create a monitor
To create a monitor with the AWS CLI, use the `create-monitor` command. The following example creates a monitor named `demo` in the specified account.
```
aws networkflowmonitor create-monitor \
--monitor-name demo \
--local-resources type="AWS::EC2::VPC",identifier="arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889" \
--scope-arn arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-44556677889
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/demo",
"monitorName": "demo",
"monitorStatus": "ACTIVE",
"tags": {}
}
```
For more information, see [Create a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md).
## View monitor details
To view information about a monitor with the AWS CLI, use the `get-monitor` command.
```
aws networkflowmonitor get-monitor --monitor-name "TestMonitor"
```
Output:
```
{
"ClientLocationType": "city",
"CreatedAt": "2022-09-22T19:27:47Z",
"ModifiedAt": "2022-09-22T19:28:30Z",
"MonitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/TestMonitor",
"MonitorName": "TestMonitor",
"ProcessingStatus": "OK",
"ProcessingStatusInfo": "The monitor is actively processing data",
"Resources": [
"arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
],
"MaxCityNetworksToMonitor": 10000,
"Status": "ACTIVE"
}
```
## Create a scope
The following `create-scope` example creates a scope that is the set of resources for which Network Flow Monitor will generate network traffic metrics.
```
aws networkflowmonitor create-scope \
--targets '[{"targetIdentifier":{"targetId":{"accountId":"111122223333"},"targetType":"ACCOUNT"},"region":"us-east-1"}]'
```
Output:
```
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "IN_PROGRESS",
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Delete a monitor
The following `delete-monitor` example deletes a monitor named `Demo` in your account.
```
aws networkflowmonitor delete-monitor \
--monitor-name Demo
```
This command produces no output.
For more information, see [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md).
## Delete a scope
The following `delete-scope` example deletes the specified scope.
```
aws networkflowmonitor delete-scope \
--scope-id sample-aaaa-bbbb-cccc-44556677889
```
This command produces no output.
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Get information about a monitor
The following `get-monitor` example displays information about the monitor named `demo` in the specified account.
```
aws networkflowmonitor get-monitor \
--monitor-name Demo
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE",
"localResources": [
{
"type": "AWS::EC2::VPC",
"identifier": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
],
"remoteResources": [],
"createdAt": "2024-12-09T12:21:51.616000-06:00",
"modifiedAt": "2024-12-09T12:21:55.412000-06:00",
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## Retrieve data on a specific queries
The following sections provide example CLI commands to retrieve query statuses.
### get-query-results-workload-insights-top-contributors-data
The `get-query-results-workload-insights-top-contributors-data` example returns the data for the specified query.
```
aws networkflowmonitor get-query-results-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"datapoints": [
{
"timestamps": [
"2024-12-09T19:00:00+00:00",
"2024-12-09T19:05:00+00:00",
"2024-12-09T19:10:00+00:00"
],
"values": [
259943.0,
194856.0,
216432.0
],
"label": "use1-az6"
}
],
"unit": "Bytes"
}
```
### get-query-results-workload-insights-top-contributors
The following `get-query-results-workload-insights-top-contributors` example returns the data for the specified query.
```
aws networkflowmonitor get-query-results-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"topContributors": [
{
"accountId": "111122223333",
"localSubnetId": "subnet-SAMPLE1111",
"localAz": "use1-az6",
"localVpcId": "vpc-SAMPLE2222",
"localRegion": "us-east-1",
"remoteIdentifier": "",
"value": 333333,
"localSubnetArn": "arn:aws:ec2:us-east-1:111122223333:subnet/subnet-2222444455556666",
"localVpcArn": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
]
}
```
### get-query-status-monitor-top-contributors
The following `get-query-status-monitor-top-contributors` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-monitor-top-contributors \
--monitor-name Demo \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
### get-query-status-workload-insights-top-contributors-data
The following `get-query-status-workload-insights-top-contributors-data` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
### get-query-results-workload-insights-top-contributors
The following `get-query-results-workload-insights-top-contributors` example displays the current status of the query in the specified account.
```
aws networkflowmonitor get-query-status-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
Output:
```
{
"status": "SUCCEEDED"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
## See scope information
The following `get-scope` example displays information about a scope, such as status, tags, name, and target details.
```
aws networkflowmonitor get-scope \
--scope-id sample-aaaa-bbbb-cccc-11112222333
```
Output:
```
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "SUCCEEDED",
"scopeArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-11112222333",
"targets": [
{
"targetIdentifier": {
"targetId": {
"accountId": "111122223333"
},
"targetType": "ACCOUNT"
},
"region": "us-east-1"
}
],
"tags": {}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See a list of monitors for an account
The following `list-monitors` example returns all the monitors in the specified account.
```
aws networkflowmonitor list-monitors
```
Output:
```
{
"monitors": [
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE"
}
]
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See a list of scopes for an account
The following `list-scopes` example lists all the scopes in the specified account.
```
aws networkflowmonitor list-scopes
```
Output:
```
{
"scopes": [
{
"scopeId": "sample-aaaa-bbbb-cccc-11112222333",
"status": "SUCCEEDED",
"scopeArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:scope/sample-aaaa-bbbb-cccc-11112222333"
}
]
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
## See the list of tags for a monitor
The following `list-tags-for-resource` example returns all the tags associated with the specified resource.
```
aws networkflowmonitor list-tags-for-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo
```
Output:
```
{
"tags": {
"Value": "Production",
"Key": "stack"
}
}
```
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Starting and stopping queries
The following sections provide example CLI commands for starting and stopping queries in Network Flow Monitor.
### start-query-monitor-top-contributors
The following `start-query-monitor-top-contributors` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-monitor-top-contributors \
--monitor-name Demo \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### start-query-workload-insights-top-contributors-data
The following `start-query-workload-insights-top-contributors-data` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### start-query-workload-insights-top-contributors
The following `start-query-workload-insights-top-contributors` example starts the query which returns a queryId to retrieve the top contributors.
```
aws networkflowmonitor start-query-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--start-time 2024-12-09T19:00:00Z \
--end-time 2024-12-09T19:15:00Z \
--metric-name DATA_TRANSFERRED \
--destination-category UNCLASSIFIED
```
Output:
```
{
"queryId": "sample-dddd-eeee-ffff-44556677889"
}
```
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-monitor-top-contributors
The following `stop-query-monitor-top-contributors` example stops the query in the specified account.
```
aws networkflowmonitor stop-query-monitor-top-contributors \
--monitor-name Demo \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-workload-insights-top-contributors-data
The following `stop-query-workload-insights-top-contributors-data` stops the query in the specified account.
```
aws networkflowmonitor stop-query-workload-insights-top-contributors-data \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
### stop-query-workload-insights-top-contributors
The following `stop-query-workload-insights-top-contributors` example stops the query in the specified account.
```
aws networkflowmonitor stop-query-workload-insights-top-contributors \
--scope-id sample-aaaa-bbbb-cccc-11112222333 \
--query-id sample-dddd-eeee-ffff-44556677889
```
This command produces no output.
For more information, see [Evaluate network flows with workload insights](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md).
## Tag a monitor
The following `tag-resource` adds a tag to the monitor in the specified account.
```
aws networkflowmonitor tag-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo \
--tags Key=stack,Value=Production
```
This command produces no output.
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Remove a tag from a monitor
The following `untag-resource` example removes a tag to the monitor in the specified account.
```
aws networkflowmonitor untag-resource \
--resource-arn arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo \
--tag-keys stack
```
This command produces no output.
For more information, see [Tagging your Amazon CloudWatch resources](CloudWatch-Tagging.md).
## Update an existing monitor
The following `update-monitor` example updates the monitor named ``Demo`` in the specified account.
```
aws networkflowmonitor update-monitor \
--monitor-name Demo \
--local-resources-to-add type="AWS::EC2::VPC",identifier="arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
```
Output:
```
{
"monitorArn": "arn:aws:networkflowmonitor:us-east-1:111122223333:monitor/Demo",
"monitorName": "Demo",
"monitorStatus": "ACTIVE",
"tags": {
"Value": "Production",
"Key": "stack"
}
}
```
For more information, see [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
# Work with EKS
Using Network Flow Monitor, you can collect performance metrics for workloads that use Amazon Elastic Kubernetes Service (Amazon EKS). This chapter shows you how to install the agent step-by-step and describes the different EKS scenarios you can monitor. You'll also find detailed descriptions of the metadata that Network Flow Monitor provides for Amazon EKS in the console to help you understand network performance.
To gain the benefits of Network Flow Monitor performance monitoring, you must first install the AWS Network Flow Monitor Agent add-on for Amazon EKS. For more information, see [Install the EKS AWS Network Flow Monitor Agent add-on](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md).
If you want to monitor a single EKS cluster with enhanced visibility of workload traffic and performance insights within the cluster and with external destinations, see [Amazon EKS Network Observability](https://docs.aws.amazon.com/eks/latest/userguide/network-observability.html).
**Topics**
+ [
# Install the EKS AWS Network Flow Monitor Agent add-on
](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md)
+ [
# Additional network path metadata included for Amazon EKS
](CloudWatch-NetworkFlowMonitor-work-with-eks.performance-metadata.md)
# Install the EKS AWS Network Flow Monitor Agent add-on
Follow the steps in this section to install the AWS Network Flow Monitor Agent add-on for Amazon Elastic Kubernetes Service (Amazon EKS), to send Network Flow Monitor metrics to the Network Flow Monitor backend from Kubernetes clusters. After you complete the steps, AWS Network Flow Monitor Agent pods will be running on all of your Kubernetes cluster nodes.
If you use self-managed Kubernetes clusters, the installation steps to follow are in the previous section: [Install agents for self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents-kubernetes-non-eks.md).
Be aware that Customer Managed prefix lists [Customer Managed prefix lists](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-managed-prefix-lists.html) are not supported for Network Flow Monitor.
You can install the add-on by using the console or by using API commands with the AWS Command Line Interface.
**Topics**
+ [
## Prerequisites for installing the add-on
](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-prereq)
+ [Install the add-on by using the console](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-console)
+ [Install the add-on by using the CLI](#CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-cli)
+ [Configure for third party tools](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks-third-party.md)
## Prerequisites for installing the add-on
Regardless of whether you use the console or the CLI to install the AWS Network Flow Monitor Agent add-on, there are several requirements for installing the add-on with Kubernetes.
**Ensure that your version of Kubernetes is supported**
Network Flow Monitor agent installation requires Kubernetes Version 1.25, or a more recent version.
**Amazon EKS Pod Identity Agent add-on installation**
You can install the Amazon EKS Pod Identity Agent add-on in the console or by using the CLI.
Amazon EKS Pod Identity associations provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Amazon EKS Pod Identity provides credentials to your workloads with an additional Amazon EKS Auth API and an agent pod that runs on each node.
To learn more and see the steps for installing the Amazon EKS Pod Identity add-on, see [Set up the Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) in the Amazon EKS User Guide.
## Install the AWS Network Flow Monitor Agent add-on by using the console
Follow the steps in this section to install and configure the AWS Network Flow Monitor Agent add-on in the Amazon EKS console.
If you have already installed the add-on and have issues upgrading to a new version, see [Troubleshoot issues in EKS agents installation](CloudWatch-NetworkFlowMonitor-troubleshooting.md#CloudWatch-NetworkFlowMonitor-troubleshooting.ec2-agent-installation).
Before you begin, make sure that you have installed the Amazon EKS Pod Identity Agent add-on. For more information, see the [previous section](#NFMPodIdentity).
**To install the add-on using the console**
1. In the AWS Management Console, navigate to the Amazon EKS console.
1. On the page for installing add-ons, in the list of add-ons, choose **AWS Network Flow Monitor Agent**.
1. Configure the add-on settings.
1. For **Add-on access**, choose **EKS Pod Identity**.
1. For the IAM role to use with the add-on, use a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). This policy gives permission for an agent to send telemetry reports to the Network Flow Monitor endpoint. If you don't already have a role with the policy attached, create a role by choosing **Create recommended role**, and following the steps in the IAM console.
1. Choose **Next**.
1. On the **Review and add** page, make sure that the add-on configuration looks correct, and then choose **Create**.
## Install the AWS Network Flow Monitor Agent add-on by using the AWS Command Line Interface
Follow the steps in this section to install the AWS Network Flow Monitor Agent add-on for Amazon EKS by using the AWS Command Line Interface.
**1. Install the EKS Pod Identity Agent add-on**
Before you begin, make sure that you have installed the Amazon EKS Pod Identity Agent add-on. For more information, see the [earlier section](#NFMPodIdentity).
**2. Create the required IAM role**
The AWS Network Flow Monitor Agent add-on must have permission to send metrics to the Network Flow Monitor backend. You must attach a role with the required permissions when you create the add-on. Create a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). You need the ARN of this IAM role to install the add-on.
**3. Install the AWS Network Flow Monitor Agent add-on**
To install the AWS Network Flow Monitor Agent add-on for your cluster, run the following command:
`aws eks create-addon --cluster-name CLUSTER NAME --addon-name aws-network-flow-monitoring-agent --region AWS REGION --pod-identity-associations serviceAccount=aws-network-flow-monitor-agent-service-account,roleArn=IAM ROLE ARN`
The result should be similar to the following:
```
{
"addon": {
"addonName": "aws-network-flow-monitoring-agent",
"clusterName": "ExampleClusterName",
"status": "CREATING",
"addonVersion": "v1.0.0-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:us-west-2:000000000000:addon/ExampleClusterName/aws-network-flow-monitoring-agent/eec11111-bbbb-EXAMPLE",
"createdAt": "2024-10-25T16:38:07.213000+00:00",
"modifiedAt": "2024-10-25T16:38:07.240000+00:00",
"tags": {},
"podIdentityAssociations": [
"arn:aws:eks:us-west-2:000000000000:podidentityassociation/ExampleClusterName/a-3EXAMPLE5555555"
]
}
}
```
**4. Make sure that the add-on is active**
Review the installed AWS Network Flow Monitor Agent add-on to ensure that it's active for your cluster. Run the following command to verify that the status is `ACTIVE`:
`aws eks describe-addon --cluster-name CLUSTER NAME --addon-name aws-network-flow-monitoring-agent --region AWS REGION`
The result should be similar to the following:
```
{
"addon": {
"addonName": "aws-network-flow-monitoring-agent",
"clusterName": "ExampleClusterName",
"status": "ACTIVE",
"addonVersion": "v1.0.0-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:us-west-2:000000000000:addon/ExampleClusterName/aws-network-flow-monitoring-agent/eec11111-bbbb-EXAMPLE",
"createdAt": "2024-10-25T16:38:07.213000+00:00",
"modifiedAt": "2024-10-25T16:38:07.240000+00:00",
"tags": {},
"podIdentityAssociations": [
"arn:aws:eks:us-west-2:000000000000:podidentityassociation/ExampleClusterName/a-3EXAMPLE5555555"
]
}
}
```
# Configure add-on for third party monitoring tools
You can configure the Network Flow Monitor add-on to expose an OpenMetrics server during installation. This enables integration with third-party monitoring tools such as Prometheus, allowing you to collect and analyze network flow metrics alongside your existing monitoring infrastructure. [Learn more about about OpenMetrics](https://openmetrics.io/). This feature is available from add-on version v1.1.0.
To enable the OpenMetrics server, add OPEN\$1METRICS, OPEN\$1METRICS\$1ADDRESS, and OPEN\$1METRICS\$1PORT to the configuration values of the EKS Network Flow Monitor add-on. This guide will explain how to do this using both CLI and Console. See [Amazon EKS add-ons advanced configuration](https://aws.amazon.com/blogs/containers/amazon-eks-add-ons-advanced-configuration/) for additional details about adding configuration values.
## CLI Configuration
When using AWS Command Line Interface, you can provide the configuration values as a parameter:
```
aws eks create-addon \
--cluster-name my-cluster-name \
--addon-name aws-network-flow-monitoring-agent \
--addon-version v1.1.0-eksbuild.1 \
--configuration-values '{"env":{"OPEN_METRICS":"on","OPEN_METRICS_ADDRESS":"0.0.0.0","OPEN_METRICS_PORT":9109}}'
```
## Console Configuration
When using the Amazon EKS Console, these values can be added under Optional configuration settings, as part of the Configuration values.
**Sample JSON:**
```
{
"env": {
"OPEN_METRICS": "on",
"OPEN_METRICS_ADDRESS": "0.0.0.0",
"OPEN_METRICS_PORT": 9109
}
}
```
**Sample YAML:**
```
env:
OPEN_METRICS: "on"
OPEN_METRICS_ADDRESS: "0.0.0.0"
OPEN_METRICS_PORT: 9109
```
## EKS Network Flow Monitor add-on OpenMetric Parameters
+ **OPEN\$1METRICS:**
+ Enable or disable open metrics. Disabled if not supplied
+ Type: String
+ Values: ["on", "off"]
+ **OPEN\$1METRICS\$1ADDRESS:**
+ Listening IP address for open metrics endpoint. Defaults to 127.0.0.1 if not supplied
+ Type: String
+ **OPEN\$1METRICS\$1PORT:**
+ Listening port for open metrics endpoint. Defaults to 80 if not supplied
+ Type: Integer
+ Range: [0..65535]
**Important:** When setting OPEN\$1METRICS\$1ADDRESS to 0.0.0.0, the metrics endpoint will be accessible from any network interface. Consider using 127.0.0.1 for localhost-only access or implement appropriate network security controls to restrict access to authorized monitoring systems only.
## Troubleshooting
If you encounter issues with the OpenMetrics server configuration, use the following information to diagnose and resolve common problems.
### Metrics not displaying
Problem: The OpenMetrics server is configured, but metrics are not appearing in your monitoring tool.
Troubleshooting Steps:
1. Verify that the OpenMetrics server is enabled in your add-on configuration:
+ Check that OPEN\$1METRICS is set to "on" in your configuration values. See [describe-addon](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-addon.html).
+ Confirm that the add-on version is v1.1.0 or later in the *Configure selected add-ons settings*.
1. Test the metrics endpoint directly:
+ Access the metrics at http://*pod-ip:port*/metrics (replace pod-ip with the actual pod IP address and port with your configured port).
+ If you can't access the endpoint, verify your network configuration and security group settings.
1. Validate your monitoring tool configuration. Consult you monitoring tools user guide for details on how to do the following:
+ Ensure your monitoring tool (such as Prometheus) is configured to scrape the correct endpoint.
+ Check that the scraping interval and timeout settings are appropriate.
+ Verify that your monitoring tool has network access to the pod IP address.
### Metrics missing from specific pods
Problem: Metrics are available from some pods but not others in your cluster.
Troubleshooting Steps:
The Network Flow Monitor add-on doesn't support pods that use hostNetwork: true. If your pod specification includes this setting, metrics won't be available from those pods.
Workaround: Remove the hostNetwork: true setting from your pod specification if possible. If you require host networking for your application, consider using alternative monitoring approaches for those specific pods.
### Connection refused errors
Problem: You receive "connection refused" errors when trying to access the metrics endpoint.
Troubleshooting Steps:
1. Verify the OPEN\$1METRICS\$1ADDRESS configuration:
+ If set to 127.0.0.1, the endpoint is only accessible from within the pod.
+ If set to 0.0.0.0, the endpoint should be accessible from other pods in the cluster.
+ Ensure your monitoring tool can reach the configured address.
1. Check the OPEN\$1METRICS\$1PORT configuration:
+ Verify that the port number is not already in use by another service.
+ Ensure the port is within the valid range (1-65535).
+ Confirm that any security groups or network policies allow traffic on this port.
### Verification steps
To confirm your OpenMetrics configuration is working correctly:
1. Check the add-on status:
```
aws eks describe-addon --cluster-name your-cluster-name --addon-name aws-network-flow-monitoring-agent
```
1. Verify pod status:
```
kubectl get pods app.kubernetes.io/name=aws-network-flow-monitoring-agent
```
1. Test the metrics endpoint from within the cluster:
```
kubectl exec add-on-pod-name -- curl localhost:9109/metrics
```
Replace 9109 with your configured port number, and the pod name with an AddOn pod name.
# Additional network path metadata included for Amazon EKS
When Network Flow Monitor gathers performance metrics for network flows between Amazon EKS components, it includes additional metadata information about the network path, to help you better understand how the network paths for your workload are performing.
You can view detailed information about Amazon EKS network flow performance by creating a monitor for the network flows that you're interested in, and then viewing details on the **Historical explorer** tab.
With Network Flow Monitor, you can measure network performance between the following Amazon EKS components, to better understand how your workload is performing with your Amazon EKS configuration and determine where there are bottlenecks or impairments.
+ Pod to pod on the same node
+ Node to node on the same cluster
+ Pod to pod on a different cluster
+ Node to node on different clusters
+ With and without Network Load Balancer
The following table lists the information that Network Flow Monitor returns for each network flow scenario.
| **Connection information** | **Metadata information** | | **Local** | **Remote** | **Scenario** | **Initiated by** | **Local** | **Remote** | **Pod name** | **Service** | **Namespace** | **Pod name** | **Service** | **Namespace** |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Local pod connecting to cluster IP of another internal cluster service | Local | Local pod IP address | Remote pod IP address (through cluster IP address) | ✓ | ✓ | ✓ | ✓ ¹ | ✓ | ✓ |
| Local pod in a node network namespace connecting to cluster IP of another internal cluster service | Local | Local node IP address | Remote pod IP address (through cluster IP address) | ✓ ² | ✓ ² | ✓ ² | ✓ ¹ | ✓ | ✓ |
| Local pod connecting to individual pod IP address of another pod (headless service) | Local | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Local pod connecting to individual pod IP address of another pod in node network namespace (headless service) | Local | Local pod IP address | Remote node IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Local pod connecting to remote pod in another cluster | Local | Local pod IP address | Remote pod IP address (another cluster) | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Local pod connecting to an external network address | Local | Local pod IP address | External IP address | ✓ | ✓ | ✓ | N/A | N/A | N/A |
| Local pod operating in a node network namespace connecting to an external network IP address | Local | Local node IP address | External IP address | ✓ ² | ✓ ² | ✓ ² | N/A | N/A | N/A |
| Remote pod connecting to local pod through cluster IP address | Remote | Local pod IP address (through cluster IP address) | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Remote pod in a node network namespace connecting to local pod | Remote | Local pod IP address (through cluster IP address) | Remote node IP address | ✓ | ✓ | ✓ | ✓ ³ | ✓ ³ | ✓ ³ |
| Remote pod connecting to local pod (headless service) | Remote | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| External pod connecting to a local pod | Remote | Local pod IP address | Remote pod IP address | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ |
| External resource connecting through NodePort or a Load Balancer to a local pod | Remote | Local pod IP address | External IP address ⁴ | ✓ | ✓ | ✓ | N/A | N/A | N/A |
| External resource connecting through NodePort or a Load Balancer to a local pod operating in a node network namespace | Remote | Local node IP address | External IP address ⁴ | ✓ | ✓ | ✓ | N/A | N/A | N/A |
Be aware of the following additional information corresponding to the items marked with footnotes in the preceding table.
1. Pod name is not visible in this scenario for pods with other owners, such as a Kubernetes service managed by the EKS control plane.
1. Local pod name, service, and namespace are not resolved if other pods are present in node network namespace.
1. Remote pod name, service, and namespace are not resolved if other pods are present in node network namespace.
1. If service is using NodePort or LoadBalancer in instance mode, and `ExternalTrafficPolicy` is set to `Cluster`, then this IP address will be reported as the IP address of the node that receives the NodePort connection.
# Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances
To provide performance metrics for network flows in your AWS workloads, Network Flow Monitor relies on *agents* that you install, which send the metrics to Network Flow Monitor. You install Network Flow Monitor agents on your instances, and then set the correct permissions for the agents so that they can send metrics to the Network Flow Monitor backend.
An agent is a lightweight software application that you install on your resources, such as your VPC EC2 instances. Agents send performance metrics to the Network Flow Monitor backend on an ongoing basis. Then, you can view the metrics on the **Workload insights** page in the Network Flow Monitor console. You can also track detailed metrics for a specific network flow, or set of flows, by creating a monitor.
The steps that you follow to deploy agents in your instances depend on the type of instance: Amazon EKS Kubernetes instances, VPC EC2 instances, or self-managed (non-EKS) Kubernetes instances.
+ For information about working with Amazon EKS, including installing agents on EKS, see [Work with EKS](CloudWatch-NetworkFlowMonitor-work-with-eks.md).
+ For information about installing agents on VPC EC2 instances and self-managed Kubernetes instances, see the sections in this chapter.
You can establish a private connection between your VPC and Network Flow Monitor agents by using AWS PrivateLink. For more information, see [Using CloudWatch, CloudWatch Synthetics, and CloudWatch Network Monitoring with interface VPC endpoints](cloudwatch-and-interface-VPC.md).
**Topics**
+ [
# Linux versions supported for Network Flow Monitor agents
](CloudWatch-NetworkFlowMonitor-agents-versions.md)
+ [
# Install and manage agents for EC2 instances
](CloudWatch-NetworkFlowMonitor-agents-ec2.md)
+ [
# Install agents for self-managed Kubernetes instances
](CloudWatch-NetworkFlowMonitor-agents-kubernetes-non-eks.md)
# Linux versions supported for Network Flow Monitor agents
The instances that you install agents on must be running supported versions and distributions of Linux. Network Flow Monitor supports agents to run only on Linux, and the Linux kernel version must be 5.8 or later. The following Linux distributions are supported. Note that agents are tested to run on the latest versions of these distributions.
+ Amazon Linux
+ Ubuntu
+ Red Hat
+ Suse Linux
+ Debian distributions for both x86 and aarch64
# Install and manage agents for EC2 instances
Follow the steps in this section to install Network Flow Monitor agents for workloads on Amazon EC2 instances. You can install agents by using SSM or by downloading and installing prebuilt packages for the Network Flow Monitor agent by using the command line.
Regardless of the method that you use to install agents on EC2 instances, you must configure permissions for the agents to enable them to send performance metrics to the Network Flow Monitor backend.
**Topics**
+ [
# Configure permissions for agents
](CloudWatch-NetworkFlowMonitor-agents-ec2-permissions.md)
+ [EC2 instance agents with SSM](CloudWatch-NetworkFlowMonitor-agents-ec2-install-ssm.md)
+ [Download and install the agent](CloudWatch-NetworkFlowMonitor-agents-download-agent-commandline.md)
# Configure permissions for agents
To enable agents to send metrics to the Network Flow Monitor ingestion backend, the EC2 instances that the agents run in must use a role that has a policy attached with the correct permissions. To provide the required permissions, use a role that has the following AWS managed policy attached: [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html). Attach this policy to the IAM roles of the EC2 instances where you plan to install Network Flow Monitor agents.
We recommend that you add the permissions before you install agents on the EC2 instances. You can choose to wait until after you install agents, but the agents won't be able to send metrics to the service until the permissions are in place.
**To add permissions for Network Flow Monitor agents**
1. In the AWS Management Console, in the Amazon EC2 console, locate the EC2 instances that you plan to install Network Flow Monitor agents on.
1. Attach the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) to the IAM role for each instance.
If an instance doesn't have an IAM role attached, choose a role by doing the following:
1. Under **Actions**, choose **Security**.
1. Choose **Modify IAM role**, or create a new role by choosing **Create new IAM role**.
1. Choose a role for the instance, and attach the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) policy.
# Install agents on EC2 instances with SSM
Network Flow Monitor agents provide performance metrics about network flows. Follow the steps in this section to install and work with Network Flow Monitor agents on EC2 instances, by using AWS Systems Manager. If you use Kubernetes, skip to the next sections for information about installing agents with Amazon EKS clusters or self-managed Kubernetes clusters.
Network Flow Monitor provides a Distributor package for you in Systems Manager to use to install or uninstall agents. In addition, Network Flow Monitor provides a document to activate or deactivate agents, by using the Document Type command. Use standard Systems Manager procedures to use the package and the document, or follow the steps provided here for detailed guidance.
For more information in general about using Systems Manager, see the following documentation:
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)
+ [AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html)
Complete the steps in the following sections to configure permissions, install, and work with Network Flow Monitor agents.
**Contents**
+ [Install or uninstall agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-install)
+ [Activate or deactivate agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-manage)
## Install or uninstall agents by using Systems Manager
Network Flow Monitor provides a distributor package in AWS Systems Manager for you to install Network Flow Monitor agents: **AmazonCloudWatchNetworkFlowMonitorAgent**. To access and run the package to install agents, follow the steps provided here.
**To install agents in EC2 instances**
1. In the AWS Management Console, in AWS Systems Manager, under **Node Tools**, choose **Distributor**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor package, **AmazonCloudWatchNetworkFlowMonitorAgent**, and select it.
1. In the **Run command** flow, choose **Install one time** or **Install on schedule**.
1. In the **Target selection** section, choose how you want to select your EC2 instances to install agents on. You can select instances based on tags, choose instances manually, or base the choice on resource groups.
1. In the **Commmand parameters** section, under **Action**, choose **Install**.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
If the installation is successful and the instances have permissions to access Network Flow Monitor endpoints, the agent will start collecting metrics and send reports to the Network Flow Monitor backend.
Agents that are active (sending metrics data) incur billing costs. For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page. If you don't need metrics data temporarily, you can deactivate an agent. For more information, see [Activate or deactivate agents](#CloudWatch-NetworkFlowMonitor-agents-ec2-manage). If you no longer need Network Flow Monitor agents, you can uninstall them from the EC2 instances.
**To uninstall agents from EC2 instances**
1. In the AWS Management Console, in AWS Systems Manager, under **Node Tools**, choose **Distributor**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor package, **AmazonCloudWatchNetworkFlowMonitorAgent**, and select it.
1. In the **Commmand parameters** section, under **Action**, choose **Uninstall**.
1. Select the EC2 instances to uninstall agents from.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
## Activate or deactivate agents by using Systems Manager
After you install a Network Flow Monitor agent with SSM, you must activate it to receive network flow metrics from the instance where it's installed. Agents that are active (sending metrics data) incur billing costs. For more information about Network Flow Monitor and Amazon CloudWatch pricing, see Network Monitoring on the [Amazon CloudWatch pricing](https://aws.amazon.com//cloudwatch/pricing/) page. If you don't need metrics data temporarily, you can deactivate an agent to prevent ongoing billing for the agent.
Network Flow Monitor provides a document in AWS Systems Manager that you can use activate or deactivate agents that you've installed on your EC2 instances. By running this document to manage the agents, you can activate them to begin receiving performance metrics. Or, you can deactivate them to temporarily stop metrics from being sent,without uninstalling the agents.
The document in SSM that you can use to activate or deactivate agents is called **AmazonCloudWatch-NetworkFlowMonitorManageAgent**. To access and run the document, follow the steps in the procedure.
**To activate or deactivate Network Flow Monitor agents**
1. In the AWS Management Console, in AWS Systems Manager, under **Change Management Tools**, choose **Documents**.
1. Under **Owned by Amazon**, locate the Network Flow Monitor document, **AmazonCloudWatch-NetworkFlowMonitorManageAgent**, and select the document.
1. In the **Target selection** section, choose how you want to select your EC2 instances to install agents on. You can select instances based on tags, choose instances manually, or base the choice on resource groups.
1. In the **Command parameters** section, under **Action**, choose **Activate** or **Deactivate**, depending on the action that you want to take for the agents.
1. Scroll down, if necessary, and then choose **Run** to start the installation.
# Download prebuilt packages of the Network Flow Monitor agent by using the command line
You can use the command line to install the Network Flow Monitor agent as a package in Amazon Linux 2023, or download and install prebuilt packages of the Network Flow Monitor agent.
Before or after you download a prebuilt package, you can optionally verify the package signature. For more information, see [ Verify the signature of the Network Flow Monitor agent package](#CloudWatch-NetworkFlowMonitor-agents-download-agent-commandline-verify-sig).
Choose from the following instructions, depending on the Linux operating system that you're using and the type of installation that you want.
**Amazon Linux AMIs**
The Network Flow Monitor agent is available as a package in Amazon Linux 2023. If you're using this operating system, you can install the package by entering the following command:
`sudo yum install network-flow-monitor-agent`
You must also make sure that the IAM role attached to the instance has the [CloudWatchNetworkFlowMonitorAgentPublishPolicy](security-iam-awsmanpol-network-flow-monitor.md#security-iam-awsmanpol-CloudWatchNetworkFlowMonitorAgentPublishPolicy) policy attached. For more information, see [Configure permissions for agents](CloudWatch-NetworkFlowMonitor-agents-ec2-permissions.md).
**Amazon Linux 2023**
Install the package for your architecture by using one of the following commands:
+ **x86\$164**: `sudo yum install https://networkflowmonitoragent.awsstatic.com/latest/x86_64/network-flow-monitor-agent.rpm`
+ **ARM64 (Graviton)**: `sudo yum install https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm`
Verify that Network Flow Monitor agent is successfully installed by running the following command and verifying that the response shows that the agent is enabled and active:
```
service network-flow-monitor status
network-flow-monitor.service - Network Flow Monitor Agent
Loaded: loaded (/usr/lib/systemd/system/network-flow-monitor.service; enabled; preset: enabled)
Active: active (running) since Wed 2025-04-23 19:17:16 UTC; 1min 9s ago
```
**DEB-based distributions (Debian, Ubuntu)**
Install the package for your architecture by using one of the following commands:
+ **x86\$164**: `wget https://networkflowmonitoragent.awsstatic.com/latest/x86_64/network-flow-monitor-agent.deb`
+ **ARM64 (Graviton)**: `wget https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb`
Install the package by using the following command: `$ sudo apt-get install ./network-flow-monitor-agent.deb`
Verify that Network Flow Monitor agent is successfully installed by running the following command and verifying that the response shows that the agent is enabled and active:
```
service network-flow-monitor status
network-flow-monitor.service - Network Flow Monitor Agent
Loaded: loaded (/usr/lib/systemd/system/network-flow-monitor.service; enabled; preset: enabled)
Active: active (running) since Wed 2025-04-23 19:17:16 UTC; 1min 9s ago
```
## Verify the signature of the Network Flow Monitor agent package
The Network Flow Monitor agent rpm and deb installer packages for Linux instances are cryptographically signed. You can use a public key to verify that the agent package is original and unmodified. If the files are damaged or have been altered, the verification fails. You can verify the signature of the installer package using either RPM or GPG. The following information is for Network Flow Monitor agent versions 0.1.3 or later.
To find the correct signature file for each architecture and operating system, use the following table.
| Architecture | Platform | Download link | Signature file link |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.rpm | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.rpm.sig |
| ARM64 | Amazon Linux 2023 | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.rpm.sig |
| x86-64 | Debian/Ubuntu | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.deb | https://networkflowmonitoragent.awsstatic.com/latest/x86\$164/network-flow-monitor-agent.deb.sig |
| ARM64 | Debian/Ubuntu | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb | https://networkflowmonitoragent.awsstatic.com/latest/arm64/network-flow-monitor-agent.deb.sig |
Follow the steps here to verify the signature of the Network Flow Monitor agent.
**To verify the signature of the Network Flow Monitor agent for Amazon S3 package**
1. Install GnuPG so that you can run the gpg command. GnuPG is required to verify the authenticity and integrity of a downloaded Network Flow Monitor agent for an Amazon S3 package. GnuPG is installed by default on Amazon Linux Amazon Machine Images (AMIs).
1. Copy the following public key and save it to a file named `nfm-agent.gpg`.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGf0b5IBEAC6YQc0aYrTbcHNWWMbLuqsqfspzWrtCvoU0yQ62ld7nvCGBha9
lu4lbhtiwoDawC3h6Xsxc3Pmm6kbMQfZdbo4Gda4ahf6zDOVI5zVHs3Yu2VXC2AU
5BpKQJmYddTb7dMI3GBgEodJY05NHQhq1Qd2ptdh03rsX+96Fvi4A6t+jsGzMLJU
I+hGEKGif69pJVyptJSibK5bWCDXh3eS/+vB/CbXumAKi0sq4rXv/VPiIhn6bsCI
A2lmzFd3vMJQUM/T7m7skrqetZ4mWHr1LPDFPK/H/81s8TJawx7MACsK6kIRUxu+
oicW8Icmg9S+BpIgONT2+Io5P1tYO5a9AyVF7X7gU0VgHUA1RoLnjHQHXbCmnFtW
cYEuwhUuENMl+tLQCZ+fk0kKjOlIKqeS9AVwhks92oETh8wpTwTE+DTBvUBP9aHo
S39RTiJCnUmA6ZCehepgpwW9AYCc1lHv/xcahD418E0UHV22qIw943EwAkzMDA4Q
damdRm0Nud0OmilCjo9oogEB+NUoy//5XgQMH1hhfsHquVLU/tneYexXYMfo/Iu5
TKyWL2KdkjKKP/dMR4lMAXYi0RjTJJ5tg5w/VrHhrHePFfKdYsgN6pihWwj2Px/M
ids3W1Ce50LOEBc2MOKXYXGd9OZWyR8l15ZGkySvLqVlRGwDwKGMC/nS2wARAQAB
tEJOZXR3b3JrIEZsb3cgTW9uaXRvciBBZ2VudCA8bmV0d29yay1mbG93LW1vbml0
b3ItYWdlbnRAYW1hem9uLmNvbT6JAlcEEwEIAEEWIQR2c2ypl63T6dJ3JqjvvaTM
vJX60QUCZ/RvkgIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAK
CRDvvaTMvJX60euSD/9cIu2BDL4+MFFHhyHmG3/se8+3ibW0g8SyP3hsnq7qN+bm
ZzLAhll7DVoveNmEHI1VC7Qjwb30exgLcyK2Ld6uN6lwjjK0qiGGz943t230pJ3z
u7V2fVtAN+vgDVmD7agE6iqrRCWu3WfcgzFlEkE/7nkhtbWzlaK+NkdEBzNZ+W7/
FmLClzIbMjIBW2M8LdeZdQX0SWljy18x7NGNukWeNTJxmkDsjAeKl+zkXYk9h7ay
n3AVl1KrLZ5P9vQ5XsV5e4T6qfQ3XNY1lm54cpa+eD7NyYcTGRDK+vIxO4xD8i2M
yl1iNf2+84Tt6/SAgR/P9SJ5tbKD0iU9n4g1eBJVGmHDuXTtDR4H/Ur7xRSxtuMl
yZP/sLWm8p7+Ic7aQJ5OVw36MC7Oa7/K/zQEnLFFPmgBwGGiNiw5cUSyCBHNvmtv
FK0Q2XMXtBEBU9f44FMyzNJqVdPywg8Y6xE4wc/68uy7G6PyqoxDSP2ye/p+i7oi
OoA+OgifchZfDVhe5Ie0zKR0/nMEKTBV0ecjglb/WhVezEJgUFsQcjfOXNUBesJW
a9kDGcs3jIAchzxhzp/ViUBmTg6SoGKh3t+3uG/RK2ougRObJMW3G+DI7xWyY+3f
7YsLm0eDd3dAZG3PdltMGp0hKTdslvpws9qoY8kyR0Fau4l222JvYP27BK44qg==
=INr5
-----END PGP PUBLIC KEY BLOCK-----
```
1. Import the public key into your keyring and note the returned value.
```
PS> rpm --import nfm-agent.gpg
gpg: key 3B789C72: public key "Network Flow Monitor Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
Make a note of the key value because you need it in the next step. In this example, the key value is `3B789C72`.
1. Verify the fingerprint by running the following command. Be sure to replace *key-value* with the value from the preceding step. We recommend that you use GPG to verify the fingerprint even if you use RPM to verify the installer package.
```
PS> gpg --fingerprint key-value
pub rsa4096 2025-04-08 [SC] [expires: 2028-04-07]
7673 6CA9 97AD D3E9 D277 26A8 EFBD A4CC BC95 FAD1
uid Network Flow Monitor Agent
```
The fingerprint string should be equal to the following:
`7673 6CA9 97AD D3E9 D277 26A8 EFBD A4CC BC95 FAD1`
If the fingerprint string doesn't match, don't install the agent. Contact Amazon Web Services.
After you have verified the fingerprint, you can use it to verify the signature of the Network Flow Monitor agent package.
1. Download the package signature file, if you haven't already done so, based on your instance's architecture and operating system.
1. Verify the installer package signature. Be sure to replace the `signature-filename` and `agent-download-filename` with the values that you specified when you downloaded the signature file and agent, as shown in the table earlier in this topic.
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made Tue Apr 8 00:40:02 2025 UTC
gpg: using RSA key 77777777EXAMPLEKEY
gpg: issuer "network-flow-monitor-agent@amazon.com"
gpg: Good signature from "Network Flow Monitor Agent " [unknown]
gpg: WARNING: Using untrusted key!
```
If the output includes the phrase `BAD signature`, check to make sure that you performed the procedure correctly. If you continue to get this response, contact [AWS Support](https://aws.amazon.com/premiumsupport/) and avoid using the downloaded file.
Note the warning about trust. A key is trusted only if you or someone who you trust has signed it. This doesn't mean that the signature is invalid, only that you have not verified the public key.
Next, follow the steps here to verify the RPM package.
**To verify the signature of the RPM package**
1. Copy the following public key and save it to a file named `nfm-agent.gpg`.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGf0b5IBEAC6YQc0aYrTbcHNWWMbLuqsqfspzWrtCvoU0yQ62ld7nvCGBha9
lu4lbhtiwoDawC3h6Xsxc3Pmm6kbMQfZdbo4Gda4ahf6zDOVI5zVHs3Yu2VXC2AU
5BpKQJmYddTb7dMI3GBgEodJY05NHQhq1Qd2ptdh03rsX+96Fvi4A6t+jsGzMLJU
I+hGEKGif69pJVyptJSibK5bWCDXh3eS/+vB/CbXumAKi0sq4rXv/VPiIhn6bsCI
A2lmzFd3vMJQUM/T7m7skrqetZ4mWHr1LPDFPK/H/81s8TJawx7MACsK6kIRUxu+
oicW8Icmg9S+BpIgONT2+Io5P1tYO5a9AyVF7X7gU0VgHUA1RoLnjHQHXbCmnFtW
cYEuwhUuENMl+tLQCZ+fk0kKjOlIKqeS9AVwhks92oETh8wpTwTE+DTBvUBP9aHo
S39RTiJCnUmA6ZCehepgpwW9AYCc1lHv/xcahD418E0UHV22qIw943EwAkzMDA4Q
damdRm0Nud0OmilCjo9oogEB+NUoy//5XgQMH1hhfsHquVLU/tneYexXYMfo/Iu5
TKyWL2KdkjKKP/dMR4lMAXYi0RjTJJ5tg5w/VrHhrHePFfKdYsgN6pihWwj2Px/M
ids3W1Ce50LOEBc2MOKXYXGd9OZWyR8l15ZGkySvLqVlRGwDwKGMC/nS2wARAQAB
tEJOZXR3b3JrIEZsb3cgTW9uaXRvciBBZ2VudCA8bmV0d29yay1mbG93LW1vbml0
b3ItYWdlbnRAYW1hem9uLmNvbT6JAlcEEwEIAEEWIQR2c2ypl63T6dJ3JqjvvaTM
vJX60QUCZ/RvkgIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAK
CRDvvaTMvJX60euSD/9cIu2BDL4+MFFHhyHmG3/se8+3ibW0g8SyP3hsnq7qN+bm
ZzLAhll7DVoveNmEHI1VC7Qjwb30exgLcyK2Ld6uN6lwjjK0qiGGz943t230pJ3z
u7V2fVtAN+vgDVmD7agE6iqrRCWu3WfcgzFlEkE/7nkhtbWzlaK+NkdEBzNZ+W7/
FmLClzIbMjIBW2M8LdeZdQX0SWljy18x7NGNukWeNTJxmkDsjAeKl+zkXYk9h7ay
n3AVl1KrLZ5P9vQ5XsV5e4T6qfQ3XNY1lm54cpa+eD7NyYcTGRDK+vIxO4xD8i2M
yl1iNf2+84Tt6/SAgR/P9SJ5tbKD0iU9n4g1eBJVGmHDuXTtDR4H/Ur7xRSxtuMl
yZP/sLWm8p7+Ic7aQJ5OVw36MC7Oa7/K/zQEnLFFPmgBwGGiNiw5cUSyCBHNvmtv
FK0Q2XMXtBEBU9f44FMyzNJqVdPywg8Y6xE4wc/68uy7G6PyqoxDSP2ye/p+i7oi
OoA+OgifchZfDVhe5Ie0zKR0/nMEKTBV0ecjglb/WhVezEJgUFsQcjfOXNUBesJW
a9kDGcs3jIAchzxhzp/ViUBmTg6SoGKh3t+3uG/RK2ougRObJMW3G+DI7xWyY+3f
7YsLm0eDd3dAZG3PdltMGp0hKTdslvpws9qoY8kyR0Fau4l222JvYP27BK44qg==
=INr5
-----END PGP PUBLIC KEY BLOCK-----
```
1. Import the public key into your keyring.
```
PS> rpm --import nfm-agent.gpg
```
1. Verify the installer package signature. Be sure to replace the `agent-download-filename` with the value that you specified when you downloaded the agent, as shown in the table earlier in this topic.
```
PS> rpm --checksig agent-download-filename
```
For example, for the x86\$164 architecture on Amazon Linux 2023, use the following command:
```
PS> rpm --checksig network-flow-monitor-agent.rpm
```
This command returns output similar to the following.
```
network-flow-monitor-agent.rpm: digests signatures OK
```
If the output contains the phrase `NOT OK (MISSING KEYS: (MD5) key-id)`, check to make sure that you performed the procedure correctly. If you continue to get this response, contact [AWS Support](https://aws.amazon.com/premiumsupport/) and don't install the agent.
# Install agents for self-managed Kubernetes instances
Follow the steps in this section to install Network Flow Monitor agents for workloads on self-managed Kubernetes clusters. After you complete the steps, Network Flow Monitor agent pods will be running on all of your self-managed Kubernetes cluster nodes.
If you use Amazon Elastic Kubernetes Service (Amazon EKS), the installation steps to follow are in the following section: [Install the EKS AWS Network Flow Monitor Agent add-on](CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.md).
**Topics**
+ [
# Before you begin
](CloudWatch-NetworkFlowMonitor-agents-kubernetes-before-you-begin.md)
+ [
# Download Helm charts and install agents
](CloudWatch-NetworkFlowMonitor-agents-kubernetes-install-agents.md)
+ [
# Configure permissions for agents to deliver metrics
](CloudWatch-NetworkFlowMonitor-agents-kubernetes-permissions.md)
# Before you begin
Before you start the installation process, follow the steps in this section to make sure that your environment is set up to successfully install agents on the right Kubernetes clusters.
**Ensure that your version of Kubernetes is supported**
Network Flow Monitor agent installation requires Kubernetes Version 1.25, or a more recent version.
**Ensure that you have installed required tools**
The scripts that you use for this installation process require that you install the following tools. If you don’t have the tools installed already, see the provided links for more information.
+ The AWS Command Line Interface (CLI). For more information, see [Installing or updating to the latest version of the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) in the AWS Command Line Interface Reference Guide.
+ The Helm package manager. For more information, see [Installing Helm](https://helm.sh/docs/intro/install/) on the Helm website.
+ The `kubectl` command line tool. For more information, see [Install kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) on the Kubernetes website.
+ The `make` Linux command dependency. For more information, see the following blog post: [ Intro to make Linux Command: Installation and Usage](https://ioflood.com/blog/install-make-command-linux/). For example, do one of the following:
+ For Debian based distributions, such as Ubuntu, use the following command: `sudo apt-get install make`
+ For RPM-based distributions, such as CentOS, use the following command: `sudo yum install make`
**Ensure that you have valid, correctly configured KubeConfig environment variables**
Network Flow Monitor agent installation uses the Helm package manager tool, which uses the kubeconfig variable, `$HELM_KUBECONTEXT`, to determine the target Kubernetes clusters to work with. Also, be aware that when Helm runs installation scripts, by default, it references the standard `~/.kube/config` file. You can change the configuration environment variables, to use a different config file (by updating `$KUBECONFIG`) or to define the target cluster you want to work with (by updating `$HELM_KUBECONTEXT`).
**Create a Network Flow Monitor Kubernetes namespace**
The Network Flow Monitor agent's Kubernetes application installs its resources into a specific namespace. The namespace must exist for the installation to succeed. To ensure that the required namespace is in place, you can do one of the following:
+ Create the default namespace, `amazon-network-flow-monitor`, before you begin.
+ Create a different namespace, and then define it in the `$NAMESPACE` environment variable when you run the installation to make targets.
# Download Helm charts and install agents
You can download the Network Flow Monitor agent Helm charts from the AWS public repository by using the following command. Make sure that you first authenticate with your GitHub account.
`git clone https://github.com/aws/network-flow-monitor-agent.git`
In the `./charts/amazon-network-flow-monitor-agent` directory, you can find the Network Flow Monitor agent Helm charts and Makefile that contain the installation make targets that you use for installing agents. You install agents for Network Flow Monitor by using the following Makefile target: `helm/install/customer`
You can customize the installation if you like, for example, by doing the following:
```
# Overwrite the kubeconfig files to use
KUBECONFIG= make helm/install/customer
# Overwrite the Kubernetes namespace to use
NAMESPACE= make helm/install/customer
```
To verify that the Kubernetes application pods for the Network Flow Monitor agents have been created and deployed successfully, check to be sure that their state is `Running`. You can check state of the agents by running the following command: `kubectl get pods -o wide -A | grep amazon-network-flow-monitor`
# Configure permissions for agents to deliver metrics
After you install agents for Network Flow Monitor, you must enable the agents to send network metrics to the Network Flow Monitor ingestion APIs. Agents in Network Flow Monitor must have permission to access the Network Flow Monitor ingestion APIs so that they can deliver network flow metrics that they've collected for each instance. You grant this access by implementing IAM roles for service accounts (IRSA).
To enable agents to deliver network metrics to Network Flow Monitor, follow the steps in this section.
1. **Implement IAM roles for service accounts**
IAM roles for service accounts provides the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Implementing IRSA is the recommended way to provide all permissions required by Network Flow Monitor agents to successfully access Network Flow Monitor ingestion APIs. For more information, see [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) in the Amazon EKS User Guide.
When you set up IRSA for Network Flow Monitor agents, use the following information:
+ **ServiceAccount: **When you define your IAM role trust policy, for `ServiceAccount`, specify `aws-network-flow-monitor-agent-service-account`.
+ **Namespace: **For the `namespace`, specify `amazon-network-flow-monitor`.
+ **Temporary credentials deployment: **When you configure permissions after you have deployed Network Flow Monitor agent pods, updating the `ServiceAccount` with your IAM role, Kubernetes does not deploy the IAM role credentials. To ensure that the Network Flow Monitor agents acquire the IAM role credentials that you've specified, you must rolling out a restart of `DaemonSet`. For example, use a command like the following:
`kubectl rollout restart daemonset -n amazon-network-flow-monitor aws-network-flow-monitor-agent`
1. **Confirm that the Network Flow Monitor agent is successfully accessing the Network Flow Monitor ingestion APIs**
You can check to make sure that your configuration for agents is working correctly by using the HTTP 200 logs for Network Flow Monitor agent pods. First, search for a Network Flow Monitor agent pod, and then search through the log files to find successful HTTP 200 requests. For example, you can do the following:
1. Locate a Network Flow Monitor agent pod name. For example, you can use the following command:
```
RANDOM_AGENT_POD_NAME=$(kubectl get pods -o wide -A | grep amazon-network-flow-monitor | grep Running | head -n 1 | tr -s ' ' | cut -d " " -f 2)
```
1. Grep all the HTTP logs for the pod name that you've located. If you've changed the NAMESPACE, make sure that you use the new one.
```
NAMESPACE=amazon-network-flow-monitor
kubectl logs $RANDOM_AGENT_POD_NAME -\-namespace ${NAMESPACE} | grep HTTP
```
If access has been granted successfully, you should see log entries similar to the following:
```
...
{"level":"INFO","message":"HTTP request complete","status":200,"target":"amzn_nefmon::reports::publisher_endpoint","timestamp":1737027525679}
{"level":"INFO","message":"HTTP request complete","status":200,"target":"amzn_nefmon::reports::publisher_endpoint","timestamp":1737027552827}
```
Note that the Network Flow Monitor agent publishes network flow reports every 30 seconds, by calling the Network Flow Monitor ingestion APIs.
# Initialize Network Flow Monitor
Before you can view performance metrics for network flows, you must initialize Network Flow Monitor, which grants required permissions and creates an initial topology for your account or accounts. If you plan to monitor resources for multiple accounts, you must also configure AWS Organizations with Amazon CloudWatch. Then, you specify accounts for your Network Flow Monitor scope, so that Network Flow Monitor can create an initial topology for all the accounts that you'll be tracking performance metrics for.
In addition, you must install agents on your instances, to send performance metrics to the Network Flow Monitor ingestion server. For more information, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
The steps that you take to initialize Network Flow Monitor vary depending on whether you are measuring performance metrics for resources in a single account, or you want to monitor metrics from resources that are owned by multiple accounts in your organization.
+ [Single account monitoring initialization](CloudWatch-NetworkFlowMonitor-single-account.md)
+ [Multi-account monitoring initialization](CloudWatch-NetworkFlowMonitor-multi-account.md)
# Initialize Network Flow Monitor for single account monitoring
To initialize Network Flow Monitor to monitor network performance metrics, you must grant permissions and Network Flow Monitor must create the initial topology for your account. When you monitor resources in just one account, Network Flow Monitor sets your account as the scope for network monitoring and creates a topology for that scope.
Initializing Network Flow Monitor does the following:
+ Grants permissions for Network Flow Monitor to use required service-linked roles with your account. Network Flow Monitor requires you to grant it specific permissions so that the feature can send metrics to Amazon CloudWatch on your behalf, as well as create topologies of network flows. For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
+ Sets your monitoring scope for Network Flow Monitor to the AWS account that you're signed in with. For more information, see **Scope** in [Components and features of Network Flow Monitor](CloudWatch-NetworkFlowMonitor-components.md).
+ Creates an initial topology for your scope.
To initialize Network Flow Monitor by setting up the service-linked roles that provide the required permissions, setting the scope to your account, and creating a topology for network flow performance monitoring, follow these steps.
**To initialize Network Flow Monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. In the **Getting started with Network Flow Monitor** section, under Step 1, choose **Start initialization**.
1. On the **Configure Network Flow Monitor** page, scroll down, and then choose **Initialize Network Flow Monitor**.
Completing the initialization can take 20-30 minutes.
After you initialize Network Flow Monitor for your account, before you can view network flow performance metrics, you must also install Network Flow Monitor agents for your resources that send performance metrics to the Network Flow Monitor backed ingestion server. For more information, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
# Initialize Network Flow Monitor for multi-account monitoring
If you want to monitor network flows in Network Flow Monitor for resources that are owned by different accounts, you must first configure Amazon CloudWatch with AWS Organizations. To use multiple accounts in Network Flow Monitor, you're required to turn on trusted access for CloudWatch, and it's a best practice to also register a delegated administrator.
In addition, if you plan to create monitors for network flows from the console, you must add a Network Flow Monitor policy to the role that is attached to your resources. The policy enables you to view resources from other accounts in the console, so that you can add the resources in multiple accounts to a monitor.
To monitor network flows for resources that are owned by different accounts, there are additional configuration steps to take. First, as the management account, you must configure CloudWatch with AWS Organizations to turn on trusted access, and, typically, you'll also register a delegated administrator account. Then, using the delegated administrator account, you can add more accounts in your organization, to set the scope for your network observability to include resources in those accounts. (You can also add multiple accounts with a management account, but it's a best practice in Organizations to use the delegated administrator account when you work with resources in a service. We provide steps that follow that guidance in the instructions here for Network Flow Monitor.)
Note that if you don’t need to monitor network flows for instances from multiple accounts, you can use Network Flow Monitor with a single account. The scope for Network Flow Monitor is automatically set to the AWS account that you sign in with.
Use the guidance in the following sections to complete these steps.
**Topics**
+ [Multi-account setup overview](#CloudWatch-NetworkFlowMonitor-multi-account.overview)
+ [Configure AWS Organizations](#CloudWatch-NetworkFlowMonitor-multi-account.config-orgs)
+ [Add multiple accounts](#CloudWatch-NetworkFlowMonitor-multi-account.config-scope)
+ [Add permissions for the console](#CloudWatch-NetworkFlowMonitor-multi-account.console-perms)
## Overview of steps for using multiple accounts in Network Flow Monitor
To get started with Network Flow Monitor, any account that has not used Network Flow Monitor before must initialize Network Flow Monitor. When you initialize Network Flow Monitor for an account, Network Flow Monitor adds the required service-linked role permissions and creates a scope of the account or accounts to be included in network observability. To work with multiple accounts in Network Flow Monitor, there are additional steps, to integrate with AWS Organizations, and then add the accounts to work with.
In summary, you take the following steps:
1. Sign in to the AWS Management Console as the management account, and then do the following:
+ Complete the required steps for integrating with AWS Organizations in CloudWatch.
1. Sign in to the AWS Management Console as the delegated administrator account, and then do the following:
+ Initialize Network Flow Monitor, including adding accounts to include in your scope.
+ Add the required permissions for accessing resources that are in other accounts from the console.
If you're setting up Network Flow Monitor to work with multiple accounts and you’re not familiar with AWS Organizations, review the following resources to learn about concepts such as the management account, trusted access, and the delegated administrator account, and to learn how to integrate Organizations with CloudWatch.
+ [Managing accounts in an organization with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html) in the AWS Organizations User Guide.
+ [Amazon CloudWatch and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudwatch.html) in the AWS Organizations User Guide.
Follow the steps in the following sections for specific guidance in configuring Network Flow Monitor for multiple accounts.
## Configure AWS Organizations in CloudWatch
To configure Network Flow Monitor with AWS Organizations, sign in to the management account, and turn on trusted access for CloudWatch. Then, register a delegated administrator account to use for initializing Network Flow Monitor and adding multiple accounts.
If you’ve already configured Organizations in CloudWatch to turn on trusted access for Organizations in CloudWatch and register a delegated administrator account, you don’t need to configure anything more for Organizations that is specific to Network Flow Monitor. You can sign in with the delegated administrator account for CloudWatch, and then initialize Network Flow Monitor, including adding multiple accounts for your network observability scope.
If you haven’t yet configured Organizations in CloudWatch, follow the steps here to turn on trusted access and register a delegated administrator account.
### Turn on trusted access in CloudWatch
Before you can use Network Flow Monitor with more than one account in your organization, you must turn on trusted access for AWS Organizations in Amazon CloudWatch. Use the following steps to turn on trusted access in the CloudWatch console.
**To turn on trusted access**
1. Sign in to the console with your organization’s management account.
1. In the CloudWatch console, in the navigation pane, choose **Settings**.
1. Choose the **Organizations** tab.
1. In **Organizational Management Settings**, choose **Turn on**. The **Enable trusted access** page appears.
1. To review the role policy, choose **View permission** details to see the role policy.
1. Choose **Enable trusted access**.
Now, as CloudWatch discovers resources, it automatically updates information about accounts that you have permission to access the resources for in Network Flow Monitor.
### Register a delegated administrator account
As a best practice with AWS Organizations, the management account for your organization should register a member account as a delegated administrator account for CloudWatch. After you register a delegated administrator account in CloudWatch, members of your organization can sign in with the delegated administrator account to monitor the network performance for resources in multiple accounts in Network Flow Monitor.
Using the delegated administrator account, you can add multiple accounts for your network observability scope in Network Flow Monitor. Although the management account can also create a scope that includes multiple accounts, we recommend that you follow the best practices for AWS Organizations and use a delegated administrator account for adding multiple accounts in Network Flow Monitor. For member accounts that are not the delegated administrator account, the scope is limited to the signed-in account, which is automatically set for the scope.
A delegated administrator account for Organizations is a member account that shares administrator access for service-managed permissions. The account that you choose to register as a delegated administrator account must be a member account in your organization. A delegated administrator account for your organization can be used outside of CloudWatch, so make sure that you understand this account type before following this procedure. For more information, see [Amazon CloudWatch and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudwatch.html) in the AWS Organizations User Guide.
**To register a delegated administrator account**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Organization** tab.
1. Choose **Register delegated administrator**.
1. In the **Register delegated administrator** window, in the **Delegated administrator account ID** field, enter the 12-digit Organization member account ID.
1. Choose **Register delegated administrator**. At the top of the page, a message appears indicating the account was registered successfully. The **Organization Settings** page appears. To see information about the delegated administrator account, hover over the number below **Delegated administrators**.
To remove or change the delegated administrator account, deregister the account first. For more information, see [ Deregistering a delegated administrator account](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/telemetry-config-turn-on.html#telemetry-config-deregister-administrator).
## Add multiple accounts to your scope
To add accounts to your Network Flow Monitor scope, sign in with the delegated administrator account. (You can add accounts to a scope if you're signed in with the management account, but it's a best practice in AWS Organizations to use the delegated administrator account to work with resources.)
After you sign in, follow the steps to initialize Network Flow Monitor, a process which authorizes the required service-linked role permissions, lets you set the scope for your network observability by adding accounts, and then creates an initial topology for the accounts in the scope you've set. The account that you sign in with—in this case, the delegated administrator account—is automatically included in your Network Flow Monitor scope.
**To initialize Network Flow Monitor with multiple accounts in your scope**
1. Sign in to the console with your organization’s delegated administrator account.
1. In the navigation pane for the CloudWatch console, under **Network Monitoring**, choose **Flow monitors**.
1. Under **Getting started with Network Flow Monitor**, in Step 1, choose **Start initialization**.
1. On the **Network Flow Monitor** page, under **Add accounts**, choose **Add**. The account that you're signed in with is automatically included in the scope and already appears in the **Accounts in scope** table as **(this account)**.
1. On the **Add accounts** dialog page, optionally filter the accounts, and then select up to 99 additional accounts to add to your scope. The maximum number of accounts in a scope is 100.
1. Choose **Add**.
1. Choose **Initialize Network Flow Monitor**. Network Flow Monitor adds the required service-linked role permissions, creates a scope that includes all the accounts you specified, and then creates an initial topology of the resources in the accounts in your scope.
To add or remove accounts for your scope after you've already initialized Network Flow Monitor, follow the steps here.
Be aware that after you make a change to your scope, either to add or delete accounts, you must wait about 20 minutes before you can make another change to the scope. This delay is because Network Flow Monitor requires a brief period of time to update its topology information.
**To add or remove accounts for your scope**
1. Sign in to the console with your organization’s delegated administrator account.
1. In the navigation pane for the CloudWatch console, under **Network Monitoring**, choose **Flow monitors**.
1. Under **Monitors**, select a monitor.
1. On the **Monitor details** tab, under **Accounts in scope**, choose **Add** or **Delete**.
1. Select accounts to add to your scope, up to a total of 100 accounts, or select accounts to delete.
1. Complete the steps in the confirmation dialog.
## Set up permissions for multi-account resource access (console only)
If you plan to create monitors for network flows from the console, a specific policy is required for each member account in your scope. This policy enables you to view resources from other accounts when you add local and remote resources to a monitor.
For each of the account in your scope, create a role, **NetworkFlowMonitorAccountResourceAccess**, and attach the **AmazonEC2ReadOnlyAccess** policy. To see permission details for the policy, see [ AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html) in the AWS Managed Policy Reference Guide.
This policy is in addition to the policy that you must add to each instance so that the Network Flow Monitor agent can send performance metrics from the instance to the Network Flow Monitor ingestion backend server. For more information about requirements for agents, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
The following procedure provides a summary of the steps to create the required role for accessing resources in your scope in the Network Flow Monitor console. For general guidance on how to create a role in IAM, see [Create a role to give permissions to an IAM user ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the AWS Identity and Access Management User Guide.
**To create a role for resource access in the Network Flow Monitor console**
1. Sign in to the AWS Management Console and open the IAM console.
1. In the navigation pane of the console, choose **Roles**, and then choose **Create role**.
1. Specify the **AWS account** trusted entity. This trusted entity type enables principals in other AWS accounts to assume the role and access resources in other accounts.
1. Choose **Next**.
1. In the list of AWS managed policies, choose the **AmazonEC2ReadOnlyAccess** policy.
1. Choose **Next**.
1. For role name, enter **NetworkFlowMonitorAccountResourceAccess**.
1. Review the role, and then choose **Create role**.
## Install agents on instances
To track network performance with Network Flow Monitor, you must initialize the service, but you must also install Network Flow Monitor agents on your workload's EC2 instances and add permissions for the agents to send networking performance metrics to Network Flow Monitor. After you install the agents, wait a short period of time (about 20 minutes), for data to begin being sent to the Network Flow Monitor backend. Then, you can view network performance metrics, on the **Workload insights** tab, and also create monitors, to view detailed information.
For example, you can view the top contributor performance metrics for data transferred and retransmission timeouts, for network flows between your local and remote resources, collected by Network Flow Monitor agents. By viewing and analyzing these metrics, you can choose specific flows that you want to see more details for and track more closely with a monitor. By creating a monitor for specific flows, you can see detailed information about them, including metrics, sorted by the top contributors for each metric type and network paths for each network flow.
With a monitor, Network Flow Monitor also provides a network health indicator (NHI), which you can use to see if there have been AWS network impairments for network flows that you're tracking in the monitor, during a time period that you've selected. That information can help you decide where to focus your network troubleshooting efforts.
For more information, and instructions for how to install agents, see [Install Network Flow Monitor agents on EC2 and self-managed Kubernetes instances](CloudWatch-NetworkFlowMonitor-agents.md).
# Monitor and analyze network flows in Network Flow Monitor
With Network Flow Monitor, you can learn about network flows and performance for traffic that you're monitoring with your scope. Start by reviewing top contributors information, by each metric type, in the **Workload insights** tab. Then, create monitors so that you can explore network performance in detail, over different time frames, for network flows that you select in **Workload insights**.
After you initialize Network Flow Monitor and install agents on your instances, Network Flow Monitor generates performance metrics for the network flows from those instances. Review the sections in this chapter to learn more about how to use Network Flow Monitor to evaluate network performance in Network Flow Monitor, create monitors for more in-depth information, and learn about the specific metrics provided by Network Flow Monitor.
The steps provided in these sections use the AWS Management Console. You can also use Network Flow Monitor API operations with the AWS Command Line Interface (AWS CLI) or AWS SDKs to review workload insights and top contributors metrics, and to create and configure a monitor. For more information, see the following resources:
+ If you plan to work with Network Flow Monitor with the CLI, see [Examples of using the CLI with Network Flow Monitor](CloudWatch-NFM-get-started-CLI.md).
+ For detailed information about working with Network Flow Monitor API operations, see the [ Network Flow Monitor API Reference Guide](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/Welcome.html).
**Topics**
+ [Evaluate network flows](CloudWatch-NetworkFlowMonitor-configure-evaluate-flows.md)
+ [Create and work with monitors](CloudWatch-NetworkFlowMonitor-configure-monitors.md)
+ [Monitor and analyze](CloudWatch-NetworkFlowMonitor-monitor-and-analyze.md)
+ [Delete scope](CloudWatch-NetworkFlowMonitor-disable.md)
# Evaluate network flows with workload insights
Network Flow Monitor provides workload insights about the network flows in the scope that you enable monitoring for. By surfacing top contributor network flows for each metric type, you can see which flows are potentially experiencing issues. You can view these top contributor metrics in the console on the **Workload insights** tab. In Network Flow Monitor, top contributors are network flows that have the highest values for each network performance metric.
**Top contributors**
On the **Workload insights** page in the Network Flow Monitor console, Network Flow Monitor displays the top contributor network performance statistics for the network flows between all the resources in your monitoring scope where you've deployed agents.
To compile lists of top contributors, Network Flow Monitor determines the network flows in your scope that have the highest values for retransmissions, retransmission timeouts, and data transferred. These network flows are the *top contributors* for each metric type.
For workload insights, the top contributors are determined for all the network flows that you're receiving performance information for; that is, network flows for all of the resources in your scope with Network Flow Monitor agents installed.
**Network flow classifications**
Network Flow Monitor classifies metrics into designated local-remote categories. Metrics are grouped into two types of flows:
+ **Network Health Indicator (NHI) Flows:** Flows which contribute to Network Health Indicator (NHI) calculations:
+ Between AZs (`INTER_AZ`). Always within the same VPC.
+ Within AZs (`INTRA_AZ`). Always within the same VPC.
+ Between VPCs (`INTER_VPC`). Crosses the boundary between VPCs.
+ Between Regions (`INTER_REGION`). This means performance for network flows between resources in your Region and the edge of another Region.
+ Toward Amazon S3 buckets (`AMAZON_S3`)
+ Toward Amazon DynamoDB (`AMAZON_DYNAMODB`)
+ **Non Network Health Indicator (NHI) Flows:** Flows which do not contribute to Network Health Indicator (NHI) calcuations:
+ Toward the Internet (`INTERNET`). Flows that traverse an Internet Gateway and end on the public Internet.
+ Towards AWS Services (`AWS_SERVICE`). Flows that end at an AWS service that is not fully monitored (like CloudFront or API Gateway).
+ Towards a Transit Gateway (`TRANSIT_GATEWAY`). Flows in this classification are flows that arrive at a Transit Gateway, but the final destination of the flow is unknown.
+ Towards a local zone (`LOCAL_ZONE`). Flows that start or end in a local zone
+ Any other flow that cannot be otherwise classified (`UNCLASSIFIED`).
**Performance metrics**
Performance metrics on **Workload insights** are shown in separate tables for the following metric type: Retransmissions, retransmission timeouts, and data transferred. The data provided is for the top contributors for each type. Note that after you first install Network Flow Monitor agents, there is a waiting period (about 20 minutes) before you can view performance metrics, while agents gather and send data to the Network Flow Monitor backend.
**Monitor specific network flows**
As you review performance metrics, when you see specific resources or network flows that you want to explore more details for, you can create a monitor that includes just those flows.
With a monitor, you can track specific groups of network flows over a period of time, to gain insights into one aspect of your workload. You can also get helpful troubleshooting information, such as checking the network health indicator (NHI) to see if issues you see are caused by AWS impairments.
For more information, see [Create and work with monitors in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors.md)
**Multi-account coverage**
To work with multiple accounts in Network Flow Monitor, you must configure AWS Organizations integration with CloudWatch. By configuring Organizations, you can add accounts to the scope for your Network Flow Monitor coverage. Then, if you have multiple accounts in your scope that each have resources that you want to monitor network flows between, you can specify a scope that includes all of the accounts, and then view performance metrics gathered by the Network Flow Monitor agents that you've installed on your resources. For more information, see [Initialize Network Flow Monitor for multi-account monitoring](CloudWatch-NetworkFlowMonitor-multi-account.md).
# Create and work with monitors in Network Flow Monitor
You create a monitor to see details about the network performance for one or several network flows for a workload. For each monitor, Network Flow Monitor publishes end-to-end performance metrics and a network health indicator (NHI), and generates network paths of individual network flows. After you create a monitor, you can view information provided by the monitor in the console on the **Monitors** tab.
Flow monitors can help you to assess network performance issues that are impacting your workloads, including impairments within an AWS Region and issues on the AWS global network between a local and a remote Region. The network health indicator (NHI) provided by the monitor also captures the health of the AWS global network on your workload’s network paths between Regions. This helps you to quickly identify whether impairments in a local Region, in the AWS global network, or in the remote Region are affecting your workloads.
For remote Regions, monitors can provide network visibility for flows to the Region’s public IP address, and for private traffic flowing to a remote Region over VPC peering or Transit Gateway peering.
After you create a monitor, you can edit the monitor to make changes (except change the monitor name) or delete the monitor, at any time.
The following sections includes procedures for creating, editing, and deleting monitors in the Network Flow Monitor console.
**Topics**
+ [Create a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-create.md)
+ [Edit a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-edit.md)
+ [Delete a monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md)
# Create a monitor in Network Flow Monitor
As you review top contributors in the **Workload insights** tab, if you see one or several network flows that you want to follow over time, or that you want more details about, you can create a monitor directly from **Workload insights**. This simplifies the process for creating a monitor for specific network flows.
Or, if you know specific network flows that you want to track with a monitor, such as looking at performance information for all network flows to another AWS Region, you can use the ** Create monitor** wizard to create a monitor from scratch. When you create a monitor this way, you specify all of the local and remote resources that define the network flows that you want to monitor.
For specific procedures, see the following sections:
+ [Create a monitor by specifying network flows](#CloudWatch-NetworkFlowMonitor-configure-monitors-create-workload-insights)
+ [Create a monitor by specifying local and remote resources](#CloudWatch-NetworkFlowMonitor-configure-monitors-create-standalone)
## Create a monitor by specifying network flows
To create a monitor by selecting network flows, start on the **Workload insights** tab. Select one or more network flows in one of the tables, in a single Region, and then, choose to create a monitor with those flows.
When you create a monitor in this way, the **Create monitor** wizard pre-populates local and remote resources for you and displays them in a modal dialog. You can choose to create a monitor with those resources, or edit the selection of local or remote resources to add or remove resources to include.
By reviewing the top contributors on **Workload insights** on an ongoing basis, you can regularly evaluate if you have the monitors that you need, or if creating new monitors would be helpful.
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To create a monitor from **Workload insights****
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. Choose **Workload insights**.
1. In one of the **Top contributors** tables, select one or more network flows and then choose **Create monitor**.
1. In the modal window that opens, you can edit the resources that define the network flows that you chose, or choose **Create monitor**.
## Create a monitor by specifying local and remote resources
You can create a monitor at any time for specific local and remote resources that define network flows that you want to see details for.
For example, you might want to create a monitor for one of the following scenarios:
+ A monitor that includes network flows for a specific VPC in a local Region to another VPC in the same Region. (Note that you can't select a specific resource, such as a VPC, as a network flow endpoint - that is, the remote resource - in another Region.)
+ For local resource, choose **Specific resources in *Region***. Then, choose **VPC and subnets**, and then, in the table, select a specific VPC.
+ For remote resource, do the same: choose **Specific resources in *Region***, then, choose **VPC and subnets**, and finally, select a specific VPC.
+ A monitor that includes all network flows from your workload in a local Region to a specific Availability Zone.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Availability Zone**, and then choose a specific AZ
+ A monitor that includes all network flows for your workload within a local Region.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Everywhere in *Region***
+ A monitor that includes all network flows for your workload from a local Region to the edge of another Region.
+ For local resource, choose **Everywhere in *Region***
+ For remote resource, choose **Another Region**, and then choose the remote Region
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To create a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. From the Network Flow Monitor page, select the **Monitors** tab, and then choose **Create monitor**.
1. For **Monitor name**, enter the name that you want to use for the monitor. You can't change this name later.
1. Choose **Next**.
1. Select the local resources (one or more) for the network flows that you want to monitor.
+ To monitor network flows from all resources in your Region, choose **Everywhere in *Region***.
+ To choose specific local resources to monitor flows from, choose **Specific resources in *Region***. Then, under **Add resources**, choose **Availability Zones**, **EKS clusters**, or **VPCs and subnets**, and then choose resources to add.
1. Choose **Next**.
1. Select the remote resources (one or more) for the network flows that you want to monitor.
+ To monitor network flows to all resources in your Region, choose **Everywhere in *Region***.
+ To monitor flows from specific remote resources, choose **Specific resources in *Region***. Under **Add resources**, select **VPCs and subnets**, **Availability Zones**, or **AWS services**, and then choose the resources to add.
+ To monitor network flows to the edge of another Region, choose ** Another Region**.
1. Choose **Next**.
1. Review your choices to confirm the network flows to monitor, or edit the options to make changes.
1. Choose **Create monitor**.
After you create a monitor, you can edit or delete the monitor at any time to add or remove network flows. Select a monitor, and then choose **Edit** or **Delete**. Note that you can't change the name of a monitor.
**To view the Network Flow Monitor dashboard**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, choose **Network monitoring**, then **Flow monitors**.
The **Monitors** tab displays a list of the monitors that you have created.
To see more information about a specific monitor, choose a monitor.
# Edit a monitor in Network Flow Monitor
You can edit a monitor at any time, to add or remove network flows.
Note that you can't change the name of a monitor after you create it.
**Important**
These steps are designed to be completed all at once. You won't be able to save any in-process work to continue later.
**To edit a monitor using the console**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Monitors** tab, select a monitor, and then under the **Actions** menu, choose **Edit**.
1. Select the local or remote resources that you want add or remove for the monitor. If you have multiple accounts in your scope, specify the account where the resources are located, and then choose resources.
1. When you're finished updating the monitor, choose **Next**, to review and confirm the network flows to monitor.
1. Choose **Save monitor**.
# Delete a monitor in Network Flow Monitor
To delete a monitor in Network Flow Monitor, follow the steps here.
**To delete a monitor**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Monitors** tab, select a monitor, and then under the **Actions** menu, choose **Delete**.
1. In the dialog that appears, enter confirmation text, and then choose **Delete**.
# Monitor and analyze network flows with a Network Flow Monitor monitor
Network Flow Monitor data and graphs help you to visualize and track network issues. You can create monitors to see detailed information about specific network segments for your AWS workloads, including a view of the network path for individual network flows. After you create one or more monitors in Network Flow Monitor, you can observe performance and metrics, and explore historical data, to find anomalies.
To see the information provided by a monitor, on the **Monitors** tab, choose a monitor in the **Monitors** table. Then, choose one of the following tabs for more information: **Overview**, **Historical explorer**, or **Monitor details**.
**Overview tab**
On the **Overview** tab, you can review the following, for time periods that you specify. To see a broader or narrower range of historical information, including the NHI and traffic summary data, adjust the time period selection at the top of the page.
+ **Network health indicator (NHI):** NHI alerts you to whether there there were AWS network issues for one or more of the network flows tracked by your monitor, during the time frame that you've selected for viewing performance metrics. NHI is a binary value, that is, 1 or 0, which is shown in the console as **Degraded** or **Healthy**.
+ NHI is shown as **Degraded** if there were issues with the portion of the AWS network that any network flow in the monitor traversed, at any time during the time frame that you select.
+ Otherwise, NHI is shown as **Healthy**.
If the NHI is **Degraded**, you can view the **Network health indicator** bar graph for more information. The graph shows you when, during the selected time frame, there were AWS network issues for the network flows tracked by your monitor.
+ **Traffic summary:** Observe overall metrics for the flows tracked by this monitor, for the time period that you've selected. You can see average round-trip time, sums (totals) of transmission timeouts and retransmissions, and the average amount of data transferred for the flows in the monitor. Be aware that RTT data can be sparse because RTT is not always calculated.
**Historical explorer tab**
On the **Historical explorer** tab, you can dive deep into information about specific flows. You can review metrics and network paths for top contributor network flows for specified time frames. In the tables of metrics, you can filter the data by different categories of flows, such as flows between Availability Zones (`INTER_AZ`).
+ **Metrics:** View detailed information for the top contributors for each metric type that Network Flow Monitor aggregates data for. Separate tables of top contributors are provided for retransmission timeouts, retransmissions, round-trip time, and data transferred.
+ **Network paths:** To get an idea about where anomalies are occurring, you can view the network path of a network flow. When you choose a specific metric in a metrics table, the network path for that flow is displayed below the table.
**Monitor details tab**
On the **Monitor details** tab, you can see details about the monitor, including the monitor state, the ARN, when it was created and last updated, and the flows that are included.
You can choose to edit or delete a monitor from any page on the **Monitors** tab.
As part of your regular use of Network Flow Monitor, we recommend that you periodically review the data on the **Workload insights** page to determine if there are new flows that show metrics anomalies that you want to track more closely over time. When you see a set of flows on the **Workload insights** page that you want to see details about, select the flows and create a monitor for them.
# Delete scope for Network Flow Monitor
If you decide that you no longer want to monitor network flows using Network Flow Monitor, you can delete your Network Flow Monitor scope. When you delete your scope, you can no longer see network performance information.
Before you can delete your scope, you must delete all monitors. Be aware that it can take about 15 minutes to complete removing monitors after you request to delete them. For more information, see [Delete a monitor in Network Flow Monitor](CloudWatch-NetworkFlowMonitor-configure-monitors-delete.md).
**To delete your scope**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the left navigation pane, under **Network Monitoring**, choose **Flow monitors**.
1. On the **Settings** tab, choose **Delete scope**.
1. In the dialog box, enter confirmation text, and then choose **Delete scope**.
# View Network Flow Monitor metrics in CloudWatch
Network Flow Monitor publishes the following network flow performance metrics to your account: round-trip time, TCP retransmissions, TCP retransmission timeouts, data transferred, and network health indicator. You can view these metrics in CloudWatch Metrics in the Amazon CloudWatch console.
To find all metrics for your monitor, in the CloudWatch Metrics dashboard, see the custom namespace `AWS/NetworkFlowMonitor`. Metrics are aggregated for each monitor that is deployed and active.
Network Flow Monitor provides the following metrics. Be aware that RoundTripTime data can be sparse, as this metric is not always calculated.
| Metric | Description |
| --- | --- |
| DataTransferred | The number of bytes transferred for all flows for a monitor. |
| Retransmissions | Total number of retransmissions for a monitor. Retransmissions occur when the sender needs to resend packets that have been either damaged or lost. |
| Timeouts | Total retransmission timeouts for a monitor. This occurs when the sender is missing too many acknowledgments, and therefore decides to take a time out and stop sending altogether. |
| RoundTripTime | Average round-trip time for network flows for a monitor. This metric, measured in microseconds, is a measure of performance. It records the time it takes for traffic to be transmitted from a local resource to a remote IP address, and for the associated response to be received. The time is an average over the aggregation period. Data can be sparse, as this metric is not always calculated. |
| HealthIndicator | Network health indicator (NHI) for a monitor overall. Network health indicator (NHI) is a value that surfaces an AWS network impairment. The NHI value is 1 (degraded) if there was an AWS network issue during a specified time frame. It's set to 0 (healthy) if no AWS network issues were detected. Observing the NHI can help you to prioritize troubleshooting for either your workload or the AWS network. |
# Create alarms with Network Flow Monitor
You can create Amazon CloudWatch alarms based on Network Flow Monitor metrics, just as you can for other CloudWatch metrics.
For example, you can create an alarm based on the Network Flow Monitor metric `Retransmissions`, and configure it to send a notification when the metric is higher than a value that you choose. You configure alarms for Network Flow Monitor metrics following the same guidelines as for other CloudWatch metrics.
Following are example Network Flow Monitor metrics that you might choose to create an alarm for:
+ **Retransmissions**
+ **Timeouts**
+ **RoundTripTime**
To see all the metrics available for Network Flow Monitor see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
The following procedure provides an example of setting an alarm on **Retransmissions** by navigating to the metric in the CloudWatch dashboard. Then, you follow the standard CloudWatch steps to create an alarm based on a threshold that you choose, and set up a notification or choose other options.
**To create an alarm for **Retransmissions** in CloudWatch Metrics**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choose **Metrics**, and then choose **All metrics**.
1. Filter for Network Flow Monitor by choosing `AWS/NetworkFlowMonitor`.
1. Choose **MeasurementSource, MonitorName**.
1. In the list, select **Retransmissions**.
1. On the **GraphedMetrics** tab, under **Actions**, choose the bell icon to create an alarm based on a static threshold.
Now, follow the standard CloudWatch steps to choose options for the alarm. For example, you can choose to be notified by an Amazon SNS message if **Retransmissions** is below a specific threshold number. Alternatively, or in addition, you can add the alarm to a dashboard.
Keep in mind the following:
+ Network Flow Monitor metrics are typically aggregated and sent to the Network Flow Monitor backend every 30 seconds, with a 5 second potential jitter (in other words, 25 to 35 seconds).
+ When you create an alarm based on Network Flow Monitor metrics, make sure that you take into account the short delay before publication when you set an alarm’s lookback period. We recommend that you configure **Evaluation Periods** with lookback period that is a minimum of 25 minutes.
For more information about options when you create a CloudWatch alarm, see [Create a CloudWatch alarm based on a static threshold](ConsoleAlarms.md).
# AWS CloudTrail for Network Flow Monitor
Monitoring a service is an important part of maintaining reliability, availability, and performance. of Network Flow Monitor and your other AWS solutions. *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
For more information about Network Flow Monitor CloudTrail logging, see [Network Flow Monitor in CloudTrail](logging_cw_api_calls.md#CloudWatch-NetworkFlowMonitor-info-in-ct).
# Troubleshoot issues in Network Flow Monitor
This section provides guidance for troubleshooting errors with Network Flow Monitor, including solving issues with installing agents.
## Troubleshoot issues in EKS agents installation
When you try to upgrade the AWS Network Flow Monitor Agent add-on for EKS from v1.0.0 to v1.0.1 in AWS Management Console, you might receive the following error message:
"Service account `aws-network-flow-monitoring-agent-service-account` in pod identity configuration is not supported for addon `aws-network-flow-monitoring-agent`."
This error is returned because a resource was renamed. The EKS add-on v1.0.1 changes the service account name from `aws-network-flow-monitoring-agent-service-account` to `aws-network-flow-monitor-agent-service-account`.
Then, if **Not set** is not selected in the console, the pod identity association is not reset to the new resource name.
To fix this issue, do the following when you upgrade to the new version by using the console:
1. Under **Pod Identity IAM role for service account**, select **Not set**.
1. Select **New version (v1.0.1)**.
1. Select **Upgrade**.
1. Choose **Save changes**.
# Data security and data protection in Network Flow Monitor
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from data centers and network architectures that are built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Network Flow Monitor, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using Network Flow Monitor. The following topics show you how to configure Network Flow Monitor to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Network Flow Monitor resources.
**Topics**
+ [
# Data protection in Network Flow Monitor
](data-protection-nfw.md)
+ [
# Infrastructure Security in Network Flow Monitor
](infrastructure-security-nfw.md)
+ [
# Identity and Access Management for Network Flow Monitor
](CloudWatch-NetworkFlowMonitor-security-iam.md)
# Data protection in Network Flow Monitor
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Network Flow Monitor. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Network Flow Monitor or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Infrastructure Security in Network Flow Monitor
As a managed service, Network Flow Monitor is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper.
You use AWS published API calls to access Network Flow Monitor through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
# Identity and Access Management for Network Flow Monitor
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Network Flow Monitor resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [How Network Flow Monitor works with IAM](security_iam_service-with-iam-network-flow-monitor.md)
+ [AWS managed policies](security-iam-awsmanpol-network-flow-monitor.md)
+ [Service-linked roles](using-service-linked-roles-network-flow-monitor.md)
# How Network Flow Monitor works with IAM
Before you use IAM to manage access to Network Flow Monitor, learn what IAM features are available to use with Network Flow Monitor.
To see tables showing a similar high-level view of how AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**IAM features you can use with Network Flow Monitor**
| IAM feature | Network Flow Monitor support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies-nfm) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies-nfm) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions-nfm) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources-nfm) | Yes |
| [Policy condition keys (service-specific)](#security_iam_service-with-iam-id-based-policies-conditionkeys-nfm) | Yes |
| [ACLs](#security_iam_service-with-iam-acls-nfm) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags-nfm) | Yes |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds-nfm) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions-nfm) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service-nfm) | No |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked-nfm) | Yes |
## Identity-based policies for Network Flow Monitor
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
## Resource-based policies within Network Flow Monitor
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource.
## Policy actions for Network Flow Monitor
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of Network Flow Monitor actions, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in Network Flow Monitor use the following prefix before the action:
```
networkflowmonitor
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"networkflowmonitor:action1",
"networkflowmonitor:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "networkflowmonitor:Describe*"
```
## Policy resources for Network Flow Monitor
**Supports policy resources:** Yes
In the *Service Authorization Reference*, you can see the following information related to Network Flow Monitor:
+ To see a list of Network Flow Monitor resource types and their ARNs, see [Resources defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-resources-for-iam-policies).
+ To learn the actions that you can specify with the ARN of each resource, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions).
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
## Policy condition keys for Network Flow Monitor
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of Network Flow Monitor condition keys, see [Condition keys for Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by Network Flow Monitor](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchnetworkflowmonitor.html#amazoncloudwatchnetworkflowmonitor-actions-as-permissions).
## ACLs in Network Flow Monitor
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## ABAC with Network Flow Monitor
**Supports ABAC (tags in policies):** Yes
Network Flow Monitor has *partial* support for tags in policies. It supports tagging for one resource, monitors.
To use tags with Network Flow Monitor, use the AWS Command Line Interface or an AWS SDK. Tagging for Network Flow Monitor is not supported with the AWS Management Console.
To learn more about using tags in policies in general, review the following information.
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using temporary credentials with Network Flow Monitor
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for Network Flow Monitor
**Supports forward access sessions (FAS):** Yes
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Network Flow Monitor
**Supports service roles:** No
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
## Service-linked role for Network Flow Monitor
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For more information about the service-linked role for Network Flow Monitor, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
For details about creating or managing service-linked roles in general in AWS, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# AWS managed policies for Network Flow Monitor
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
## AWS managed policy: CloudWatchNetworkFlowMonitorServiceRolePolicy
You can't attach `CloudWatchNetworkFlowMonitorServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role named **AWSServiceRoleForNetworkFlowMonitor**, which publishes network telemetry aggregation results, collected by Network Flow Monitor agents, to CloudWatch. It also allows the service to use AWS Organizations to get information for multi-account scenarios.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
## AWS managed policy: CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy
You can't attach ` CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role named **AWSServiceRoleForNetworkFlowMonitor\$1Topology**. Using these permissions, as well as internal meta data information gathering (for performance efficiencies), this service-linked role gathers meta data about resource network configurations, such as describing route tables and gateways, for resources that this service monitors network traffic for. This meta data enables Network Flow Monitor to generate topology snapshots of the resources. When there is network degradation, Network Flow Monitor uses the topologies to provide insights into the location of issues in the network and to help determine attribution for issues.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
For more information, see [Service-linked roles for Network Flow Monitor](using-service-linked-roles-network-flow-monitor.md).
## AWS managed policy: CloudWatchNetworkFlowMonitorAgentPublishPolicy
You can use this policy in IAM roles that are attached to Amazon EC2 and Amazon EKS instance resources to send telemetry reports (metrics) to a Network Flow Monitor endpoint.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorAgentPublishPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) in the *AWS Managed Policy Reference*.
## Updates to the Network Flow Monitor service-linked roles
For updates to the AWS managed policies for the Network Flow Monitor service-linked roles, see the [AWS managed policies updates table](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates) for CloudWatch. You can also subscribe to automatic RSS alerts on the CloudWatch [Document history page](DocumentHistory.md).
# Service-linked roles for Network Flow Monitor
Network Flow Monitor uses AWS Identity and Access Management (IAM) [ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Network Flow Monitor. The service-linked role is predefined by Network Flow Monitor and includes all the permissions that the service requires to call other AWS services on your behalf.
Network Flow Monitor defines the permissions of the service-linked roles, and unless defined otherwise, only Network Flow Monitor can assume the roles. The defined permissions include the trust policies and the permissions policies, and the permissions policies cannot be attached to any other IAM entity.
You can delete the roles only after first deleting their related resources. This restriction protects your Network Flow Monitor resources because you can't inadvertently remove permissions to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-linked role permissions for Network Flow Monitor
Network Flow Monitor uses the following service-linked roles:
+ **AWSServiceRoleForNetworkFlowMonitor**
+ **AWSServiceRoleForNetworkFlowMonitor\$1Topology**
### Service-linked role permissions for AWSServiceRoleForNetworkFlowMonitor
Network Flow Monitor uses the service-linked role named **AWSServiceRoleForNetworkFlowMonitor**. This role allows Network Flow Monitor to publish CloudWatch aggregated telemetry metrics gathered for network traffic between instances, and between instances and AWS locations. It also allows the service to use AWS Organizations to get information for multi-account scenarios.
This service-linked role uses the managed policy `CloudWatchNetworkFlowMonitorServiceRolePolicy`.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
The **AWSServiceRoleForNetworkFlowMonitor** service-linked role trusts the following service to assume the role:
+ `networkflowmonitor.amazonaws.com`
### Service-linked role permissions for AWSServiceRoleForNetworkFlowMonitor\$1Topology
Network Flow Monitor uses the service-linked role named **AWSServiceRoleForNetworkFlowMonitor\$1Topology**. This role allows Network Flow Monitor to generate a topology snapshot of the resources that you use with Network Flow Monitor.
This service-linked role uses the managed policy `CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy`.
To view the permissions for this policy, see [CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
The **AWSServiceRoleForNetworkFlowMonitor\$1Topology** service-linked role trusts the following service to assume the role:
+ `topology.networkflowmonitor.amazonaws.com`
## Creating a service-linked role for Network Flow Monitor
You do not need to manually create the service-linked roles for Network Flow Monitor. The first time that you initialize Network Flow Monitor, Network Flow Monitor creates **AWSServiceRoleForNetworkFlowMonitor** and **AWSServiceRoleForNetworkFlowMonitor\$1Topology** for you.
For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*.
## Editing a service-linked role for Network Flow Monitor
After Network Flow Monitor creates a service-linked role in your account, you cannot change the name of the role because various entities might reference the role. You can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Network Flow Monitor
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete the role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for the service-linked role before you can manually delete it.
**Note**
If the Network Flow Monitor service is using the role when you try to delete it, then the deletion might fail. If that happens, wait for a few minutes and then try again.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForNetworkFlowMonitor** or the **AWSServiceRoleForNetworkFlowMonitor\$1Topology** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Updates to the Network Flow Monitor service-linked role
For updates to `CloudWatchNetworkFlowMonitorServiceRolePolicy` or `CloudWatchNetworkFlowMonitorTopologyServiceRolePolicy`, the AWS managed policies for the Network Flow Monitor service-linked roles, see [CloudWatch updates to AWS managed policies](managed-policies-cloudwatch.md#security-iam-awsmanpol-updates). For automatic alerts about managed policy changes in CloudWatch, subscribe to the RSS feed on the CloudWatch [Document history](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) page.