Fix AWS Lambda EFS Mount Failed (EFSMountFailureException): Subnet, AZ & Security Group Causes

If your Lambda function is throwing "EFSMountFailureException," "EFSMountConnectivityException," or "EFSMountTimeoutException," the fix almost never involves touching Amazon EFS itself — it's nearly always the IAM permissions on the function's execution role, the security group rules between Lambda and EFS, or a root directory inside the access point that was never actually created. Here's the reveal that trips up most people: Lambda will report a generic mount failure even when the real problem is a folder that silently doesn't exist, and AWS CloudTrail won't log anything useful about it either — the failure just looks identical to a permissions problem from the outside.

Which Error Are You Actually Staring At?

Jake called me from his shop counter, phone wedged between his ear and shoulder, trying to read an error out loud while a customer waited for a repair quote. "It says EFS Mount Failure Exception, and then a bunch of letters and numbers I definitely got wrong." That's the first thing to sort out — AWS Lambda doesn't give you one generic "EFS mount failed" error. It gives you one of three, and each one points to a completely different part of your setup.

The three exceptions are EFSMountFailureException, EFSMountConnectivityException, and EFSMountTimeoutException. There's also a fourth error, EFSIOException, that shows up after a mount succeeds, when the file system runs out of gas mid-invocation. Before you touch a single setting, find out which one of these four you're actually looking at in your CloudWatch Logs — it changes everything about where you should be spending your next ten minutes.

EFSMountFailureException: the Mount Request Got Rejected

This is the most common of the four errors, and it's a permissions story almost every time. Lambda's own documentation describes it plainly: the mount request to the function's file system was rejected, and you should check the function's permissions and confirm the file system and access point exist and are ready for use. The exact error text looks like this in your logs:

EFSMountFailureException: The function could not mount the EFS file system with access point arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd.

Notice what that message does not tell you: it doesn't say whether it's a permissions problem, a missing access point, or a missing folder inside the file system. That's genuinely one of the more frustrating things about this error — three completely different root causes produce the exact same wording, so you have to work through a checklist rather than trust the message to point you at the fix.

The execution role permissions your function actually needs

Your Lambda function runs under an execution role — think of it as the function's ID badge. It's a set of permissions attached to an IAM role (IAM is AWS's system for deciding who can do what; imagine it as the building's access-card system, deciding which doors each badge opens) that AWS checks every single time your code tries to touch another AWS service. For EFS, two specific permissions matter:

1. elasticfilesystem:ClientMount — required for every connection, read-only or read-write. Without this, the mount is rejected before your code even runs.
2. elasticfilesystem:ClientWrite — required only if your function writes to the file system. If you're only reading files (like loading a shared machine learning model or a reference dataset), you can skip this one and keep the role tighter.

Both of these are bundled together in the AWS managed policy AmazonElasticFileSystemClientReadWriteAccess, which is the fastest way to get unblocked while you're troubleshooting — attach it, confirm the mount works, then tighten the policy down to a custom one scoped to your specific access point ARN once you know the fix actually solves it.

There's a second, separate permission for the person setting it up

Here's a wrinkle that catches people who copy IAM policies between team members: the permission your function's role needs to mount EFS at runtime is different from the permission your own IAM user needs to configure the connection in the console or CLI in the first place. To attach a file system to a function, your own IAM user needs elasticfilesystem:DescribeMountTargets. Miss that one and you won't even get as far as deploying the broken configuration — the console will refuse to save the file system connection, or the CLI call to update-function-configuration will fail with an access-denied error before your function ever attempts a mount.

When the file system has its own IAM policy attached

Amazon EFS has an interesting default: if the file system doesn't have a user-configured IAM policy of its own, EFS falls back to a default policy that grants full access to any client that can connect through a mount target. That's convenient for testing but loose for production. The moment someone attaches a custom IAM policy directly to the file system — which is common in shared or multi-team accounts, to lock a file system down to specific roles — your execution role's permissions have to line up with both the Lambda-side permissions above and whatever the file system's own resource policy allows. If someone on your team recently tightened the file system's resource policy, that's worth checking before you assume the problem lives entirely on the Lambda side.

The Silent Killer: a Root Directory That Was Never Created

This is the counterintuitive part, and it's worth its own section because it wastes more troubleshooting time than any other single cause. When you create an EFS access point — an application-specific entry point into a file system, scoped to a single path and a specific operating-system user and group, so your application code doesn't need to know the full file system layout — you can optionally tell EFS to automatically create the root directory the first time something connects, and set its ownership and permissions at the same time. If you leave that "creation info" blank and the folder you pointed the access point at doesn't already exist, EFS will not create it for you.

