Networking checklist for AWS Lambda

June 20, 2021 · app

For streetwarp.com, I recently had to update the config of my AWS Lambda function. I had two goals:

  1. add an EFS (elastic file system) mount to the instance
  2. still let it call out to the public internet (specifically to the Google Maps API and to the home server to report progress)

The initial problem is that attaching the EFS mount requires the function to run in a private subnet which doesn't have internet access.

If you're like me, you'll think this should be easy. But after spending a couple of days trying to get a tenuous grasp on AWS arcana, I've completely changed my mind. Anyway, it works now, finally, so here I'll list all the steps I took in the hopes it's easier for you!

The most helpful source for me was this blog post, much more so than the official documentation. My contribution here is a condensed summary.

  1. create a VPC in your region
  2. create a subnet in the VPC, name it my-private-subnet
  3. create a second subnet, name it my-public-subnet
  4. create an internet gateway in the region and attach it to the VPC
  5. create a NAT gateway in the my-public-subnet
  6. create a routing table called my-public-route-table and add the routing rule 0.0.0.0/0 -> internet gateway created in 4.
  7. associate this route table to the my-public-subnet
  8. create another routing table called my-private-route-table and add the routing rule 0.0.0.0/0 -> NAT gateway created in 5.
  9. associate this route table to the my-private-subnet
  10. update Lambda function networking configuration to use this new VPC in the my-private-subnet
  11. create an EFS in the my-private-subnet
  12. create an access point for this EFS with user:1000, group:1000, and mount:/efs
  13. back to your Lambda function, add this EFS to your File System configuration with the mount point /mnt/efs
  14. create an IAM role called lambda_vps_execution_role
  15. Attach the policy AWSLambdaVPCAccessExecutionRole to this role
  16. Back in Lambda land, go to basic settings and set the execution role to "existing role", then lambda_vps_execution_role

Conclusion

AWS has invented a perpetual job security machine, kudos to them!

Gotcha!

Update from a day later: I was a little surprised when my billing alert fired. It turns out the managed NAT Gateway offering actually costs $0.045 per hour! That translates to more than $30 a month. Way more than I'm willing to pay for a little hobby project that sees very little traffic, and apparently I'm not alone.

One fix is to use a tiny EC2 instance as a NAT gateway instead. So instead of step 5 above, provision a cheap EC2 server in your public subnet (as of this writing the cheapest is the t4g.nano ARM server). Then set up forwarding by following these instructions.

Postscript

If you see the error EFSMountConnectivityException: The function couldn't connect to the Amazon EFS file system with access point when launching your Lambda function, then the fix is steps 14-17 above.

Previous: Typesafe RPC without codegen
Next: A captioned day in Chicago
View Comments