Financial Services Spotlight – Amazon Elastic File System

In this edition of the Financial Services Industry (FSI) Services Spotlight monthly series, we highlight five key considerations for customers running workloads on Amazon Elastic File System (Amazon EFS) to achieve compliance, data protection, isolation of compute environments, audits with APIs, and access control and security. Across each area, we examine specific guidance, suggested reference architectures, and technical code to help streamline service approval of Amazon EFS.

Amazon EFS is a serverless, fully-elastic file storage that lets you share file data and automatically scale from gigabytes to petabytes of data without needing to provision or manage storage capacity. It delivers low-latency performance for a wide variety of workloads and can scale to thousands of concurrent clients or connections.

Amazon EFS is highly durable and available, and supports full file system access semantics, such as strong consistency and file locking. You can access Amazon EFS file systems through a file system interface, using standard operating system file I/O APIs, from AWS compute services such as Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon container services (Amazon Elastic Container Service Amazon (ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Fargate), and AWS Lambda functions.

You can use replication to automatically maintain copies of your Amazon EFS file systems within a single AWS Region or between two AWS Regions, for business continuity or to meet compliance requirements as part of your disaster recovery strategy.

Additionally, Amazon EFS Intelligent-Tiering optimizes costs by moving individual files between a performance-optimized storage class and a cost-optimized storage class based on file access patterns. Amazon EFS Standard storage classes are ideal for workloads that require the highest levels of durability and availability. Amazon EFS One Zone storage classes are ideal for workloads such as development, build, and staging environments. They are also ideal for analytics, simulation, and media transcoding, and for backups or replicas of on-premises data that don’t require Multi-Availability Zone (AZ) resilience.

Amazon EFS use cases in FSI

Amazon EFS provides performance for a broad spectrum of workloads and applications: big data and analytics, machine learning (ML) inference, media processing workflows, content management, web serving, and home directories.

With Amazon EFS, Discover Financial Services could easily provide shared access across data science tools, projects, and datasets for more seamless collaboration. According to Keith Toney, Discover’s Chief Data Officer, Amazon EFS automatic scaling allowed Discover to cut storage management time by 90%, and costs by 50–60%. Amazon EFS has enabled Discover’s data scientists to focus on insights instead of technology.

Capital One uses Amazon EFS to store hundreds of terabytes and run analytics, backup, and ML workloads, including one of their heaviest analytics workloads. Amazon EFS Intelligent-Tiering gives Capital One additional, lower cost options for workloads with changing access patterns. Amazon EFS helps Capital One focus on innovating for their customers instead of managing file storage infrastructure.

Achieving compliance

Amazon EFS is an AWS managed service, and third-party auditors regularly assess the security and compliance of it as part of multiple AWS compliance programs. As part of the AWS shared responsibility model, Amazon EFS is in the scope of the following compliance programs.

SOC 1,2,3
PCI
ISO/IEC 27001:2013, 27017:2015, 27018:2019, 27701:2019, 22301:2019, 9001:2015, and CSA STAR CCM v4.0
ISMAP
FedRAMP (Moderate and High)
DoD CC SRG (IL2-IL6)
HIPAA
IRAP
MTCS (Regions: US-East, US-West, Singapore, Seoul)
C5
K-ISMS
ENS High
OSPAR
HITRUST CSF
FINMA
GSMA (Regions: US-East (Ohio) and Europe (Paris))
PiTuKri
CCCS Medium
GNS National Restricted Certification
IAR
DESC CSP

You can obtain corresponding compliance reports under an AWS non-disclosure agreement (NDA) through AWS Artifact. Amazon EFS compliance status doesn’t automatically apply to applications that you run in the AWS Cloud. You must make sure that your use of AWS services complies with the standards.

Your scope of the shared responsibility model when using Amazon EFS is determined by the sensitivity of your data, your organization’s compliance objectives, and applicable laws and regulations. If your use of Amazon EFS is subject to compliance with standards like HIPAA, PCI, or FedRAMP, then AWS provides resources to help.

Data protection

At AWS, we recommend that encryption is applied to complement other access controls already in place. Data protection refers to protecting data at rest (while it’s stored on disks in Amazon EFS data centers) and while in-transit (as it travels to and from Amazon EFS). You can enable encryption of data at rest when creating an Amazon EFS file system. You can enable encryption of data in transit when you mount the file system.

Encrypting data at rest: In an encrypted file system, data and metadata are automatically encrypted before being written to the file system and are automatically decrypted before being presented to the application. Amazon EFS uses the industry-standard AES-256 encryption algorithm to encrypt Amazon EFS data and metadata at rest. Amazon EFS uses the AWS managed key for Amazon EFS (aws/elasticfilesystem) to encrypt and decrypt file system metadata. To encrypt the file data at rest, you can use AWS managed key for Amazon EFS. However, it’s recommended that you use a customer managed key (CMK). CMK lets you configure key policies and grants for multiple users or services.

Encrypting data in transit: You can enable encryption of data in transit for the Amazon EFS file system by enabling Transport Layer Security (TLS) when mounting the file system using the Amazon EFS mount helper, which uses TLS version 1.2 to communicate with your file system. The mount helper initializes a client stunnel (an open source multipurpose network relay) process. The client stunnel process listens on a local port for inbound traffic, and the mount helper redirects Network File System (NFS) client traffic to this local port.

Isolation of compute environments

To access your Amazon EFS file system in a VPC, create one or more mount targets in the VPC through the Network File System versions 4.0 and 4.1 (NFSv4) protocol. Specify security groups for your Amazon EC2 instances and security groups for the Amazon EFS mount targets associated with the file system. An Amazon EFS file system can only have mount targets in one VPC at a time. For Amazon ECS instances, AWS recommends using a current generation Linux NFSv4.1 client, such as those found in the latest Amazon Linux, Amazon Linux 2, Red Hat, Ubuntu, and macOS Big Sur AMIs. This is done in conjunction with the Amazon EFS mount helper. For instructions, see Using the amazon-efs-utils Tools. Using Amazon EFS with Microsoft Windows–based Amazon EC2 instances isn’t supported.

For file systems using Standard storage classes, create a mount target in each AZ in the Region. As depicted in the following figure, the VPC has three AZs. AWS recommends that you access the file system from a mount target within the same AZ for performance and cost reasons. Because one of the AZs has two subnets, create a mount target in one of the subnets. Then, all EC2 instances in that AZ share that mount target.

Figure 1: Amazon EFS with Standard storage classes

For file systems using One Zone storage classes, create only a single mount target in the same AZ as the file system. The following figure shows a VPC that has two AZs, each with one subnet. The file system uses One Zone storage classes, so it can only have a single mount target. For better performance and cost, AWS recommends that you access the file system from a mount target in the same AZ as the EC2 instance on which you’re mounting it.

Figure 2: Amazon EFS with One Zone storage classes

An Amazon EFS file system can provide a common data source for workloads and applications that are running on more than one compute instance or server. Access Amazon EFS from multiple AWS services:

Containerized applications launched by Amazon ECS, using both Amazon EC2 and Fargate launch types, by referencing an Amazon EFS file system in your task definition.
Containerized applications launched by Amazon EKS, with either Amazon EC2 or Fargate launch types, using the Amazon EFS CSI driver.
Functions running in Lambda by referencing an Amazon EFS file system in your function settings.
Amazon SageMaker training jobs by referencing an Amazon EFS file system in your CreateTrainingJob request. Amazon EFS is also automatically used for home directories created by SageMaker Studio.

On-premises access

Mount your Amazon EFS file systems on your on-premises data center servers when connected to your Amazon Virtual Private Cloud (Amazon VPC) with AWS Direct Connect or AWS Client VPN. You can mount your Amazon EFS file systems on on-premises servers to migrate datasets to Amazon EFS, enable cloud bursting scenarios, or back up your on-premises data to Amazon EFS.

As shown in the following figure, you can use any mount target in your VPC if you can reach that mount target’s subnet by using an Direct Connect connection between your on-premises server and VPC. To access Amazon EFS from an on-premises server, add a rule to your mount target security group to allow inbound traffic to the NFS port (2049) from your on-premises server.

Figure 3: Mount Amazon EFS file system on on-premises servers

Access your Amazon EFS file system concurrently from servers in your on-premises datacenter as well as EC2 instances in your Amazon VPC. Amazon EFS provides the same file system access semantics, such as strong data consistency and file locking, across all EC2 instances and on-premises servers accessing a file system.

Note the following considerations when using Amazon EFS with an on-premises server:

Your on-premises server must have a Linux-based operating system. AWS recommends Linux kernel version 4.0 or later.
For simplicity, AWS recommends mounting an Amazon EFS file system on an on-premises server using a mount target IP address instead of a DNS name.

VPC endpoints

Interface VPC endpoints are powered by AWS PrivateLink, a feature that enables private communication between AWS services using private IP addresses. To use PrivateLink, create an interface VPC endpoint for Amazon EFS in your VPC using the Amazon VPC console, Amazon API Gateway, and AWS Command Line Interface (AWS CLI). Doing this creates an elastic network interface in your subnet with a private IP address that serves Amazon EFS API requests. You can also access a VPC endpoint from on-premises environments or from other VPCs using AWS VPN, Direct Connect, or VPC peering. To learn more, see Accessing Services Through AWS PrivateLink in the Amazon VPC User Guide.

Access points

An EFS Access Point is a network endpoint that users and applications can use to access an Amazon EFS file system and enforce file- and folder-level permissions (POSIX) based on fine-grained access control and policy-based permissions defined in AWS Identity and Access Management (IAM). Amazon EFS Access Points gives you the flexibility to create and manage multi-tenant environments for your file applications in a cloud-native way, thus helping you simplify data sharing. Amazon EFS Access Points integrates with IAM to enable cloud native applications to use POSIX-based shared file storage. Use cases that can benefit from Amazon EFS Access Points include container-based environments where developers build and deploy their own containers, data science applications that require access to production data, and sharing a specific directory in your file system with other AWS accounts. For more information, see Working with Amazon EFS access points.

Automating audits with APIs

AWS Config monitors the configuration of resources and can send alerts in the case that resources fall into a non-compliant state. The service provides the ability to use predefined AWS-managed rules or define custom Lambda-based rules to monitor access logs and different security configurations. Here are some examples of AWS-managed rules:

Besides managed rules in AWS Config, customers can build custom Config rules using API calls related to Amazon EFS recorded by AWS CloudTrail. CloudTrail is an AWS service that helps customers enable governance, compliance, and operational and risk auditing of their AWS accounts. CloudTrail provides an aggregated repository of API Gateway calls and changes to many AWS services. CloudTrail records API calls made to the Amazon EFS service. For a complete list of Amazon EFS APIs, you can review the Amazon EFS API References. The following is an example of what a CloudTrail log looks like for the CreateDistribution API:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AKIAIOSFODNN7EXAMPLE",
        "arn": "arn:aws:iam::123456789012:user/johndoe",
        "accountId": "123456789012",
        "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
        "userName": "johndoe"
    },
    "eventTime": "2023-02-12T21:42:08Z",
    "eventSource": "elasticfilesystem.amazonaws.com",
    "eventName": "CreateFileSystem",
    "awsRegion": "eu-west-1",
    "sourceIPAddress": "192.0.2.0",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36",
    "requestParameters": {
        "creationToken": "quickCreated-xcf223-asd12-1122-qw12-a12313a",
        "encrypted": true,
        "throughputMode": "bursting",
        "tags": [
            {
                "key": "Name",
                "value": "EFSSpotlightDemo"
            }
        ]
    },
    "responseElements": {
        "ownerId": "1234567891111",
        "creationToken": "quickCreated-ff6acd5f-976e-4953-9b2e-a64126010515",
        "fileSystemId": "fs-069ead71c2ff68bad",
        "fileSystemArn": "arn:aws:elasticfilesystem:eu-west-1:1234567891111:file-system/fs-069ead71c2ff68bad",
        "creationTime": "Feb 12, 2023, 9:42:08 PM",
        "lifeCycleState": "creating",
        "name": "EFSSpotlightDemo",
        "numberOfMountTargets": 0,
        "sizeInBytes": {
            "value": 0,
            "valueInIA": 0,
            "valueInStandard": 0
        },
        "performanceMode": "generalPurpose",
        "encrypted": true,
        "kmsKeyId": "arn:aws:kms:eu-west-1:1234567891111:key/1e7b72eb-0a59-4c9a-bf38-71f2b25ac95c",
        "throughputMode": "bursting",
        "tags": [
            {
                "key": "Name",
                "value": "EFSSpotlightDemo"
            }
        ]
    },
    "requestID": "c027c396-9416-ed9c-4ffd-724e19e4",
    "eventID": "724e19e4-ed9c-4ffd-9416-c027c396",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "apiVersion": "2015-02-01",
    "managementEvent": true,
    "recipientAccountId": "123456789012",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "elasticfilesystem.eu-west-1.amazonaws.com"
    },
    "sessionCredentialFromConsole": "true"
}