When that happens, your Lambda function's attempt to mount fails, and you'll see the exact same EFSMountFailureException you'd see for a permissions problem. There's no separate error message, no distinguishing detail, and critically — nothing shows up in AWS CloudTrail to flag it, because from AWS's perspective the request was valid and simply had nowhere to attach.

How to check it

Open the Amazon EFS console, go to your file system, and look at the access point your Lambda function connects through. You're checking two things: the root directory path (the folder inside the file system this access point points at) and whether "creation info" is filled in with an owner user ID, group ID, and permissions. If the path points at a folder that doesn't exist yet, and creation info is empty, that's your problem — and it's an easy one to fix.

Confirmed working access point configurations, drawn from AWS's own troubleshooting guidance, generally fall into two shapes: either the root directory already exists and you leave the POSIX user blank, or the directory doesn't exist yet and you fill in creation info with a specific owner UID and GID (a numeric user ID and group ID, the same identifiers Linux systems use — 1000:1000 is a common non-root default) plus a permissions value like 755 or 777. What consistently does not work is pointing at a directory that doesn't exist while leaving creation info blank and specifying a POSIX user — that combination fails every time, because EFS has a user to apply but no folder to apply it to and no instruction to build one.

"Permission Denied" on Writes Even Though the Mount Succeeded

Ethan's take on this one is blunt: "If your mount succeeds but every write bounces back with Permission denied, stop looking at Lambda entirely — you're looking at a Linux file-permissions problem wearing an AWS costume." This is a different failure from the three exceptions above; the mount itself works, your function can see the directory, but any attempt to create or modify a file fails.

The cause is almost always a missing or mismatched POSIX user on the access point. If you require write operations from a Lambda function to an EFS-mounted path, you have to provide POSIX user information on the access point — the user ID and group ID Lambda should present itself as when it touches files. Skip that, and write operations fail with Permission denied, even though the underlying elasticfilesystem:ClientWrite IAM permission is correctly attached to your execution role. IAM decides whether Lambda is allowed to attempt the write at the AWS level; the POSIX user and file permissions decide whether that write actually succeeds at the Linux file-system level. They're two separate gatekeepers, and passing one doesn't get you past the other.

EFSMountConnectivityException: Lambda Can't Even Reach EFS

This one's a networking error, plain and simple — and it's a different animal from EFSMountFailureException, so don't go chasing IAM permissions here. The message reads:

EFSMountConnectivityException: The function couldn't connect to the Amazon EFS file system with access point arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd. Check your network configuration and try again.

Amazon's own explanation is direct about what's happening under the hood: your function couldn't establish a connection to the file system using the NFS protocol on TCP port 2049. NFS (Network File System) is the underlying protocol EFS uses to let a remote server act like a local folder — think of port 2049 as a specific, dedicated doorway that traffic has to pass through, and if anything blocks that doorway, the connection never opens no matter how correct your permissions are.

The security group checklist

