In this tutorial, we will look at configuring AWS EFS (Elastic File System) on an EC2 instance. All our Kubernetes deployments use EFS, so before we dive to real world deployments, let’s get this infrastructure ready.

So far in our series of blogs (part1, part2, part3, part4, part5) of deploying a single node Kubernetes cluster (Master node and Worker node), we have not yet deployed any containers on our Kubernetes cluster.

One important point to note is that it doesn’t matter what the underlying operating system or which cloud provider you are using, Kubernetes deployment and commands remain the same across all platforms, even if you are using bare metal instead of a cloud provider.

One of the most important things about containers is data persistence. Whatever application you deploy, the underlying data must be persistent, even if the container stops working or the cluster is deleted and re-deployed.

What does persistent data actually mean?


Data persistency in Kubernetes is achieved through API resources: PersistentVolume and PersistentVolumeClaim.

PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see AccessModes).

For more details on volumes on Kubernetes, refer the below link for the types of storages available.

For all our Kubernetes deployments, we will be using a distributed storage system.

AWS provides an Elastic File System (EFS) service, which provides the distributed storage system to multiple nodes. EFS persists with the data, even if the pods get killed or the entire cluster is deleted. Moreover, it is not very expensive and easy to manage.

Why use EFS for Kubernetes deployment?


One of the biggest advantages of using EFS is that the data can be shared across multiple nodes. This ensures that even if a node (EC2 instance) crashes or is unavailable, the data is still available to other nodes in the cluster.

In a DevOps or Micro-service architecture environment, required data MUST be available to all nodes, so that any update on 1 node is available and visible to other nodes.

AWS EFS service is one of the cheap, and easiest ways of maintaining Persistent data across nodes. In situations where there are multiple Replica sets of a pod, then having the same data for all the pods can be achieved using EFS. EFS ensures that any update to the data is visible to all the pods across nodes.

Amazon Elastic File System (Amazon EFS) is a straightforward, serverless, set-and-forget file system. There is no setup or minimum fee. You only pay for the storage you use, for reading and writing access to data kept in Infrequent Access storage classes, and any allocated throughput.

For all our Kubernetes deployments, we use AWS EFS. Using EFS, we remove the dependency on the EBS (Elastic Block Storage). We use EBS only for operating system files. All Kubernetes deployment files (configuration) and pod data (datafiles) are stored on AWS EFS, so that even if the nodes (Master or Worker) crash or are shutdown, the data is available, by bringing up a new EC2 instance.


How to create an EFS and mount it on the node.



Step1: Create the EFS


EFS can be created using the AWS EFS console or AWS CLI (command line interface).

Login to AWS account –> Services (tab on top) –> EFS –> Create file system (tab) –> (This opens a dialog box)


Name –> test-config-files (you can give any name appropriate for your setup and can be easily identified)

VPC –> Choose the appropriate VPC from the drop-down box)

Storage class –> Standard (standard stores data across multiple availability zones)

                                One Zone (stores data in a single availability zone)

Create –> (click the create tab)



This creates an EFS as shown below.



Before mounting the EFS on an EC2 instance, ensure that port “2049″ of type=NFS is enabled on the security group attached to the EC2 instance.



However, to use this EFS, we need to mount this on a directory in the EC2 instance.

The command to mount the EC2 instance can be obtained from the EFS console:

Elastic File System –> File systems > test-config-file (Click on the file system created above) –>  Attach (tab on the top right)



Step2: Mount the EFS on the EC2 instance


Login to the EC2 instance.

Prior to mounting the EFS, ensure that the “nfs” utility is installed in the system:

If not then in in CentOS-7 or Ubuntu install nfs utility


On CentOS-7


    • $ sudo yum install -y nfs-utils


On Ubuntu


    • $ sudo apt install nfs-common -y



The EFS can be mounted in any directory. However, you need to ensure that the correct user permissions are assigned to the directory. We will create a directory “test” and mount the EFS on this directory.


    • $ cd ~
    • $ pwd

Output –> /home/jenkins

    • $ mkdir test


Now we will mount the EFS on this directory. The below command is obtained from the EFS console, ONLY the directory name is changed to what we want to mount it on. The mount command is taken from the screenshot in Step 1.


    • $ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport test


IMPORTANT: Ensure that when mounting the directory on the EFS “/” the forward slash is not included in the mount command. ONLY the directory name should be used, or else the EFS will not get mounted and the command will be unresponsive.


Once mounted you can check the status by using the below command


    • $ df -k


Output should be as below: 9007199254739968       0 9007199254739968   0% /home/jenkins/test


The output shows the EFS is mounted on the test directory. Now all the data (files or directories stored on the directory “test” will automatically be stored on the EFS. The same EFS can be mounted on another EC2 instance, and that way data across 2 instances can be stored using a common storage)


The above mounting is temporary and valid till the instance is rebooted, once the instance is rebooted, EFS will get unmounted.


To mount the EFS permanently on the EC2 instance, you need to update the “/etc/fstab” file.


    • $ vi /etc/fstab


Make the below entry in the “/etc/fstab” file. Provide the complete path of the directory on which the EFS is to mounted, as highlighted below. Again ensure that there is no “/” forward slash at the end of the directory. /home/jenkins/test      nfs4    defaults        0 0


Save the “/etc/fstab” file.

Now even after a reboot the EFS will be mounted on the “test” directory.

If now you take an AMI of the above instance and launch a new instance with that AMI, the EFS will be mounted on the “test” directory.


Unmounting the EFS from the EC2 instances.


To un-mount the EFS from the EC2 instance’s directory, use the below command:


    • $ sudo umount test


We will use the shared storage (EFS) across nodes (Master and Worker) so that we can deploy our Kubernetes applications. 


This completes the tutorial of creating an EFS and mounting it on an EC2 instance. The data stored on this EFS can now be shared across instances.