# Ensure EFS file systems have no mount targets in public subnets

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292241055955-ensure-efs-file-systems-have-no-mount-targets-in-public-subnets
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that no Amazon Elastic File System (EFS) file system has a mount target in a public subnet. A subnet is considered public when its route table has a default route (0.0.0.0/0) to an internet gateway. Mount targets should be placed only in private subnets.

**Rationale**

A mount target in a public subnet places the file system's NFS endpoint in a network segment that is routed to the Internet. A misconfigured security group or network ACL can then expose the file system to Internet scanning, unauthorized reads and writes, deletion of data and denial-of-service attacks. Placing mount targets in private subnets, restricting NFS (TCP port 2049) to known sources with security groups, and using VPN, AWS Direct Connect or VPC peering for remote access applies defense in depth.

**Impact**

-   Keeps the file system's network endpoints out of Internet-routed subnets
    
-   A file system can have only one mount target per Availability Zone, so the public mount target must be deleted before a new one is created in the same Availability Zone; clients in that Availability Zone lose access briefly
    
-   The mount target IP address changes; clients that mount by IP address instead of the file system DNS name must be updated
    

**Default Value**

There is no default subnet type for mount targets. Mount targets are created in the subnets selected when the file system or mount target is created, and the default subnets of a default VPC are public subnets.

**Pre-Requisites**

-   IAM permissions: elasticfilesystem:DescribeFileSystems, elasticfilesystem:DescribeMountTargets, elasticfilesystem:DescribeMountTargetSecurityGroups, elasticfilesystem:CreateMountTarget, elasticfilesystem:DeleteMountTarget, ec2:DescribeSubnets, ec2:DescribeRouteTables and ec2:DescribeNetworkInterfaces
    
-   A private subnet (without a default route to an internet gateway) in each Availability Zone that needs a mount target
    
-   A maintenance window, since clients in the affected Availability Zone lose access while the mount target is replaced
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon EFS console, select **File systems** and open each file system.
    
3.  On the **Network** tab, note the subnet of each mount target.
    
4.  Open the Amazon VPC console, select **Subnets**, select each noted subnet and open the **Route table** tab.
    
5.  Check whether the route table has a route with destination 0.0.0.0/0 and a target that starts with igw-.
    
6.  Repeat for each file system in each region in use.
    
7.  If any mount target is in such a subnet, follow the implementation steps.
    

**CLI:**

List the mount targets of a file system:

aws efs describe-mount-targets --file-system-id <FILE\_SYSTEM\_ID> --region <REGION> --query "MountTargets\[\].\[MountTargetId,SubnetId,VpcId,AvailabilityZoneName,IpAddress\]" --output table

Show the routes of the route table associated with a mount target's subnet:

aws ec2 describe-route-tables --region <REGION> --filters Name=association.subnet-id,Values=<SUBNET\_ID> --query "RouteTables\[\].Routes\[\].\[DestinationCidrBlock,GatewayId\]" --output table

If no route table is returned, the subnet uses the VPC's main route table:

aws ec2 describe-route-tables --region <REGION> --filters Name=vpc-id,Values=<VPC\_ID> Name=association.main,Values=true --query "RouteTables\[\].Routes\[\].\[DestinationCidrBlock,GatewayId\]" --output table

A file system fails if any of its mount targets is in a subnet whose route table has a route with destination 0.0.0.0/0 and a gateway ID that starts with igw-.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon EFS console, select **File systems** and open the file system.
    
3.  On the **Network** tab, choose **Manage**.
    
4.  For the Availability Zone that uses a public subnet, remove the mount target.
    
5.  Add a mount target in a private subnet of the same Availability Zone and select security groups that allow NFS (TCP port 2049) only from trusted sources.
    
6.  Choose **Save**.
    
7.  Repeat for each affected file system in each region in use.
    

**Backout Plan**

Before making changes, save the current mount target configuration:

aws efs describe-mount-targets --file-system-id <FILE\_SYSTEM\_ID> --region <REGION> > efs-mount-targets-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon EFS console, select **File systems** and open the file system.
    
3.  On the **Network** tab, choose **Manage**.
    
4.  Remove the new mount target and add one in the original subnet with the original security groups from the saved backup.
    
5.  Choose **Save**.
    

Note: rolling back places the file system endpoint in an Internet-routed subnet again. Use it only as a temporary measure.

**Reference**

-   [https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/efs/describe-mount-targets.html](https://docs.aws.amazon.com/cli/latest/reference/efs/describe-mount-targets.html)
    
-   [https://docs.aws.amazon.com/securityhub/latest/userguide/efs-controls.html](https://docs.aws.amazon.com/securityhub/latest/userguide/efs-controls.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.