For the past week or so, I’ve been previewing a major new cloud filesystem from AWS. It’s called the Elastic File System and it’s big, big news. For EC2 instances running in a VPC, EFS presents a shared, read-after-write-consistent filesystem of essentially unlimited size. Because it’s based on NFSV4.1 NFSv4 (only — not prior nor later versions), it’s very different from S3. S3 is a programmatic datastore — you call it from your app over HTTP (or TLS). That requires re-architecting many applications. NFS is a true filesystem in the old-school sense. You create a mount point in your Linux server and use the tried-and-true mount command to make it available to all the applications running on that server.
AWS has done an admirable job of making EFS easy to use. Basically, you create the filesystem and define access to the filesystem in each availability zone where you plan to run EC2 instances that need EFS access.
AWS calls these access points “mount targets.” They are IP addresses in your VPC and, as such, they can have DNS names. AWS generates DNS names for the mount targets (much as it does for ELBs). And the documentation has some clever examples of how you can derive the EFS mount target address if you know the EFS filesystem ID.
But you know me…I am a fan of using Route 53 private DNS and DNS CNAMEs to set up my own naming scheme. That way, you can develop a meaningful DNS scheme and let Route 53 DNS do the lookups needed to resolve the actual mount target IP addresses. Note that you really should use either EFS’s DNS names or your own since mount target IP addresses cannot (currently) be changed. You must delete and re-create them.
First, set up a Route 53 private DNS. I use the .aws TLD to indicate a private, cloud-only domain. The beauty of this is that more than one VPC can use the same private domain — this means you can have a single, consistent private DNS scheme across many AWS regions.
Next, use the AWS console to set up EFS. Part of this setup includes defining your mount targets. This is where you can use your own IP addresses, as you see in the screenshot below.
You could stop here, of course, and just use the EFS-generated DNS entries. But they are, of necessity, long in order to be unique. They also contain lots of extraneous (IMHO) information like the region the filesystem is in. They also contain the filesystem identifier, something one might consider a leakage of confidential information. So, as you see below, I use Route 53 to CNAME my preferred DNS name in .aws to the EFS-generated DNS entry.
EFS is the answer to many to many of the AWS cloud’s long-standing filesystem obstacles and is really easy to use and configure. (Yo, AWS: what about Windows?? Asked and answered: with general availability of NFS on June 29, 2016, NFSv4.1 support was announced. This means Windows Server 2012 and later can directly support NFS mounts. Update 2016-07-01: EFS does not support Windows, at least not yet. I tried and tried and tried — but could not mount the EFS filesystem. I really wish AWS would support Windows.)
I hope you find this technique of combining EFS mount target names and private Route 53 domains of some use.
Leave a Reply