Reference Material:

https://docs.aws.amazon.com/efs/latest/ug/performance.html
"When burst credits are available, a file system can drive up to 100 MBps per terabyte (TB) of storage, with a minimum of 100 MBps. If no burst credits are available, a file system can drive up to 50 MBps per TB of storage with a minimum of 1 MBps"
It is mentioned that the size of the EFS is not going to exceed 1 TB, and each job outputs 100 MB of data, and there will be hundreds of them.
If we go with the burst throughput, we will have maximum 100 MB/s which will be enough just for 10 job output. So, we need provisioned throughput, which is B.
https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/storage.html
By default, containers don't persist the data they produce. When a container is terminated, the data that it wrote to its writable layer gets destroyed with the container. This makes containers suitable for stateless applications that don't need to store data locally. Containerized applications that require data persistence need a storage backend that isn't destroyed when the application’s container terminates.
With Amazon ECS, you can run stateful containers using volumes. Amazon ECS is integrated with Amazon EFS natively, and uses volumes that are integrated with Amazon EBS. For Windows containers, Amazon ECS integrates with FSx for Windows File Server to provide persistent storage.
Confused with EBS now!