AWS Audit Manager helps FSI customers continuously audit their AWS usage and simplify how they assess risk and compliance with regulations and industry standards. Audit Manager collects and organizes the evidence by selected frameworks, such as PCI-DSS, SOC 2, and GDPR from different sources (including CloudTrail) to compare the environment’s configurations against the compliance controls. Audit Manager saves time with an automated collection of evidence and provides audit-ready reports for customers to review. Moreover, these reports use cryptographic verification to make sure of their integrity.

Operational access and security

AWS customers in FSI care deeply about privacy and data security. That’s why AWS gives you ownership and control over your content through simple, powerful tools that let you determine where your content will be stored, secure your content in transit and at rest, and manage your access to AWS services and resources for your users. AWS has developed a security assurance program that uses best practices for global privacy and data protection to help you operate securely within AWS, and to best utilize the AWS security control environment. These security protections and control processes are independently validated by multiple third-party independent assessments. You can review third-party auditor reports, such as the AWS SOC 2 Type II report, ISO 27001, and others, in AWS Artifact.

IAM

Amazon EFS supports both IAM identity-based policies and resource-based policies.

Identity-based policies determine whether someone can create, access, or delete Amazon EFS resources in your account. Then, the administrator attaches those policies for users that require them. When granting permissions with IAM policies, follow the principle of least-privilege to grant permission only for the specific task and use conditions in the policies to further restrict access. The following example shows an example of an identity-based policy that authorizes principals to create Amazon EFS file systems that are encrypted. If the user, to whom this policy is attached, tries to create an unencrypted file system, then the request fails.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "elasticfilesystem:CreateFileSystem",
            "Condition": {
                "Bool": {
                    "elasticfilesystem:Encrypted": "true"
                }
            },
            "Resource": "*"
        }
    ]
}

