AWS Transfer Family Web Apps: Pricing, Limitations, and Alternatives

When AWS Transfer Family Web Apps launched, my first reaction was relief. Finally, an official way to give business users a browser to click around in S3. No glue code, no homegrown portal, no Friday-afternoon hack jobs.

Then I read the pricing page. And the setup guide. And it became pretty clear that "first-party" doesn't always mean "the right fit."

Here's what I've found digging into it.

How the pricing actually works

There are two things you pay for, and both add up faster than you'd expect.

The first is the server endpoint itself. $0.30 an hour, billed every hour the endpoint exists. Nobody using it? Doesn't matter. That works out to about $219 a month just to keep the door open.

The second is data transfer through the service, charged at $0.04 per megabyte. If your team pulls 10 GB a month (pretty modest), you're tacking on another $400. So a "small" deployment lands somewhere between $365 and $600 a month, and that's before anyone really starts using it.

If you're moving terabytes, the math gets uncomfortable in a hurry. There's no flat-rate option to fall back on. The bill scales with whatever your users decide to download this month, which is exactly the kind of cost that makes finance people nervous.

The setup is not a one-click thing

The marketing copy makes it sound easy. Reality is four AWS services you have to wire together by hand, and they all have to be configured just right.

IAM Identity Center, no exceptions. Transfer Family Web Apps only authenticates through Identity Center (the service formerly known as AWS SSO). If your company already runs on Cognito, or you federate Okta straight into your apps, you can't reuse any of that. You either migrate to Identity Center or run two identity systems side by side. Neither option is fun.

S3 Access Grants. File-level permissions live in Access Grants, a newer service that adds yet another layer to learn. You define grant scopes that bridge Identity Center users and S3 prefixes. It works, but it's another moving part you now own.

CORS, again. The web app needs specific CORS headers on your buckets. The docs cover it, but if you already have CORS rules for other apps, the merge is on you and it's easy to get wrong.

IAM roles and trust policies. You'll create a few. One for the Transfer Family server, one for the web app, plus the trust relationships that tie them together. Standard stuff if you live in IAM, but it's still real work.

Most teams I've talked to lose half a day to this on the first attempt. Not catastrophic, but definitely not "five minutes."

A few things you might not realize until later

No Cognito. If your app already uses Cognito User Pools (a lot of AWS shops do), those users and groups can't be reused here. That's a real gap if you've already standardized.

No admin UI to speak of. Want a clean dashboard for managing bucket access or browsing audit logs? You're back in the AWS Console, the CLI, or CloudFormation. Workable, but not what you'd hand to a non-technical admin.

Audit logs live in CloudTrail. Which is great when you need it, but "who downloaded what file last Tuesday" isn't a one-click answer. You'll be writing Athena queries or piping logs into CloudWatch Insights to get reports you can actually share.

Costs are unpredictable. If a user grabs 50 GB next month because they're prepping for a big launch, your bill notices. There's no ceiling.

What else is out there

Depending on what you actually need, you have options.

EC2-based portals (StorageLink, FileMage)

These are AMI-based products. You spin up an EC2 instance, point it at your buckets, and you've got a web UI. They're cheaper on paper ($80 to $150 a month plus the EC2), but you're back to patching servers, watching CPU graphs, and getting paged when something falls over. If you went serverless to escape that, going back hurts.

Triofox

Triofox aims at replacing Windows file servers and happens to support S3 as a backend. Powerful, but it's overkill for most file-sharing needs. The per-user pricing ($10–15/user/month) climbs fast, and the architecture wants Windows servers. Probably the right tool if you're swapping out an on-prem file server. Probably not if you just want users to grab some PDFs.

Build it yourself

You can absolutely roll your own. You'll get exactly what you want. You'll also own auth, authz, file listing, downloads, and audit logs forever. Most teams underestimate the maintenance tail by a wide margin. We wrote a whole post on what's actually involved in building an S3 file browser with Cognito if you want to look before you leap.

BucketDrive

This is the path we took with BucketDrive: serverless, deploys as a single CloudFormation stack into your account, and uses Cognito so you can plug into whatever identity setup you already have (Okta, Azure AD, anything SAML/OIDC).

The differences from Transfer Family Web Apps, briefly:

• Flat pricing starting at $199/month, not metered per MB
• Cognito-native, no Identity Center requirement
• An admin portal you'd actually want to use
• One CloudFormation deploy instead of stitching four services together
• Actually serverless. When nobody's using it, you're not paying for an idle endpoint

So which one?

Transfer Family Web Apps is the right call if you've already gone all-in on Identity Center, you're fine with metered pricing, and "it's first-party AWS" trumps everything else for your team.

If you're on Cognito, want a number you can budget around, or just don't want to spend a day stitching services together, you'll probably be happier with one of the alternatives. Pick the one that fits your stack instead of bending your stack to fit the tool.