Handle Traffic Spikes on Static Sites: S3 and Cloudflare

A popular link can turn an inexpensive static site into a costly distribution problem. Static HTML removes database bottlenecks, but oversized downloads, cache misses, and external APIs can still make a launch fail.

This guide separates two deployment paths: an S3 origin distributed through CloudFront, and a site deployed directly to Cloudflare Pages. You will estimate traffic, set safe cache policies, and rehearse a release without treating either platform as unlimited infrastructure.

Model the spike before changing infrastructure

Start with bytes per visit and peak arrival rate, not your monthly visitor average. Open browser developer tools, disable the cache, and load representative pages. Record transferred bytes for HTML, scripts, styles, fonts, and images. Test a returning visit separately because browser caching changes the result dramatically.

Use the Bandwidth & Transfer Time Calculator below to multiply page size by expected visits and compare transfer sizes against a realistic connection speed. Its monthly estimator provides a planning baseline, not a billing quote or a simulation of concurrent requests.

For example, a 2 MB cold visit multiplied by 100,000 visits represents roughly 200 GB in decimal units before retries or additional navigation. Separate edge-delivered bytes from origin fetches. A high cache-hit ratio reduces origin traffic, but does not make the visitor's download disappear. Treat bots, downloads, and uncached responses as separate budget lines.

Choose one delivery path and protect its origin

With S3 plus CloudFront, keep the bucket private and use CloudFront Origin Access Control with the S3 REST endpoint. Restrict the bucket policy to the intended distribution. S3 website endpoints behave differently, require public website access for this pattern, and cannot use OAC. Do not mix those architectures accidentally.

Follow the Amazon S3 documentation for access controls, object metadata, and request behavior. Configure HTTPS, your custom domain, and the distribution's default root object before promoting DNS. Deep links may need explicit rewrites or error handling; a default root object alone does not implement single-page application routing.

With Cloudflare Pages, publish the generated output through its supported deployment workflow. Pages is not a switch that places a private S3 bucket behind Cloudflare. Its static hosting, build pipeline, and optional Functions have different limits. Review the Cloudflare documentation for current Pages limits and caching behavior rather than assuming account tiers behave identically.

Avoid adding a second CDN merely for reassurance. Layered caches complicate purges, error diagnosis, headers, and incident ownership. First establish which service terminates HTTPS, serves cached objects, and receives an origin request when a cache misses.

Publish immutable assets and refreshable HTML

Give scripts, styles, and versioned images content-hashed filenames. These can use long cache lifetimes because a changed file gets a new URL. Give HTML a short lifetime or require revalidation so visitors discover new asset names. Never apply a year-long immutable policy indiscriminately to the entire build directory.

For an S3 deployment, a minimal example is:

aws s3 sync ./dist/assets/ s3://example-static-site/assets/ \
--cache-control 'public,max-age=31536000,immutable'
aws s3 cp ./dist/index.html s3://example-static-site/index.html \
--content-type 'text/html' \
--cache-control 'public,max-age=0,must-revalidate'

These commands assume the build actually uses hashed assets. Upload every HTML route with the appropriate policy, not only the homepage. Check the CloudFront cache policy too: a positive minimum TTL can retain responses despite restrictive origin directives. Also remember that unchanged objects may keep old metadata when a sync skips them.

For Pages, place a custom headers file named _headers in the deployed output for routes that support it:

/assets/*
Cache-Control: public, max-age=31536000, immutable

Inspect the resulting response; Pages has its own defaults and cache behavior. Headers for static responses do not automatically govern responses produced by Functions. The MDN web documentation explains how browser freshness and shared-cache directives interact.

Upload assets before HTML and retain old hashed files through the rollback window. Otherwise, an older open tab can request a chunk deleted by an eager cleanup. A cache invalidation cannot repair an asset that no longer exists.

Test the response path, not just the homepage

Use header inspection to confirm content type, compression, and cache directives after deployment. Request the same asset more than once, but do not assume a repeated request always reaches the same edge location. Cache status and age headers are useful evidence, not a global health report.

curl -sSI https://example.com/
curl -sSI https://example.com/assets/app.a1b2c3.js
curl -sS -o /dev/null \
-w 'status=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/

Replace the asset filename with one from your actual build. A HEAD request does not measure a complete download. Use GET requests and browser waterfalls to examine transferred bytes, then test several representative routes, including a missing page and a direct navigation to a nested URL.

Run bounded load tests only against infrastructure you control and within provider rules. Increase concurrency gradually, set a request ceiling, and stop when errors rise. A developer laptop or local connection can become the bottleneck before the CDN does. Record test location, cache warmth, response codes, and payload size alongside latency.

The website speed audit workflow helps separate delivery latency from heavy client-side execution. A fast HTML response will not rescue a page that downloads unnecessary megabytes of JavaScript.

Budget for misses, dependencies, and recovery

A static shell often calls dynamic dependencies such as search, analytics, forms, or account APIs. Inventory those endpoints and their quotas. Cache public read-only results where appropriate, debounce expensive searches, and give unavailable optional services a graceful fallback. Never cache personalized responses as if they were public assets.

Set cost and error alerts before launch. Track distribution requests, origin errors, transfer volume, build failures, and Functions usage where applicable. Billing alerts are notifications, not guaranteed hard spending caps. Assign someone authority to disable an expensive optional feature during an incident.

Return to the transfer budget calculator after image optimization and compare the revised page size with the original estimate. Use measured output rather than subtracting a guessed compression percentage. For broader planning, browse the Web Hosting & Servers guides.

Keep a known-good deployment ready and practice restoring it. During a spike, prefer rolling back broken HTML to purging every cached object. Broad purges can turn a healthy warm edge into a wave of origin requests precisely when you need stability most.

Keep a short incident checklist next to the deployment procedure. It should identify the active release, the person authorized to roll back, and the dashboards that distinguish edge failures from origin failures. Rehearse the checklist while traffic is quiet so the first real spike is not also the first test of your response process.

Key takeaways

• Estimate cold-visit transfer and peak demand separately; monthly averages hide launch-day pressure.
• Choose private S3 with CloudFront or Pages deliberately, and verify each platform's actual limits.
• Cache hashed assets for the long term while keeping HTML refreshable and old assets available.
• Validate real responses, nested routes, dynamic dependencies, alerts, and rollback before publishing a popular link.