Important note: As of 2018-07-12, EFS allows you to purchase provisioned throughput. The answer below reflects the behavior of the service before this feature was available. Previously, small EFS filesystems were easy to overwhelm with traffic, because performance scaled up linearly with the size of the data stored... so with only a few GB stored, the effective limit was too small for some use cases that did not take this into account.
Whyn't mount same EBS volume to 2 EC2 instances? I think it's a hack.
You can't mount the same EBS volume to multiple instances. You can, however, create an NFS export from the machine with the EBS volume and mount that across the network. NFS is established technology, not a hack. In fact, this would be almost identical to using EFS from your perspective, since EFS does in fact use the same protocol -- NFS.
Amazon is not charging extra for EFS outbound bandwidth. Is it limited?
"Outbound bandwith" is not exactly a valid concept with EFS, because the traffic is strictly between EFS and the instance that is accessing it. If you mount it correctly, using the availaibility zone-specific endpoint, the traffic between EFS and the EC2 instances never leaves the availability zone.
If a web browser downloads a file that is on your EFS filesystem, it must necessarily be downloading it through one of your instances. So the outbound bandwidth is actually EC2 outbound, not EFS outbound.
The available throughput ("bandwidth") between EFS and EC2 scales up with the total size of the files stored in an EFS filesystem.
Amazon EFS uses a credit system to determine when file systems can burst. Each file system earns credits over time at a baseline rate that is determined by the size of the file system, and uses credits whenever it reads or writes data. The baseline rate is 50 MiB/s per TiB of storage (equivalently, 50 KiB/s per GiB of storage).
Accumulated burst credits give the file system permission to drive throughput above its baseline rate. A file system can drive throughput continuously at its baseline rate, and whenever it's inactive or driving throughput below its baseline rate, the file system accumulates burst credits.
http://docs.aws.amazon.com/efs/latest/ug/performance.html
But there is a 100MiB/s burst capability, however small the filesystem might be. For a 10GiB filesystem, you can burst to 100MiB/s for 7.2 minutes per day, or 25MiB/s for 28.8 minutes per day, etc.
The thing you're overlooking with your conclusion that this is insufficient is the OS cache. On your web server, files read from EFS may remain in the OS cache on that machine, which means that once a file has been served to a browser, the web server may not need to read the file from EFS on the next download, but may instead only check that it has not changed and then serve it to the browser from memory. This behavior should be automatic unless you disable it.
It's strange amazon is linking size of data to traffic. I might store only little data, but that doesn't mean my outbound traffic too will be very low.
Not really strange, since the size of the stored data is the only dimension that impacts pricing. EBS volumes are generally similar -- the larger the volume, the more throughput in MiB/s and/or IOPS is available from that volume.
Here, again, don't confuse your application's outbound traffic with the backing store's throughput. The two values are not tightly correlated.
For smaller instances, the instance's characteristics are actually more likely to be the limiting factor. For example, a t2.small instance only has 31.25 MiB/s (250 mbps, 0.25 gigabit/sec) of bandwidth available at all, so the upper performance limit won't be the filesystem.
Try your application with EFS and observe the CloudWatch metrics for the filesystem. Every workload is different and that's really the only way to know if it will work as expected.