Resource-based policies are JSON policy documents that you attach to a resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must specify a principal in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services. Here is an example of a resource-based policy that grants read and write access to a specific AWS role:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/Testing_Role"
            },
            "Action": [
                "elasticfilesystem:ClientWrite",
                "elasticfilesystem:ClientMount"
            ],
            "Resource": "arn:aws:elasticfilesystem:us-east-2:111122223333:file-system/fs-1234abcd",
            "Condition": {
                "Bool": {
                    "elasticfilesystem:AccessedViaMountTarget": "true"
                }
            }
        }
    ]
}

Security groups

An Amazon EFS mount target has a security group that acts as a virtual firewall controlling the traffic to and from the mount target and determining which clients can access the Amazon EFS file system. If you don’t provide a security group when creating a mount target, then Amazon EFS associates the default security group of the VPC with it.

To enable traffic between an EC2 instance and a mount target, you must configure the following rules in these security groups:

The security groups that you associate with a mount target must allow inbound access for the TCP protocol on the NFS port (2049) from all EC2 instances on which you want to mount the file system.
Each EC2 instance that mounts the file system must have a security group that allows outbound access to the mount target on the NFS port (2049).

To access a mount target from your Amazon ECS tasks, create a security group for your mount target that contains an inbound rule referencing the security group of your cluster. To enable traffic between the Amazon EKS container instances and a mount target, create an inbound rule that allows inbound NFS traffic from the CIDR for your Amazon EKS cluster’s VPC. To further restrict access to your file system, use the CIDR for your subnet instead of the VPC. To let Lambda functions access an Amazon EFS file system, you must configure the function to access resources in a VPC. Then, you must make sure that NFS traffic (port 2049) is allowed by the security groups used by the functions and mount targets. If you must access the mount target from an on-premises client, then add an inbound rule to the mount target’s security group and set as a custom source the IP address (CIDR range) of your on-premises client.

