S3 Transfer Acceleration: when enabling the bucket flag is not enough

Back to Northlight Press. Editors in Lagos, London, and Toronto upload cover images and raw video into the same private bucket in eu-north-1. Playback already goes through CloudFront. Uploads, though, still felt “stuck” for anyone far from the bucket region.

Someone enabled Transfer Acceleration on the bucket in the AWS console and expected the Admin desk to get faster overnight.

It did not.

Because acceleration is not a magic switch on existing URLs. It is a different endpoint. Until your API signs PUTs against that endpoint, browsers keep talking to the regional host.

What Transfer Acceleration actually does

Normal direct-to-S3 uploads go roughly:

Browser → nearest public internet path → regional S3 endpoint (bucket.s3.<region>.amazonaws.com)

With Transfer Acceleration enabled and used:

Browser → nearest AWS edge → AWS backbone → your bucket (bucket.s3-accelerate.amazonaws.com)

You are not making S3 “compute faster.” You are shortening the ugly part of the trip: the public internet hop from a distant client to a single regional API. Inside AWS’s network, the rest of the transfer tends to be more predictable.

That is why the win shows up on long-haul uploads (another continent, bad last-mile routing to the bucket region) and barely shows up when the editor is already next door to the region.

How much faster?

Honest answer: it depends, and anyone quoting a single percentage is selling you a vibe.

What you can say with a straight face:

• Same metro / same region as the bucket: often little gain; occasionally a wash or slightly worse once you add the edge hop.
• Cross-continent or awkward routes: this is where acceleration earns its keep - large media (covers, podcasts, mezzanine video) commonly feel noticeably faster because time-to-first-byte and sustained throughput improve when the client stops fighting the public path to one AZ’s front door.
• AWS’s own guidance frames acceleration as a tool for distant clients and large objects, not a universal turbo button. Treat marketing “up to X%” numbers as a ceiling for lucky routes, not a promise for your newsroom.

If you need a number for a stakeholder deck, measure it:

1. Pick two realistic clients (e.g. Lagos Wi‑Fi and a London office).
2. Upload the same 50–200 MB asset with regional URLs, then with accelerate URLs.
3. Record wall-clock and failure/retry rate - not just “Mbps on a perfect day.”

Engineering > folklore.

The bug that looks like “AWS didn’t work”

Northlight’s API returned presigned PUT URLs like:

https://northlight-media.s3.eu-north-1.amazonaws.com/covers/….jpg?...

Console: Transfer Acceleration = Enabled.
Browser: still hitting the regional host.
Editors: “acceleration is a scam.”

The fix is on the signer, not the bucket checkbox.

With the AWS SDK v3 client:

new S3Client({
  region: "eu-north-1",
  credentials: { accessKeyId, secretAccessKey },
  useAccelerateEndpoint: true,
});

Presigned URLs then look like:

https://northlight-media.s3-accelerate.amazonaws.com/covers/….jpg?...

Same PutObject command. Different host. That host is what CloudFront-style edge routing is for - writes, not reader GETs.

Gate it with config so staging can opt in without surprising prod:

AWS_S3_USE_ACCELERATE=true

Read path stays on the CDN hostname you already designed (cdn.northlight.press). Acceleration does not replace CloudFront for public delivery; it complements the upload path.

Checklist before you flip it on

1. Bucket: Transfer Acceleration = Enabled (DNS-compatible bucket name; dots can be painful).
2. Code / env: signer uses useAccelerateEndpoint (or equivalent) so uploadUrl contains s3-accelerate.
3. CORS: still required for browser PUTs - same AllowedOrigins / AllowedHeaders as before; only the host changes.
4. Cost: accelerated bytes cost more than plain regional transfer. Worth it for editor UX and fewer abandoned uploads; wasteful if every client is in-region.
5. Don’t confuse layers: MediaConvert, s3:// job inputs, and CloudFront OAC reads stay on normal S3 addressing. Only the browser → S3 PUT needs the accelerate endpoint.

How this sits next to private S3 + OAC

In the earlier Northlight write-up, the shape was:

• Write: presigned PUT into a private bucket
• Read: CloudFront + OAC, never public ACLs

Acceleration slots into the write side only:

Path	Host you want
Editor upload (PUT)	bucket.s3-accelerate.amazonaws.com when far away
Reader image/video (GET)	cdn.northlight.press via OAC

Mixing them up (accelerating reads, or leaving PUTs regional after “enabling” the feature) is how you burn an afternoon and still ship slow Admin uploads.

Takeaway

Enabling Transfer Acceleration in the console is permission for AWS to accept accelerate-endpoint traffic. Your app must generate that traffic.

One client flag - useAccelerateEndpoint: true - is the difference between a checked box and a faster newsroom. Measure from the geographies your editors actually live in; keep CDN for readers; pay the accelerate premium only on the bytes that hurt.