Definition
- Network connectivity – EFS mount targets live in a specific VPC; the Lambda's VPC must reach it via VPC peering or Transit Gateway with NFS port 2049 open.
- Authorization – the EFS file system needs a resource policy granting Account B's execution role ClientMount/ClientWrite; the execution role needs EFS client and VPC networking permissions.
- Both required – the axes fail independently: network without authorization gives access-denied; authorization without network gives timeout.
- SCP trap – Service Control Policies can only restrict, never grant permissions or create network paths.
- Role assumption trap – EFS mounting is authorized by resource policy plus network path, not by assuming a role in Account A.
Imagine Account A is National Bank of India's central records vault, and Account B is a partner branch. For a courier from the branch to read a ledger, two things must be true: there must be a physical road connecting the branch to the vault (VPC peering), AND the vault's access policy must list the courier as allowed to enter (EFS resource policy). No road means the courier cannot get there. No policy means the vault door stays locked. An SCP is the head office saying 'no branch may EVER access any vault' : it can forbid but never grant. Cross-region role assumption is a pass to a vault in a different city entirely : irrelevant.
Understanding the Concepts
What is the scenario?
Account A owns an Amazon EFS file system with statement PDFs. Account B has a Lambda function that needs to read those PDFs for fraud detection. The Lambda must mount the EFS, which requires solving two completely independent problems.
┌─────────────────────┐ ┌─────────────────────┐ │ Account A │ │ Account B │ │ │ │ │ │ ┌──────────────┐ │ │ ┌──────────────┐ │ │ │ EFS File │ │ │ │ Lambda │ │ │ │ System │ │ │ │ Function │ │ │ │ (statements) │ │ │ │ (fraud scan) │ │ │ └──────┬───────┘ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ ┌──────▼───────┐ │ VPC │ ┌──────▼───────┐ │ │ │ Mount Target │ │ Peering │ │ ENIs in VPC │ │ │ │ (VPC A) │◀──┼──────────┼──│ (VPC B) │ │ │ │ port 2049 │ │ │ │ │ │ │ └──────────────┘ │ │ └──────────────┘ │ └─────────────────────┘ └─────────────────────┘ Required: 1. Network path (VPC peering + routes + SG rules for port 2049) 2. Authorization (EFS resource policy + Lambda execution role)
Why is network connectivity required?
EFS is a network file system mounted over NFS. The mount target lives inside Account A's VPC. The Lambda in Account B must have a network path to reach that VPC over TCP port 2049.
# Step 1: Create VPC peering connection
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-aaaa1111 \
--peer-vpc-id vpc-bbbb2222 \
--peer-owner-id 222222222222 \
--peer-region ap-south-1
# Step 2: Accept the peering connection in Account A
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0123456789
# Step 3: Add routes in both VPCs
# In Account B's route table: traffic to Account A's CIDR goes through peering
aws ec2 create-route \
--route-table-id rtb-bbbb \
--destination-cidr-block 10.0.0.0/16 \
--vpc-peering-connection-id pcx-0123456789
# Step 4: Security group on EFS mount target must allow NFS from Lambda's CIDR
aws ec2 authorize-security-group-ingress \
--group-id sg-efs-mount-target \
--protocol tcp \
--port 2049 \
--cidr 10.1.0.0/16 # Account B's VPC CIDR
Why is authorization required?
Even with a perfect network path, the EFS will deny access without a resource policy. The EFS resource policy must explicitly allow Account B's Lambda execution role.
// EFS file system resource policy (attached in Account A)
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowCrossAccountMount",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:role/bank-fraud-lambda-role"
},
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite",
"elasticfilesystem:ClientRootAccess"
],
"Condition": {
"StringEquals": {
"elasticfilesystem:AccessPointArn": "arn:aws:elasticfilesystem:ap-south-1:111111111111:access-point/fsap-0abc123"
}
}
}]
}
// Lambda execution role in Account B needs these permissions
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EFSClientAccess",
"Effect": "Allow",
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite"
],
"Resource": "arn:aws:elasticfilesystem:ap-south-1:111111111111:file-system/fs-0abc123"
},
{
"Sid": "VPCAccess",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DeleteNetworkInterface"
],
"Resource": "*"
}
]
}
Why do both axes fail independently?
Network and authorization are completely separate. You cannot substitute one for the other.
| Scenario | Network | Authorization | Result |
|----------|---------|---------------|--------|
| Both correct | Peering + routes + SG | EFS policy + role perms | Mount succeeds |
| Network only | Peering + routes + SG | Missing EFS resource policy | Access denied |
| Authorization only | No peering | EFS policy + role perms | Timeout (no route) |
| Neither | No peering | No policy | Timeout |
# Test: network correct, authorization missing
$ mount -t efs fs-0abc123:/ /mnt/efs
mount.nfs4: access denied by server while mounting fs-0abc123.efs.ap-south-1.amazonaws.com:/
# Test: authorization correct, network missing
$ mount -t efs fs-0abc123:/ /mnt/efs
mount.nfs4: Connection timed out (no route to mount target)
Why do SCPs NOT solve this?
A Service Control Policy is an organization-level guardrail that sets the maximum permissions an account can have. It can only restrict, never grant.
SCP capabilities:
- Can DENY actions (restrict the maximum permissions)
- Cannot GRANT actions (cannot add permissions)
- Cannot create network routes (not a networking tool)
- Cannot modify resource policies on EFS
For cross-account EFS:
- SCP cannot grant ClientMount permission to Account B
- SCP cannot create a VPC peering connection
- SCP can only accidentally BLOCK the access if written too restrictively
Why does cross-region role assumption NOT solve this?
EFS mounting is authorized by the resource policy plus a network path, not by assuming a role in Account A. Even if the Lambda assumed a role in Account A, it would still have no network route from its own VPC.
Cross-region role assumption:
- Gives you different IAM credentials
- Does NOT change your VPC or network path
- Does NOT bypass the EFS resource policy requirement
- The Lambda's ENIs are still in Account B's VPC
- No peering = no route = timeout regardless of credentials
EFS access model:
- Network: VPC peering + NFS port 2049
- Authorization: EFS resource policy + execution role
- NOT: identity swap via role assumption
What is the complete solution?
Both network connectivity and authorization must be configured.
# Lambda configuration in Account B
Resources:
FraudScanFunction:
Type: AWS::Lambda::Function
Properties:
FunctionName: bank-fraud-scan
Runtime: java21
Handler: com.bank.fraud.Handler::handleRequest
Role: !GetAtt FraudLambdaRole.Arn
VpcConfig:
SubnetIds:
- subnet-bbbb1111
- subnet-bbbb2222
SecurityGroupIds:
- !Ref LambdaSecurityGroup
FileSystemConfigs:
- Arn: arn:aws:elasticfilesystem:ap-south-1:111111111111:access-point/fsap-0abc123
LocalMountPath: /mnt/statements
package com.bank.fraud;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import java.io.File;
public class Handler implements RequestHandler<Object, String> {
@Override
public String handleRequest(Object input, Context context) {
// EFS is mounted at /mnt/statements
File statementsDir = new File("/mnt/statements");
File[] pdfs = statementsDir.listFiles((dir, name) -> name.endsWith(".pdf"));
context.getLogger().log("Found " + (pdfs != null ? pdfs.length : 0) + " statements");
// Process statements for fraud detection...
return "Processed " + (pdfs != null ? pdfs.length : 0) + " statements";
}
}
What are common mistakes with cross-account EFS?
# WRONG: trying to fix with an SCP
"Let's add an SCP to allow cross-account EFS access."
# SCPs can only restrict. They cannot grant permissions or create network routes.
# WRONG: assuming a role in Account A
"The Lambda should assume a role in Account A to access EFS."
# EFS is not an API call -- it is a network mount. The Lambda's ENIs stay in its own VPC.
# CORRECT: VPC peering + EFS resource policy + execution role permissions
# Both the network path AND the authorization must be configured.
Visual Overview
Cross-Account EFS Access: Two Axes
=====================================
Authorization
(EFS policy + role)
│
Denied ─────┼───── Granted
│ │ │
No route ──┤ TIMEOUT ACCESS ──── Network
│ DENIED (peering)
│ │ │
Route ───┤ ACCESS SUCCESS ─── Both
│ DENIED ── correct
Complete Solution
==================
Account A Account B
┌──────────────┐ ┌──────────────┐
│ EFS │ │ Lambda │
│ + Resource │ │ + Exec Role │
│ Policy │ │ (EFS + │
│ (allows │ │ VPC perms)│
│ Acct B │ │ │
│ role) │ │ + VPC Config │
├──────────────┤ VPC Peering ├──────────────┤
│ Mount Target │◀═════════════════▶│ Lambda ENIs │
│ SG: allow │ port 2049 │ │
│ 2049 from B │ │ │
└──────────────┘ └──────────────┘
Why traps fail:
SCP: Can only DENY, not GRANT or build network
Role assumption: Changes credentials, not VPC/network path
Key Takeaway
Letting a Lambda in Account B use an EFS owned by Account A requires solving two completely independent problems simultaneously. The first is network connectivity: the EFS mount target lives in Account A's VPC, so Account B's Lambda needs VPC peering with routes and security groups allowing NFS on port 2049. The second is authorization: the EFS needs a resource policy allowing Account B's execution role, and that role needs EFS client and VPC networking permissions.
The axes fail independently and cannot substitute for each other. Perfect authorization with no peering results in a timeout because there is no route. Perfect peering with no resource policy results in access denied. Both must be correct.
The two tempting wrong answers are SCPs and cross-region role assumption. SCPs can only restrict, never grant, so they cannot add permissions or build network routes. Role assumption changes credentials but does not change the Lambda's VPC, so the mount still times out with no route. EFS is fundamentally a VPC-scoped, NFS-mounted resource, so cross-account access is always a networking-plus-resource-policy exercise.
Remember one sentence: cross-account EFS needs both a network path (VPC peering plus NFS port 2049) and authorization (EFS resource policy plus execution role), and neither SCPs nor role assumption can substitute for either.
---