# Managing EFS file systems
File system management tasks include managing a file system's network accessibility with mount targets, changing its throughput mode, updating its lifecycle policies, and managing its encryption.
You can perform these file system management tasks using the AWS Management Console, or programmatically using the AWS Command Line Interface (AWS CLI) or API, as discussed in the following sections.
**Topics**
+ [Understanding file system status](file-system-state.md)
+ [Managing mount targets](accessing-fs.md)
+ [Managing file system throughput](managing-throughput.md)
+ [Managing storage lifecycle](lifecycle-management-efs.md)
# Understanding file system status
You can view the status of Amazon EFS file systems using the Amazon EFS console or the AWS CLI. An Amazon EFS file system can have one of the status values described in the following table.
| File system state | Description |
| --- | --- |
| AVAILABLE | The file system is in a healthy state, and is reachable and available for use. |
| CREATING | Amazon EFS is in the process of creating the new file system. |
| DELETING | Amazon EFS is deleting the file system in response to a user-initiated delete request. For more information, see [Deleting EFS file systems](delete-efs-fs.md). |
| DELETED | Amazon EFS has deleted the file system in response to a user-initiated delete request. For more information, see [Deleting EFS file systems](delete-efs-fs.md). |
| UPDATING | The file system is undergoing an update in response to a user-initiated update request. |
| ERROR | Applicable for One Zone file systems, including file systems in a replication configuration. The file system is in a failed state and is unrecoverable. To access the file system data, restore a backup of this file system to a new file system. For more information, see [Backing up and replicating data in Amazon EFS](backup-replication.md) |
# Managing mount targets
You mount your file system on Amazon EC2 or other AWS compute instance in your virtual private cloud (VPC) using one or more mount targets that you create for the file system. You can create the mount target when you create the file system or after you create the file system.
After a mount target is created for a file system, you can create additional mount targets, delete mount targets, and modify the security groups for mount targets. If you want to modify the VPC for mount targets, then you need to first delete the existing mount targets.
**Note**
You can't change the IP address of an existing mount target. To change an IP address, you need to delete the mount target and create a new one with the new address.
**Topics**
+ [Mount targets and Availability Zones](#about-mount-targets)
+ [Creating mount targets](manage-fs-access-create-delete-mount-targets.md)
+ [Deleting mount targets](mount-target-delete.md)
+ [Changing the mount target VPC](manage-fs-access-change-vpc.md)
+ [Changing mount target security groups](manage-fs-access-update-mount-target-config-sg.md)
## Mount targets and Availability Zones
For EFS file systems that use Regional storage classes, you can create a mount target in each Availability Zone in an AWS Region.
For One Zone file systems, you can only create a single mount target in the same Availability Zone as the file system. Then you can mount the file system on compute instances, including Amazon EC2, Amazon ECS, and AWS Lambda in your virtual private cloud (VPC).
The following diagram shows a Regional file system with mount targets created in all Availability Zones in the VPC. The illustration shows three EC2 instances launched in different VPC subnets accessing an EFS file system. The illustration also shows one mount target in each of the Availability Zones (regardless of the number of subnets in each Availability Zone).
You can create only one mount target per Availability Zone. If an Availability Zone has multiple subnets, as shown in one of the zones in the illustration, you create a mount target in only one of the subnets. As long as you have one mount target in an Availability Zone, the EC2 instances launched in any of its subnets can share the same mount target.
![\[Regional file system with mount targets in three Availability Zones within a VPC on EC2 instances.\]](http://docs.aws.amazon.com/efs/latest/ug/images/efs-ec2-how-it-works-Regional_china-world.png)
The following diagram shows a One Zone file system, with a single mount target created in the same Availability Zone as the file system. Accessing the file system by using the EC2 instance in the `us-west2c` Availability Zone incurs data access charges because it is located in a different Availability Zone than the mount target.
![\[One Zone file system with a single mount target created in the same Availability Zone.\]](http://docs.aws.amazon.com/efs/latest/ug/images/efs-ec2-how-it-works-OneZone.png)
The mount target security group acts as a virtual firewall that controls the traffic. For example, it determines which clients can access the file system. This section explains the following:
+ Managing mount target security groups and enabling traffic.
+ Mounting the file system on your clients.
+ NFS-level permissions considerations.
Initially, only the root user on the Amazon EC2 instance has read-write-execute permissions on the file system. This topic discusses NFS-level permissions and provides examples that show you how to grant permissions in common scenarios. For more information, see [Network File System (NFS) level users, groups, and permissions](accessing-fs-nfs-permissions.md).
# Creating mount targets
To access an EFS file system in a VPC, you need to create mount targets for the file system.
For an EFS file system, the following is true:
+ You can create mount targets for the file system in one VPC at a time. If you want to access the file system from another VPC, you need to delete the mount targets from the current VPC and then create new mount targets in the other VPC. For more information, see [Changing the mount target VPC](manage-fs-access-change-vpc.md).
+ If the VPC has multiple subnets in an Availability Zone, you can create a mount target in only one of those subnets. All EC2 instances in the Availability Zone can share the single mount target.
+ At a minimum, you should create a mount target in each Availability Zone from which you want to access the file system.
**Note**
There are cost considerations for mounting a file system on an EC2 instance in an Availability Zone through a mount target created in another Availability Zone. For more information, see [Amazon EFS Pricing](https://aws.amazon.com/efs/pricing). In addition, by always using a mount target local to the instance's Availability Zone, you remove a partial failure scenario. If the mount target's zone goes down, you can't access your file system through that mount target.
You can create mount targets for a file system by using the AWS Management Console, AWS CLI, or programmatically by using the AWS SDKs. In the console, you can create mount targets when you create the file system or after the file system is created. For instructions on creating mount targets when creating a file system, see [Custom create using the console](creating-using-create-fs.md#creating-using-fs-part1-console).
## Using the console
Use the following procedure to add mount targets to an existing EFS file system.
**To create a mount target on an EFS file system**
1. Open the Amazon Elastic File System console at [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).
1. In the left navigation pane, choose **File systems**, and then select the file system for which you want to change the VPC.
1. Choose **Network** and then choose **Manage** to display the mount targets for the file system.
1. Choose the file system that you want to add mount targets for by choosing its **Name** or the **File system ID**.
**Note**
For One Zone file systems, you can only create a single mount target that is in the same Availability Zone as the file system.
1. For file systems that use EFS Regional storage classes, choose **Add mount target** for each mount target you want to create for the file system.
1. Define the mount target settings:
1. Choose the Availability Zone and subnet ID for the mount target.
1. For **IP address type**, choose **IPv4 only** to support IPv4 addresses only, **IPv6 only** to support IPv6 addresses only, or **Dual-stack** to support both IPv4 and IPv6 addresses.
**Note**
The IP address type must match the IP type of the subnet. Additionally, the IP address type overrides the IP addressing attribute of your subnet. For example, if the IP address type is IPv4-only and the IPv6 addressing attribute is enabled for your subnet, network interfaces created in the subnet receive an IPv4 address from the range of the subnet. For more information, see [Modify the IP addressing attributes of your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-public-ip.html).
1. If you know the IP address where you want to place the mount target, then enter it in the IP address box that matches the **IP address type**. If you don't specify a value, Amazon EFS selects an unused IP address from the specified subnet.
**Note**
You can't change the IP address of a mount target after it's created. To change an IP address, you need to delete the mount target and create a new one with the new address.
1. Choose at least one security group to associate with the mount target. You can [modify the security groups](manage-fs-access-update-mount-target-config-sg.md) later.
1. Choose **Save**.
## Using the AWS CLI
This section provide examples for creating a mount target in the AWS CLI using the `create-mount-target` command. The equivalent API command is [CreateMountTarget](API_CreateMountTarget.md).
+ If you don't specify an IP address type for the mount target, then IPv4-only is used.
+ If you don't specify an IP address for the mount target, then Amazon EFS assigns an available address on the specified subnet.
+ The IP address type overrides the IP addressing attribute of your subnet. For example, if the IP address type is IPv4-only and the IPv6 addressing attribute is enabled for your subnet, network interfaces created in the subnet receive an IPv4 address from the range of the subnet. For more information, see [Modify the IP addressing attributes of your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-public-ip.html).
**Note**
For One Zone file systems, you can only create a single mount target that is in the same Availability Zone as the file system.
### Example: Create mount target at an available IPv4 address on a subnet
The following command specifies the file system, subnet, and security group for the mount target. The target is created at an available IPv4 address on the specified subnet.
```
$ aws efs create-mount-target \
--file-system-id file-system-id \
--subnet-id subnet-id \
--security-group ID-of-the-security-group-created-for-mount-target \
--region aws-region \
```
The following example shows the command with sample data.
```
$ aws efs create-mount-target \
--file-system-id fs-0123456789abcdef1 \
--subnet-id subnet-b3983dc4 \
--security-group sg-01234567 \
--region us-east-2 \
```
After successfully creating the mount target, Amazon EFS returns the mount target description as JSON as shown in the following example.
```
{
"OwnerID": "111122223333"
"MountTargetId": "fsmt-f9a14450",
"FileSystemId": "fs-0123456789abcdef1",
"SubnetId": "subnet-b3983dc4",
"LifeCycleState": "available",
"IpAddress": "10.0.1.24",
"NetworkInterfaceId": "eni-3851ec4e",
"AvailabilityZoneId": "use2-az1",
"AvailabilityZoneName": "us-east-2a",
"VpcId": "vpc-3c39ef57"
}
```
### Example: Create a mount target at a specific IPv4 address
The following command specifies the file system, subnet, security group, and IPv4 address to use for the mount target. The target is created at the specified IPv4 address on the specified subnet.
```
$ aws efs create-mount-target \
--file-system-id file-system-id \
--subnet-id subnet-id \
--security-group ID-of-the-security-group-created-for-mount-target \
--ip-address IPv4-address
--region aws-region \
```
The following example shows the command with sample data.
```
$ aws efs create-mount-target \
--file-system-id fs-0123456789abcdef1 \
--subnet-id subnet-b3983dc4 \
--security-group sg-01234567 \
--ip-address 10.0.1.24 \
--region us-east-2 \
```
After successfully creating the mount target, Amazon EFS returns the mount target description as JSON as shown in the following example.
```
{
"OwnerID": "111122223333"
"MountTargetId": "fsmt-f9a14450",
"FileSystemId": "fs-0123456789abcdef1",
"SubnetId": "subnet-b3983dc4",
"LifeCycleState": "available",
"IpAddress": "10.0.1.24",
"NetworkInterfaceId": "eni-3851ec4e",
"AvailabilityZoneId": "use2-az1",
"AvailabilityZoneName": "us-east-2a",
"VpcId": "vpc-3c39ef57"
}
```
### Example: Create a mount target at a specific IPv6 address
The following command specifies the file system, subnet, security group, and IPv6 address to use for the mount target. The target is created at the specified IPv6 address on the specified subnet.
```
$ aws efs create-mount-target \
--file-system-id file-system-id \
--subnet-id subnet-id \
--security-group ID-of-the-security-group-created-for-mount-target \
--ip-address-type IP-address-type \
--ipv6-address IPv6-address \
--region aws-region \
```
The following example shows the command with sample data.
```
$ aws efs create-mount-target \
--file-system-id fs-0123456789abcdef1 \
--subnet-id subnet-b3983dc4 \
--security-group sg-01234567 \
--ip-address-type IPV6_ONLY \
--ipv6-address 2001:0db8:85a3:0000:0000:8a2e:0370:7334 \
--region us-east-2 \
```
After successfully creating the mount target, Amazon EFS returns the mount target description as JSON as shown in the following example.
```
{
"OwnerID": "111122223333"
"MountTargetId": "fsmt-f9a14450",
"FileSystemId": "fs-0123456789abcdef1",
"SubnetId": "subnet-b3983dc4",
"LifeCycleState": "available",
"Ipv6Address": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
"NetworkInterfaceId": "eni-3851ec4e",
"AvailabilityZoneId": "use2-az1",
"AvailabilityZoneName": "us-east-2a",
"VpcId": "vpc-3c39ef57"
}
```
### Example: Create a mount target at an available IPv4 address on dual-stack subnet
The command specifies the file system, subnet, security group, dual-stack IP address type, and IPv6 address for the mount target. The target is created at an available IPv4 address and the specified IPv6 address on the dual-stack subnet.
```
$ aws efs create-mount-target \
--file-system-id file-system-id \
--subnet-id subnet-id \
--security-group ID-of-the-security-group-created-for-mount-target \
--ip-address-type IP-address-type
--ipv6-address IPv6-address \
--region aws-region \
```
The following example shows the command with sample data.
```
$ aws efs create-mount-target \
--file-system-id fs-0123456789abcdef1 \
--subnet-id subnet-b3983dc4 \
--security-group sg-01234567 \
--ip-address-type DUAL_STACK \
--ipv6-address 2001:0db8:85a3:0000:0000:8a2e:0370:7334 \
--region us-east-2 \
```
After successfully creating the mount target, Amazon EFS returns the mount target description as JSON as shown in the following example.
```
{
"OwnerID": "111122223333"
"MountTargetId": "fsmt-f9a14450",
"FileSystemId": "fs-0123456789abcdef1",
"SubnetId": "subnet-b3983dc4",
"LifeCycleState": "available",
"IpAddress": "10.0.1.24",
"Ipv6Address": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
"NetworkInterfaceId": "eni-3851ec4e",
"AvailabilityZoneId": "use2-az1",
"AvailabilityZoneName": "us-east-2a",
"VpcId": "vpc-3c39ef57"
}
```
# Deleting mount targets
When you delete a mount target, the operation forcibly breaks any mounts of the file system, which might disrupt instances or applications using those mounts. To avoid application disruption, stop applications and unmount the file system before deleting the mount target. For more information, see [Unmounting file systems](unmounting-fs.md).
You can delete mount targets for a file system by using the AWS Management Console, AWS CLI, or programmatically by using the AWS SDKs.
## Using the console
Use the following procedure to delete mount targets for an existing EFS file system.
**To delete mount targets on an EFS file system**
1. Unmount the file system. For instructions, see [Unmounting file systems](unmounting-fs.md).
1. Open the Amazon Elastic File System console at [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).
1. In the left navigation pane, choose **File systems**, and then select the file system for which you want to delete the mount target.
1. Choose **Network** and then choose **Manage** to display the mount targets for the file system.
1. For each mount target you want to delete, choose **Remove**.
1. Choose **Save**.
## Using the AWS CLI
To delete an existing mount target, use the `delete-mount-target` AWS CLI command (corresponding operation is [DeleteMountTarget](API_DeleteMountTarget.md)), as shown following.
**Note**
Before deleting a mount target, first unmount the file system.
```
$ aws efs delete-mount-target \
--mount-target-id mount-target-ID-to-delete \
--region aws-region-where-mount-target-exists
```
The following is an example with sample data.
```
$ aws efs delete-mount-target \
--mount-target-id fsmt-5751852e \
--region us-east-2 \
```
# Changing the mount target VPC
You can use an EFS file system in one VPC based on the Amazon VPC service at a time. That is, you create mount targets in a VPC for your file system, and use those mount targets to provide access to the file system.
You can mount the EFS file system from these targets:
+ Amazon EC2 instances in the same VPC
+ EC2 instances in a VPC connected by VPC peering
+ On-premises servers by using AWS Direct Connect
+ On-premises servers over an AWS virtual private network (VPN) by using Amazon VPC
A *VPC peering connection* is a networking connection between two VPCs that enables you to route traffic between them. The connection can use private Internet Protocol version 4 (IPv4) or version 6 (IPv6). For more information on how Amazon EFS works with VPC peering, see [Mounting EFS file systems from another AWS account or VPC](manage-fs-access-vpc-peering.md).
**To change the VPC for a file system**
The following are the steps that you'll perform to change the VPC for an EFS file system's network configuration.
1. Delete each mount target assigned to the file system. For instructions, see [Deleting mount targets](mount-target-delete.md).
1. When the **Mount targets status** for each mount target is **Deleted**, assign the new VPC and create new mount targets for the file system. For instructions, see [Creating mount targets](manage-fs-access-create-delete-mount-targets.md).
# Changing mount target security groups
Security groups define inbound and outbound access. When you change security groups associated with a mount target, make sure that you authorize necessary inbound and outbound access. Doing so enables your EC2 instance to communicate with the file system. For more information about security groups, see [Using VPC security groups](network-access.md).
You can add or remove security groups for a file system's mount target by using the AWS Management Console, AWS CLI, or programmatically by using the AWS SDKs.
## Using the console
**To modify security groups for mount targets**
Use the following procedure to add or remove mount target security groups for an existing EFS file system.
1. Open the Amazon Elastic File System console at [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).
1. In the left navigation pane, choose **File systems**, and then select the file system for which you want to manage mount targets.
1. Choose **Network** and then choose **Manage** to display the mount targets for the file system.
1. To remove a security group from a mount target, choose **X** next to the security group ID.
1. To add a security group to a mount target, choose the security from the **Security groups** list.
1. Choose **Save**.
## Using the AWS CLI
To modify security groups that are in effect for a mount target, use the `modify-mount-target-security-group` AWS CLI command (the corresponding operation is [ModifyMountTargetSecurityGroups](API_ModifyMountTargetSecurityGroups.md)) to replace any existing security groups, as shown following.
```
$ aws efs modify-mount-target-security-groups \
--mount-target-id mount-target-ID-whose-configuration-to-update \
--security-groups security-group-ids-separated-by-space \
--region aws-region-where-mount-target-exists \
--profile adminuser
```
The following is an example with sample data.
```
$ aws efs modify-mount-target-security-groups \
--mount-target-id fsmt-5751852e \
--security-groups sg-1004395a sg-1114433a \
--region us-east-2
```
# Managing file system throughput
*Elastic throughput* is the default throughput mode in the Amazon EFS console and is recommended for most use cases. With Elastic throughput, performance automatically scales up or down to meet the needs of your workload activity. If, however, you know the specific access patterns for your workloads (including throughput, latency, and storage needs), then you can choose to change the throughput mode.
**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).
Other throughput modes you can choose include:
+ **Provisioned throughput** – You specify a level of throughput that the file system can drive independent of the file system's size or burst credit balance.
+ **Bursting throughput** – Throughput scales with the amount of storage in your file system and supports bursting to higher levels for up to 12 hours per day.
For more information about Amazon EFS throughput modes, see [Throughput modes](performance.md#throughput-modes).
**Note**
You can change the throughput mode and the provisioned throughput amount after the file system is available. Changing throughput mode does not cause application downtime. However, any time that you change the file system to Provisioned throughput or increase the provisioned throughput amount, you must wait at least 24 hours before you can change the throughput mode again or decrease the provisioned amount.
You can manage the file system throughput mode by using the Amazon EFS console, the AWS Command Line Interface (AWS CLI), and Amazon EFS API.
## Using the console
**To manage file system throughput**
1. Open the Amazon Elastic File System console at [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).
1. In the left navigation pane, choose **File systems** to display the list of EFS file systems in your account.
1. Choose the file system that you want to change the throughput mode for.
1. On the file system details page, in the **General** section, choose **Edit**. The **Edit** page displays.
1. Modify the **Throughput mode** setting.
+ To use Elastic throughput or Provisioned throughput, choose **Enhanced**, and then choose **Elastic** or **Provisioned**.
If you choose **Provisioned**, then, in **Provisioned Throughput (MiB/s)**, enter the amount of throughput to provision for file system requests. The amount of **Maximum Read Throughput** is displayed at three times the amount of the throughput that you enter. EFS file systems meter read requests at one-third the rate of other requests. After you enter the throughput, an estimate of the monthly cost for the file system is shown.
**Note**
You can change the throughput mode and the provisioned throughput amount after the file system is available. However, any time that you change the file system throughput to Provisioned or increase the provisioned throughput amount, you must wait at least 24 hours before you can change the throughput mode again or decrease the provisioned amount.
+ To use Bursting throughput, choose **Bursting**.
For more information about choosing the correct throughput mode for your performance needs, see [Throughput modes](performance.md#throughput-modes).
1. Choose **Save changes** to implement your changes.
## Using the AWS CLI
Use the [https://docs.aws.amazon.com/cli/latest/reference/efs/update-file-system.html](https://docs.aws.amazon.com/cli/latest/reference/efs/update-file-system.html) CLI command, or the [UpdateFileSystem](API_UpdateFileSystem.md) API action to change a file system's throughput mode.
# Managing storage lifecycle
You can manage your file systems so that they have cost-effective storage throughout their lifecycle. Use lifecycle management to automatically transition data between storage classes according to the lifecycle configuration for the file system. The lifecycle configuration comprises of three *lifecycle policies* that you set for the file system.
Lifecycle policies instruct lifecycle management when to transition files into and out of the EFS Infrequent Access (IA) and EFS Archive storage classes. Transition time is based on when the files were last accessed in the Standard storage class. To determine last accessed time in the Standard storage class, an internal timer tracks when a file was last accessed (not the POSIX file system attributes that are publicly viewable). Whenever a file in Standard is accessed, the lifecycle management timer is reset.
Lifecycle policies apply to the entire EFS file system.
The EFS lifecycle policies are:
+ **Transition into IA** – Instructs lifecycle management when to move files in to the Infrequent Access (IA) storage class, which is cost-optimized for data that is accessed only a few times each quarter. By default, files that are not accessed in Standard storage fclass or 30 days are transitioned into IA.
+ **Transition into Archive** – Instructs lifecycle management when to move files from the Standard or IA storage class in to the Archive storage class, which is cost-optimized for data that is accessed only a few times each year or less. By default, files that are not accessed in the Standard storage class for 90 days are transitioned in to the Archive storage class.
+ **Transition into Standard** – Instructs lifecycle management whether to transition files out of the IA or Archive storage class and back in to the Standard storage class when the files are accessed in the IA or Archive storage class. By default, files are not moved back to the Standard storage class, and they remain in the IA or Archive storage class when they are accessed.
For performance-sensitive use cases that demand the fastest latency performance (such as applications that work with a large volume of small files), choose to transition files into Standard storage **On first access**.
For more information about configuring the lifecycle policies for a file system, see [Configuring lifecycle policies](enable-lifecycle-management.md).
## File system operations for lifecycle management
File system operations for lifecycle management have a lower priority than operations for EFS file system workloads. The time required to transition files in to or out of IA and Archive storage varies depending on the file size and file system workload. For example, transitioning millions of small files may take longer than transitioning fewer larger files of the same total storage size.
File metadata, including file names, ownership information, and file system directory structure, is always stored in Standard to help ensure consistent metadata performance.
Metadata operations for file systems in IA or Archive storage, such as listing the contents of a directory, don't count as file access. During the process of transitioning a file's content to the IA or Archive storage classes, the file is stored in the Standard storage class and is billed at that storage rate.
All write operations to files in the file system's IA or Archive storage classes are first written to Standard storage classes, and are then eligible to be transitioned to the applicable storage class after 24 hours.
# Configuring lifecycle policies
When you create an EFS file system that has the recommended settings using the AWS Management Console, the file system is automatically configured with the following default lifecycle configuration:
+ **Transition into IA** is set to **30 days since last access**.
+ **Transition into Archive** is set to **90 days since last access**.
+ **Transition into Standard** is set to **None**.
You can change the default lifecycle policies when creating a file system with customized settings using the AWS Management Console or when creating a file system using the AWS CLI. Alternately, you can change the policies after the file system is created, as described in the following procedures.
## Using the console
You can use the AWS Management Console to set the lifecycle policies for an existing file system.
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** to display the list of file systems in your account.
1. Choose the file system on which you want to modify lifecycle policies.
1. On the file system details page, in the **General** section, choose **Edit**. The **Edit** page displays.
1. For Lifecycle management, configure the lifecycle policies:
+ Set **Transition into IA** to one of the available options. To stop moving files into IA storage, choose **None**.
+ Set **Transition into Archive** to one of the available options. To stop moving files into Archive storage, choose **None**.
+ Set **Transition into Standard** to **On first access** to move files that are in IA storage to standard storage when they're accessed for non-metadata operations.
To stop moving files from IA or Archive to Standard storage on first access, select **None**.
1. Choose **Save changes** to save your changes.
## Using the AWS CLI
You can use the AWS CLI to set or modify a file system's lifecycle policies.
+ Run the [https://docs.aws.amazon.com/cli/latest/reference/efs/put-lifecycle-configuration.html](https://docs.aws.amazon.com/cli/latest/reference/efs/put-lifecycle-configuration.html) AWS CLI command or the [PutLifecycleConfiguration](API_PutLifecycleConfiguration.md) API command, specifying the file system ID of the file system for which you are managing lifecycle management.
```
$ aws efs put-lifecycle-configuration \
--file-system-id File-System-ID \
--lifecycle-policies "[{\"TransitionToIA\":\"AFTER_60_DAYS\"},{\"TransitionToPrimaryStorageClass\":\"AFTER_1_ACCESS\"},{\"TransitionToArchive\":\"AFTER_90_DAYS\"}]" \
--region us-west-2 \
--profile adminuser
```
You get the following response.
```
{
"LifecyclePolicies": [
{
"TransitionToIA": "AFTER_60_DAYS"
},
{
"TransitionToPrimaryStorageClass": "AFTER_1_ACCESS"
},
{
"TransitionToArchive": "AFTER_90_DAYS"
}
]
}
```
**To stop lifecycle management for an existing file system (CLI)**
+ Run the `put-lifecycle-configuration` command specifying the file system ID of the file system for which you are stopping lifecycle management. Keep the `--lifecycle-policies` property empty.
```
$ aws efs put-lifecycle-configuration \
--file-system-id File-System-ID \
--lifecycle-policies \
--region us-west-2 \
--profile adminuser
```
You get the following response.
```
{
"LifecyclePolicies": []
}
```