S3 and EFS actually are quite different. Files on EFS are update-able, rename-able and link-able (I.e what’s expected from a file system), while S3 objects are immutable once they are created. This comes from the underlying data structures. EFS uses inodes and directories while S3 is more of a flat map.
Protocol-wise EFS uses standard NFS 4.1. We added some optional innovations outside the protocol that you can use through our mount helper (mount.efs). This includes in-transit encryption with TLS (you can basically talk TLS to our endpoint and we will detect that automatically), and we support strong client auth using SigV4 over x509 client certificate.
Will EFS be updated to use the NFS-TLS RFC once it settles down some?
* https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-t...
I can't commit on a public forum for obvious reasons but we'll definitely take a serious look at this, especially when the Linux client starts supporting this. We did consult with the authors of that draft RFC earlier and it should be relatively easy for us to adopt this.
* https://mailarchive.ietf.org/arch/browse/nfsv4/
But no recent commits to the draft:
I don't know, I hope it will.
Not to go on too much of a tangent, and at the risk of sounding like my employer's fanboy, but one of the great things about working at AWS (I'm being honest, and yes we are hiring SDEs and PMs) is that we 100% focus on the customer. When our customers told us they needed encryption in transit, we figured out we could simply offer them transport-level TLS independent from the application-level RPC protocol. It may not have been the standards-compliant approach, but our customers have been enjoying fast reliable encryption for over 4 years now [1]. It solves a real problem because customers have compliance requirements.
[1] https://aws.amazon.com/about-aws/whats-new/2018/04/amazon-ef...
Here is the status:
"This one had to be paused for a bit to work out some issues around using a wider type to hold the epoch value, to accomodate some DTLS-SCTP use cases involving associations expected to remain up for years at a time. https://github.com/tlswg/dtls13-spec/issues/249 ends up covering most of the topics, though the discussion is a bit jumbled. We have a proposed solution with almost all the signoffs needed, and should be attempting to confirm this approach at the session at IETF 112 next week...
"I'm sorry that these have been taking so long; these delays were unexpected."
Last I checked it spawns a HAProxy on the client and points the in-kernel NFS client to this HAProxy on lo, is this still the case?
And, out of curiosity: now that EFS claims 600us average read latency, would the extra hop matter?