Alright, let’s talk about EFS throughput. This isn’t just some abstract setting you flip on; it’s the fundamental lever you pull to control how your file system breathes. Get it wrong, and you’ll either be paying for a firehose when you need a sippy cup, or you’ll be throttled into the stone age right when your application needs to sprint. We have three modes: Bursting, Provisioned, and Elastic. Let’s break them down like we’re diagnosing a weird performance bug.

Bursting Throughput: The Default with a Quirk

This is the default mode, and it’s a bit like having a credit card for performance. Your baseline throughput is determined by the amount of data you’ve stored. The formula is simple: you get 50 KiB/s for every GiB you have stored, plus the ability to burst far beyond that.

Why this weird KiB/s-per-GiB model? Because it loosely couples performance to cost. You pay for storage, and you get a baseline performance tier as a side effect. It’s the designers saying, “Hey, if you’re storing more stuff, you probably need to move more stuff.” It’s not a perfect correlation, but it’s a decent starting point.

The magic is in the burst bucket. You accumulate burst credits over time when you’re operating below your baseline. When you need to go faster—say, during a morning batch processing job—you spend those credits to burst up to 100 MiB/s (for General Purpose performance mode) or 250 MiB/s (for Max I/O), regardless of your piddly little baseline.

Here’s the pitfall, and it’s a classic: you can exhaust this bucket. If you have a small filesystem (say, 100 GiB), your baseline is a measly ~5 MiB/s. You can burst to 100 MiB/s, but you’ll burn through your credits in a matter of minutes. After that, you’re slammed back down to your baseline. Your application will crawl, and you’ll be left wondering why your fancy cloud file system feels like a congested dial-up modem.

You can check your burst credit balance to see if this is your problem. This is a non-negotiable diagnostic step.

# Use the AWS CLI to check your burst credit percentage
aws cloudwatch get-metric-statistics \
    --namespace AWS/EFS \
    --metric-name BurstCreditBalance \
    --dimensions Name=FileSystemId,Value=fs-yourfilesystemid123 \
    --statistics Average \
    --start-time $(date -d "1 hour ago" +%Y-%m-%dT%H:%M:%SZ) \
    --end-time $(date +%Y-%m-%dT%H:%M:%SZ) \
    --period 300 \
    --output json

If that BurstCreditBalance is trending toward zero, you’ve found your culprit. The solution? Either add more data (which feels absurd, I know—“just add junk data to go faster!”), or move to a different throughput mode.

Provisioned Throughput: The Predictable Power Play

When bursting isn’t cutting it, you step up to Provisioned mode. This is where you divorce performance from storage. You say, “I don’t care if I’m only storing 10 GiB of cat GIFs; I need a consistent 50 MiB/s,” and you pay for that privilege separately.

This is your go-to mode for latency-sensitive applications (like a website hosting its assets from EFS) or any workload with a known, steady-state requirement. You set a throughput value in MiB/s, and EFS delivers it, full stop. No credits, no buckets, no surprises.

The catch? You’re paying for that guaranteed throughput on top of your storage costs. It’s more expensive, but you’re buying predictability. The other catch is that it’s… well, provisioned. If you set it to 50 MiB/s and suddenly need 200 MiB/s for an hour, you’re out of luck unless you manually (or automatically) scale it up.

# Update your filesystem to use Provisioned throughput at 100 MiB/s
aws efs update-file-system \
    --file-system-id fs-yourfilesystemid123 \
    --throughput-mode provisioned \
    --provisioned-throughput-in-mibps 100

Use this when you have a known quantity and failure isn’t an option. It’s the “grown-up” mode.

Elastic Throughput: The Autoscaling Dream

Elastic throughput is the newest mode, and it’s AWS finally admitting, “Yeah, manually scaling throughput is a pain in the neck.” In this mode, you just… stop thinking about it. EFS automatically scales your throughput up and down based on actual demand, and you pay per MiB/s for the throughput you use.

It’s brilliant for spiky, unpredictable workloads. Think data processing jobs that spin up 100 containers for 20 minutes and then vanish. With Provisioned, you’d have to over-provision for the peak and waste money the rest of the time, or constantly write scripts to adjust it. With Bursting, you’d vaporize your burst bucket. With Elastic, it just works.

The rough edge? It’s not instantaneous. The scaling is fast, but it’s not infinitely granular. It works on an average-over-time basis. So for a truly sudden, massive spike—like a single operation demanding gigantic throughput—Provisioned might still be more predictable. But for 99% of use cases, Elastic is the hands-off winner.

# The simplest command you'll run all day. Just turn it on.
aws efs update-file-system \
    --file-system-id fs-yourfilesystemid123 \
    --throughput-mode elastic

The Best Practice Summary: Start with Bursting for dev/test. For production, if your workload is predictable, use Provisioned. If it’s unpredictable or spiky, use Elastic. And for the love of all that is holy, monitor your BurstCreditBalance if you stick with Bursting. Don’t be a cautionary tale.