CDNs, or Content Delivery Networks, are made up of many edge servers all around the world, and cache your website’s content or static files for greater performance and significantly lower last-mile latency to the end user.
What Is a Cloud CDN?
CDNs are usually used for two reasons. The first is for hosting large static content that would be infeasible to host on a traditional web server—things like large videos, images, or other large static media. Cloud CDN can connect to a Cloud Storage bucket, and serve content directly from it.
Because CDNs cache content around the world, they’re also used for performance, as a layer of cache for your entire website. For many publicly accessible pages, you don’t need to be serving it directly from your web server, especially for sites like WordPress where there is server side processing going on for every request. Instead, a CDN sits in front of it, and handles the bulk of the load.
Google’s Cloud CDN works fairly comparatively to other offerings like AWS CloudFront, but it has one cool feature none of the others have—a single anycast IP for the whole network. Because Google actually owns a lot of the physical internet, most of the internal traffic can be sent over Google-controlled equipment, making up their Premium network tier. Rather than having one load balancer per region, you can simplify your architecture and have every instance behind a single global load balancer.
Unlike AWS CloudFront, Cloud CDN by itself is just a cache, and requires Google’s Premium network tier. Because it’s really just something you can turn on for performance, it requires a Load Balancer to connect to in order to serve content and provide most of the configuration. This means you’ll always be paying at least $20 per month for the load balancer, plus any data charges that will apply. It makes the “free S3 website” configuration impossible on GCP, though they do have Firebase Hosting that can do the same job.
Setting Up Cloud CDN
Head over to the GCP Networking Console to get started. Click “Add Origin” from the Cloud CDN tab.
Because Cloud CDN uses a Load Balancer for the backend, you’ll need one of them. If you already have one, you can select it here, but if not click “Create Load Balancer.”
If you’re serving content from Compute Engine or containers, add a new backend service, select the port, and select the instance group. If you don’t have auto-scaling set up, you can create a new unmanaged group.
If you’re serving content from Cloud Storage, simply select the backend bucket that you wish to use.
On the next tab, you can configure the routing rules. You can create simple routing rules to match specific paths and route them to different backends, or create more complex rules to redirect and rewrite URLs. For example, you may wish to serve static media from a /media route pointed at a Cloud Storage backend bucket, and have all other requests directed to your webserver.
The next tab is frontend setup, which involves setting the protocol (HTTPS, most likely), switching the ephemeral IP address to a static one, and selecting your SSL certificate. If you don’t have one, you can provision one from Google for free.
Click “Create,” and head back over to the Cloud CDN setup. Select the newly created load balancer, and turn on Cloud CDN for each backend.
Click “Add,” and the CDN will turn on. It’s really that simple—most of the configuration happens in the load balancer, so if you need to make changes you’ll likely need to edit the load balancer.
As far as the CDN itself goes, there’s a monitoring tab that displays some metrics, as well as a manual override for cache invalidations.
For your DNS configuration, just point it at the load balancer. Cloud CDN automatically sits in front of it.
