# Monitoring Amazon EFS
Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon EFS and your AWS solutions. We recommend that you collect monitoring data from all of the parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. Before you start monitoring Amazon EFS, however, create a monitoring plan that includes answers to the following questions:
+ What are your monitoring goals?
+ What resources will you monitor?
+ How often will you monitor these resources?
+ What monitoring tools will you use?
+ Who will perform the monitoring tasks?
+ Who should be notified when something goes wrong?
The next step is to establish a baseline for normal Amazon EFS performance in your environment, by measuring performance at various times and under different load conditions. As you monitor Amazon EFS, consider storing historical monitoring data. This stored data will give you a baseline to compare against with current performance data, identify normal performance patterns and performance anomalies, and devise methods to address issues.
For example, with Amazon EFS, you can monitor network throughput, I/O for read, write, and metadata operations, client connections, and burst credit balances for your file systems. If performance falls outside your established baseline, you might need to change the size of your file system or the number of connected clients to optimize the file system for your workload.
To establish a baseline, you should, at a minimum, monitor the following items:
+ Your file system's network throughput.
+ The number of client connections to a file system.
+ The number of bytes for each file system operation, including data read, data write, and metadata operations.
**Topics**
+ [Monitoring tools](monitoring_automated_manual.md)
+ [How Amazon EFS reports file system and object sizes](metered-sizes.md)
+ [Viewing storage class size](view-storage-class-size.md)
+ [Monitoring metrics with Amazon CloudWatch](monitoring-cloudwatch.md)
+ [Logging Amazon EFS API calls with AWS CloudTrail](logging-using-cloudtrail.md)
# Monitoring tools
AWS provides various tools that you can use to monitor Amazon EFS. You can configure some of these tools to do the monitoring for you, but some of the tools require manual intervention. We recommend that you automate monitoring tasks as much as possible.
## Automated monitoring tools
You can use the following automated monitoring tools to watch Amazon EFS and report when something is wrong:
+ **Amazon CloudWatch Alarms** – Watch a single metric over a time period that you specify, and perform one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon Simple Notification Service (Amazon SNS) topic or Amazon EC2 Auto Scaling policy. CloudWatch alarms do not invoke actions only because they are in a particular state; the state must have changed and been maintained for a specified number of periods. For more information, see [Monitoring metrics with Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Amazon CloudWatch Logs** – Monitor, store, and access your log files from AWS CloudTrail or other sources. For more information, see [What is Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) in the *Amazon CloudWatch User Guide*.
+ **Amazon CloudWatch Events** – Match events and route them to one or more target functions or streams to make changes, capture state information, and take corrective action. For more information, see [What is Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) in the *Amazon CloudWatch User Guide*.
+ **AWS CloudTrail Log Monitoring** – Share log files between accounts, monitor CloudTrail log files in real time by sending them to CloudWatch Logs, write log processing applications in Java, and validate that your log files have not changed after delivery by CloudTrail. For more information, see [Working with CloudTrail log files](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-working-with-log-files.html) in the *AWS CloudTrail User Guide*.
## Manual monitoring tools
Another important part of monitoring Amazon EFS involves manually monitoring those items that the Amazon CloudWatch alarms don't cover. The Amazon EFS, CloudWatch, and other AWS Management Console dashboards provide an at-a-glance view of the state of your AWS environment. We recommend that you also check the log files for the file systems.
+ From the Amazon EFS console, you can find the following items for your file systems:
+ The current metered size
+ The number of mount targets
+ The lifecycle state
+ CloudWatch home page shows:
+ Current alarms and status
+ Graphs of alarms and resources
+ Service health status
In addition, you can use CloudWatch to do the following:
+ Create [customized dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) to monitor the services that you use.
+ Graph metric data to troubleshoot issues and discover trends.
+ Search and browse all your AWS resource metrics.
+ Create and edit alarms to be notified of problems.
# How Amazon EFS reports file system and object sizes
The following sections describe how Amazon EFS reports file system sizes, sizes of objects within a file system, and file system throughput.
## Metering EFS file system objects
Objects that you can view in an EFS file system include regular files, directories, symbolic links, and special files (FIFOs and sockets). Each of these objects is metered for 2 kibibytes (KiB) of metadata (for its inode) and one or more increments of 4 KiB of data. The following list explains the metered data size for different types of file system objects:
+ **Regular files** – The metered data size of a regular file is the logical size of the file rounded to the next 4-KiB increment, except that it might be less for sparse files.
A *sparse file* is a file to which data is not written to all positions of the file before its logical size is reached. For a sparse file, in some cases the actual storage used is less than the logical size rounded to the next 4-KiB increment. In these cases, Amazon EFS reports actual storage used as the metered data size.
+ **Directories** – The metered data size of a directory is the actual storage used for the directory entries and the data structure that holds them, rounded to the next 4-KiB increment. The metered data size doesn't include the actual storage used by the file data.
+ **Symbolic links and special files** – The metered data size for these objects is always 4 KiB.
When Amazon EFS reports the space used for an object, through the NFSv4.1 `space_used` attribute, it includes the object's current metered data size but not its metadata size. You can use two utilities for measuring the disk usage of a file, the `du` and `stat` utilities. Following is an example of how to use the `du` utility on an empty file that includes the `-k` option to return the output in kilobytes.
```
$ du -k file
4 file
```
Following example shows how to use the `stat` utility on an empty file to return the file's disk usage.
```
$ /usr/bin/stat --format="%b*%B" file | bc
4096
```
To measure the size of a directory, use the `stat` utility. Find the `Blocks` value, and then multiply that value by the block size. Following is an example of how to use the `stat` utility on an empty directory:
```
$ /usr/bin/stat --format="%b*%B" . | bc
4096
```
## Metered size of an EFS file system
The metered size of an EFS file system includes the sum of the sizes of all current objects in all of the EFS storage classes. The size of each object is calculated from a representative sampling of the size of the object during the metered hour, for example from 8 AM to 9 AM.
An empty file contributes 6 KiB (2 KiB metadata \$1 4 KiB data) to the metered size of a file system. Upon creation, a file system has a single empty root directory and therefore has a metered size of 6 KiB.
The metered sizes of a particular file system define the usage for which the owner account is billed for that file system for that hour.
**Note**
The computed metered size doesn't represent a consistent snapshot of the file system at any particular time during that hour. Instead, it represents the sizes of the objects that existed in the file system at varying times within each hour, or possibly the hour before it. These sizes are summed to determine the file system's metered size for the hour. The metered size of a file system is thus eventually consistent with the metered sizes of the objects stored when there are no writes to the file system.
You can see the metered size for an EFS file system in the following ways:
+ Using the [https://docs.aws.amazon.com/cli/latest/reference/efs/describe-file-systems.html](https://docs.aws.amazon.com/cli/latest/reference/efs/describe-file-systems.html) AWS CLI command and the [DescribeFileSystem](API_DescribeFileSystems.md) API operation, the response includes the following:
```
"SizeInBytes":{
"Timestamp": 1403301078,
"Value": 29313744866,
"ValueInIA": 675432,
"ValueInStandard": 29312741784
"ValueInArchive": 327650
}
```
Where the metered size of `ValueInStandard` is also used to determine your I/O throughput baseline and burst rates for file systems using the [Bursting throughput](performance.md#throughput-modes).
+ View the `StorageBytes` CloudWatch metric, which displays the total metered size of data in each storage classes. For more information about the `StorageBytes` metric, see [CloudWatch metrics for Amazon EFS](efs-metrics.md).
+ Run the `df` command in Linux at the terminal prompt of an EC2 instance.
Don't use the **du** command on the root of the file system for storage metering purposes because the response does not reflect the full set data used for metering your file system.
**Note**
The metered size of `ValueInStandard` is also used to determine your I/O throughput baseline and burst rates. For more information, see [Bursting throughput](performance.md#bursting).
### Metering Infrequent Access and Archive storage classes
The EFS Infrequent Access (IA) and Archive storage classes are metered in 4 KiB increments and have a minimum billing charge per file of 128 KiB. IA and Archive file metadata (2 KiB per file) is always stored and metered in the Standard storage class. Support for files smaller than 128 KiB is only available for lifecycle policies updated on or after 12:00 PM PT, November 26, 2023. Data access for IA and Archive storage is metered in 128 KiB increments.
You can use the `StorageBytes` CloudWatch metric to view the metered size of data in each of the storage classes. The metric also displays the total number of bytes that are consumed by small-file rounding within the IA and Archive storage classes. For more information about viewing CloudWatch metrics, see [Accessing CloudWatch metrics for Amazon EFS](accessingmetrics.md). For more information about the `StorageBytes` metric, see [CloudWatch metrics for Amazon EFS](efs-metrics.md).
## Metering throughput
Amazon EFS meters the throughput for read requests at one-third the rate of the other file system I/O operations. For example, if you are driving 30 mebibytes per second (MiBps) of both read and write throughput, the read portion counts as 10 MiBps of effective throughput, the write portion counts as 30 MiBps, and the combined metered throughput is 40 MiBps. This combined throughput adjusted for consumption rates is reflected in the `MeteredIOBytes` CloudWatch metric.
### Metering Elastic throughput
When Elastic throughput mode is enabled for a file system, you pay only for the amount of metadata and data read from or written to the file system. EFS file systems using Elastic throughput mode meter and bill metadata reads as read operations and metadata writes as write operations. Metadata operations are metered in 1 KiB increments after the first 4 KiB. Data operations are metered in 1 KiB increments after the first 32 KiB.
**Note**
While Elastic throughput is designed to scale elastically with your throughput, we recommend implementing proper governance through monitoring metrics with CloudWatch (MeteredIOBytes) and usage alerts as part of your operational best practices. This helps you maintain optimal resource utilization and stay within your planned operational parameters. For more information, see [Monitoring metrics with Amazon CloudWatch](monitoring-cloudwatch.md).
### Metering Provisioned throughput
For file systems that use Provisioned throughput mode, you pay only for the amount of time that throughput is enabled. Amazon EFS meters file systems with Provisioned throughput mode enabled once every hour. For metering when Provisioned throughput mode is set for less than one hour, Amazon EFS calculates the time-average using millisecond precision.
# Viewing storage class size
You can view how much data is stored in each storage class of your file system using the Amazon EFS console, the AWS CLI, or the EFS API.
## Using the console
The **Metered size** tab on the **File system details** page displays the current metered size of the file system in binary multiples of bytes (kibibytes, mebibytes, gibibytes, and tebibytes). The metric is emitted every 15 minutes and lets you view your file system's metered size over time. **Metered size** displays the following information for the file system storage size:
+ **Total size** is the size (in binary bytes) of data stored in the file system, including all storage classes.
+ **Size in Standard ** is the size (in binary bytes) of data stored in the EFS Standard storage class.
+ **Size in IA** is the size (in binary bytes) of data stored in the EFS Infrequent Access storage class. Files smaller than 128KiB are rounded up to 128KiB.
+ **Size in Archive** is the size (in binary bytes) of data stored in the EFS Archive storage class. Files smaller than 128KiB are rounded up to 128KiB.
You can also view the `Storage bytes` metric on the **Monitoring** tab on the **File system details** page in the Amazon EFS console. For more information, see [Accessing CloudWatch metrics for Amazon EFS](accessingmetrics.md).
## Using the AWS CLI
You can view how much data is stored in each storage class of your file system using the AWS CLI or EFS API. View data storage details by calling the `describe-file-systems` CLI command (the corresponding API operation is [DescribeFileSystems](API_DescribeFileSystems.md)).
```
$ aws efs describe-file-systems \
--region us-west-2 \
--profile adminuser
```
In the response, `ValueInIA` displays the last metered size in bytes in the file system's Infrequent Access storage class. `ValueInStandard` displays the last metered size in bytes in the Standard storage class. `ValueInArchive` displays the last metered size in bytes in the Archive storage class. The sum of the three values equals the size of the entire file system, which is displayed in `Value`.
```
{
"FileSystems":[
{
"OwnerId":"251839141158",
"CreationToken":"MyFileSystem1",
"FileSystemId":"fs-47a2c22e",
"PerformanceMode" : "generalPurpose",
"CreationTime": 1403301078,
"LifeCycleState":"created",
"NumberOfMountTargets":1,
"SizeInBytes":{
"Value": 29313746702,
"ValueInIA": 675432,
"ValueInStandard": 29312741784,
"ValueInArchive":329486
},
"ThroughputMode": "elastic"
}
]
}
```
For additional ways to view and measure disk usage, see [Metering EFS file system objects](metered-sizes.md#metered-sizes-fs-objects).
# Monitoring metrics with Amazon CloudWatch
You can monitor file systems using Amazon CloudWatch, which collects and processes raw data from Amazon EFS into readable, near real-time metrics. These statistics are recorded for a period of 15 months, so that you can gain a better perspective on how your web application or service is performing.
By default, Amazon EFS metric data is automatically sent to CloudWatch at 1-minute periods, unless noted for some individual metrics. The Amazon EFS console displays a series of graphs based on the raw data from Amazon CloudWatch. Depending on your needs, you might prefer to get data for your file systems from CloudWatch instead of the graphs in the console.
For more information about Amazon CloudWatch, see [What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) in the *Amazon CloudWatch User Guide*.
Amazon EFS CloudWatch metrics are reported as raw *bytes*. Bytes are not rounded to either a decimal or binary multiple of the unit.
**Topics**
+ [CloudWatch metrics for Amazon EFS](efs-metrics.md)
+ [Accessing CloudWatch metrics for Amazon EFS](accessingmetrics.md)
+ [Using CloudWatch metrics for Amazon EFS](how_to_use_metrics.md)
+ [Using metric math with CloudWatch metrics](monitoring-metric-math.md)
+ [Monitoring mount attempt successes and failures](how-to-monitor-mount-status.md)
+ [Creating CloudWatch alarms to monitor Amazon EFS](creating_alarms.md)
# CloudWatch metrics for Amazon EFS
Amazon EFS metrics use the `EFS` namespace. The `AWS/EFS` namespace includes the following metrics. All metrics except for `TimeSinceLastSync` are for a single dimension, `FileSystemId`. A file system's ID can be found in the Amazon EFS console, and it takes the form of `fs-abcdef0123456789a`.
**`TimeSinceLastSync`**
Shows the amount of time that has passed since the last successful sync to the destination file system in a replication configuration. Any changes to data on the source file system that occurred before the `TimeSinceLastSync` value have been successfully replicated. Any changes on the source that occurred after `TimeSinceLastSync` might not be fully replicated.
This metric uses two dimensions:
+ `FileSystemId` dimension – ID of the source file system in the replication configuration.
+ `DestinationFileSystemId` dimension – ID of the destination file system in the replication configuration.
Units: Seconds
Valid statistics: `Minimum`, `Maximum`, `Average`
**`PercentIOLimit`**
Shows how close a file system is to reaching the I/O limit of the General Purpose performance mode.
Units: Percent
Valid statistics: `Minimum`, `Maximum`, `Average`
**`BurstCreditBalance`**
The number of burst credits that a file system has. Burst credits allow a file system to burst to throughput levels above a file system’s baseline level for periods of time.
The `Minimum` statistic is the smallest burst credit balance for any minute during the period. The `Maximum` statistic is the largest burst credit balance for any minute during the period. The `Average` statistic is the average burst credit balance during the period.
Units: Bytes
Valid statistics: `Minimum`, `Maximum`, `Average`
**`PermittedThroughput`**
The maximum amount of throughput that a file system can drive.
+ For file systems using Elastic throughput, this value reflects the maximum write throughput of the file system.
+ For file systems using Provisioned throughput, if the amount of data stored in the EFS Standard storage class allows your file system to drive a higher throughput than you provisioned, this metric reflects the higher throughput instead of the provisioned amount.
+ For file systems in Bursting throughput, this value is a function of the file system size and `BurstCreditBalance`.
The `Minimum` statistic is the smallest throughput permitted for any minute during the period. The `Maximum` statistic is the highest throughput permitted for any minute during the period. The `Average` statistic is the average throughput permitted during the period.
Read operations are metered at one-third the rate of other operations.
Units: Bytes per second
Valid statistics: `Minimum`, `Maximum`, `Average`
**`MeteredIOBytes`**
The number of metered bytes for each file system operation, including data read, data write, and metadata operations, with read operations discounted according to the throughput limit.
You can create a [CloudWatch metric math expression](monitoring-metric-math.md#metric-math-throughput-utilization) that compares `MeteredIOBytes` to `PermittedThroughput`. If these values are equal, then you are consuming the entire amount of throughput allocated to your file system. In this situation, you might consider changing the file system's throughput mode to get higher throughput.
The `Sum` statistic is the total number of metered bytes associated with all file system operations. The `Minimum` statistic is the size of the smallest operation during the period. The `Maximum` statistic is the size of the largest operation during the period. The `Average` statistic is the average size of an operation during the period. The `SampleCount` statistic provides a count of all operations.
Units:
+ Bytes for `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
** TotalIOBytes **
The actual number of bytes for each file system operation processed by Amazon EFS, without any read discounts. This number may differ from the actual amount requested by your applications because it includes minimums. This number may also be higher than the numbers shown in `PermittedThroughput`.
Data operations are metered at 32 KiB and other operations are metered at 4 KiB. After the minimum, all operations are metered per KiB.
The `Sum` statistic is the total number of bytes associated with all file system operations. The `Minimum` statistic is the size of the smallest operation during the period. The `Maximum` statistic is the size of the largest operation during the period. The `Average` statistic is the average size of an operation during the period. The `SampleCount` statistic provides a count of all operations.
To calculate the average operations per second for a period, divide the `SampleCount` statistic by the number of seconds in the period. To calculate the average throughput (bytes per second) for a period, divide the `Sum` statistic by the number of seconds in the period.
Units:
+ Bytes for `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`DataReadIOBytes`**
The actual number of bytes for each file system read operation.
The `Sum` statistic is the total number of bytes associated with read operations. The `Minimum` statistic is the size of the smallest read operation during the period. The `Maximum` statistic is the size of the largest read operation during the period. The `Average` statistic is the average size of read operations during the period. The `SampleCount` statistic provides a count of read operations.
Units:
+ Bytes for `Minimum`, `Maximum`, `Average`, and `Sum`.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`DataWriteIOBytes`**
The actual number of bytes for each file system write operation.
The `Sum` statistic is the total number of bytes associated with write operations. The `Minimum` statistic is the size of the smallest write operation during the period. The `Maximum` statistic is the size of the largest write operation during the period. The `Average` statistic is the average size of write operations during the period. The `SampleCount` statistic provides a count of write operations.
Units:
+ Bytes are the units for the `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`MetadataIOBytes`**
The actual number of bytes for each metadata operation.
The `Sum` statistic is the total number of bytes associated with metadata operations. The `Minimum` statistic is the size of the smallest metadata operation during the period. The `Maximum` statistic is the size of the largest metadata operation during the period. The `Average` statistic is the size of the average metadata operation during the period. The `SampleCount` statistic provides a count of metadata operations.
Units:
+ Bytes are the units for the `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`MetadataReadIOBytes`**
The actual number of bytes for each metadata read operation.
The `Sum` statistic is the total number of bytes associated with metadata read operations. The `Minimum` statistic is the size of the smallest metadata read operation during the period. The `Maximum` statistic is the size of the largest metadata read operation during the period. The `Average` statistic is the average size of metadata read operations during the period. The `SampleCount` statistic provides a count of metadata read operations.
Units:
+ Bytes are the units for the `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`MetadataWriteIOBytes`**
The actual number of bytes for each metadata write operation.
The `Sum` statistic is the total number of bytes associated with metadata write operations. The `Minimum` statistic is the size of the smallest metadata write operation during the period. The `Maximum` statistic is the size of the largest metadata write operation during the period. The `Average` statistic is the average size of metadata write operations during the period. The `SampleCount` statistic provides a count of metadata write operations.
Units:
+ Bytes are the units for the `Minimum`, `Maximum`, `Average`, and `Sum` statistics.
+ Count for `SampleCount`.
Valid statistics: `Minimum`, `Maximum`, `Average`, `Sum`, `SampleCount`
**`ClientConnections`**
The number of client connections to a file system. When using a standard client, there is one connection per mounted Amazon EC2 instance.
To calculate the average `ClientConnections` for periods greater than one minute, divide the `Sum` statistic by the number of minutes in the period.
Units: Count of client connections
Valid statistics: `Sum`
**`StorageBytes`**
The size of the file system in bytes, including the amount of data stored in the EFS storage classes. This metric is emitted to CloudWatch every 15 minutes.
The `StorageBytes` metric has the following dimensions:
+ `Total` is the metered size (in bytes) of data stored in the file system, in all storage classes. For EFS Infrequent Access (IA) and EFS Archive storage classes, files smaller than 128KiB are rounded to 128KiB.
+ `Standard` is the metered size (in bytes) of data stored in the EFS Standard storage class.
+ `IA` is the actual size (in bytes) of data stored in the EFS Infrequent Access storage class.
+ `IASizeOverhead` is the difference (in bytes) between the actual size of data in the EFS Infrequent Access storage class (indicated in the `IA` dimension) and the metered size of the storage class, after rounding small files to 128KiB.
+ `Archive` is the actual size (in bytes) of data stored in the EFS Archive storage class.
+ `ArchiveSizeOverhead` is the difference (in bytes) between the actual size of data in the EFS Archive storage class (indicated in the `Archive` dimension) and the metered size of the storage class, after rounding small files to 128KiB.
Units: Bytes
Valid statistics: `Minimum`, `Maximum`, `Average`
`StorageBytes` is displayed on the Amazon EFS console **File system metrics** page using base 1024 units (kibibytes, mebibytes, gibibytes, and tebibytes).
# Accessing CloudWatch metrics for Amazon EFS
You can view Amazon EFS metrics for CloudWatch in several ways:
+ In the Amazon EFS console
+ In the CloudWatch console
+ Using the CloudWatch CLI
+ Using the CloudWatch API
## To view CloudWatch metrics and alarms (Amazon EFS console)
1. Sign in to the AWS Management Console and open the Amazon EFS console at [ https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).
1. Choose **File systems**.
1. Choose the file system that you want to view CloudWatch metrics for.
1. Choose **Monitoring** to display the **File system metrics** page.
The **File system metrics** page displays a default set of CloudWatch metrics for the file system. Any CloudWatch alarms that you have configured also display with these metrics. For file systems that use Max I/O performance mode, the default set of metrics includes Burst Credit balance in place of Percent IO limit. You can override the default settings using the **Metrics settings** dialog box, accessed by opening the settings.
**Note**
The Throughput utilization (%) metric is not a CloudWatch metric; it is derived using CloudWatch metric math.
1. You can adjust the way metrics and alarms are displayed using the controls on the **File system metric** page, as follows.
+ Toggle the **Display mode** between **Time series** or **Single value**.
+ Show or hide any CloudWatch alarms configured for the file system.
+ Choose **See more in CloudWatch** to view the metrics in CloudWatch.
+ Choose **Add to dashboard** to open your CloudWatch dashboard and add the displayed metrics.
+ Adjust the metric time window displayed from 1 hour to 1 week.
## To view CloudWatch metrics and alarms (CloudWatch console)
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch).
1. In the navigation pane, choose **Metrics**.
1. Select the **EFS** namespace.
1. (Optional) To view a metric, enter its name in the search field.
1. (Optional) To filter by dimension, select **FileSystemId**.
## To access metrics from the AWS CLI
+ Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) command with the `--namespace "AWS/EFS"` namespace. For more information, see the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/).
## To access metrics from the CloudWatch API
+ Call `[https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)`. For more information, see the [Amazon CloudWatch API Reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/).
# Using CloudWatch metrics for Amazon EFS
The metrics reported by Amazon EFS provide information that you can analyze in different ways. The following list shows some common uses for the metrics. These are suggestions to get you started, not a comprehensive list.
| How do I? | Relevant metrics |
| --- | --- |
| How can I determine my throughput? | You can monitor the daily `Sum` statistic of the `TotalIOBytes` metric to see your throughput. |
| How can I determine the total amount of data transferred? | You can monitor the daily Sum statistic of MeteredIOBytes to see your total data transferred. |
| How can I track the number of Amazon EC2 instances that are connected to a file system? | You can monitor the `Sum` statistic of the `ClientConnections` metric. To calculate the average `ClientConnections` for periods greater than one minute, divide the sum by the number of minutes in the period. |
| How can I see my burst credit balance? | You can see your balance by monitoring the `BurstCreditBalance` metric for your file system. For more information on bursting and burst credits, see [Bursting throughput](performance.md#bursting). |
## Monitoring throughput performance
The CloudWatch metrics for throughput monitoring—`TotalIOBytes`, `ReadIOBytes`, `WriteIOBytes`, and `MetadataIOBytes`— represent the actual throughput that you are driving on your file system. The metric `MeteredIOBytes` represents the calculation of the overall metered throughput that you are driving. You can use the **Throughput utilization (%)** graph in the Amazon EFS console **Monitoring** section to monitor your throughput utilization. If you use custom CloudWatch dashboards or another monitoring tool, you can create a [CloudWatch metric math expression](monitoring-metric-math.md#metric-math-throughput-utilization) that compares `MeteredIOBytes` to `PermittedThroughput`.
`PermittedThroughput` measures the amount of allowed throughput for the file system. This value is based on one of the following methods:
+ For file systems in Elastic throughput, this value reflects the maximum write throughput of the file system.
+ For file systems using Provisioned throughput, if the amount of data stored in the EFS Standard storage class allows your file system to drive a higher throughput than you provisioned, this metric reflects the higher throughput instead of the provisioned amount.
+ For file systems using Bursting throughput, this value is a function of the file system size and `BurstCreditBalance`. Monitor `BurstCreditBalance` to ensure that your file system is operating at its burst rate rather than its base rate. If the balance is consistently at or near zero, consider switching to Elastic throughput or Provisioned throughput to get additional throughput.
When the values for `MeteredIOBytes` and `PermittedThroughput` are equal, your file system is consuming all available throughput. For file systems using Provisioned throughput, you can provision additional throughput.
# Using metric math with CloudWatch metrics
Using metric math, you can query multiple Amazon CloudWatch metrics and use math expressions to create new time series based on these metrics. You can visualize the resulting time series in the CloudWatch console and add them to dashboards. For example, you can use Amazon EFS metrics to take the sample count of `DataRead` operations divided by 60. The result is the average number of reads per second on your file system for a given 1-minute period. For more information on metric math, see [Using math expressions with CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) in the * Amazon CloudWatch User Guide.*
Following, find some useful metric math expressions for Amazon EFS.
**Topics**
+ [Metric math: Throughput in MiBps](#metric-math-throughput-mib)
+ [Metric math: Percent throughput](#metric-math-throughput-percent)
+ [Metric math: Percentage of permitted throughput utilization](#metric-math-throughput-utilization)
+ [Metric math: Throughput IOPS](#metric-math-throughput-iops)
+ [Metric math: Percentage of IOPS](#metric-math-iops-percent)
+ [Metric math: Average I/O size in KiB](#metric-math-average-io)
+ [Using metric math through an CloudFormation template for Amazon EFS](#metric-math-cloudformation-template)
## Metric math: Throughput in MiBps
To calculate the average throughput (in MiBps) for a time period, first choose a sum statistic (`DataReadIOBytes`, `DataWriteIOBytes`, `MetadataIOBytes`, or `TotalIOBytes`). Then convert the value to MiB, and divide that by the number of seconds in the period.
Suppose that your example logic is this: (sum of `TotalIOBytes` ÷ 1,048,576 (to convert to MiB)) ÷ seconds in the period
Then your CloudWatch metric information is the following.
| ID | Usable metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sum | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | (m1/1048576)/PERIOD(m1) |
## Metric math: Percent throughput
This metric math expression calculates the percent of overall throughput used for the different I/O types—for example, the percentage of total throughput that is driven by read requests. To calculate the percent of overall throughput used by one of the I/O types (`DataReadIOBytes`, `DataWriteIOBytes`, or `MetadataIOBytes`) for a time period, first multiply the respective sum statistic by 100. Then divide the result by the sum statistic of `TotalIOBytes` for the same period.
Suppose that your example logic is this: (sum of `DataReadIOBytes` x 100 (to convert to percentage)) ÷ sum of `TotalIOBytes`
Then your CloudWatch metric information is the following.
| ID | Usable metric or metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sum | 1 minute |
| m2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sum | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | (m2\$1100)/m1 |
## Metric math: Percentage of permitted throughput utilization
To calculate the percentage of permitted throughput utilization (`MeteredIOBytes`) for a time period, first multiply the throughput in MiBps by 100. Then divide the result by the a average statistic of `PermittedThroughput` converted to MiB for the same period.
Suppose that your example logic is this: (metric math expression for throughput in MiBps x 100 (to convert to percentage)) ÷ (sum of `PermittedThroughput` ÷ 1,048,576 (to convert bytes to MiB))
Then your CloudWatch metric information is the following.
| ID | Usable metric or metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | `MeteredIOBytes` | sum | 1 minute |
| m2 | `PermittedThroughput` | average | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | (m1/1048576)/PERIOD(m1) |
| e2 | m2/1048576 |
| e3 | ((e1)\$1100)/(e2) |
## Metric math: Throughput IOPS
To calculate the average operations per second (IOPS) for a time period, divide the sample count statistic (`DataReadIOBytes`, `DataWriteIOBytes`, `MetadataIOBytes`, or `TotalIOBytes`) by the number of seconds in the period.
Suppose that your example logic is this: sample count of `DataWriteIOBytes` ÷ seconds in the period
Then your CloudWatch metric information is the following.
| ID | Usable metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sample count | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | m1/PERIOD(m1) |
## Metric math: Percentage of IOPS
To calculate the percentage of IOPS per second of the different I/O types (`DataReadIOBytes`, `DataWriteIOBytes`, or `MetadataIOBytes`) for a time period, first multiply the respective sample count statistic by 100. Then divide that value by the sample count statistic of `TotalIOBytes` for the same period.
Suppose that your example logic is this: (sample count of `MetadataIOBytes` x 100 (to convert to percentage)) ÷ sample count of `TotalIOBytes`
Then your CloudWatch metric information is the following.
| ID | Usable metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sample count | 1 minute |
| m2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sample count | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | (m2\$1100)/m1 |
## Metric math: Average I/O size in KiB
To calculate the average I/O size (in KiB) for a period, divide the respective sum statistic for the `DataReadIOBytes`, `DataWriteIOBytes`, or `MetadataIOBytes` metric by the same sample count statistic of that metric.
Suppose that your example logic is this: (sum of `DataReadIOBytes` ÷ 1,024 (to convert to KiB)) ÷ sample count of `DataReadIOBytes`
Then your CloudWatch metric information is the following.
| ID | Usable metrics | Statistic | Period |
| --- | --- | --- | --- |
| m1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sum | 1 minute |
| m2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/efs/latest/ug/monitoring-metric-math.html) | sample count | 1 minute |
Your metric math ID and expression are the following.
| ID | Expression |
| --- | --- |
| e1 | (m1/1024)/m2 |
## Using metric math through an CloudFormation template for Amazon EFS
You can also create metric math expressions through CloudFormation templates. One such template is available for you to download and customize for use from the [Amazon EFS tutorials](https://github.com/aws-samples/amazon-efs-tutorial) on GitHub. For more information about using CloudFormation templates, see [Working with CloudFormation templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) in the *AWS CloudFormation User Guide.*
# Monitoring mount attempt successes and failures
You can use Amazon CloudWatch Logs to monitor and report the success or failure of mount attempts for your EFS file systems remotely without having to log into the clients. Use the following procedure to configure your EC2 instance to use CloudWatch Logs to monitor the success or failure of its file system mount attempts.
**To enable mount attempt success or failure notification in CloudWatch logs**
1. Install `amazon-efs-utils` on the EC2 instance mounting the file system. For more information, see [Automatically installing or updating Amazon EFS client using AWS Systems Manager](manage-efs-utils-with-aws-sys-manager.md) or [Manually installing the Amazon EFS client](installing-amazon-efs-utils.md).
1. Install `botocore` on the EC2 instance that will mount the file system. For more information, see [Installing and upgrading `botocore`](install-botocore.md).
1. Enable the CloudWatch Logs feature in `amazon-efs-utils`. When you use AWS Systems Manager to install and configure `amazon-efs-utils`, CloudWatch logging is automatically done for you. When you install the `amazon-efs-utils` package manually, you have to manually update the `/etc/amazon/efs/efs-utils.conf` configuration file by uncommenting the `# enabled = true` line in the `cloudwatch-log` section. Use one of the following commands to enable CloudWatch Logs manually.
For Linux instances:
```
sudo sed -i -e '/\[cloudwatch-log\]/{N;s/# enabled = true/enabled = true/}' /etc/amazon/efs/efs-utils.conf
```
For MacOS instances:
```
EFS_UTILS_VERSION= efs-utils-version
sudo sed -i -e '/\[cloudwatch-log\]/{N;s/# enabled = true/enabled = true/;}' /usr/local/Cellar/amazon-efs-utils/${EFS_UTILS_VERSION}/libexec/etc/amazon/efs/efs-utils.conf
```
For Mac2 instances:
```
EFS_UTILS_VERSION= efs-utils-version
sudo sed -i -e '/\[cloudwatch-log\]/{N;s/# enabled = true/enabled = true/;}' /opt/homebrew/Cellar/amazon-efs-utils/${EFS_UTILS_VERSION}/libexec/etc/amazon/efs/efs-utils.conf
```
1. Optionally, you can configure CloudWatch Logs group names and set the log retention days in the `efs-utils.conf` file. If you want to have separate log groups in CloudWatch for each mounted file system, add `/{fs_id}` to the end of the `log_group_name` field in `efs-utils.conf` file, as follows:
```
[cloudwatch-log]
log_group_name = /aws/efs/utils/{fs_id}
```
1. Attach the `AmazonElasticFileSystemsUtils` AWS managed policy to the IAM role that you have attached to the EC2 instance, or to the AWS credentials configured on your instance. You can use Systems Manager to do this, for more information, see [Step 1: Configure an IAM instance profile with the required permissions](setting-up-aws-sys-mgr.md#configure-sys-mgr-iam-instance-profile).
The following are examples of mount attempt status log entries:
```
Successfully mounted fs-12345678.efs.us-east-1.amazonaws.com at /home/ec2-user/efs
Mount failed, Failed to resolve "fs-01234567.efs.us-east-1.amazonaws.com"
```
**To view mount status in CloudWatch Logs**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choose **Log groups** in the left-hand navigation bar.
1. Choose the **/aws/efs/utils** log group. You will see a log stream for each Amazon EC2 instance and EFS file system combination.
1. Choose a log stream to view specific log events including mount attempt success or failure status.
# Creating CloudWatch alarms to monitor Amazon EFS
You can create a CloudWatch alarm that sends an Amazon SNS message when the alarm changes state. An alarm watches a single metric over a time period that you specify. The alarm then performs one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon SNS topic or Auto Scaling policy.
Alarms invoke actions for sustained state changes only. CloudWatch alarms don't invoke actions only because they are in a particular state; the state must have changed and been maintained for a specified number of periods.
One important use of CloudWatch alarms for Amazon EFS is to enforce encryption at rest for your file system. You can enable encryption at rest for an Amazon EFS file system when it's created. To enforce data encryption-at-rest policies for Amazon EFS file systems, you can use Amazon CloudWatch and AWS CloudTrail to detect the creation of a file system and verify that encryption at rest is enabled.
**Note**
Currently, you can't enforce encryption in transit.
The following procedures outline how to create alarms for Amazon EFS.
## Using the console
**To set alarms using the CloudWatch console**
1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Choose **Create Alarm**. This launches the **Create Alarm Wizard**.
1. Choose **EFS Metrics** and scroll through the Amazon EFS metrics to locate the metric you want to place an alarm on. To display only the Amazon EFS metrics in this dialog box, search for the file system ID of your file system. Select the metric to create an alarm on, and choose **Next**.
1. Fill in the **Name**, **Description**, **Whenever** values for the metric.
1. If you want CloudWatch to send you an email when the alarm state is reached, in the **Whenever this alarm:** field, choose **State is ALARM**. In the **Send notification to:** field, choose an existing SNS topic. If you select **Create topic**, you can set the name and email addresses for a new email subscription list. This list is saved and appears in the field for future alarms.
**Note**
If you use **Create topic** to create a new Amazon SNS topic, the email addresses must be verified before they receive notifications. Emails are only sent when the alarm enters an alarm state. If this alarm state change happens before the email addresses are verified, they do not receive a notification.
1. At this point, the **Alarm Preview** area gives you a chance to preview the alarm you’re about to create. Choose **Create Alarm**.
## Using the AWS CLI
**To set an alarm using the AWS CLI**
+ Call `[https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html)`. For more information, see the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/).
## Using the CloudWatch API
**To set an alarm using the CloudWatch API**
+ Call `[https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)`. For more information, see the [Amazon CloudWatch API Reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/).
# Logging Amazon EFS API calls with AWS CloudTrail
Amazon EFS is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon EFS. CloudTrail captures all API calls for Amazon EFS as events, including calls from the Amazon EFS console and from code calls to Amazon EFS API operations.
If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amazon EFS. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to Amazon EFS, the IP address from which the request was made, who made the request, when it was made, and additional details.
For more information, see the [What is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/) in the *AWS CloudTrail User Guide*.
## Amazon EFS information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in Amazon EFS, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Working with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for Amazon EFS, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all AWS Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following topics in the *AWS CloudTrail User Guide:*
+ [Creating a trail for your AWS account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [AWS service integrations with CloudTrail logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Receiving CloudTrail log files from multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All Amazon EFS [Amazon EFS API](api-reference.md) are logged by CloudTrail. For example, calls to the `CreateFileSystem`, `CreateMountTarget` and `CreateTags` operations generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root user or AWS Identity and Access Management (IAM) user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
For more information, see [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html) in the *AWS CloudTrail User Guide.*
## Understanding Amazon EFS log file entries
A *trail* is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An *event* represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the `CreateTags` operation when a tag for a file system is created from the console.
```
{
"eventVersion": "1.06",
"userIdentity": {
"type": "Root",
"principalId": "111122223333",
"arn": "arn:aws:iam::111122223333:root",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2017-03-01T18:02:37Z"
}
}
},
"eventTime": "2017-03-01T19:25:47Z",
"eventSource": "elasticfilesystem.amazonaws.com",
"eventName": "CreateTags",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.0",
"userAgent": "console.amazonaws.com",
"requestParameters": {
"fileSystemId": "fs-00112233",
"tags": [{
"key": "TagName",
"value": "AnotherNewTag"
}
]
},
"responseElements": null,
"requestID": "dEXAMPLE-feb4-11e6-85f0-736EXAMPLE75",
"eventID": "eEXAMPLE-2d32-4619-bd00-657EXAMPLEe4",
"eventType": "AwsApiCall",
"apiVersion": "2015-02-01",
"recipientAccountId": "111122223333"
}
```
The following example shows a CloudTrail log entry that demonstrates the `DeleteTags` action when a tag for a file system is deleted from the console.
```
{
"eventVersion": "1.06",
"userIdentity": {
"type": "Root",
"principalId": "111122223333",
"arn": "arn:aws:iam::111122223333:root",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2017-03-01T18:02:37Z"
}
}
},
"eventTime": "2017-03-01T19:25:47Z",
"eventSource": "elasticfilesystem.amazonaws.com",
"eventName": "DeleteTags",
"awsRegion": "us-west-2",
"sourceIPAddress": "192.0.2.0",
"userAgent": "console.amazonaws.com",
"requestParameters": {
"fileSystemId": "fs-00112233",
"tagKeys": []
},
"responseElements": null,
"requestID": "dEXAMPLE-feb4-11e6-85f0-736EXAMPLE75",
"eventID": "eEXAMPLE-2d32-4619-bd00-657EXAMPLEe4",
"eventType": "AwsApiCall",
"apiVersion": "2015-02-01",
"recipientAccountId": "111122223333"
}
```
### Log entries for EFS service-linked roles
The Amazon EFS service-linked role makes API calls to AWS resources. You will see CloudTrail log entries with `username: AWSServiceRoleForAmazonElasticFileSystem` for calls made by the EFS service-linked role. For more information about EFS and service-linked roles, see [Using service-linked roles for Amazon EFS](using-service-linked-roles.md).
The following example shows a CloudTrail log entry that demonstrates a `CreateServiceLinkedRole` action when Amazon EFS creates the AWSServiceRoleForAmazonElasticFileSystem service-linked role.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "111122223333",
"arn": "arn:aws:iam::111122223333:user/user1",
"accountId": "111122223333",
"accessKeyId": "A111122223333",
"userName": "user1",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2019-10-23T22:45:41Z"
}
},
"invokedBy": "elasticfilesystem.amazonaws.com”
},
"eventTime": "2019-10-23T22:45:41Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateServiceLinkedRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "user_agent",
"requestParameters": {
"aWSServiceName": "elasticfilesystem.amazonaws.com”
},
"responseElements": {
"role": {
"assumeRolePolicyDocument": "111122223333-10-111122223333Statement111122223333Action111122223333AssumeRole111122223333Effect%22%3A%20%22Allow%22%2C%20%22Principal%22%3A%20%7B%22Service%22%3A%20%5B%22 elasticfilesystem.amazonaws.com%22%5D%7D%7D%5D%7D",
"arn": "arn:aws:iam::111122223333:role/aws-service-role/elasticfilesystem.amazonaws.com/AWSServiceRoleForAmazonElasticFileSystem",
"roleId": "111122223333",
"createDate": "Oct 23, 2019 10:45:41 PM",
"roleName": "AWSServiceRoleForAmazonElasticFileSystem",
"path": "/aws-service-role/elasticfilesystem.amazonaws.com/“
}
},
"requestID": "11111111-2222-3333-4444-abcdef123456",
"eventID": "11111111-2222-3333-4444-abcdef123456",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
The following example shows a CloudTrail log entry that demonstrates a `CreateNetworkInterface` action made by the `AWSServiceRoleForAmazonElasticFileSystem` service-linked role, noted in the `sessionContext`.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:sts::0123456789ab:assumed-role/AWSServiceRoleForAmazonElasticFileSystem/0123456789ab",
"accountId": "0123456789ab",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::0123456789ab:role/aws-service-role/elasticfilesystem.amazonaws.com/AWSServiceRoleForAmazonElasticFileSystem",
"accountId": "0123456789ab",
"userName": "AWSServiceRoleForAmazonElasticFileSystem"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2019-10-23T22:50:05Z"
}
},
"invokedBy": "AWS Internal"
},
"eventTime": "20You 19-10-23T22:50:05Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "CreateNetworkInterface",
"awsRegion": "us-east-1",
"sourceIPAddress": "elasticfilesystem.amazonaws.com”,
"userAgent": "elasticfilesystem.amazonaws.com",
"requestParameters": {
"subnetId": "subnet-71e2f83a",
"description": "EFS mount target for fs-1234567 (fsmt-1234567)",
"groupSet": {},
"privateIpAddressesSet": {}
},
"responseElements": {
"requestId": "0708e4ad-03f6-4802-b4ce-4ba987d94b8d",
"networkInterface": {
"networkInterfaceId": "eni-0123456789abcdef0",
"subnetId": "subnet-12345678",
"vpcId": "vpc-01234567",
"availabilityZone": "us-east-1b",
"description": "EFS mount target for fs-1234567 (fsmt-1234567)",
"ownerId": "666051418590",
"requesterId": "0123456789ab",
"requesterManaged": true,
"status": "pending",
"macAddress": "00:bb:ee:ff:aa:cc",
"privateIpAddress": "192.0.2.0",
"privateDnsName": "ip-192-0-2-0.ec2.internal",
"sourceDestCheck": true,
"groupSet": {
"items": [
{
"groupId": "sg-c16d65b6",
"groupName": "default"
}
]
},
"privateIpAddressesSet": {
"item": [
{
"privateIpAddress": "192.0.2.0",
"primary": true
}
]
},
"tagSet": {}
}
},
"requestID": "11112222-3333-4444-5555-666666777777",
"eventID": "aaaabbbb-1111-2222-3333-444444555555",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
### Log entries for EFS authentication
Amazon EFS authorization for NFS clients emits `NewClientConnection` and `UpdateClientConnection` CloudTrail events. A `NewClientConnection` event is emitted when a connection is authorized immediately after an initial connection, and immediately after a re-connection. An `UpdateClientConnection` is emitted when a connection is reauthorized and the list of permitted actions has changed. The event is also emitted when the new list of permitted actions doesn't include `ClientMount`. For more information about EFS authorization, see [Using IAM to control access to file systems](iam-access-control-nfs-efs.md).
The following example shows a CloudTrail log entry that demonstrates a `NewClientConnection` event.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:sts::0123456789ab:assumed-role/abcdef0123456789",
"accountId": "0123456789ab",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE ",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::0123456789ab:role/us-east-2",
"accountId": "0123456789ab",
"userName": "username"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2019-12-23T17:50:16Z"
},
"ec2RoleDelivery": "1.0"
}
},
"eventTime": "2019-12-23T18:02:12Z",
"eventSource": "elasticfilesystem.amazonaws.com",
"eventName": "NewClientConnection",
"awsRegion": "us-east-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "elasticfilesystem",
"requestParameters": null,
"responseElements": null,
"eventID": "27859ac9-053c-4112-aee3-f3429719d460",
"readOnly": true,
"resources": [
{
"accountId": "0123456789ab",
"type": "AWS::EFS::FileSystem",
"ARN": "arn:aws:elasticfilesystem:us-east-2:0123456789ab:file-system/fs-01234567"
},
{
"accountId": "0123456789ab",
"type": "AWS::EFS::AccessPoint",
"ARN": "arn:aws:elasticfilesystem:us-east-2:0123456789ab:access-point/fsap-0123456789abcdef0"
}
],
"eventType": "AwsServiceEvent",
"recipientAccountId": "0123456789ab",
"serviceEventDetails": {
"permissions": {
"ClientRootAccess": true,
"ClientMount": true,
"ClientWrite": true
},
"sourceIpAddress": "10.7.3.72"
}
}
```
## Amazon EFS log file entries for encrypted-at-rest file systems
Amazon EFS gives you the option of using encryption at rest, encryption in transit, or both, for your file systems. For more information, see [Data encryption in Amazon EFS](encryption.md).
Amazon EFS sends [Encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) when making AWS KMS API requests to generate data keys and decrypt Amazon EFS data. The file system ID is the encryption context for all file systems that are encrypted at rest. In the `requestParameters` field of a CloudTrail log entry, the encryption context looks similar to the following.
```
"EncryptionContextEquals": {}
"aws:elasticfilesystem:filesystem:id" : "fs-4EXAMPLE"
```