Amazon EFS offers Bursting, Provisioned and Elastic throughput modes. What does each one do, and how would you choose between them for a given workload?

## Two separate knobs EFS performance has two independent settings, and candidates routinely conflate them: - **Throughput mode** — how much data per second the file system can move, and how you pay for it. Changeable after creation (AWS enforces a cooldown between changes). - **Performance mode** — the latency-versus-parallelism profile of file operations. Chosen at creation and **not changeable afterwards**; changing it means creating a new file system and copying the data. ## Throughput mode 1: Bursting The original model, and the source of most EFS performance surprises. Baseline throughput is a function of how much data you store in the Standard storage class: a large file system gets a high baseline, a nearly empty one gets very little. When the file system runs below its baseline it accrues **burst credits**; when it runs above, it spends them. The failure this produces is a delayed cliff. A 5 GB file system serving a busy read workload runs fine for hours or days on accumulated credits, then the credits hit zero, throughput collapses to the tiny size-derived baseline, and application latency goes through the roof — with nothing in the application having changed. The CloudWatch metric to watch is `BurstCreditBalance`, and the classic ugly workaround was to write a large dummy file purely to raise the baseline. ## Throughput mode 2: Provisioned Provisioned mode breaks the link between size and speed: you state a throughput in MiB/s and get it regardless of how little data is stored. You are billed for what you provisioned, used or not, on top of storage. ```bash aws efs update-file-system \ --file-system-id fs-0123456789abcdef0 \ --throughput-mode provisioned \ --provisioned-throughput-in-mibps 128 ``` This is the right answer for a small dataset with a predictable, sustained appetite — a handful of gigabytes of shared assets read continuously at a known rate. It is the wrong answer for spiky traffic, because you either provision for the peak and pay for idle capacity or provision for the average and throttle at the peak. ## Throughput mode 3: Elastic Elastic throughput removes the reservation entirely. The file system scales throughput up and down automatically with demand, and you are billed for the data actually read and written rather than for a rate. It is the default for newly created file systems, and it is the answer AWS steers you toward when the workload is spiky, bursty, or simply unknown — which describes most of them. The tradeoff is metering. Because you pay per GB moved, a workload that reads enormous volumes at a steady, well-characterised rate can be cheaper on Provisioned. The decision rule is therefore about *predictability*, not about size: unpredictable or idle-most-of-the-time → Elastic; sustained and measurable → do the arithmetic against Provisioned. One constraint matters: Elastic throughput is available only with the General Purpose performance mode. ## Performance mode: General Purpose vs Max I/O **General Purpose** gives the lowest per-operation latency and is what almost every workload should use — web serving, content management, home directories, container volumes, CI artifacts. **Max I/O** was designed for highly parallel workloads (large-scale analytics, many thousands of concurrent clients) that need higher aggregate operations per second and can tolerate **higher latency on every single operation**. It is now legacy: AWS recommends General Purpose, and Max I/O cannot be combined with Elastic throughput. Choosing Max I/O "to be safe" is a real mistake, because the latency penalty is paid on every operation forever and the setting cannot be undone in place. ## How to answer the question in an interview Start from the workload, not the menu. Ask two things: is throughput demand predictable, and is the dataset large relative to the throughput needed? Unpredictable → Elastic. Predictable and high on a small dataset → Provisioned. Bursting only survives as an answer for a large file system whose baseline is comfortably above demand — and even then, Elastic is usually the lower-risk default. Then note the asymmetry that catches teams out: you can move between throughput modes later, but you are stuck with the performance mode you picked on day one.