If you are a WordPress developer who has been building sites professionally for a few years, you probably have a standard media offload recommendation that you give to clients when their hosting storage starts filling up. For many developers, that recommendation is AWS S3 with WP Offload Media. It is a reasonable choice with strong documentation, broad plugin support, and a familiar name that clients associate with reliability.
It is also frequently the wrong choice for budget clients, and recommending it by default without considering the alternatives is worth examining. The combination of S3 storage costs, egress fees, plugin license costs, IAM configuration complexity, and the ongoing support burden of helping a non-technical small business owner manage AWS credentials creates a total cost of ownership that is higher than it needs to be for most client use cases.
This guide is written for developers who want to think through their default recommendation more carefully. It examines what S3 costs and requires in a client context, what the FTP alternative looks like in practice, and how to determine which recommendation is appropriate for which type of client project. The goal is not to argue that S3 is bad. It is to argue that it is the right tool for a specific set of requirements that most budget client sites do not have.
The full cost of an S3 recommendation in a client context
When you recommend S3 to a client, the cost is not just the S3 bill. It is the sum of several cost components that are easy to underestimate when you are thinking primarily about the technical solution rather than the total ownership experience.
Creating an AWS account (or navigating an existing one), creating an IAM user with the correct policy, generating access keys, creating an S3 bucket, configuring bucket permissions, disabling block public access, setting up CORS, installing and configuring WP Offload Media, testing the connection, running the initial sync, and verifying CDN delivery. For a developer who does this regularly, this is 1.5 hours. For one doing it for the first time or debugging a permissions issue, it can be 3 hours or more.
S3 storage for 50GB: $1.23/mo. Egress for a site with 20,000 monthly visitors and modest image payload: $2 to $8/mo. WP Offload Media plugin license amortized: $8/mo. Optional CloudFront CDN: $3 to $15/mo depending on usage. Total: $14 to $32/mo. This is the recurring cost your client pays for a feature that a $4/mo FTP storage server could provide at equivalent or better performance. For a budget client paying $5,000 total for their website build, a $30/mo ongoing infrastructure cost is significant relative to the build fee.
S3 generates support tickets in ways that FTP does not. Expired access keys. IAM policy changes that break permissions after an AWS Console update. S3 bucket policy changes required when WordPress is migrated to a new domain. Egress bill spikes that trigger client calls. AWS account closure emails that arrive when a billing method expires. CloudFront invalidation questions. Each of these is a support event that arrives months or years after the project closed, consumes your time, and often goes unbilled because it feels like a small fix that would be awkward to charge for.
The specific S3 support scenarios that cost developers time
These are the actual support scenarios that experienced WordPress developers who have recommended S3 to clients have encountered. Each one requires developer involvement that a FTP-based setup would not generate.
A year after launch, the client’s IT person rotates their AWS access keys as part of a security audit. They do not know that the WordPress plugin requires the old keys. Images stop loading site-wide. The client calls you in a panic. You diagnose the issue, log into their AWS account, generate new keys, update the plugin, verify images are loading. 45 minutes of unbilled work.
The client runs a promotion that drives an unusual traffic spike. Image egress costs triple for the month. The client receives an AWS bill three times their expected amount and calls you asking what happened. You explain egress fees. They ask if there is a cheaper option. You explain that yes, there was a cheaper option from the start, but this is what you recommended. This conversation is awkward and occasionally damages the client relationship.
The client migrates from a development domain to their final domain, or changes their domain two years later. The S3 bucket CORS policy is scoped to the old domain. Image uploads from the new domain fail with CORS errors. Diagnosing CORS errors in an S3 context requires AWS knowledge the client does not have. Developer involvement required for what should have been a straightforward domain change.
WP Offload Media releases a major version update that changes how it stores credentials or handles the S3 API. After a WordPress auto-update, the plugin version changes and images stop uploading correctly. The client does not notice for two weeks until they try to upload new product photos and they do not appear on the site. Debugging required.
What the FTP alternative looks like in a client context
For comparison, here is what the same client media offload setup looks like using FTP storage and WP FTP Media instead of S3.
Sign up for an FTP storage plan (Hetzner Storage Box or IONOS), receive credentials immediately, install WP FTP Media on the client site, enter hostname, username, and password, set CDN base URL, test connection, run initial sync. No IAM roles, no bucket policies, no CORS configuration, no access key management. Total active time: 20 to 30 minutes including the initial sync setup.
FTP storage (Hetzner 100GB): $3.81/mo. BunnyCDN delivery (typical small business site): $0.50 to $2/mo. WP FTP Media plugin: approximately $4/mo amortized. Total: $8 to $10/mo flat with no egress surprises regardless of traffic spikes. This is 60 to 70% less than the S3 equivalent for a typical small business site, and the cost does not increase with traffic.
FTP credentials do not expire unless the client changes them. There are no IAM policies to maintain. There are no CORS configurations. There are no egress bills to explain. If a client changes their domain, no storage configuration changes are needed — the URL rewriting adapts automatically. The support scenarios that generate unbilled developer time with S3 simply do not arise with FTP storage.
The decision framework: when S3 is right and when FTP wins
The argument here is not that S3 is always the wrong choice. It is that S3 is the right choice for a specific set of requirements, and most budget client sites do not have those requirements. Here is the decision framework.
How to present FTP storage to clients who have heard of S3
One practical challenge with recommending FTP storage over S3 is the name recognition gap. A client who has done any reading about WordPress media offloading has probably encountered S3. They may have seen it described as the professional choice. Recommending something they have never heard of can feel like recommending a cheaper substitute rather than a better alternative.
The framing that works well in client conversations is function-first: explain what the system does before naming the components. A dedicated file storage server holds all your site’s images. A global delivery network serves those images from locations close to your visitors. The technology that connects WordPress to the file server is a plugin. The result is that your images load fast, your hosting costs stay low, and the setup is simple enough that if something needs changing in the future, it does not require an AWS expert.
Instead of: “We’ll use AWS S3 for your media storage.”
Try: “We’ll host your images on a dedicated storage server in Germany. It’s about $4 a month, your images will load faster than they do now, and you won’t have any surprise bills when your traffic is high. I use this setup for most of my smaller business clients because it’s reliable and keeps costs predictable.”
The client hears: dedicated, fast, cheap, predictable. They do not need to know it is Hetzner. They do not need to understand FTP. They need to understand the outcome.
The agency benefit: standardized FTP reduces per-client overhead
For developers who manage multiple clients, there is an additional argument for standardizing on FTP rather than S3: the ability to use a single shared storage server for the entire client portfolio.
With S3, every client needs their own AWS account, their own IAM configuration, and their own bucket. Managing ten clients means ten separate sets of AWS credentials, ten separate billing relationships, and ten separate configurations to maintain. If a plugin update changes how credentials are stored, ten configurations need updating.
With FTP and WP FTP Media, you can run one shared Hetzner Storage Box with per-client subdirectories. One storage server, one billing relationship, one place to check on storage usage across all clients. Each client site connects to the shared server with its own remote root path pointing to their subdirectory. When WP FTP Media is updated, it is one plugin configuration across all sites. The per-client overhead for media storage management approaches zero as the portfolio grows.
According to Kinsta’s WordPress market share research, the vast majority of WordPress sites are small to medium business sites operated by non-technical owners. The developers who build and maintain those sites are responsible for making infrastructure decisions on behalf of clients who will live with those decisions for years. Recommending the infrastructure that produces the best outcome for the client — lower cost, simpler management, predictable billing, less support overhead — is the most professional choice regardless of which technology that recommendation involves.
For most budget client WordPress builds, that recommendation is FTP storage with WP FTP Media rather than S3 with WP Offload Media. WP FTP Media’s developer-first WordPress media offload plugin for client site deployments is built around the requirements of the developer-client relationship: fast setup, simple credentials, no ongoing IAM management, and a consistent interface that works the same way across every site in the portfolio.
The infrastructure your budget clients actually need. Not the infrastructure you learned about first.
WP FTP Media gives WordPress developers a faster client setup, lower client ongoing costs, and zero IAM-related support tickets — making it the better default recommendation for the majority of client WordPress builds.
Finally found a smarter S3 alternative for small biz $5/month vs their $30+ with egress fees. win
Oh man, I was so excited to finally move my client's media to S3 like all the "pro" devs recommend until the access keys expired again and their whole site crashed right in the middle of launch. now I'm stuck explaining AWS IAM to a small business owner who absolutely despises it, and that $30 monthly bill is really adding up for them. for what? My old $4 FTP server never caused this much trouble. The docs are fine, but what good is reliability if the keys keep failing and my client is freaking out?
as a nurse who runs a small wellness blog on the side, I got talked into using S3 for media storage last year.
Saved my sanity with budget clients!