visit
In this blog post I am sharing some points about Amazon Elastic File System (EFS), some of these facts are opinionated and most of them are based on my own experience.
1 — When you have an application that requires multiple virtual machines to access the same file system at the same time, AWS EFS is a tool that you can use.
2 — Think of EFS as a managed Network File System (NFS), that is easily integrated with other AWS services like EC2 or S3.
3 — By the way, S3 could neither be an alternative to a Network File System nor a replacement for EFS... S3 is not a file system.
4 — Sometimes when you think about using a service like EFS, you may also think about “Cloud Lock” and its negative sides on your business but to reduce the Time To Market, increase productivity and costs, EFS could be a good choice.
5 — GlusterFS is an open source alternative to EFS but when thinking about the amount of work to manage it, the complexity to keep it stable and all of its maintenance efforts, some organizations would prefer Cloud Lock over spending more money or time.
6 — This is really a business and a strategic choice and every organization have its own choices.
7 — What I liked the more about EFS is the extreme simplicity to use it.
8 — Creating an EFS file system can be done easily using the console or the CLI.
9 — EFS uses NFSv4.x protocol that fixes issues of the v3 and comes with performance and security improvements while introducing a stateful protocol.
10 — The replication of files between multiple availability zones in a region is insured automatically by EFS.
11 — Making an EFS backup may decrease your production FS performance; the throughput used by backup counts towards your total file system throughput.
12 — You can decide on your security (e.g which EC2 instance could have access to an EFS file system) since EFS support users and groups read, write and execute permissions, works with Security Groups and could b integrated with AWS IAM.
13 — EFS support encryption.
Don’t forget to download our mini ebook .
14 — EFS is SSD based storage and its storage capacity and pricing will scale in or out as needed, so there is no need for the system administrator to do additional operations. It can grow to a petabyte scale.
15 — Throughput and IOPS (Input/output operations per second) will be scaled according to how much your storage will grow/shrink.
16 — It is possible to use your EFS from your in-premise data center and attach your storage directly to EFS using Direct Connect
17 — EFS is expensive compared to EBS (probably 10x more EBS pricing)
18 — EFS is not the magical solution for all your distributed FS problems, it can be slow in many cases. Test, benchmark and measure to insure your if EFS is a good solution for your use case.
19 — EFS distributed architecture results in a latency overhead for each file read/write operation.
20 — Most Network File Systems are not being used in the right way. This is a must-read: .
21 — If you have the possibility to use a CDN, don’t use EFS, keep just files that can not be stored in a CDN.
22 — It is evident to say, but don’t use EFS as a caching system, sometimes you could be doing this unintentionally.
23 — EFS now supports NFSv4 lock upgrading and downgrading, so yes, you can use SQLite with EFS… even if .
24 — EFS is only compatible with Linux, if you’re using another OS, find another solution.
25 — Last but not least, even if EFS is a fully managed NFS, you will face performance problems in many cases, resolving this could take some time and needs some efforts, so brace yourself. A good way to measure and ameliorate performance is integrating CloudWatch service and choosing the right metrics to focus on while benchmarking your application in a staging environment.
Our goal is giving people the opportunity to learn DevOps technologies with quality courses and practical learning paths.
If you are interested in , you can . You can also download our mini ebook .