Self-Hosted FTP vs Managed Cloud:
Which One Survives a Traffic Spike?

When 500 simultaneous visitors hit a WordPress page, each one requires a PHP process to generate the HTML. If the hosting plan provides 4 PHP workers, the first 4 requests are served immediately. The remaining 496 queue. Queue depth grows faster than PHP processes can clear it. Response times climb from 200ms to 2 seconds to 10 seconds. Eventually, requests time out. This is the primary failure mode of WordPress under traffic spikes and it has nothing to do with where images are stored.

Each PHP process executing a WordPress page load runs dozens to hundreds of database queries. Under traffic spike conditions, the database server handles hundreds of simultaneous query loads. Without object caching (Redis/Memcached), the database becomes the second bottleneck, adding latency to every PHP process waiting for query results and further degrading TTFB. Again, no relationship to image storage location.

If images are served from the hosting server without a CDN, the 30 to 40 image requests per page visit add to the hosting server’s I/O and network burden simultaneously with PHP execution. This is where media storage location becomes relevant: images served from a properly cached CDN create zero additional load on the origin server during a traffic spike. Images served from the hosting server or from uncached object storage create direct resource competition with PHP processing.

With a properly warmed CDN, S3 egress during a spike is minimal (only cache misses hit S3 origin). The S3 bill for a 4-hour traffic spike with 98% cache hit rate is negligible. However, if the spike happens before the CDN cache is warm, such as on a site launch day or after a CDN cache purge, all image requests miss the cache and hit S3 origin directly, generating the catastrophic egress costs shown in Scenario 3.

S3 is backed by AWS’s globally distributed infrastructure with effectively unlimited bandwidth at the origin. A Hetzner Storage Box has a network connection of 1Gbps included with the subscription. At 1Gbps, the storage box can transfer approximately 450GB per hour at full bandwidth. For a site where 2% of 350,000 image requests per hour (7,000 cache misses) each require an average 200KB image, the total origin bandwidth requirement is approximately 1.4GB per hour of cache miss traffic. Well within the FTP server’s 450GB/hour capacity. S3’s unlimited origin bandwidth is irrelevant at this scale.

AWS S3 offers a 99.99% uptime SLA with formal compensation terms for downtime. Hetzner Storage Box does not offer a formal SLA document with compensation terms, though Hetzner’s track record of uptime is strong. For operators who require a formal SLA for compliance or contractual purposes, S3 is the appropriate choice. For the vast majority of WordPress sites where a formal SLA is not a contractual requirement, the practical uptime difference between the two options is immaterial.

Both options face the cold cache problem when the CDN cache is not yet populated. The difference is financial: a cold cache S3 direct-serve spike costs the S3 egress rate ($0.09/GB) for every image request that misses the cache. A cold cache FTP + BunnyCDN spike costs the CDN delivery rate ($0.01/GB). If your store launch day happens to be the same day you go viral, the financial exposure under a cold cache S3 setup is nine times higher than under FTP + BunnyCDN for the same traffic volume.

Before a planned product launch or sale, use a crawling tool (wget with recursive flag, or a dedicated cache warmer) to pre-fetch the CDN URLs for your key product pages. This populates the CDN cache before visitors arrive, ensuring that your spike traffic is served entirely from edge nodes from the first request rather than generating cache misses under load.

Full-page caching eliminates PHP execution for repeat page visits. During a spike where the same product pages are visited thousands of times, page caching means those pages are served as static HTML from cache rather than requiring PHP processing for each visitor. This directly addresses the primary spike failure mode: PHP worker exhaustion.

If you are using S3 as your origin, set an AWS billing alert at a threshold that would indicate unexpected direct-serve traffic. An alert at $20/day in S3 egress would fire within the first hour of a cold-cache traffic spike, giving you time to respond. FTP users do not need this step — there are no egress surprise bills regardless of traffic volume.

Object caching (Redis or Memcached) reduces the database query load per PHP process during a spike by serving repeated queries from memory. For WooCommerce stores, enabling object caching before a promotional event can double or triple the effective throughput of the hosting plan’s PHP worker count.