{"id":715,"date":"2026-04-15T03:37:11","date_gmt":"2026-04-15T03:37:11","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-cdn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-15T03:37:11","modified_gmt":"2026-04-15T03:37:11","slug":"google-cloud-cdn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-cdn-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Google Cloud CDN Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Cloud CDN is Google Cloud\u2019s content delivery network feature for accelerating content delivery over the public internet. It works by caching cacheable HTTP(S) responses at Google\u2019s edge locations so users can fetch content from a nearby edge cache instead of always going back to your origin.<\/p>\n\n\n\n<p>In simple terms: you place Cloud CDN in front of your website, APIs, or download endpoints (typically through an external Application Load Balancer), and Google serves repeated requests faster and with less load on your backends.<\/p>\n\n\n\n<p>Technically, Cloud CDN is enabled on a Google Cloud external HTTP(S) load balancer backend (a backend service or a backend bucket). When requests arrive at the load balancer, Cloud CDN evaluates cacheability (based on HTTP headers and your CDN policy), looks up the object in edge cache, and either serves it from cache (cache hit) or fetches it from the origin (cache miss \/ cache fill). It integrates closely with Google Cloud Load Balancing, Cloud Armor, Cloud Logging\/Monitoring, and Cloud Storage (as an origin via backend buckets).<\/p>\n\n\n\n<p>The main problem Cloud CDN solves is latency and scalability for internet-facing content. It reduces round-trip time, offloads origin compute and storage, smooths traffic spikes, and can lower bandwidth costs in some patterns\u2014while keeping operations integrated into Google Cloud Networking.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud CDN?<\/h2>\n\n\n\n<p>Cloud CDN (Google Cloud) is a caching layer at Google\u2019s edge that accelerates delivery of HTTP(S) content served through Google Cloud external Application Load Balancing.<\/p>\n\n\n\n<p><strong>Important naming note (current product status):<\/strong>\n&#8211; The service name <strong>Cloud CDN<\/strong> is current and active on Google Cloud.\n&#8211; Google also offers <strong>Media CDN<\/strong> for certain high-throughput media delivery use cases. Media CDN is a different product with different capabilities and operational model. This tutorial focuses only on <strong>Cloud CDN<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Cloud CDN\u2019s purpose is to <strong>cache and deliver content closer to end users<\/strong> using Google\u2019s globally distributed edge infrastructure, reducing latency and origin load.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Edge caching for cacheable HTTP(S) responses.<\/li>\n<li>Configurable caching behavior (cache mode, TTLs, cache keys).<\/li>\n<li>Cache invalidation.<\/li>\n<li>Support for origins behind Google Cloud external Application Load Balancing:<\/li>\n<li>Compute Engine instance groups \/ NEGs (including serverless NEGs)<\/li>\n<li>Cloud Storage via backend buckets<\/li>\n<li>(Other supported origins via load balancer backends as documented)<\/li>\n<li>Observability via load balancer logs and Cloud Monitoring metrics.<\/li>\n<li>Integration with Cloud Armor (WAF \/ DDoS protections) and TLS features of the load balancer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (how you \u201cuse\u201d Cloud CDN)<\/h3>\n\n\n\n<p>Cloud CDN is not deployed as a standalone service. You enable it on load balancer components:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>External Application Load Balancer (HTTP(S))<\/strong>: the entry point with a global anycast IP.<\/li>\n<li><strong>URL map<\/strong>: routes requests to backends.<\/li>\n<li><strong>Backend service<\/strong> (for compute\/serverless origins) and\/or <strong>backend bucket<\/strong> (for Cloud Storage origin).<\/li>\n<li><strong>Cloud CDN policy<\/strong> (on backend service) or <strong>enable-cdn<\/strong> (on backend bucket): controls caching behavior.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed edge caching feature<\/strong> attached to Google Cloud Load Balancing.<\/li>\n<li>Control plane configured per <strong>project<\/strong>.<\/li>\n<li>Data plane served globally at Google edge locations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: global\/regional\/zonal<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud CDN is <strong>global<\/strong> in the sense that it uses Google\u2019s global edge network and is typically used with <strong>global external HTTP(S) load balancing<\/strong>.<\/li>\n<li>Your <strong>backends<\/strong> can be regional\/zonal (for example, zonal instance groups) or global (for example, Cloud Storage), but the CDN edge is global.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud CDN sits squarely in <strong>Google Cloud Networking<\/strong>:\n&#8211; It is commonly paired with:\n  &#8211; <strong>Cloud Load Balancing (external Application Load Balancer)<\/strong>\n  &#8211; <strong>Cloud Armor<\/strong> for security controls at the edge\n  &#8211; <strong>Cloud Logging<\/strong> (load balancer request logs)\n  &#8211; <strong>Cloud Monitoring<\/strong> (cache hit ratio, request count, latency)\n  &#8211; <strong>Cloud Storage<\/strong> (as a static origin using backend buckets)\n  &#8211; <strong>Certificate Manager<\/strong> \/ managed certificates (for TLS termination at the load balancer)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud CDN?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster user experience<\/strong>: lower latency improves conversions and engagement for user-facing apps.<\/li>\n<li><strong>Better resilience during spikes<\/strong>: caching absorbs bursts (product launches, marketing campaigns, breaking news).<\/li>\n<li><strong>Potential cost efficiency<\/strong>: offloading requests can reduce origin compute and origin egress, depending on your architecture and traffic profile.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Edge caching close to users<\/strong> reduces latency and time-to-first-byte (TTFB) for cacheable content.<\/li>\n<li><strong>Global anycast entry point<\/strong> via the external Application Load Balancer provides robust routing.<\/li>\n<li><strong>Origin protection<\/strong>: fewer requests reach your origin, and origin can be isolated behind the load balancer.<\/li>\n<li><strong>Configurable caching behavior<\/strong> (TTL, cache keys, negative caching, etc.) helps you tune correctness vs performance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed service<\/strong>: no need to operate your own caching proxies across regions.<\/li>\n<li><strong>Integrated logging\/metrics<\/strong>: diagnose cache hit\/miss, latency, and errors using standard Google Cloud tools.<\/li>\n<li><strong>Infrastructure as code friendly<\/strong>: CDN config is part of load balancer resources, manageable with Terraform and CI\/CD.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Works with Cloud Armor<\/strong> for WAF rules, rate limiting, and L7 DDoS protections at the edge.<\/li>\n<li><strong>TLS termination<\/strong> at Google edge using managed certificates and modern SSL policies.<\/li>\n<li><strong>Central control plane<\/strong> with IAM and audit logging for change tracking.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Offloads traffic<\/strong> from origins and reduces hot-spot pressure on application servers.<\/li>\n<li><strong>Efficient for static and semi-static content<\/strong> such as images, JS\/CSS bundles, downloads, and public API GET responses.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Cloud CDN<\/h3>\n\n\n\n<p>Choose Cloud CDN when:\n&#8211; Your workload is <strong>HTTP(S)<\/strong> and you can use an external Application Load Balancer.\n&#8211; You have <strong>cacheable content<\/strong> (static assets, downloads, images, public responses).\n&#8211; You want <strong>Google-managed edge caching<\/strong> integrated into Google Cloud Networking.\n&#8211; You already use or plan to use <strong>Cloud Load Balancing<\/strong> and want CDN with minimal extra moving parts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid or reconsider Cloud CDN when:\n&#8211; Your content is <strong>highly personalized<\/strong> per user and cannot be safely cached.\n&#8211; You require <strong>non-HTTP(S)<\/strong> delivery (pure TCP\/UDP) at the edge.\n&#8211; You need <strong>full control<\/strong> of edge compute\/logic beyond what load balancing + CDN provides (you may need a specialized edge platform; evaluate other options).\n&#8211; You cannot route traffic through Google Cloud external HTTP(S) load balancing (for example, strict architectural constraints).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud CDN used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Media and publishing (article pages, images, public video manifests)<\/li>\n<li>E-commerce (product images, static JS\/CSS, category pages with controlled caching)<\/li>\n<li>SaaS and B2B platforms (static assets for single-page apps, documentation sites)<\/li>\n<li>Gaming (patch distribution, launchers, static content)<\/li>\n<li>Education (course content, public lecture materials)<\/li>\n<li>Public sector (public information sites with high availability and scale needs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering and SRE teams standardizing ingress and edge controls<\/li>\n<li>DevOps teams building CI\/CD pipelines for web delivery<\/li>\n<li>Security teams enforcing edge policies with Cloud Armor<\/li>\n<li>App teams optimizing performance for web and mobile clients<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Static web content and assets<\/li>\n<li>Download endpoints (installers, archives)<\/li>\n<li>Image delivery and resizing pipelines (when paired with an image backend)<\/li>\n<li>Public or semi-public APIs where GET responses can be cached safely<\/li>\n<li>Hybrid workloads where origin runs on Compute Engine, GKE, Cloud Run, or Cloud Storage<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single global external HTTPS load balancer with multi-region backends<\/li>\n<li>Cloud Storage \u201cstatic origin\u201d with backend bucket<\/li>\n<li>Multi-backend routing using URL maps (e.g., <code>\/static\/*<\/code> cached heavily, <code>\/api\/*<\/code> cached lightly or not cached)<\/li>\n<li>Layered security at edge: CDN + Cloud Armor + TLS + logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Cloud CDN is most valuable when you have real traffic, global users, and meaningful cache reuse.<\/li>\n<li><strong>Dev\/test<\/strong>: useful for learning and validating caching behavior, headers, and invalidation workflows\u2014but watch out for:<\/li>\n<li>Logging costs<\/li>\n<li>Accidentally making buckets public<\/li>\n<li>Misinterpreting results due to small request volume (cache may evict quickly depending on demand)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Cloud CDN is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Accelerate static website assets for a web app<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Users worldwide experience slow loads for JS\/CSS bundles and images.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Static assets are highly cacheable and benefit from edge distribution.<\/li>\n<li><strong>Example scenario:<\/strong> A React SPA hosted behind an external HTTPS load balancer caches <code>\/assets\/*<\/code> for days with versioned filenames.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Offload Cloud Storage static content delivery<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Direct bucket access can create performance variability and complicate edge security controls.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Backend buckets let you front Cloud Storage with the load balancer and CDN.<\/li>\n<li><strong>Example scenario:<\/strong> A documentation site stores HTML and images in Cloud Storage; Cloud CDN caches globally and uses Cloud Armor to block abusive IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Software download and patch distribution<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Large binaries cause origin bandwidth spikes and slow downloads in distant regions.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Repeated downloads cache well, reducing origin load.<\/li>\n<li><strong>Example scenario:<\/strong> A desktop app update endpoint serves versioned installers; Cloud CDN caches by path and serves most downloads from edge.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Cache public API GET responses (carefully)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> High read traffic on public endpoints overloads backend services.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> You can cache safe GET responses with controlled cache keys and TTLs.<\/li>\n<li><strong>Example scenario:<\/strong> A public \u201cproduct catalog\u201d API caches GET <code>\/v1\/catalog?category=...<\/code> with query-string caching and short TTL.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Improve performance for image-heavy content<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Image requests dominate traffic and cause backend hot spots.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Images are cache-friendly, and edge caching reduces repeated origin fetches.<\/li>\n<li><strong>Example scenario:<\/strong> A marketplace caches <code>\/images\/*<\/code> for 30 days while ensuring cache busting via content hashes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Protect origins from traffic bursts (\u201cflash crowds\u201d)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> News or social virality sends massive traffic to a small set of pages.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Cached responses absorb much of the burst; origin sees fewer requests.<\/li>\n<li><strong>Example scenario:<\/strong> A public announcement page is cached for minutes; origin handles only cache misses and refreshes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Deliver static content for mobile apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Mobile users on high-latency networks experience slow content fetches.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Edge caching reduces RTT; HTTP(S) load balancer provides global entry.<\/li>\n<li><strong>Example scenario:<\/strong> A mobile app fetches JSON configuration and images; config is cached briefly, images longer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Multi-origin routing with different caching policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> One backend serves APIs and static assets; caching needs differ by path.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> URL maps route to different backends; enable CDN only where appropriate.<\/li>\n<li><strong>Example scenario:<\/strong> <code>\/static\/*<\/code> routes to Cloud Storage backend bucket with CDN; <code>\/api\/*<\/code> routes to Cloud Run NEG without CDN.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Add edge security controls with Cloud Armor + caching<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Bot traffic and L7 attacks stress origins.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Cloud Armor can block\/rate-limit at edge; CDN reduces origin exposure.<\/li>\n<li><strong>Example scenario:<\/strong> A public site blocks suspicious geographies and rate-limits login paths, while caching public pages and assets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Reduce latency for globally distributed SaaS marketing site<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Marketing pages must load fast worldwide and withstand campaign spikes.<\/li>\n<li><strong>Why Cloud CDN fits:<\/strong> Easy to cache HTML with short TTL and assets with long TTL.<\/li>\n<li><strong>Example scenario:<\/strong> A SaaS company caches HTML for 60 seconds and assets for 30 days; deployments purge or version assets.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on commonly used, currently relevant Cloud CDN capabilities. For exact limits and latest behavior, verify in official docs: https:\/\/cloud.google.com\/cdn\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Enable CDN on backend services and backend buckets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Turns on edge caching for a backend service (compute\/serverless origins) or a backend bucket (Cloud Storage origin).<\/li>\n<li><strong>Why it matters:<\/strong> Cloud CDN is configured where traffic meets your origin (the load balancer backend).<\/li>\n<li><strong>Practical benefit:<\/strong> You can selectively enable CDN only for the routes that benefit.<\/li>\n<li><strong>Caveats:<\/strong> Cloud CDN is tied to external HTTP(S) load balancing; it is not a generic cache you can attach to any protocol.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Cache modes and TTL behavior<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you decide whether Cloud CDN honors origin cache headers or applies broader caching rules.<\/li>\n<li><strong>Why it matters:<\/strong> Correctness (fresh data) vs performance (cache reuse) depends on TTL strategy.<\/li>\n<li><strong>Practical benefit:<\/strong> You can:<\/li>\n<li>Respect <code>Cache-Control<\/code>\/<code>Expires<\/code> headers for standard web behavior, or<\/li>\n<li>Apply a policy for more aggressive caching (for truly static assets).<\/li>\n<li><strong>Caveats:<\/strong> If you override caching behavior, you must ensure your application supports it (cache busting\/versioning, purge strategy). Verify exact cache mode names and options in current docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Cache key configuration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls what request attributes must match for a cached response to be reused (for example: host, path, query string, headers, cookies\u2014per supported configuration).<\/li>\n<li><strong>Why it matters:<\/strong> Cache keys directly affect:<\/li>\n<li>Cache hit ratio<\/li>\n<li>Risk of serving incorrect content<\/li>\n<li><strong>Practical benefit:<\/strong> You can ignore unimportant query parameters (e.g., tracking params) to improve cache hits.<\/li>\n<li><strong>Caveats:<\/strong> Overly broad cache keys can cause content mix-ups; overly narrow keys reduce hit ratio and increase origin load.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Cache invalidation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Purges cached content so new content is served from origin.<\/li>\n<li><strong>Why it matters:<\/strong> You need a reliable way to update content before TTL expires.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate invalidations into CI\/CD after deploys.<\/li>\n<li><strong>Caveats:<\/strong> Invalidations can take time to propagate; design for versioned assets when possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Negative caching (caching of error responses)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows caching certain error responses for short periods (where supported and configured).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents repeated origin hits for missing resources or transient errors.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduces thundering-herd effects for popular missing objects.<\/li>\n<li><strong>Caveats:<\/strong> Misconfiguration can cache errors longer than desired and harm user experience.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Request coalescing (origin request reduction)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Helps reduce duplicate origin fetches when multiple clients request the same uncached object simultaneously (behavior depends on product implementation).<\/li>\n<li><strong>Why it matters:<\/strong> During cache misses or expirations, origins can be overwhelmed.<\/li>\n<li><strong>Practical benefit:<\/strong> Better origin stability under bursty access patterns.<\/li>\n<li><strong>Caveats:<\/strong> Verify in official docs how this is configured and what conditions apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 HTTP(S) performance features inherited from the load balancer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Benefits from Google\u2019s global edge, modern TLS termination, and HTTP protocol optimizations provided by the external HTTP(S) load balancer.<\/li>\n<li><strong>Why it matters:<\/strong> CDN performance is not only caching; it\u2019s also edge connectivity and protocol efficiency.<\/li>\n<li><strong>Practical benefit:<\/strong> Improved performance for both cached and uncached requests.<\/li>\n<li><strong>Caveats:<\/strong> Exact protocol support (HTTP\/2, QUIC\/HTTP3) depends on current load balancer capabilities and configuration. Verify in official load balancing docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Logging and metrics visibility<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides visibility into cache decisions via load balancer logging and monitoring.<\/li>\n<li><strong>Why it matters:<\/strong> You cannot optimize what you cannot measure.<\/li>\n<li><strong>Practical benefit:<\/strong> Track cache hit ratio, latency, and error rates; troubleshoot MISS vs HIT patterns.<\/li>\n<li><strong>Caveats:<\/strong> Logging can increase costs and generate large volumes of data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Integration with Cloud Armor (edge security)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Applies WAF rules, IP allow\/deny, geo-based rules, and rate limiting at the edge for traffic through the load balancer.<\/li>\n<li><strong>Why it matters:<\/strong> Security controls should be as close to the edge as possible.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduce malicious traffic before it hits cache or origin.<\/li>\n<li><strong>Caveats:<\/strong> Some protections require careful tuning to avoid false positives.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 TLS and certificate management (via the load balancer)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Terminate TLS at the edge using Google-managed certificates or Certificate Manager resources.<\/li>\n<li><strong>Why it matters:<\/strong> Modern web delivery expects HTTPS everywhere.<\/li>\n<li><strong>Practical benefit:<\/strong> Centralize cert lifecycle; enable strong SSL policies.<\/li>\n<li><strong>Caveats:<\/strong> Domain ownership validation and provisioning takes time; plan for DNS and certificate issuance steps.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Cloud CDN is implemented as part of the Google Cloud external Application Load Balancer\u2019s request path. Requests come to a global anycast IP. At the edge, Cloud CDN checks whether the request is cacheable and whether the cache already contains a valid response. If yes, it serves from edge; if not, the request is forwarded to the origin backend through the load balancer\u2019s routing and backend selection logic.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (simplified)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Client makes an HTTP(S) request to your domain (resolved to the load balancer\u2019s anycast IP).<\/li>\n<li>The edge checks CDN policy and cache key:\n   &#8211; If cached and fresh: return response from edge (HIT).\n   &#8211; If not cached or expired: forward request to origin (MISS \/ revalidate).<\/li>\n<li>Origin responds (Compute Engine \/ GKE \/ Cloud Run \/ Cloud Storage via backend bucket).<\/li>\n<li>If response is cacheable, Cloud CDN stores it at edge according to TTL and policy.<\/li>\n<li>Subsequent requests are served from edge until TTL expires or you invalidate.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Load Balancing<\/strong>: required; Cloud CDN attaches to its backends.<\/li>\n<li><strong>Cloud Storage<\/strong>: backend bucket origin for static content.<\/li>\n<li><strong>Cloud Armor<\/strong>: edge security policy applied at the load balancer.<\/li>\n<li><strong>Cloud Logging<\/strong>: HTTP(S) load balancer logs include cache-related fields.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: metrics for load balancer and CDN behavior.<\/li>\n<li><strong>Certificate Manager \/ Google-managed certificates<\/strong>: TLS termination at the edge.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>External Application Load Balancer resources (forwarding rules, proxies, URL maps, backends)<\/li>\n<li>Your chosen origin platform:<\/li>\n<li>Compute Engine \/ Managed Instance Groups<\/li>\n<li>GKE (via NEGs)<\/li>\n<li>Cloud Run \/ Cloud Functions (via serverless NEGs, where supported)<\/li>\n<li>Cloud Storage buckets (backend buckets)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane access<\/strong>: IAM controls who can create\/modify load balancers, backends, and CDN settings.<\/li>\n<li><strong>Data plane access<\/strong>: Clients access the anycast IP; optional Cloud Armor rules can block\/allow traffic. For private content, you typically use signed URLs\/cookies or application-layer auth patterns. (Exact supported auth patterns vary\u2014verify in official docs for your architecture.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Internet clients connect to Google\u2019s edge.<\/li>\n<li>Edge routes to your backends over Google\u2019s network.<\/li>\n<li>For multi-region backends, the load balancer selects healthy backends based on policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and analyze <strong>HTTP(S) load balancer logging<\/strong> to view cache results and latency.<\/li>\n<li>Use <strong>Cloud Monitoring<\/strong> dashboards\/alerts for:<\/li>\n<li>Request count and error rates<\/li>\n<li>Backend latency<\/li>\n<li>Cache hit ratio (where available)<\/li>\n<li>Use <strong>Cloud Audit Logs<\/strong> for configuration changes to load balancing\/CDN resources.<\/li>\n<li>Apply <strong>labels<\/strong> (where supported) and consistent naming for cost allocation and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User Browser] --&gt;|HTTP(S)| LB[External Application Load Balancer&lt;br\/&gt;Cloud CDN enabled]\n  LB --&gt;|Cache HIT| U\n  LB --&gt;|Cache MISS \/ Fill| ORIGIN[Origin Backend&lt;br\/&gt;(Cloud Storage \/ Compute \/ GKE \/ Cloud Run)]\n  ORIGIN --&gt; LB\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    C1[Clients&lt;br\/&gt;Web\/Mobile]\n  end\n\n  subgraph Google_Edge[Google Edge]\n    GFE[External HTTPS Load Balancer&lt;br\/&gt;Anycast IP]\n    CDN[Cloud CDN Cache]\n    ARMOR[Cloud Armor Policy]\n  end\n\n  subgraph Google_Cloud[Google Cloud Project]\n    UM[URL Map&lt;br\/&gt;host\/path routing]\n    BB[Backend Bucket&lt;br\/&gt;Cloud Storage Origin]\n    BS[Backend Service&lt;br\/&gt;Multi-region backends]\n    MIG1[Managed Instance Group&lt;br\/&gt;Region A]\n    MIG2[Managed Instance Group&lt;br\/&gt;Region B]\n    LOG[Cloud Logging]\n    MON[Cloud Monitoring]\n  end\n\n  C1 --&gt;|HTTPS| GFE\n  GFE --&gt; ARMOR\n  ARMOR --&gt; CDN\n  CDN --&gt; UM\n  UM --&gt;|\/static\/*| BB\n  UM --&gt;|\/api\/*| BS\n  BS --&gt; MIG1\n  BS --&gt; MIG2\n  GFE --&gt; LOG\n  GFE --&gt; MON\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account and project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with an active <strong>billing account<\/strong>.<\/li>\n<li>A Google Cloud <strong>project<\/strong> where you can create networking and load balancing resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You can do this lab as a project owner, but least-privilege is better in real environments.<\/p>\n\n\n\n<p>For the hands-on tutorial, you typically need permissions to:\n&#8211; Create and manage load balancer resources (forwarding rules, proxies, URL maps, backend buckets).\n&#8211; Create and manage a Cloud Storage bucket and objects.<\/p>\n\n\n\n<p>Common roles (verify and tailor to your org):\n&#8211; <code>roles\/compute.loadBalancerAdmin<\/code> (or equivalent load balancing admin permissions)\n&#8211; <code>roles\/compute.networkAdmin<\/code> (if you also manage networking; may not be required for all steps)\n&#8211; <code>roles\/storage.admin<\/code> (for creating bucket and uploading objects)\n&#8211; <code>roles\/viewer<\/code> for validation tasks<\/p>\n\n\n\n<p>If your organization uses custom roles or restrictions (VPC-SC, org policies), coordinate with your admins.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing must be enabled to create external load balancers and to use Cloud CDN.<\/li>\n<li>Cloud CDN and load balancing incur usage-based charges (see Pricing section).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>gcloud CLI<\/strong> installed and authenticated: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>Optional but helpful:<\/li>\n<li><code>curl<\/code><\/li>\n<li><code>gsutil<\/code> (bundled with Google Cloud SDK; still commonly used for Cloud Storage operations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud CDN is a global edge service used with external HTTP(S) load balancing.<\/li>\n<li>Your origins may be deployed in specific regions\/zones; choose based on user distribution and data residency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You may encounter quotas for:<\/li>\n<li>Forwarding rules<\/li>\n<li>URL maps, proxies<\/li>\n<li>Backend services\/buckets<\/li>\n<li>Invalidation requests<\/li>\n<li>Quotas vary by project and can often be increased via the Quotas page. Verify current quota documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>Enable APIs in your project:\n&#8211; Compute Engine API: <code>compute.googleapis.com<\/code>\n&#8211; Cloud Storage API: <code>storage.googleapis.com<\/code><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Cloud CDN pricing is usage-based and depends on where your users are, how much data they download, and how often cache misses require fetching from your origin.<\/p>\n\n\n\n<p>Because exact prices vary by SKU, geography, and sometimes by negotiated agreements, do not rely on fixed numbers in third-party blogs. Always verify on:\n&#8211; Official Cloud CDN pricing: https:\/\/cloud.google.com\/cdn\/pricing\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you get charged)<\/h3>\n\n\n\n<p>Typical cost components to plan for:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>CDN egress (cache-to-user data transfer)<\/strong><br\/>\n   &#8211; Bytes served from CDN edge to clients.\n   &#8211; Rates vary by destination region.<\/p>\n<\/li>\n<li>\n<p><strong>Cache fill (origin-to-edge data transfer)<\/strong><br\/>\n   &#8211; When CDN fetches from origin on a miss, that data transfer is billed (how it is categorized depends on origin type and SKU; review official pricing terms).<\/p>\n<\/li>\n<li>\n<p><strong>HTTP(S) Load Balancing charges<\/strong><br\/>\n   Cloud CDN is used through the external Application Load Balancer, which has its own pricing dimensions (for example, per rule\/proxy and\/or per GB processed, depending on the load balancer type and pricing model). Verify current load balancing pricing:\n   &#8211; https:\/\/cloud.google.com\/load-balancing\/pricing<\/p>\n<\/li>\n<li>\n<p><strong>Origin costs<\/strong>\n   Depending on your origin, you may also pay for:\n   &#8211; Compute (Compute Engine, GKE, Cloud Run)\n   &#8211; Cloud Storage operations and storage\n   &#8211; Origin egress (if applicable)<\/p>\n<\/li>\n<li>\n<p><strong>Logging\/monitoring costs<\/strong>\n   &#8211; Load balancer request logging can generate significant log volume.\n   &#8211; Logs ingestion\/retention may incur charges.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Google Cloud frequently has free tiers for some products, but CDN\/load balancing typically incur charges once created\/used. Check the official pricing pages for any current free usage tiers and always validate in the Billing console.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Total internet egress served from edge (GB)<\/li>\n<li>Cache miss rate (which increases cache fill and origin load)<\/li>\n<li>Cache key design that fragments cache (many variants of \u201csame\u201d object)<\/li>\n<li>Short TTLs and frequent invalidations (more cache misses\/refills)<\/li>\n<li>High request volume (especially for small objects)<\/li>\n<li>Verbose logging and long retention<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Unexpected logging volume<\/strong> during load tests.<\/li>\n<li><strong>Origin scaling costs<\/strong> if caching is misconfigured and hit ratio is low.<\/li>\n<li><strong>Cache fragmentation<\/strong> from unbounded query strings (e.g., <code>utm_*<\/code>).<\/li>\n<li><strong>Multiple environments<\/strong> (dev\/stage\/prod) each running their own global load balancer resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Serving more from CDN edge often <strong>reduces origin egress<\/strong>, but you still pay for edge egress.<\/li>\n<li>For Cloud Storage origins, be especially careful about:<\/li>\n<li>Cache-Control metadata<\/li>\n<li>Object versioning strategies<\/li>\n<li>Access patterns that force frequent cache fills<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Improve cache hit ratio:<\/li>\n<li>Use long TTLs for versioned assets (<code>app.3f2c1.js<\/code>)<\/li>\n<li>Ignore irrelevant query parameters<\/li>\n<li>Avoid varying on headers unless necessary<\/li>\n<li>Reduce invalidations by using content-hash versioning instead of purging.<\/li>\n<li>Use compression where appropriate (verify supported behavior with your load balancer and clients).<\/li>\n<li>Scope logging:<\/li>\n<li>Enable logging for troubleshooting windows<\/li>\n<li>Sample logs if supported and acceptable<\/li>\n<li>Consider multi-region origin placement to reduce cache fill latency and improve resilience.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small dev\/test setup might include:\n&#8211; A single external HTTP load balancer with Cloud CDN enabled\n&#8211; A Cloud Storage backend bucket\n&#8211; Light traffic for learning and validation<\/p>\n\n\n\n<p>Costs will come from:\n&#8211; Load balancer resource charges and data processing\n&#8211; CDN egress for your test downloads\n&#8211; Minimal Cloud Storage storage\/operations<\/p>\n\n\n\n<p>Use the pricing calculator with your expected monthly GB and request volume. Avoid load testing from many locations unless you intend to pay for the egress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, model these variables:\n&#8211; Monthly egress by geography (NA\/EU\/APAC)\n&#8211; Object size distribution and request rate\n&#8211; Target cache hit ratio\n&#8211; Logging volume and retention policy\n&#8211; WAF\/rate limiting overhead (usually worth it for risk reduction)<\/p>\n\n\n\n<p>Then run \u201cwhat-if\u201d scenarios:\n&#8211; What if hit ratio drops from 90% to 60%?\n&#8211; What if a marketing event triples traffic for 48 hours?\n&#8211; What if a cache key change doubles variants?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Set up Cloud CDN in Google Cloud using a <strong>Cloud Storage backend bucket<\/strong> behind an <strong>external HTTP load balancer<\/strong>, verify cache HIT\/MISS behavior, perform a cache invalidation, and then clean up all resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a Cloud Storage bucket and upload a static file.\n2. Create an external HTTP load balancer with a <strong>backend bucket<\/strong>.\n3. Enable <strong>Cloud CDN<\/strong> on the backend bucket.\n4. Verify caching via response headers (<code>X-Cache<\/code>, <code>Age<\/code>, etc.).\n5. Invalidate cached content and verify the change.\n6. Clean up to avoid ongoing charges.<\/p>\n\n\n\n<p>This lab is designed to be low-cost, but it still creates billable resources (external load balancer + CDN egress). Keep traffic minimal and clean up at the end.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and enable APIs<\/h3>\n\n\n\n<p>1) Set your project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>2) Enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com storage.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs are enabled successfully.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:compute.googleapis.com OR name:storage.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a Cloud Storage bucket and upload content<\/h3>\n\n\n\n<p>1) Choose a globally unique bucket name:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export BUCKET_NAME=\"YOUR_UNIQUE_BUCKET_NAME\"\nexport REGION=\"us-central1\"\n<\/code><\/pre>\n\n\n\n<p>2) Create the bucket (uniform bucket-level access is recommended):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets create \"gs:\/\/${BUCKET_NAME}\" --location=\"${REGION}\" --uniform-bucket-level-access\n<\/code><\/pre>\n\n\n\n<p>3) Create a simple file locally and upload it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; index.html &lt;&lt;'EOF'\n&lt;!doctype html&gt;\n&lt;html&gt;\n  &lt;head&gt;&lt;meta charset=\"utf-8\"&gt;&lt;title&gt;Cloud CDN Lab&lt;\/title&gt;&lt;\/head&gt;\n  &lt;body&gt;\n    &lt;h1&gt;Cloud CDN lab page&lt;\/h1&gt;\n    &lt;p&gt;If you can read this, your origin is working.&lt;\/p&gt;\n  &lt;\/body&gt;\n&lt;\/html&gt;\nEOF\n\ngcloud storage cp index.html \"gs:\/\/${BUCKET_NAME}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p>4) Make the object publicly readable (for lab simplicity)<\/p>\n\n\n\n<p>This lab uses a public object so you can fetch it easily through the load balancer. In production, do not make sensitive content public; use appropriate access controls and consider signed URLs\/cookies. Review current recommended patterns in official docs.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets add-iam-policy-binding \"gs:\/\/${BUCKET_NAME}\" \\\n  --member=\"allUsers\" \\\n  --role=\"roles\/storage.objectViewer\"\n<\/code><\/pre>\n\n\n\n<p>5) (Recommended) Set Cache-Control metadata so caching behavior is predictable.<\/p>\n\n\n\n<p>Using <code>gsutil<\/code> for metadata is common:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gsutil setmeta -h \"Cache-Control:public, max-age=3600\" \"gs:\/\/${BUCKET_NAME}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A Cloud Storage bucket exists with <code>index.html<\/code> uploaded and cache headers set.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Confirm object exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage ls \"gs:\/\/${BUCKET_NAME}\/\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm metadata (either via <code>gsutil ls -L<\/code> or console):<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">gsutil ls -L \"gs:\/\/${BUCKET_NAME}\/index.html\" | sed -n '1,120p'\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a backend bucket with Cloud CDN enabled<\/h3>\n\n\n\n<p>1) Create the backend bucket and enable Cloud CDN:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export BACKEND_BUCKET_NAME=\"cdn-backend-bucket-lab\"\n\ngcloud compute backend-buckets create \"${BACKEND_BUCKET_NAME}\" \\\n  --gcs-bucket-name=\"${BUCKET_NAME}\" \\\n  --enable-cdn\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A backend bucket exists with CDN enabled.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute backend-buckets describe \"${BACKEND_BUCKET_NAME}\" --format=\"yaml(enableCdn,bucketName,name)\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a URL map, target HTTP proxy, and global forwarding rule<\/h3>\n\n\n\n<p>These components create a minimal external HTTP load balancer that routes all requests to the backend bucket.<\/p>\n\n\n\n<p>1) Create a URL map:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export URL_MAP_NAME=\"cdn-url-map-lab\"\n\ngcloud compute url-maps create \"${URL_MAP_NAME}\" \\\n  --default-backend-bucket=\"${BACKEND_BUCKET_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a target HTTP proxy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export HTTP_PROXY_NAME=\"cdn-http-proxy-lab\"\n\ngcloud compute target-http-proxies create \"${HTTP_PROXY_NAME}\" \\\n  --url-map=\"${URL_MAP_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>3) Create a global forwarding rule on port 80:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export FWD_RULE_NAME=\"cdn-forwarding-rule-lab\"\n\ngcloud compute forwarding-rules create \"${FWD_RULE_NAME}\" \\\n  --global \\\n  --target-http-proxy=\"${HTTP_PROXY_NAME}\" \\\n  --ports=80\n<\/code><\/pre>\n\n\n\n<p>4) Get the external IP address:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export LB_IP=\"$(gcloud compute forwarding-rules describe \"${FWD_RULE_NAME}\" --global --format='value(IPAddress)')\"\necho \"Load balancer IP: ${LB_IP}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a public IP for the HTTP load balancer.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute forwarding-rules describe \"${FWD_RULE_NAME}\" --global --format=\"yaml(IPAddress,portRange,target)\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Request the content and observe cache behavior<\/h3>\n\n\n\n<p>1) Fetch headers the first time (likely a MISS):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I \"http:\/\/${LB_IP}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p>Look for headers commonly associated with Cloud CDN\/load balancer responses, such as:\n&#8211; <code>Via: ...<\/code>\n&#8211; <code>Age: ...<\/code> (often appears when cached)\n&#8211; <code>X-Cache: HIT<\/code> or <code>MISS<\/code> (header presence\/format may vary; verify in your environment)<\/p>\n\n\n\n<p>2) Fetch again (should become a HIT after the object is cached):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I \"http:\/\/${LB_IP}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; First request: cache miss (or MISS\/REVALIDATED depending on timing).\n&#8211; Second request: cache hit with a non-zero <code>Age<\/code> header (commonly).<\/p>\n\n\n\n<p><strong>Notes:<\/strong>\n&#8211; Caching is influenced by <code>Cache-Control<\/code> headers and CDN policy.\n&#8211; If you do not see HIT immediately, wait ~30\u2013120 seconds and retry. Some edge caching behavior depends on request patterns and propagation.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Update the object and invalidate the CDN cache<\/h3>\n\n\n\n<p>1) Update <code>index.html<\/code> and upload again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; index.html &lt;&lt;'EOF'\n&lt;!doctype html&gt;\n&lt;html&gt;\n  &lt;head&gt;&lt;meta charset=\"utf-8\"&gt;&lt;title&gt;Cloud CDN Lab&lt;\/title&gt;&lt;\/head&gt;\n  &lt;body&gt;\n    &lt;h1&gt;Cloud CDN lab page (updated)&lt;\/h1&gt;\n    &lt;p&gt;If you can read this, invalidation worked or cache expired.&lt;\/p&gt;\n  &lt;\/body&gt;\n&lt;\/html&gt;\nEOF\n\ngcloud storage cp index.html \"gs:\/\/${BUCKET_NAME}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p>2) Invalidate cached content for the URL map.<\/p>\n\n\n\n<p>Invalidate just the file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute url-maps invalidate-cdn-cache \"${URL_MAP_NAME}\" --path=\"\/index.html\"\n<\/code><\/pre>\n\n\n\n<p>Or invalidate everything (use carefully in production):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># gcloud compute url-maps invalidate-cdn-cache \"${URL_MAP_NAME}\" --path=\"\/*\"\n<\/code><\/pre>\n\n\n\n<p>3) Fetch again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s \"http:\/\/${LB_IP}\/index.html\" | sed -n '1,20p'\ncurl -I \"http:\/\/${LB_IP}\/index.html\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; After invalidation propagates, you should see the updated HTML content.\n&#8211; Headers should show a MISS shortly after invalidation, then HIT again after subsequent requests.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) Origin works (Cloud Storage object exists and is reachable through the LB):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s \"http:\/\/${LB_IP}\/index.html\" | grep -i \"Cloud CDN lab page\" -n\n<\/code><\/pre>\n\n\n\n<p>2) CDN caching is active:\n&#8211; Re-run <code>curl -I<\/code> multiple times and look for <code>Age<\/code> increasing and cache headers indicating HIT\/MISS behavior.<\/p>\n\n\n\n<p>3) Invalidation works:\n&#8211; Update the file, invalidate <code>\/index.html<\/code>, confirm you see the updated content.<\/p>\n\n\n\n<p>If you need deeper visibility, enable\/inspect HTTP(S) load balancer logs and check cache-related fields in Cloud Logging (field names can differ by log format\/version; verify in docs).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>You always see MISS<\/strong>\n&#8211; Confirm the object is cacheable:\n  &#8211; Ensure <code>Cache-Control<\/code> is not <code>no-store<\/code> or <code>private<\/code>.\n  &#8211; Ensure you set <code>Cache-Control: public, max-age=...<\/code> on the object metadata.\n&#8211; Retry after a short wait; caching may not appear instantaneous.\n&#8211; Ensure Cloud CDN is enabled on the backend bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute backend-buckets describe \"${BACKEND_BUCKET_NAME}\" --format=\"value(enableCdn)\"\n<\/code><\/pre>\n\n\n\n<p>2) <strong>403 Forbidden<\/strong>\n&#8211; Bucket\/object may not be public. Re-check IAM binding on the bucket.\n&#8211; Confirm uniform bucket-level access and permissions are correct.<\/p>\n\n\n\n<p>3) <strong>404 Not Found<\/strong>\n&#8211; Ensure the path is correct: <code>\/index.html<\/code>.\n&#8211; Confirm the object exists in the bucket and was uploaded successfully.<\/p>\n\n\n\n<p>4) <strong><code>curl<\/code> works for direct bucket URL but not via load balancer<\/strong>\n&#8211; Confirm URL map default backend bucket is correctly set.\n&#8211; Confirm forwarding rule is global and points to the correct proxy.<\/p>\n\n\n\n<p>5) <strong>Invalidation doesn\u2019t seem to update immediately<\/strong>\n&#8211; Invalidation propagation can take time.\n&#8211; Confirm you invalidated the correct path and URL map.<\/p>\n\n\n\n<p>If something doesn\u2019t match what you see, rely on official Cloud CDN troubleshooting guidance: https:\/\/cloud.google.com\/cdn\/docs\/troubleshooting<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete resources in reverse order.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute forwarding-rules delete \"${FWD_RULE_NAME}\" --global --quiet\ngcloud compute target-http-proxies delete \"${HTTP_PROXY_NAME}\" --quiet\ngcloud compute url-maps delete \"${URL_MAP_NAME}\" --quiet\ngcloud compute backend-buckets delete \"${BACKEND_BUCKET_NAME}\" --quiet\ngcloud storage rm -r \"gs:\/\/${BUCKET_NAME}\"\nrm -f index.html\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All created resources are removed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Split cacheable and non-cacheable paths<\/strong> using URL maps:<\/li>\n<li>Cache <code>\/static\/*<\/code> aggressively<\/li>\n<li>Cache <code>\/api\/*<\/code> only if safe (often short TTL or no CDN)<\/li>\n<li>Prefer <strong>content-hash versioning<\/strong> for assets (e.g., <code>app.&lt;hash&gt;.js<\/code>) to minimize invalidations.<\/li>\n<li>Use <strong>multi-region origins<\/strong> for resilience if your origin is compute-based and your workload requires high availability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use least-privilege roles:<\/li>\n<li>Separate \u201cLB admins\u201d from \u201cstorage admins\u201d.<\/li>\n<li>Protect change operations with:<\/li>\n<li>IAM conditions (where appropriate)<\/li>\n<li>Change management and approvals<\/li>\n<li>Use Cloud Audit Logs to monitor changes to URL maps\/backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Optimize cache hit ratio:<\/li>\n<li>Remove tracking query params from cache key where safe.<\/li>\n<li>Avoid varying on too many headers\/cookies.<\/li>\n<li>Control logging volume:<\/li>\n<li>Enable logging strategically; set retention appropriately.<\/li>\n<li>Avoid unnecessary cache invalidations; rely on asset versioning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Set correct <code>Cache-Control<\/code> and <code>ETag<\/code>\/<code>Last-Modified<\/code> headers at origin.<\/li>\n<li>Ensure your application does not unintentionally disable caching (e.g., <code>Cache-Control: no-store<\/code> globally).<\/li>\n<li>Keep objects cache-friendly:<\/li>\n<li>Use long TTL for immutable assets<\/li>\n<li>Use short TTL for HTML that changes frequently, or implement revalidation patterns as needed<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep origins healthy and scalable:<\/li>\n<li>CDN reduces load, but misses and cache refreshes still hit the origin.<\/li>\n<li>Use health checks and multi-zone\/multi-region deployments for compute origins.<\/li>\n<li>Consider Cloud Armor rate limiting for abusive clients that can still generate cache misses.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build dashboards:<\/li>\n<li>Request rate<\/li>\n<li>Cache hit ratio trends<\/li>\n<li>Backend error rate<\/li>\n<li>Latency percentiles<\/li>\n<li>Alert on:<\/li>\n<li>Sudden drop in cache hit ratio<\/li>\n<li>Spike in 4xx\/5xx<\/li>\n<li>Backend saturation signals<\/li>\n<li>Automate invalidations (sparingly) as part of CI\/CD.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent resource naming (environment, app, purpose):<\/li>\n<li><code>prod-web-urlmap<\/code><\/li>\n<li><code>prod-static-backend-bucket<\/code><\/li>\n<li>Apply labels where supported for cost allocation.<\/li>\n<li>Document cache key rules and TTL strategy per route.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud CDN configuration is managed through Google Cloud IAM on load balancer resources.<\/li>\n<li>Use separate roles for:<\/li>\n<li>Read-only viewers (auditors)<\/li>\n<li>Network\/LB operators<\/li>\n<li>Security policy operators (Cloud Armor admins)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit:<\/strong> Use HTTPS at the load balancer with modern TLS policies.<\/li>\n<li><strong>At rest:<\/strong> Cached objects live in Google-managed edge caches; your origin data should also be encrypted at rest (Cloud Storage and most Google Cloud services are encrypted by default). For regulatory requirements, verify details in official compliance docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>External HTTP(S) load balancer is publicly reachable by design.<\/li>\n<li>Reduce risk with:<\/li>\n<li>Cloud Armor allow\/deny lists and WAF rules<\/li>\n<li>Rate limiting on sensitive endpoints (especially those that cause cache misses)<\/li>\n<li>Separate frontends for public static content vs private application endpoints<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not embed secrets in cacheable responses.<\/li>\n<li>Never cache content that contains:<\/li>\n<li>Session tokens<\/li>\n<li>CSRF tokens<\/li>\n<li>Personalized user data<\/li>\n<li>Use application design patterns that separate personalized data from static assets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable Cloud Audit Logs (Admin Activity is enabled by default for most services) for change tracking.<\/li>\n<li>Use load balancer request logs for forensic analysis, but consider privacy and retention requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data residency: Cloud CDN is global edge caching. If you have strict data residency requirements, confirm whether caching content at global edge locations is acceptable for your compliance profile.<\/li>\n<li>PII: Avoid caching PII in edge caches. Prefer short TTL or no caching for endpoints returning PII.<\/li>\n<li>For regulated environments, validate configurations with your security and compliance teams and review Google Cloud compliance documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Caching authenticated\/personalized pages because cache keys ignore cookies\/authorization.<\/li>\n<li>Making Cloud Storage buckets public without a clear policy.<\/li>\n<li>Not rate limiting endpoints that trigger expensive origin work.<\/li>\n<li>Using overly permissive IAM roles for load balancer configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Default to <strong>cache static assets<\/strong>; be conservative with HTML and APIs.<\/li>\n<li>Use <strong>Cloud Armor<\/strong> to:<\/li>\n<li>Block common attacks<\/li>\n<li>Rate-limit abusive traffic<\/li>\n<li>Use <strong>HTTPS everywhere<\/strong> and enforce strong TLS policies.<\/li>\n<li>Use signed URLs\/cookies (where applicable and supported) for protected content; verify the recommended approach in current official Cloud CDN docs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Verify current limits and constraints in official documentation, especially if you are designing production systems: https:\/\/cloud.google.com\/cdn\/docs<\/p>\n\n\n\n<p>Key limitations and gotchas to plan for:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>HTTP(S) only<\/strong>\n&#8211; Cloud CDN is for HTTP(S) traffic via external Application Load Balancing, not for raw TCP\/UDP delivery.<\/p>\n<\/li>\n<li>\n<p><strong>Not ideal for personalized content<\/strong>\n&#8211; CDN caching can serve the wrong content if cache keys are misconfigured.\n&#8211; Avoid caching responses that vary per user unless you deeply understand the cache key and correctness model.<\/p>\n<\/li>\n<li>\n<p><strong>Cache behavior depends on headers and policy<\/strong>\n&#8211; Missing or overly restrictive <code>Cache-Control<\/code> headers can lead to unexpectedly low cache hit ratios.\n&#8211; Overriding caching policy can cause stale content if you don\u2019t implement versioning\/invalidations.<\/p>\n<\/li>\n<li>\n<p><strong>Invalidations are operationally useful but not a substitute for asset versioning<\/strong>\n&#8211; Overuse of invalidation can create cost and operational noise and may lead to cache churn.<\/p>\n<\/li>\n<li>\n<p><strong>Query strings can fragment cache<\/strong>\n&#8211; If your cache key includes all query parameters, tracking parameters can explode cache variants.<\/p>\n<\/li>\n<li>\n<p><strong>Logging costs can surprise you<\/strong>\n&#8211; High-traffic sites can generate massive log volume.<\/p>\n<\/li>\n<li>\n<p><strong>Origin still matters<\/strong>\n&#8211; CDN does not remove the need for a scalable origin. Cache misses, revalidations, and uncached paths still load your backend.<\/p>\n<\/li>\n<li>\n<p><strong>Global edge vs compliance constraints<\/strong>\n&#8211; Global caching may conflict with strict residency requirements. Validate with governance teams.<\/p>\n<\/li>\n<li>\n<p><strong>Interoperability nuances with authentication<\/strong>\n&#8211; Some authentication patterns and per-user cookies can effectively bypass caching. Plan routes accordingly and verify supported configurations for your chosen auth approach.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud CDN is one option in a broader content delivery and edge networking toolbox.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Cloud CDN (Google Cloud)<\/strong><\/td>\n<td>General HTTP(S) content acceleration integrated with Google Cloud<\/td>\n<td>Tight integration with external Application Load Balancer, Cloud Armor, Cloud Logging\/Monitoring; managed edge caching<\/td>\n<td>Not a general-purpose edge compute platform; caching correctness requires careful cache key\/TTL design<\/td>\n<td>You\u2019re on Google Cloud and want managed CDN with load balancer integration<\/td>\n<\/tr>\n<tr>\n<td><strong>Media CDN (Google Cloud)<\/strong><\/td>\n<td>Media delivery at scale (streaming-focused workloads)<\/td>\n<td>Specialized media delivery capabilities (verify current features in docs)<\/td>\n<td>Different product; may require different integration and operational model<\/td>\n<td>Primary workload is large-scale media streaming and you need media-oriented features<\/td>\n<\/tr>\n<tr>\n<td><strong>Direct Cloud Storage public hosting (no CDN)<\/strong><\/td>\n<td>Simple static hosting with minimal setup<\/td>\n<td>Very simple, fewer moving parts<\/td>\n<td>Higher latency globally; fewer edge security controls; no integrated WAF at edge<\/td>\n<td>Low-traffic static content or internal\/testing needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloudflare CDN<\/strong><\/td>\n<td>External CDN\/WAF in front of multi-cloud origins<\/td>\n<td>Strong edge footprint, feature-rich edge platform<\/td>\n<td>Additional vendor and routing complexity; integration differs from Google Cloud native<\/td>\n<td>Multi-cloud, strong edge features needed, or existing Cloudflare standard<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudFront<\/strong><\/td>\n<td>CDN integrated with AWS<\/td>\n<td>Strong AWS integrations<\/td>\n<td>Not Google Cloud native; cross-cloud complexity<\/td>\n<td>Workload primarily on AWS or you standardize on AWS edge services<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Front Door \/ Azure CDN<\/strong><\/td>\n<td>Microsoft ecosystem edge delivery<\/td>\n<td>Integrates with Azure networking\/security<\/td>\n<td>Cross-cloud complexity if origins are on Google Cloud<\/td>\n<td>Workload primarily on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Fastly<\/strong><\/td>\n<td>Highly programmable CDN and caching control<\/td>\n<td>Deep caching controls, VCL-style customization<\/td>\n<td>Separate vendor and operations; cost model differs<\/td>\n<td>You need advanced caching logic and edge control beyond typical managed options<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed NGINX\/Varnish (regional)<\/strong><\/td>\n<td>Full control, custom behavior<\/td>\n<td>Maximum customization<\/td>\n<td>Operational burden, scaling challenges, less global reach<\/td>\n<td>You must implement custom behavior and accept ops complexity, or have special constraints<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Global e-commerce platform on Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Product images, JS bundles, and marketing pages are slow for international users; origin services experience spikes during promotions.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>External HTTPS load balancer (global anycast)<\/li>\n<li>Cloud CDN enabled on:<ul>\n<li>Backend bucket for static assets in Cloud Storage<\/li>\n<li>Backend service for cacheable marketing pages (short TTL)<\/li>\n<\/ul>\n<\/li>\n<li>Cloud Armor policy with WAF rules and rate limiting<\/li>\n<li>Multi-region origin backends for APIs (generally not cached; separate route)<\/li>\n<li>Centralized logging and monitoring with alerts on cache hit ratio and backend errors<\/li>\n<li><strong>Why Cloud CDN was chosen:<\/strong><\/li>\n<li>Native Google Cloud Networking integration<\/li>\n<li>Strong global performance via Google edge<\/li>\n<li>Unified operational model with load balancing and security controls<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced page load time globally<\/li>\n<li>Lower origin CPU and bandwidth usage<\/li>\n<li>Better stability during promotion spikes<\/li>\n<li>Improved security posture at the edge<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS marketing site + docs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team hosts marketing pages and documentation; international users report slow page loads; ops team is tiny.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Cloud Storage bucket for static site content<\/li>\n<li>Backend bucket + Cloud CDN<\/li>\n<li>External HTTPS load balancer with a Google-managed certificate<\/li>\n<li>Minimal Cloud Armor rules for basic protection (optional, as needs evolve)<\/li>\n<li><strong>Why Cloud CDN was chosen:<\/strong><\/li>\n<li>Simple architecture with low operational overhead<\/li>\n<li>Good performance for a globally distributed audience<\/li>\n<li>Central place to manage TLS and routing<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster site globally<\/li>\n<li>Lower support burden and fewer performance complaints<\/li>\n<li>Scales with minimal re-architecture<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Cloud CDN a standalone service?<\/strong><br\/>\nNo. Cloud CDN is enabled on backends behind Google Cloud external Application Load Balancing (backend services or backend buckets).<\/p>\n\n\n\n<p>2) <strong>Does Cloud CDN work with Cloud Storage?<\/strong><br\/>\nYes, commonly via <strong>backend buckets<\/strong> (Cloud Storage as origin) behind an external HTTP(S) load balancer.<\/p>\n\n\n\n<p>3) <strong>Can Cloud CDN cache dynamic API responses?<\/strong><br\/>\nSometimes, for safe GET endpoints with correct cache headers and cache key configuration. You must ensure correctness and avoid caching personalized content.<\/p>\n\n\n\n<p>4) <strong>How do I know if a response is served from cache?<\/strong><br\/>\nCheck response headers (often <code>X-Cache<\/code> and <code>Age<\/code>) and analyze HTTP(S) load balancer logs\/metrics for cache-related fields. Header formats can vary; verify in your environment.<\/p>\n\n\n\n<p>5) <strong>What is a cache key and why does it matter?<\/strong><br\/>\nA cache key determines which request attributes must match to reuse a cached response. Poor cache key design can either serve incorrect content (too broad) or reduce hit ratio (too narrow).<\/p>\n\n\n\n<p>6) <strong>Do I need to change my application to use Cloud CDN?<\/strong><br\/>\nOften no, but you should:\n&#8211; Ensure correct <code>Cache-Control<\/code> headers\n&#8211; Use versioned asset filenames\n&#8211; Avoid caching personalized responses<\/p>\n\n\n\n<p>7) <strong>What\u2019s the difference between Cloud CDN and Media CDN?<\/strong><br\/>\nThey are different products. Cloud CDN is general-purpose CDN integrated with load balancing. Media CDN is designed for media delivery workflows. Choose based on workload requirements; verify current docs for exact feature differences.<\/p>\n\n\n\n<p>8) <strong>Does Cloud CDN support HTTPS?<\/strong><br\/>\nYes\u2014typically via external HTTPS load balancing with TLS termination at the edge. You manage certs using Google-managed certificates or Certificate Manager.<\/p>\n\n\n\n<p>9) <strong>Can I use Cloud CDN with Cloud Armor?<\/strong><br\/>\nYes. Cloud Armor integrates with the external HTTP(S) load balancer, and Cloud CDN is enabled on the backend side.<\/p>\n\n\n\n<p>10) <strong>How do cache invalidations work?<\/strong><br\/>\nYou issue an invalidation request (often against a URL map path). After propagation, edge caches purge those objects. Use versioned assets to reduce the need for invalidations.<\/p>\n\n\n\n<p>11) <strong>Are invalidations instant?<\/strong><br\/>\nNo. They propagate, and there may be delays. Plan for eventual consistency.<\/p>\n\n\n\n<p>12) <strong>Why am I still seeing MISS after multiple requests?<\/strong><br\/>\nCommon reasons:\n&#8211; Response isn\u2019t cacheable (<code>Cache-Control: no-store\/private<\/code>)\n&#8211; TTL is too small\n&#8211; Cache key is overly specific (query params, headers)\n&#8211; Object hasn\u2019t been cached at your edge location yet<\/p>\n\n\n\n<p>13) <strong>Does Cloud CDN reduce my Google Cloud bill automatically?<\/strong><br\/>\nNot automatically. It can reduce origin load and sometimes origin egress, but you will pay for CDN egress and load balancing. Measure and model.<\/p>\n\n\n\n<p>14) <strong>Can I cache HTML pages?<\/strong><br\/>\nYes, but carefully. HTML changes more often and can be personalized. Use short TTLs, revalidation patterns, and avoid caching user-specific content.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the safest content to cache?<\/strong><br\/>\nImmutable, versioned static assets (JS\/CSS\/images\/fonts) and public downloads. Then evaluate other content types with careful TTL and cache key design.<\/p>\n\n\n\n<p>16) <strong>Do I need a domain name to test Cloud CDN?<\/strong><br\/>\nNot strictly for basic HTTP testing (as shown in the lab using an IP), but production deployments typically use domains and HTTPS.<\/p>\n\n\n\n<p>17) <strong>How do I monitor cache hit ratio?<\/strong><br\/>\nUse Cloud Monitoring metrics and load balancer logs. Create dashboards showing hit ratio trends alongside origin latency and error rates.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud CDN<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud CDN docs overview \u2014 https:\/\/cloud.google.com\/cdn\/docs<\/td>\n<td>Authoritative feature descriptions, configuration guides, and concepts<\/td>\n<\/tr>\n<tr>\n<td>Official tutorial\/getting started<\/td>\n<td>Cloud CDN documentation (setup guides) \u2014 https:\/\/cloud.google.com\/cdn\/docs\/setting-up-cdn-with-bucket<\/td>\n<td>Step-by-step patterns for enabling CDN (verify exact page paths if docs reorganize)<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Cloud CDN pricing \u2014 https:\/\/cloud.google.com\/cdn\/pricing<\/td>\n<td>Current SKUs and pricing dimensions<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Load Balancing pricing \u2014 https:\/\/cloud.google.com\/load-balancing\/pricing<\/td>\n<td>Required because Cloud CDN is used through load balancing<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Model egress, request volume, and load balancing costs<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures and best practices (search for CDN\/LB patterns)<\/td>\n<\/tr>\n<tr>\n<td>Observability docs<\/td>\n<td>Cloud Logging \u2014 https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Learn how to analyze load balancer logs and cache behavior<\/td>\n<\/tr>\n<tr>\n<td>Observability docs<\/td>\n<td>Cloud Monitoring \u2014 https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<td>Build dashboards\/alerts for latency, errors, and cache trends<\/td>\n<\/tr>\n<tr>\n<td>Security docs<\/td>\n<td>Cloud Armor \u2014 https:\/\/cloud.google.com\/armor\/docs<\/td>\n<td>Add WAF and edge protections to CDN-backed endpoints<\/td>\n<\/tr>\n<tr>\n<td>Load balancer docs<\/td>\n<td>External HTTP(S) Load Balancing \u2014 https:\/\/cloud.google.com\/load-balancing\/docs\/https<\/td>\n<td>Core prerequisite concepts and configuration details<\/td>\n<\/tr>\n<tr>\n<td>Official samples<\/td>\n<td>GoogleCloudPlatform GitHub \u2014 https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Search for load balancing and CDN-related infrastructure samples (verify repository relevance)<\/td>\n<\/tr>\n<tr>\n<td>Community learning<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs; search for CDN\/load balancing content<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, cloud operations, CI\/CD, infrastructure fundamentals (check catalog for Cloud CDN\/LB topics)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>Software configuration management, DevOps foundations, cloud basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations practitioners<\/td>\n<td>Cloud ops practices, monitoring, reliability, cost awareness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, production engineers<\/td>\n<td>Reliability engineering, SLIs\/SLOs, incident response, operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify specific topics offered)<\/td>\n<td>Beginners to advanced practitioners<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and coaching (verify Google Cloud coverage)<\/td>\n<td>DevOps engineers, SREs<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training resources (verify offerings)<\/td>\n<td>Teams seeking practical implementation guidance<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify scope)<\/td>\n<td>Operations teams, engineers needing hands-on support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service lines)<\/td>\n<td>Architecture reviews, implementation support, operations<\/td>\n<td>Cloud CDN + load balancer setup; migration planning; observability and cost reviews<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement (verify offerings)<\/td>\n<td>Platform engineering, CI\/CD, cloud operations<\/td>\n<td>Edge delivery strategy; Cloud Armor policy implementation; IaC pipeline for load balancing\/CDN<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify offerings)<\/td>\n<td>DevOps process, tooling, cloud adoption<\/td>\n<td>Implement CDN-backed ingress; monitoring\/alerting design; operational runbooks<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud CDN<\/h3>\n\n\n\n<p>To be effective with Cloud CDN in Google Cloud Networking, learn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>HTTP fundamentals<\/strong><\/li>\n<li>Caching headers (<code>Cache-Control<\/code>, <code>ETag<\/code>, <code>Last-Modified<\/code>)<\/li>\n<li>Cookies and session behavior<\/li>\n<li>Status codes and cacheability concepts<\/li>\n<li><strong>Google Cloud Load Balancing basics<\/strong><\/li>\n<li>External HTTP(S) load balancer components (forwarding rule, proxy, URL map, backend)<\/li>\n<li><strong>Cloud Storage basics<\/strong><\/li>\n<li>Buckets\/objects, IAM, metadata, lifecycle rules<\/li>\n<li><strong>Basic security<\/strong><\/li>\n<li>TLS, certificates, least privilege IAM<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud CDN<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Armor<\/strong> for WAF and edge protections<\/li>\n<li><strong>Advanced load balancer routing<\/strong><\/li>\n<li>Host rules, path matchers, multi-backend routing<\/li>\n<li><strong>Observability<\/strong><\/li>\n<li>Log-based metrics, SLOs, alerting strategies<\/li>\n<li><strong>Infrastructure as Code<\/strong><\/li>\n<li>Terraform for load balancers\/CDN policies<\/li>\n<li><strong>Performance engineering<\/strong><\/li>\n<li>Cache hit ratio optimization<\/li>\n<li>Frontend performance metrics (Core Web Vitals)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Network Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Security Engineer (edge security and WAF)<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Cloud CDN is typically covered as part of broader Google Cloud architecture and networking knowledge rather than as a standalone certification topic. Relevant Google Cloud certifications to consider (verify current certification names and exam guides):\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud Network Engineer<\/p>\n\n\n\n<p>Always verify the current certification catalog: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Build a static site on Cloud Storage behind Cloud CDN and HTTPS; automate deploy + cache invalidation.<\/li>\n<li>Create a multi-backend load balancer:\n   &#8211; <code>\/static\/*<\/code> via backend bucket + CDN\n   &#8211; <code>\/api\/*<\/code> via Cloud Run backend (no CDN or short TTL)<\/li>\n<li>Implement Cloud Armor rate limiting on a download endpoint and measure origin load reduction.<\/li>\n<li>Create dashboards showing cache hit ratio vs backend latency and error rate; set alerts for regressions.<\/li>\n<li>Run a controlled experiment: vary TTL and cache key rules and measure hit ratio and cost impact.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CDN (Content Delivery Network):<\/strong> A distributed system that caches and serves content closer to users to reduce latency and origin load.<\/li>\n<li><strong>Edge cache:<\/strong> Cache servers located near end users (at the \u201cedge\u201d of the network).<\/li>\n<li><strong>Origin:<\/strong> The backend that serves the authoritative content (Cloud Storage, Compute Engine, Cloud Run, etc.).<\/li>\n<li><strong>External Application Load Balancer:<\/strong> Google Cloud\u2019s external HTTP(S) load balancing solution used to route web traffic globally.<\/li>\n<li><strong>Backend bucket:<\/strong> A Google Cloud Load Balancing backend that uses a Cloud Storage bucket as the origin.<\/li>\n<li><strong>Backend service:<\/strong> A load balancer backend definition typically used for compute or serverless origins.<\/li>\n<li><strong>URL map:<\/strong> Load balancer routing configuration based on host\/path rules.<\/li>\n<li><strong>Cache key:<\/strong> The set of request attributes used to identify a cached object (e.g., host + path + query).<\/li>\n<li><strong>TTL (Time To Live):<\/strong> How long a cached response is considered fresh before it must be refreshed\/revalidated.<\/li>\n<li><strong>Cache invalidation:<\/strong> A forced purge of cached content before TTL expiry.<\/li>\n<li><strong>Cache hit \/ miss:<\/strong> A hit is served from cache; a miss requires fetching from origin.<\/li>\n<li><strong>Anycast IP:<\/strong> A single IP advertised from multiple locations; traffic is routed to the nearest\/optimal edge.<\/li>\n<li><strong>WAF (Web Application Firewall):<\/strong> Security rules that detect\/block malicious web traffic (Cloud Armor in Google Cloud context).<\/li>\n<li><strong>Egress:<\/strong> Outbound data transfer (often a major cost driver for CDN and web delivery).<\/li>\n<li><strong>Observability:<\/strong> Monitoring, logging, and tracing used to understand system behavior and performance.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud CDN is Google Cloud\u2019s edge caching capability for accelerating HTTP(S) content delivered through external Application Load Balancing. It matters because it reduces latency for global users, offloads origin traffic, and integrates cleanly into Google Cloud Networking with load balancing, Cloud Armor security controls, and built-in logging\/monitoring.<\/p>\n\n\n\n<p>Cost-wise, focus on the big drivers: CDN egress, cache fill behavior, load balancer charges, origin scaling, and logging volume. Security-wise, avoid caching personalized content, use HTTPS, apply least-privilege IAM, and consider Cloud Armor for edge protection and rate limiting.<\/p>\n\n\n\n<p>Use Cloud CDN when you have cacheable HTTP(S) content and want a managed, Google Cloud-native approach. Avoid it for highly personalized or non-HTTP(S) workloads. The best next step after this tutorial is to deepen your understanding of external HTTPS load balancing, Cloud Armor, and cache key\/TTL design\u2014then productionize with infrastructure-as-code and dashboards\/alerts.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,50],"tags":[],"class_list":["post-715","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/715","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=715"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/715\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}