Hosting Modern Frontend Applications Using S3 + CloudFront

Most frontend applications today are deployed in minutes. Run the build command, upload the files, connect a domain, and the application is live.

But once traffic starts growing, the real challenges begin:

• Users accessing the application from different regions
• Slow asset loading
• Cache-related deployment issues
• SPA routing failures
• Security concerns around public asset hosting

This is where a simple AWS architecture using Amazon Web Services S3 and CloudFront becomes extremely effective for frontend applications.

The Architecture

At a high level, the setup is very straightforward.

             Users
               │
               ▼
      CloudFront CDN
               │
               ▼
        Private S3 Bucket

S3 stores the frontend build artifacts, while CloudFront acts as the global CDN layer responsible for caching and delivering assets closer to users.

Instead of users directly downloading files from S3, requests first reach the nearest CloudFront edge location. If the assets are already cached there, the response is returned immediately without contacting the origin again.

This significantly improves latency and reduces unnecessary traffic to S3.

Why S3 Alone Is Usually Not Enough

S3 static website hosting is great for quick demos and internal applications. However, production-grade frontend applications typically need much more control around performance, security, and caching.

Without CloudFront:

• Assets are not globally cached efficiently
• Buckets are often exposed publicly
• HTTPS handling becomes limited
• SPA routing requires additional handling
• Large-scale traffic can become inefficient

CloudFront solves these problems while keeping the architecture simple.

Understanding the Request Flow

Here’s what happens when a user opens your application:

User Request
     │
     ▼
CloudFront Edge Location
     │
 Cache Hit? ── Yes ──► Return Response
     │
     No
     ▼
Fetch Asset From S3
     │
     ▼
Cache Asset At Edge

The first request may fetch assets from S3, but subsequent users from nearby regions are usually served directly from the edge cache.

This is one of the main reasons CDN-backed frontend applications feel noticeably faster.

A Better Production Setup

One mistake I often see is making the S3 bucket publicly accessible.

A cleaner and more secure approach is:

• Keep the bucket private
• Block all public access
• Allow access only through CloudFront using Origin Access Control (OAC)

In this setup, CloudFront becomes the only public entry point to the frontend application.

On the CloudFront side, a few configurations make a huge difference:

• Redirect HTTP traffic to HTTPS
• Enable compression for assets
• Attach an SSL certificate using ACM
• Configure proper cache behavior
• Add SPA fallback handling

These are small settings, but they directly affect performance and reliability in production.

The SPA Refresh Problem

This is one of the most common issues frontend developers hit after deployment. Imagine a React application with routes like:

/dashboard
/profile
/settings

Navigation works perfectly inside the application.

But if the user refreshes /dashboard, CloudFront forwards the request to S3, and S3 tries to locate an actual file or folder named /dashboard.

Since that path does not physically exist, the result becomes:

403 or 404

The fix is simple but important.

Configure CloudFront custom error responses so that both 403 and 404 errors redirect back to:

/index.html

This allows the frontend router to handle navigation correctly.

Cache Strategy Matters More Than People Think

A lot of frontend deployment issues are actually cache issues. The most important thing is understanding that not every file should be cached the same way.

For index.html, the cache duration should remain short because this file changes frequently during deployments.

Cache-Control: no-cache

For hashed JavaScript and CSS assets, aggressive caching is completely safe.

Cache-Control: public, max-age=31536000, immutable

Files like:

main.ae72f.js
vendor.91ab2.css

are uniquely generated during every build, which means they never need to be overwritten.

This gives excellent CDN performance without serving stale assets.

CI/CD Flow

A typical deployment pipeline usually looks something like this:

Git Push
   │
   ▼
Frontend Build
   │
   ▼
Upload Assets to S3
   │
   ▼
CloudFront Cache Invalidation
   │
   ▼
Production Deployment

The invalidation step is especially important.

Without it, users may continue receiving older cached versions of the application even after a successful deployment.

Final Thoughts

Frontend engineering today goes far beyond building UI components. The way assets are delivered directly impacts:

• Performance
• Scalability
• Security
• User experience

Understanding how AWS S3 and CloudFront work together gives frontend developers a much stronger foundation in cloud-native application delivery.

And honestly, this is one of the simplest AWS architectures that delivers immediate real-world impact.

Thank You.