Lambda functions that connect to a VPC (Virtual Private Cloud — your own private, isolated network inside AWS, the same way a company office has its own internal network that outsiders can't just wander into) do so through elastic network interfaces attached to specific subnets, and traffic between those interfaces and your EFS mount targets is controlled by security groups — virtual firewalls attached to each resource. Two rules have to exist, in two different places, for the connection to succeed:

1. On the EFS file system's security group — allow inbound NFS traffic (port 2049) from the Lambda function's security group, or from the specific CIDR range (the block of IP addresses) of the VPC subnets your function uses.
2. On the Lambda function's security group — allow outbound NFS traffic to the EFS file system's security group or IP range.

People very often set up one of these two rules and forget the other, because it's intuitive to think of "allowing access" as a single, one-directional setting. It isn't. A security group rule that lets EFS receive traffic from Lambda does nothing if Lambda's own security group is quietly blocking that traffic from leaving in the first place.

Mount targets and Availability Zones

An EFS file system needs a mount target — the actual network endpoint the NFS protocol connects to — in every Availability Zone (AZ, a physically separate data center cluster within an AWS Region) that your Lambda function's VPC configuration uses. For performance and resilience, AWS recommends spreading your function across at least two Availability Zones, each with its own mount target, rather than relying on a single AZ. If your Lambda function is configured to run in a subnet in an AZ where no mount target exists, connectivity fails outright — this looks identical to a security group misconfiguration from the error message alone, so it's worth confirming mount targets exist everywhere your function's subnets do.

If this started right after a VPC configuration change

If EFSMountConnectivityException started appearing right after you updated your function's VPC settings — a new subnet, a new security group, moving to a different VPC entirely — AWS's own guidance is to try unmounting and remounting the file system rather than assuming your new configuration is wrong. Lambda execution environments can, for a short window after a VPC change, still be running on network interfaces tied to the old configuration. Deploying a trivial update to the function (even just touching an environment variable) forces new execution environments to spin up against the current network settings.

EFSMountTimeoutException: Connected, but the Mount Itself Stalled

This is the error people misdiagnose most often, because it sounds exactly like a network problem and isn't quite one. Here's the message:

EFSMountTimeoutException: The function could not mount the EFS file system with access point {arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd} due to mount timeout.

The key distinction: with this error, the function could connect to the file system — networking, security groups, and routing are all fine — but the mount operation itself didn't complete in time. AWS's own guidance for this one is refreshingly simple: try again after a short time, and consider limiting the function's concurrency to reduce load on the file system.

That second part matters more than it looks. If you've got a Lambda function set to scale to hundreds of concurrent executions, and each one is trying to mount the same EFS file system at the same moment — say, right after a traffic spike or a cold-start storm — you can genuinely overwhelm the mounting process itself, independent of the file system's actual read/write throughput. Reserved concurrency (a setting that caps how many instances of a function can run at once) on the function, or provisioned concurrency to pre-warm a pool of ready environments, both reduce how often a burst of simultaneous cold starts tries to mount the same file system all at once.

EFSIOException: it Mounted Fine, Then Stalled Mid-Invocation

Ethan flagged this one to Jake as "the one nobody expects, because by the time you see it, everything already looked like it was working." EFSIOException happens after a successful mount, when Lambda detects an IO (input/output — a read or write operation) process taking too long and stops the affected function instance. AWS's own documentation ties this directly to a specific cause: an attached file system that has run out of burst credits, combined with baseline throughput that's insufficient for what your function is actually asking the file system to do.

Amazon EFS's default throughput mode (Bursting Throughput) earns "burst credits" over time based on the file system's size, the same way a savings account earns interest, and spends them during periods of high read/write activity. A small file system that suddenly needs to serve a lot of concurrent Lambda invocations can burn through its accumulated credits faster than it earns new ones, and once the credit balance runs dry, throughput drops back to the low baseline rate the file system's size supports — which can be slow enough that an in-flight read or write simply never finishes within your function's timeout.

AWS's documented fix is one of two moves: increase the size of the file system (larger file systems earn burst credits faster and get a higher baseline rate), or switch the file system to provisioned throughput, where you pay for a guaranteed throughput level independent of file system size or accumulated credits. If your access pattern is bursty and unpredictable, provisioned throughput removes the guesswork; if it's steady and your file system is growing anyway, letting the file system grow can be the cheaper long-term fix.

Finding the Real Error in CloudWatch Logs

Before you can act on anything above, you need to actually see the exception name, and this is where Jake got stuck on the phone. Every Lambda function writes to its own CloudWatch Logs log group, named /aws/lambda/your-function-name. That's where the full EFSMountFailureException, EFSMountConnectivityException, EFSMountTimeoutException, or EFSIOException text lands — not in whatever downstream error message an API Gateway, an application, or a customer-facing screen happens to show.

1. Open the CloudWatch console and navigate to Log groups, then find /aws/lambda/ followed by your function's exact name.
2. Open the most recent log stream — each execution environment gets its own stream, so look at the one closest in time to your failed invocation.
3. Search for "EFS" within that stream using the log search box; the exception name and the full access point ARN will appear together in one line, which also confirms you're pointed at the access point you think you are.

If you're fronting the function with API Gateway and only seeing a generic error there, check the $context.integrationErrorMessage log variable in API Gateway's own access logging — for HTTP APIs specifically, that variable can surface the underlying Lambda error without you needing to cross-reference two separate consoles.

The Full VPC and Access Point Checklist

Once you know which of the four errors you're dealing with, it's worth running the full checklist anyway before you deploy a fix — a surprising number of EFS mount issues turn out to be two small misconfigurations stacked on top of each other, not one. Here's every item worth confirming, gathered in one place:

• The Lambda function's execution role has elasticfilesystem:ClientMount, and elasticfilesystem:ClientWrite if the function writes to the file system.
• Your own IAM user or role has elasticfilesystem:DescribeMountTargets, needed just to configure the connection.
• The access point exists, is in "available" status in the EFS console, and its ARN in the Lambda function configuration matches exactly — a typo in the ARN produces the same generic mount failure as a real permissions problem.
• The access point's root directory either already exists, or "creation info" is filled in with a POSIX user, group, and permissions so EFS can create it on first mount.
• If the function writes to the file system, the access point specifies a POSIX user — without one, writes fail with Permission denied even though the mount itself succeeds.
• The Lambda function's VPC configuration includes at least one subnet in every Availability Zone where an EFS mount target exists.
• The EFS file system's security group allows inbound NFS (port 2049) from the Lambda function's security group or subnet CIDR range.
• The Lambda function's security group allows outbound NFS (port 2049) to the EFS file system's security group or IP range.
• The LocalMountPath configured on the function starts with /mnt/ — Lambda enforces this pattern and will reject a configuration that doesn't follow it.
• You're deploying in an AWS Region where EFS for Lambda is actually supported (see the region note below).

Why deployments get rejected before the function ever runs

A few items on that list aren't runtime failures at all — they're deploy-time validation, and it's worth knowing the difference because the fix is different too. The LocalMountPath is the folder path inside your function's environment where the EFS file system shows up, and Lambda validates the format of that path the moment you save the configuration, before any code executes and before any of the four mount exceptions above can even happen. Give it something like /data or /efs instead of /mnt/data, and the console or the CLI will reject the update outright with a validation error, not a mount failure — that's a different problem from everything covered above, and no amount of IAM or security group work will fix a path that doesn't start with /mnt/.

The same is true of the access point ARN itself. If you paste in an ARN for an access point that belongs to a different file system than the one you think you're connecting to, or copy an ARN with a typo, Lambda will accept the configuration at save time — ARNs aren't validated for existence against the EFS service at that point — and the failure only shows up later, at invocation, as the same generic EFSMountFailureException as a real permissions problem. That's one more reason the ARN comparison item on the checklist above is worth doing with a copy-paste rather than by eye.

The IAM Permissions Table, at a Glance

Jake's honest question here was fair: "Why are there two different sets of permissions for basically the same thing?" Because two different identities are involved — the human (or automation) setting up the connection, and the function's own role that mounts the file system at runtime every time it's invoked. Here's how they split:

All three are bundled where you'd expect: ClientMount and ClientWrite live together in the AWS managed policy AmazonElasticFileSystemClientReadWriteAccess, which is the quickest way to attach both permissions at once while you're diagnosing a mount failure.

EFS for Lambda Isn't in Every AWS Region

This one is easy to overlook if you're spinning up a new account or expanding into a Region you haven't used before. As of Amazon's own current documentation, EFS for Lambda is available in all commercial AWS Regions except Asia Pacific (New Zealand), Asia Pacific (Taipei), Asia Pacific (Malaysia), Mexico (Central), Asia Pacific (Thailand), and Canada West (Calgary). If you're deploying into one of those newer Regions and getting a mount failure that doesn't match any of the four errors above, or an outright rejection when trying to attach the file system configuration at all, confirm the feature is actually supported where you're building before assuming it's a configuration mistake on your end.

When Nothing Above Fixes It

Every fix above assumes you can identify which of IAM, the access point, or networking is the culprit by reading through settings. Sometimes, especially in accounts with multiple teams touching the same VPC, the actual network path between your function and the file system is genuinely hard to trace by eye — routing tables, network ACLs, peered VPCs, and security groups can interact in ways that aren't obvious from any single console screen.

For that case, VPC Reachability Analyzer is worth reaching for. AWS describes it as a static configuration analysis tool — it builds a model of your network configuration and checks reachability against that model, rather than actually sending test packets or inspecting live traffic. You give it a source and a destination (in this case, your Lambda function's elastic network interface and your EFS mount target's network interface), and if a path exists, it returns the hop-by-hop route; if it doesn't, it names the specific blocking component — a security group rule, a network ACL entry, or a route table gap, among others — instead of leaving you to infer it.

One constraint worth knowing before you reach for it: the source and destination have to sit in the same AWS Region, and either in the same VPC or in VPCs connected through a VPC peering connection or a transit gateway. That covers the overwhelming majority of Lambda-to-EFS setups, since AWS requires EFS mount targets to live in the same VPC as the Lambda functions that use them anyway. Reachability Analyzer won't fix IAM permissions or a missing root directory, since those aren't networking problems, but for a genuine EFSMountConnectivityException that survives a careful manual security-group review, it can save you from tracing a VPC's routing tables and network ACLs by hand, one subnet at a time.

Does Mounting EFS Slow Down Cold Starts?

"Before I even fixed the mount error, my function felt slower," Jake said. "Is that the EFS thing, or is that just me?" Ethan's answer: connecting a Lambda function to a VPC — which is required for any EFS connection, since EFS lives inside your VPC and Lambda functions outside a VPC can't reach it — used to carry a real cold-start penalty in the earlier years of Lambda. Under the old model, Lambda mapped network interfaces in your VPC directly to individual execution environments, so a genuine cold start meant creating and attaching a fresh elastic network interface before your code could run at all — slow, and it also ate into a Region's ENI limits every time a function scaled up.

AWS re-architected this with what it calls Hyperplane ENI: instead of one network interface per execution environment, Lambda now maps your VPC's network interfaces to a small, shared set of Hyperplane interfaces, created once when the function itself is created or its VPC settings are changed — not at every invocation. AWS's own description of the change is direct about the effect: the execution environment "simply uses the pre-created network interface and quickly establishes a network tunnel to it," which "dramatically reduces the latency that was previously associated with creating and attaching a network interface at cold start." That one-time setup can itself take up to 90 seconds; if your function is invoked while it's still happening, the invocation still succeeds, just with a longer cold start than usual. AWS also notes that functions left idle for consecutive weeks can have their Hyperplane resources reclaimed, so a rarely-invoked function can occasionally see that slower first-cold-start behavior again.

What that means in practice: the VPC attachment itself is no longer the main cold-start cost it once was, but the EFS mount operation still happens during the Init phase of a cold start, adding some time before your handler code runs, on top of whatever the VPC attachment itself now costs. Two settings help most from your side: reserved or provisioned concurrency, which keeps a pool of execution environments warm so fewer invocations hit a genuine cold start at all, and keeping your access point's root directory small and well-organized, since a Lambda function doesn't need to enumerate the file system's contents to mount it, but a poorly organized access point can slow down whatever your code does immediately after the mount completes.

Why Lambda Requires an Access Point in the First Place

It's worth stepping back and answering the question underneath all of this: why does Lambda even need an access point, rather than just connecting to the raw EFS file system? An access point is a way of decoupling the file system's configuration from your application. It bundles together an operating-system user and group to present when accessing files, a specific path inside the file system to scope access to, and optional automatic root-directory creation — all in one reusable object with its own ARN.

The practical benefit shows up the moment you have more than one Lambda function sharing the same file system. Different functions, or different teams, can each get their own access point pointed at their own subdirectory, with their own permissions — one function's access point might be read-only and scoped to /shared-data, while another gets read-write access scoped to /uploads — all on the exact same underlying file system, without any function needing code-level logic to enforce those boundaries. That's the same file system your access points are pointed into; whether you mount fs-12345678:/ directly with an access point at its root, or mount fs-12345678:/efsaccesspoint with a scoped access point, you're touching the same data with a different lens.

It also changes what a security review actually has to look at. Without access points, granting a function access to a shared EFS file system meant granting it access to everything on that file system, and enforcing the boundary — "this function should only ever touch its own folder" — had to live in your application code, where a bug could quietly violate it. With an access point in front of it, the boundary is enforced by EFS itself, at the file-system layer, before your function's code runs at all. A reviewer checking IAM policies and access point configurations can answer "what can this function actually reach" without reading the function's source code — which is exactly the kind of thing that's easy to get right once and forget to keep updating if it lives in application logic instead.

Frequently Asked Questions

What does "EFSMountFailureException" mean?

It means Lambda's mount request to your EFS access point was rejected outright. The most common causes are a missing elasticfilesystem:ClientMount or ClientWrite permission on the execution role, an access point ARN that doesn't exist or is mistyped, or a root directory inside the access point that was never actually created.

Why do I get EFSMountFailureException even though my IAM permissions look correct?

Check whether the access point's root directory path actually exists inside the file system. If "creation info" on the access point is empty and the folder doesn't exist yet, EFS won't create it automatically, and the mount fails with the exact same error text as a permissions problem — with nothing in CloudTrail to distinguish the two.

What's the difference between EFSMountFailureException and EFSMountConnectivityException?

EFSMountFailureException means the mount request was rejected — a permissions or access point problem. EFSMountConnectivityException means Lambda couldn't even reach the file system over the network on NFS port 2049, which points at security groups, subnets, or VPC routing instead.

Why does my Lambda function time out mounting EFS (EFSMountTimeoutException)?

This means Lambda connected to the file system fine, but the mount operation itself didn't finish in time — usually because the file system is under heavy load from many concurrent mount attempts. AWS's own guidance is to retry after a short wait and consider limiting the function's concurrency.

Can I retry an EFS mount automatically?

Lambda doesn't automatically retry a failed mount within the same invocation, but if the invocation itself is retried — for example, through an asynchronous invocation with its own retry policy, or an event source mapping — a fresh mount attempt happens on the next try. For synchronous invocations, building retry logic into whatever is calling your function is the more reliable approach for a transient timeout.

Does my Lambda function need to be in the same VPC as my EFS file system?

Yes. EFS mount targets live inside a specific VPC, and your Lambda function has to be connected to that same VPC, with at least one subnet in every Availability Zone where a mount target exists, for the mount to succeed.

What security group rules does Lambda need for EFS?

Two rules, in two places: the EFS file system's security group must allow inbound NFS traffic on port 2049 from the Lambda function's security group or subnet range, and the Lambda function's security group must separately allow outbound NFS traffic on port 2049 to the file system. Missing either one blocks the connection.

Why do I get "Permission denied" when my Lambda tries to write to EFS?

This usually means the access point doesn't have a POSIX user configured. IAM's elasticfilesystem:ClientWrite permission only controls whether Lambda is allowed to attempt a write at the AWS level; the actual Linux file permissions on the folder, tied to the POSIX user set on the access point, decide whether that write succeeds.

What is an EFS access point and why does Lambda need one?

An access point is an application-specific entry point into an EFS file system — it scopes access to a specific path and presents a specific operating-system user and group when your function touches files. Lambda requires one rather than connecting to the raw file system so that different functions can share one file system safely, each with its own scoped path and permissions.

Why does the root directory need to exist before Lambda mounts it?

Because EFS only creates a root directory automatically when you fill in "creation info" on the access point — an owner user ID, group ID, and permissions. Without that, EFS expects the folder to already exist, and a mount attempt against a nonexistent folder with no creation instructions fails.

What is EFSIOException and why does it happen?

It happens after a successful mount, when Lambda detects a read or write operation taking too long and stops the function instance. AWS ties this to the file system running out of burst credits combined with insufficient baseline throughput — increasing the file system's size or switching to provisioned throughput are the documented fixes.

Can Lambda use EFS in every AWS Region?

No. As of Amazon's own current documentation, EFS for Lambda is unavailable in six commercial Regions: Asia Pacific (New Zealand), Asia Pacific (Taipei), Asia Pacific (Malaysia), Mexico (Central), Asia Pacific (Thailand), and Canada West (Calgary). It's supported everywhere else.

Does using EFS with Lambda increase cold start time?

Some, yes — the mount happens during the Init phase of a cold start, adding time on top of whatever connecting to a VPC already costs. Reserved or provisioned concurrency, which keeps environments warm, reduces how often invocations pay that cost.

How do I check which VPC and subnets my Lambda function is using?

Open your function in the Lambda console, go to the Configuration tab, then VPC. It lists the VPC, every subnet the function is attached to, and the security groups applied — cross-reference those subnets' Availability Zones against where your EFS mount targets actually exist.

What is AWS Reachability Analyzer and how does it help with EFS mount issues?

It's a network diagnostics tool that traces the actual path between two resources in your VPC and identifies exactly which security group, network ACL, or route table is blocking traffic. For a persistent EFSMountConnectivityException that survives a manual security-group review, it can pinpoint the blocking hop directly instead of you tracing routing tables by hand.

Can I use EFS and Amazon S3 Files with the same Lambda function?

No. A Lambda function can mount either an EFS file system or an S3 Files connection, but not both at the same time. If you're troubleshooting a mount error, confirm which of the two file system types your function is actually configured to use, since their error messages and ARN patterns look similar but the underlying setup is different.

Revision note. Written September 2026. This will need a refresh if AWS adds Regional support or changes the access point creation-info behavior. If you're staring at this error at midnight with a customer waiting, you're not missing something obvious — this is a genuinely confusing set of overlapping causes, and working through the checklist above in order will get you there.