File system policies/NFS

Amazon EFS provides the close-to-open consistency semantics that applications expect from NFS. It supports the same file-level permissions and access control mechanisms that are used in traditional NFS environments. In particular, it uses Unix-style permissions and ownership to control access to file system objects. By default, only the root user has read, write, and execute permissions. Other users must be explicitly granted access. Amazon EFS uses numeric identifiers to represent file ownership and check permissions when a user attempts to access a file system object. There are two options for how a client can mount the Amazon EFS file system: with or without Amazon EFS access points. If the client mounts an Amazon EFS file system without using an access point, then the user ID and group ID provided by the client is trusted. If the client mounts Amazon EFS through access points, then the original user ID and group IDs used by the NFS client can be overwritten. Furthermore, these user ID and group IDs are used to verify access permissions to the objects. Amazon EFS caches file permissions for a small time period. Therefore, there might be a small window where a user whose access was revoked recently can still access that object.

Conclusion

In this post, we reviewed Amazon EFS, highlighting essential information that can help FSI customers accelerate the service’s approval within these five categories: achieving compliance, data protection, isolation of computing environments, automating audits with APIs, and operational access and security. Although not a one-size-fits-all approach, the guidance can be adapted to meet the organization’s security and compliance requirements.

Make sure to visit the FSI Service Spotlight Series to learn how FSI customers are using other AWS services from a security lens. You may also find the following additional resources useful:

AWS Security Documentation
The security documentation repository shows how to configure AWS services to help meet security and compliance objectives. Cloud security at AWS is the highest priority. AWS customers benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations.
AWS Compliance Center
The AWS Compliance Center is an interactive tool that provides customers with country-specific requirements and any special considerations for cloud use in the geographies in which they operate. The AWS Compliance Center has quick links to AWS resources to help with navigating cloud adoption in specific countries, and it includes details about the compliance programs that are applicable in these jurisdictions. The AWS Compliance Center covers many countries, and more countries continue to be added as they update their regulatory requirements related to technology use.
AWS Well-Architected Framework and AWS Well-Architected Tool
The AWS Well-Architected Framework helps customers understand the pros and cons of decisions they make while building systems on AWS. The AWS Well-Architected Tool helps customers review the state of their workloads and compares them to the latest AWS architectural best practices. For more information about the AWS Well-Architected Framework and security, see the Security Pillar – AWS Well-Architected Framework whitepaper. For best practices for FSIs, see the Financial Services Industry Lens – AWS Well-Architected Framework.

If you have feedback about this post, then submit comments in the Comments section. Thank you.

Related resources:
AWS financial services cloud computing

AWS for Industries