CDN and WAF: Performance and security at the edge

When it comes to your website, significant time must be dedicated to thinking about performance, security, and reliability. Digital agencies are not just responsible for how sites look and function, but for how they behave under real-world conditions: traffic spikes, global audiences, and automated abuse.

One of the most effective improvements Imarc has made across client projects is placing sites behind a Content Delivery Network (CDN) with an integrated Web Application Firewall (WAF). In practice, that usually means Amazon Web Services (AWS) CloudFront paired with AWS WAF. Let’s discuss what these technologies are and how they can help improve your site's performance and security.

What’s a CDN?

The term “CDN” describes a distributed group of servers that provides dozens, hundreds, or thousands of unique entrypoints for your site. A CDN sits in front of your website and becomes the place where all web requests begin for your users. 

Instead of users connecting directly to your application server, their traffic is routed through the closest edge server. When content can be cached, it is served directly from the CDN’s edge server without touching the origin.

This changes the performance profile of your site in important ways. Latency drops because there’s less physical distance between your user and your entrypoint. TLS connections are terminated closer to users. Origin servers see fewer requests, which means more users can use the site at the same time without slowdown. Nearly all websites become faster and more resilient simply by being behind a CDN.

CDNs are a big win for Craft CMS

Craft CMS, like many server-rendered platforms, benefits immensely from this model. PHP execution and database queries are relatively expensive compared to serving cached responses. A CDN is very good at ensuring that the same work isn’t repeated unnecessarily.

With sensible cache headers and Craft’s own caching tools, CloudFront can serve rendered HTML pages, assets, and media directly from the edge for large portions of your site’s traffic. The result is fewer PHP processes spinning up, less database hits, and more consistent response times. The site still behaves dynamically where needed, but it no longer pays the full cost of dynamic rendering on every request.

Implementation is straightforward

CDNs are often overlooked or put on hold because they sound complex or risky. In reality, introducing a CDN like CloudFront is typically a small and straightforward change. Most of the work happens at the infrastructure and DNS level, not inside the application itself. In many cases, no code changes are required to get meaningful benefits.

At Imarc, we roll CDN implementations out incrementally while validating behavior in non-production environments. This approach keeps risk low while still delivering immediate improvements and providing ample opportunity to adjust caching rules to fit your site.

What a WAF brings to the table

A Web Application Firewall (WAF) is designed to inspect incoming HTTP requests and block the ones that shouldn’t be there. That includes common attack patterns like SQL injection and cross-site scripting, but also the constant stream of automated scans, bots, and malformed requests that hit every internet-accessible website.

Importantly, a WAF isn’t just about protecting against catastrophic breaches or major hack attempts. It’s constantly inspecting your requests and preventing bots from overloading your application server. Every request that gets blocked at the edge is one less request your application has to parse, route, log, and reject on its own.

Security that improves performance

Because WAFs reject bad requests before they ever reach your application server, they have a measurable performance impact. Application servers spend more time handling legitimate users and less time dealing with junk traffic. One of the most common failure modes for public websites is suddenly receiving a torrent of bot traffic before the server can scale up to accommodate it. If those requests never reach the server because the WAF blocks them first, there’s no incident!

This is especially noticeable on CMS-driven sites where even a failed request can trigger a meaningful amount of back-end work. Blocking that traffic before it reaches the application keeps resource usage predictable and stable.

Why we treat WAFs as non-optional

If a site is behind a CDN, we always enable a WAF policy regardless of the site’s size.

Most attacks on the web are automated and indiscriminate. They’re not targeting a specific brand or industry; they’re simply scanning for weaknesses. A baseline WAF configuration blocks a large percentage of that traffic immediately at a low cost. The risk of not having one in front of your site is likely greater than the effort required to implement.

Even small sites that don’t consider themselves “high risk” benefit from reduced bot request noise and more consistent performance. Those things translate to fewer incidents and less friction for your users.

A solid foundation

CDNs and WAFs won’t fix every performance or security issue on their own. What they do provide is a strong, practical entrypoint for modern websites. When implemented thoughtfully, they make sites faster, more resilient, and easier to operate without requiring invasive changes to application code.

If you need a web development partner who can help you strategize for site performance and security, say hello.