Cloud Monitoring provides real-time visibility into the health, throughput, and latency of Cloud CDN deployments across all configured backend services. Predefined dashboards offer instant insight into operational health, and custom dashboards like cloud-cdn-monitoring.json can be uploaded to track aggregated load balancing metrics across all backends. External performance reports, including third-party latency and throughput measurements, can supplement internal metrics to evaluate edge network performance. Regular review of these metrics ensures that network administrators can detect latency spikes or unexpected drops in edge cache offload.
Cloud Logging records detailed HTTP request and response information for every Cloud CDN request, allowing granular analysis of cache hit and miss ratios. Each log entry populates the HttpRequest payload with cache lookup details, along with jsonPayload.cacheId to identify the specific airport-coded edge cache location serving the client. Network engineers evaluate cache performance by querying specific log fields. For a Cache Hit, filter by jsonPayload.statusDetails=("response_from_cache" OR "byte_range_caching") or check httpRequest.cacheHit=true where httpRequest.cacheValidatedWithOriginServer!=true. For a Cache Hit Validated With Origin Server, filter by jsonPayload.statusDetails="response_from_cache_validated" or check httpRequest.cacheHit=true alongside httpRequest.cacheValidatedWithOriginServer=true. For a Cache Miss, filter by jsonPayload.statusDetails="response_sent_by_backend" or check httpRequest.cacheLookup=true with httpRequest.cacheHit!=true. Clients can also inspect cache results directly by receiving the cdn_cache_status custom response header configured on the load balancer backend.
Optimizing cache hit ratios requires setting appropriate origin response headers, defining custom cache keys, and configuring compression. Missing Cache-Control headers on origins configured for origin header caching cause cache misses, which administrators resolve by applying explicit directives such as Cache-Control: public, max-age=86400. Because Cloud CDN includes the full URI in the default cache key, unnecessary query strings can shard the cache; engineers should configure custom cache keys to exclude irrelevant query parameters, protocols, or hosts. Unnecessary Vary response headers should be removed to prevent redundant cache sharding for identical resources. Enabling compression at the origin or configuring web server proxies with settings like gzip_proxied any reduces cache fill transfer sizes and lowers egress costs.
Content versioning and selective cache invalidation control the lifecycle of edge-cached assets to prevent stale or truncated data delivery. Invalidation removes cached entries before natural expiration across distributed edge servers, but it operates under eventual consistency and strict rate limits. Because invalidation is intended primarily for emergency removals, URL and filename versioning (such as /v2/style.css or file_v2023.js) is the preferred strategy for updating static assets without cache penalties. When updating existing files that cannot change names, uploads should occur under temporary filenames before an atomic rename to prevent caching incomplete files during transit. Updating byte-range cached objects requires targeted invalidations to prevent clients from receiving mismatched chunk responses during concurrent updates.
Cache key policies determine which request attributes (like query strings or headers) uniquely identify a cached object, while TTL overrides control how long Cloud CDN stores a response before checking the origin for updates. For Cloud Storage buckets, you set TTLs by adding Cache-Control metadata directly to objects, using max-age and s-maxage directives measured in seconds. The max-age applies to all caches, including browsers, whereas s-maxage overrides it for shared caches like Cloud CDN. For managed instance groups (MIGs) and Cloud Run backends, you configure TTLs within your web server software or application code. Choose longer TTLs for static assets (like logos or CSS files) to maximize cache hits and shorter TTLs for dynamic content (like live scores) to ensure freshness, balancing origin load against staleness.
Negative caching rules define how Cloud CDN handles error responses from the origin, such as HTTP 404 (Not Found) or 5xx errors. By default, Cloud CDN does not cache these errors, but you can configure it to cache them for a specified duration to reduce origin load during failures. This is particularly useful for origins like MIGs or Cloud Run services that might generate transient errors. You optimize the overall cache by categorizing content based on update frequency and setting appropriate TTLs. For infrequently changed content, combine long TTLs with versioned URLs (by altering filenames or adding query parameters) to force cache updates without waiting for expiration, as versioning effectively creates a new cache key.
Origin authentication secures the connection between Cloud CDN and your backend, ensuring only trusted requests reach private origins like Cloud Storage buckets or S3-compatible stores. For private Cloud Storage buckets, you use IAM service accounts, while for Amazon S3 buckets, you employ AWS Signature Version 4. To further restrict access, implement IP allowlisting at the origin firewall, permitting only traffic from Cloud CDN's specific IP ranges (IPv4: 136.124.4.0/22, IPv6: 2001:4860:4864:a::/64). This prevents direct user access and other Media CDN customers from specifying your origin. Additionally, for client-facing access control, you can use signed URLs or cookies independently of origin authentication, allowing fine-grained user permissions without exposing the origin.
When Cloud CDN forwards a request to the origin, the Host header sent to the origin is determined by configuration rules. By default, Cloud CDN uses the Host header from the client request. However, you can override this at the service level (EdgeCacheService.hostRewrite) or the origin level (EdgeCacheOrigin.hostRewrite). For Cloud Storage bucket origins, any hostRewrite settings are ignored because the host header is automatically set based on the bucket name. This header rewriting affects both the HTTP Host header and the TLS SNI (Server Name Indication), ensuring the origin receives the expected hostname for routing and certificate validation. The primary and any failover origins see the same host header if they share the same route or rewrite configuration.
Cloud CDN can be enabled on backend services that use several types of origins: managed instance groups (MIGs), Cloud Storage buckets, and Cloud Run services. The global external Application Load Balancer distributes HTTP and HTTPS traffic to backends hosted on these Google Cloud platforms, as well as on-premises and other clouds using different backend configurations. For Cloud Storage backends, the bucket and objects must be public, or you must configure private origin authentication to enable access. You can use the same load balancer for GKE, Cloud Run, Cloud Run functions, and App Engine applications.
To associate Cloud CDN with an external HTTP(S) load balancer, you enable Cloud CDN on the backend service by running gcloud compute backend-services update BACKEND_SERVICE --enable-cdn --cache-mode=CACHE_MODE. The load balancer uses a two-phased routing approach: first, it selects a backend service based on rules defined in a URL map, and then the backend service selects a backend instance based on policies defined in the backend service. Global external Application Load Balancers use global URL maps and global backend services, while regional external Application Load Balancers use regional versions of these resources.
SSL certificates are configured at the load balancer level on the target proxy to enable HTTPS traffic. The external Application Load Balancer supports both HTTP/2 over TLS and cleartext HTTP/2 over TCP (H2C), as well as HTTP/3 which is negotiated between client and server. You can also configure SSL policies to control which TLS versions and cipher suites the load balancer accepts. TLS 1.3 early data support is available with configurable modes for zero-round-trip time (0-RTT) connections.
To control access to cached content, Cloud CDN supports signed URLs and signed cookies that restrict content access to authorized users. When a request includes a valid signature, Cloud CDN serves the content from cache if available; without a valid signature, the request bypasses the cache and goes to the origin. This is useful for premium content, time-limited access, or restricting access to specific users. Logs for Cloud CDN are associated with the external Application Load Balancer that the Cloud CDN-enabled backends are attached to, allowing you to check whether requests are hits or misses.
The backends are protected by Google Cloud Armor security policies that provide Layer 7 filtering by scrubbing incoming requests for common web attacks or other Layer 7 attributes, helping to block traffic before it reaches the load-balanced backend services. Protection against volumetric DDoS attacks is enabled by default on Cloud Armor. Traffic evaluation follows a specific order: first, Cloud Armor edge security policies evaluate the request, then if allowed and cacheable, Cloud CDN serves from cache, and finally on cache miss, backend policies evaluate before either denying or fulfilling the request from the origin.
The external Application Load Balancer supports advanced traffic management features including traffic steering (routing based on HTTP parameters like headers, host, and path), traffic actions (redirects and header transformations), and traffic policies (request mirroring and advanced load balancing algorithms). You can implement weight-based traffic splitting to send different percentages of traffic to different backend services, which is commonly used for deploying new versions, A/B testing, and service migration. Route rules are evaluated in priority order, with path rules evaluated on a longest-path-matches-first basis.
StudyCerts
StudyCertshttpRequest.cacheHit and jsonPayload.statusDetails to distinguish responses from cache, validated cache, or origin.Cache-Control headers), while for MIGs and Cloud Run, TTLs are configured in the web server or application code.136.124.4.0/22 and 2001:4860:4864:a::/64).A cache hit means the response was served directly from the edge cache without contacting the origin. A cache hit validated with the origin server means the edge cache had a cached copy but revalidated it with the origin (using If-Modified-Since or ETag) before serving it, and the origin confirmed it was still fresh.
You must enable Cloud CDN on the backend service and configure private origin authentication using an IAM service account that has read access to the bucket. The bucket and objects can remain private, and Cloud CDN uses the service account credentials to fetch content from the bucket.
Use signed URLs when you need to restrict access to specific users or time-limit access to content, such as for premium video or secure downloads. Use content versioning (e.g., /v2/style.css) when you want all users to access the same content but need to update it without invalidating the cache, because versioning creates a new cache key automatically.
Cloud Armor security policies are evaluated before Cloud CDN cache lookup. If the request is allowed by Cloud Armor and is cacheable, Cloud CDN serves the response from cache. If the request is blocked by Cloud Armor, it is denied before reaching the cache or the origin. On a cache miss, backend policies are evaluated before the request reaches the origin.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills