Using Amazon EFS with Encryption in Transit on EKS Fargate: A Secure Approach to Serverless Kubernetes

As organizations adopt Amazon EKS on Fargate for its simplicity and scalability, ensuring secure data access becomes critical—especially when applications require shared persistent storage.

In Fargate environments, where you don't manage the worker nodes, using Amazon EFS is a natural choice for persistent storage. But what about security? How do you ensure that the data moving between your pods and EFS is encrypted in transit?

Developers define compute resources per Kubernetes pod and are only billed for what’s provisioned. On Fargate, each pod runs in its own isolated runtime with dedicated CPU, memory, storage, and networking—ensuring strong workload isolation and enhanced security.

Since containers are ephemeral and stateless by nature, many Ananta Cloud customers have requested persistent and shared storage options for Fargate-based workloads. While EFS support for Fargate on ECS launched in 2020, demand for similar capabilities with EKS has continued to grow. Now, Amazon EFS is fully supported on EKS Fargate, enabling secure, stateful workloads.

Amazon EFS offers a scalable, fully managed shared file system that stores data across multiple Availability Zones, ensuring high availability and durability. It automatically scales with usage and eliminates capacity planning. With EFS Access Points and encryption for data at rest and in transit, it’s ideal for security-sensitive workloads.

Kubernetes supports the Container Storage Interface (CSI) standard, and the EFS CSI driver simplifies storage integration. Previously, EFS required EC2 worker nodes with manually installed CSI drivers. With this update, EKS on Fargate supports EFS natively, without installing the CSI driver—making setup faster and easier.

The EFS CSI driver handles automatic reconnection of volumes, even across AZs. On Fargate, it’s fully managed within the platform, enabling access to EFS through standard Kubernetes APIs with encryption in transit enabled by default.

In this blog post, we’ll explore how to mount EFS volumes with encryption in transit on EKS Fargate, with a real-world Kubernetes example. You’ll also learn how Ananta Cloud helps organizations design and deploy secure, serverless Kubernetes platforms on AWS.

Why Use EFS with EKS Fargate?

Fargate abstracts the infrastructure layer—you don't have to provision or manage EC2 nodes. But persistent storage is still a requirement for many workloads:

• Content management systems

• Shared cache or scratch space

• ML pipelines

• Log aggregation or file-based config

Amazon EFS offers:

• NFS-based shared storage

• High availability and scalability

• Native integration with EKS Fargate

• Encryption at rest and in transit

And best of all, no need to install the CSI driver on Fargate—AWS handles it for you behind the scenes.

How Encryption in Transit Works on EFS

When a pod running on EKS Fargate mounts an EFS volume with encryption in transit enabled, the underlying system:

• Uses the Amazon EFS mount helper with stunnel to establish a TLS 1.2 connection to the EFS mount target.

• Automatically encrypts all data flowing between the pod and the EFS file system.

• Keeps this process transparent to your application.

This provides end-to-end encryption for your data without changing any code.

Prerequisites

Before deploying, ensure:

• An existing EFS file system in your AWS account.

• A mount target in the same VPC and subnet(s) used by your EKS Fargate profile.

• The Fargate pods are configured with access to mount EFS (via IAM and security groups).

• You are using Access Points for scoped access (recommended).

Example: Mounting an Encrypted EFS Volume on EKS Fargate

Here’s a real Kubernetes manifest for EKS on Fargate that mounts an EFS volume with encryption in transit enabled.

1. Create an EFS File System

Create via AWS Console or CLI. Make sure:

• It's in the same region and VPC as your EKS cluster.

• You create a Mount Target in each subnet used by your Fargate profile.

• You create an Access Point (recommended).

Take note of:

• File System ID (e.g. fs-0abcd1234ef567890)

• Access Point ID (e.g. ap-0123456789abcdef0)

2. Create Storage Class

Once you create an EFS file system, you get your file system ID. You can configure the mount settings using a Kubernetes StorageClass and PersistentVolume. Here is an example of the YAML files:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: e

3. Create the Persistent Volume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-encrypted-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-0abcd1234ef567890::ap-0123456789abcdef0
    volumeAttributes:
      encryptInTransit: "true"

encryptInTransit: "true" ensures TLS is used for all communication between the pod and EFS.

4. Create the Persistent Volume Claim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-encrypted-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 5Gi
  volumeName: efs-encrypted-pv

5. Deploy a Fargate-Compatible Pod

This pod runs on Fargate and writes to the encrypted EFS volume:

apiVersion: v1
kind: Pod
metadata:
  name: efs-fargate-demo
  labels:
    application: demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo hello >> /data/hello.txt; sleep 10; done"]
      volumeMounts:
        - name: efs-storage
          mountPath: /data
  volumes:
    - name: efs-storage
      persistentVolumeClaim:
        claimName: efs-encrypted-pvc

How to Confirm Encryption is Enabled

Since you don’t have access to Fargate nodes, you can't run mount commands directly. Instead:

• Ensure encryptInTransit: "true" is present in your volumeAttributes.

• In EFS metrics or logs (via CloudWatch), observe secure mount behavior.

• Review EKS pod logs and events for successful mount activity.

Encryption is handled automatically by AWS when configured correctly — even on Fargate.

Gotchas & Tips

Issue	Recommendation
Pod stuck in Init or ContainerCreating	Ensure EFS Access Point and mount targets are reachable from Fargate subnets
Access denied	Attach correct IAM permissions using Fargate execution role
Mount timeout	Confirm port 2049 is open between Fargate pod and EFS mount target

How Ananta Cloud Can Help

Configuring secure storage for EKS Fargate is nuanced — especially when you need to balance security, cost-efficiency, and operational simplicity.

At Ananta Cloud, we specialize in:

• Designing secure-by-default Kubernetes platforms on EKS and Fargate.

• Implementing production-ready storage solutions using EFS, S3, and EBS.

• Automating deployments using Infrastructure as Code (IaC) tools like Terraform and Pulumi.

• Helping clients meet compliance requirements with best practices in encryption, IAM, and audit logging.

Whether you're building a new platform or modernizing an existing one, we’re here to help.

📞 Ready to Build Secure Serverless Kubernetes?

Let Ananta Cloud guide your EKS Fargate journey — from secure storage design to full-stack cloud-native platforms.

👉 Contact Us to book a consultation with our cloud experts.

Email: hello@anantacloud.com | LinkedIn: @anantacloud | Schedule Meeting