CGHero rebuilds its CDN on Amazon CloudFront, cutting third-party search cost

CMS & web-platform migrationCDN & edge delivery architectureWeb performance & Core Web Vitals optimizationWeb application firewall & bot mitigationPhased cutover with parity validationUnit-cost optimizationManaged billing & resellPer-service spend attribution

Live

public marketplace on a rebuilt CloudFront edge

Third-party cost

Algolia search spend cut by caching at the edge

Safe cutover

DNS/SSL move with a standing rollback path

Amazon CloudFrontAmazon LightsailAWS WAFRoute 53

Shared anonymously — the customer’s name is held by VeUP and available on request.

VeUP rebuilt the customer's content-delivery plane on Amazon CloudFront, moving its public site off Strapi on AWS Amplify to WordPress on Amazon Lightsail — DNS/SSL cutover with rollback, WordPress-tuned edge caching, AWS WAF hardening, improved Core Web Vitals, and reduced third-party (Algolia) cost.

The challenge

The customer, a CG/VFX talent marketplace, ran its public site on a Strapi frontend on AWS Amplify. It needed to modernize onto a maintainable WordPress platform without losing public-site performance, while getting third-party (Algolia) search cost under control and hardening the edge. And the move had to happen as a controlled cutover with a safe way back.

The solution

A two-phase Amazon CloudFront CDN rebuild and modernization. Phase 1 cut the frontend over to a new/updated Amazon CloudFront distribution with a WordPress origin on Amazon Lightsail and WordPress-appropriate cache behaviors, provisioned AWS Certificate Manager SSL with Amazon Route 53 DNS validation, and executed a controlled Route 53 DNS/SSL cutover retaining AWS Amplify as a rollback buffer. Phase 2 hardened the edge — dynamic page caching to mitigate Algolia cost, a caching-architecture review, Lambda@Edge response handling, Core Web Vitals performance optimization, AWS WAF security hardening against bots/abuse, and CDN usage/cost control — monitored with Amazon CloudWatch.

Architecture

From a Strapi-on-Amplify stack to a WordPress-on-Lightsail origin behind a rebuilt Amazon CloudFront edge.

The rebuilt edge — CloudFront over WordPress on Lightsail, with WAF and Lambda@Edge in front and the Amplify rollback buffer standing by.

Previous-state architecture: Strapi frontend on AWS Amplify with Route 53 DNS and direct, uncached per-request calls to third-party Algolia search. — Where it started — the Strapi frontend on Amplify, every search request hitting Algolia directly.

Production outcomes

KPI	Result
Production outcomes	The marketplace's public site now runs in production through the rebuilt Amazon CloudFront distribution over a WordPress-on-Lightsail origin, with AWS WAF protection and HTTPS-only delivery. Core Web Vitals improved on the rebuilt edge with WordPress-tuned caching, and dynamic page caching cut third-party (Algolia) search request volume and cost.
Engagement window	The relationship began in October 2024. Migration delivery ran through 2024–2025, the CloudFront rebuild and Phase 2 hardening landed in 2025, and the work continues.
Cost / TCO posture	Dynamic page caching at the CloudFront edge cut third-party (Algolia) request volume and cost, while Lightsail capacity right-sizing and CDN usage controls kept infrastructure spend in line.
Lessons & continuation	A CloudFront rebuild with an Amplify rollback buffer makes a CMS migration cutover low-risk; absorbing repeat requests at the edge (dynamic page caching) is a direct lever on third-party search cost; WAF managed rules belong in front of a public marketplace from the cutover.

AWS services in production

Amazon CloudFrontAmazon LightsailAWS Certificate ManagerAmazon Route 53AWS WAFAmazon CloudWatchLambda@Edge