This chapter covers Cloud CDN (Content Delivery Network) and Cloud NAT (Network Address Translation) in Google Cloud, two critical services for optimizing content delivery and enabling outbound connectivity from private instances. For the ACE exam, these topics appear in roughly 5-8% of questions, often in scenarios involving latency reduction, egress traffic management, or private VM internet access. You'll need to understand the underlying mechanisms, configuration options, and common pitfalls to answer scenario-based questions correctly.
Jump to a section
Imagine a global warehouse chain (Cloud CDN) and a company switchboard (Cloud NAT). The warehouse chain stores popular products (cached content) at locations near customers (edge locations). When a customer requests a product, the nearest warehouse delivers it quickly, reducing the load on the central factory (origin server). The warehouse only stocks items that are frequently requested; if an item isn't in stock, the warehouse requests it from the factory, then stores a copy for future requests. The factory sets rules on which items can be stocked and for how long (cache policies). Now, the company switchboard allows employees (private VMs) to make outbound calls to the outside world (internet) using a single public phone number (NAT IP). Each employee has an internal extension (private IP). When an employee calls out, the switchboard operator records the extension and replaces it with the company number. When the response comes back, the operator looks up the log and routes the call to the correct extension. From outside, nobody can dial employees directly—they only ever see the company number. The switchboard also has a limited number of lines (ports) and can handle only so many simultaneous calls; if too many employees call at once, some calls are dropped (port exhaustion). The warehouse and switchboard work independently but together they optimize traffic: the warehouse reduces inbound requests to the factory, while the switchboard manages outbound traffic from private VMs.
What is Cloud CDN?
Cloud CDN is a globally distributed caching service that accelerates content delivery by caching frequently accessed content at Google's edge locations (over 200 points of presence worldwide). It works with HTTP(S) load balancers (external or internal) to serve cached responses directly to users, reducing latency and load on backend instances. The CDN caches static and dynamic content based on cache policies defined on the backend bucket or backend service.
How Cloud CDN Works Internally
When a user requests content: 1) The request hits the nearest Google edge location. 2) If the content is cached and not expired, the edge serves it directly (cache hit). 3) If not cached (cache miss), the edge forwards the request to the origin (e.g., Cloud Storage bucket or Compute Engine instance). 4) The origin responds, and the edge caches the response according to cache directives (Cache-Control headers, TTL settings). 5) Subsequent requests for the same content are served from cache until it expires or is invalidated.
Key Components and Defaults
Cache modes: USE_ORIGIN_HEADERS (respects origin's Cache-Control), FORCE_CACHE_ALL (caches even without cache headers, default TTL 3600s), CACHE_ALL_STATIC (caches common static file extensions).
Default TTLs: If no cache headers, default TTL is 3600 seconds (1 hour). Negative caching (for 404/500) has a default TTL of 10 seconds.
Maximum cache entry size: 5 GB per object.
Cache key: By default includes host, scheme, and path; can include query parameters, headers, or cookies.
Invalidation: You can invalidate cached content by URL prefix or exact path. There is a limit of 1000 invalidation paths per day per project. Invalidation is not instantaneous; it takes a few minutes to propagate globally.
Signed URLs and Cookies: For private content, you can use signed URLs (for specific paths) or signed cookies (for broader access). Both use HMAC-SHA1 keys.
Configuration and Verification
To enable Cloud CDN on a backend bucket:
gcloud compute backend-buckets create my-bucket-backend \
--gcs-bucket-name=my-bucket \
--enable-cdn \
--cache-mode=CACHE_ALL_STATIC \
--default-ttl=3600To enable on a backend service (e.g., for Compute Engine):
gcloud compute backend-services update my-service \
--enable-cdn \
--cache-mode=USE_ORIGIN_HEADERSVerify with:
gcloud compute url-maps list
gcloud compute backend-buckets describe my-bucket-backendCloud NAT Overview
Cloud NAT (Network Address Translation) allows Compute Engine instances without external IP addresses (private instances) to access the internet for outbound traffic (e.g., updates, external APIs) while preventing unsolicited inbound connections. It is a regional, managed service that uses Cloud Router to advertise IP ranges and handle NAT configurations.
How Cloud NAT Works Internally
Cloud NAT uses Source Network Address Translation (SNAT). Each VM's private IP is translated to one of the NAT external IPs (or a pool). The translation is connection-based: for TCP/UDP, NAT creates a mapping (source IP:port -> NAT IP:port). When the response returns, NAT reverses the mapping and forwards to the original VM. NAT uses a port range (1024-65535) per NAT IP, and each connection consumes one port. If all ports are exhausted, new connections are dropped.
Key Components and Defaults
NAT IP addresses: You can assign a single IP or a pool (up to 64 per gateway). Auto-allocated IPs come from the same region.
Port exhaustion: Default maximum ports per VM is 64,000 per NAT IP. You can configure minimum ports per VM (default 64) and max ports per VM (default 65536).
Idle timeout: Default 30 seconds for TCP, 30 seconds for UDP, 5 minutes for ICMP. You can configure these (range 10s-120s for TCP/UDP).
NAT rules: You can filter by source subnets, destination IP ranges, or protocols. For example, allow only HTTP/HTTPS traffic to specific external IPs.
Logging: You can enable NAT logs (sample rate 0-100%) for debugging.
Configuration and Verification
Create a Cloud NAT gateway:
gcloud compute routers create my-router \
--network=default \
--region=us-central1
gcloud compute routers nats create my-nat \
--router=my-router \
--region=us-central1 \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ipsVerify with:
gcloud compute routers nats list --router=my-router --region=us-central1
gcloud compute routers get-status my-router --region=us-central1The status command shows active NAT mappings and usage.
Interaction with Related Technologies
Cloud CDN + Cloud Load Balancing: CDN is always enabled on a load balancer (external HTTP(S) or internal HTTPS). It cannot be used standalone.
Cloud NAT + Private Google Access: Private Google Access allows VMs without external IPs to reach Google APIs and services via the default route (0.0.0.0/0) but for other internet destinations, Cloud NAT is required.
Cloud NAT + Firewall Rules: Even with Cloud NAT, egress traffic must be allowed by VPC firewall rules. NAT does not bypass firewall.
Cloud CDN + Signed URLs: For private content, signed URLs or cookies are needed. The CDN validates the signature before serving cached content.
Performance and Scale
Cloud CDN: Cache hit ratio typically 80-95% for static content. Cache misses add latency equal to origin round-trip. Global edge network reduces latency by 50-80% for distant users.
Cloud NAT: Each NAT gateway can handle up to 64,000 connections per VM (with default port limits). For large-scale outbound traffic, use multiple NAT IPs and increase port ranges. Monitor using Cloud Monitoring metrics like "nat/closed_connections_count" and "nat/dropped_received_packets".
User requests content via URL
A user in Tokyo requests a static image from a web application hosted in us-central1. The DNS resolves to the IP of the external HTTP(S) load balancer, which has Cloud CDN enabled. The user's request is routed to the nearest Google edge location, in this case, Tokyo.
Edge checks cache for content
The Tokyo edge server checks its local cache for the requested object using the cache key (default: host, scheme, path, and any configured query parameters). If the object exists and its TTL has not expired, it is a cache hit. If not, it is a cache miss.
Cache miss: edge forwards to origin
On a cache miss, the edge server forwards the request to the origin backend (e.g., Cloud Storage bucket or Compute Engine instance group). The request goes through Google's backbone network, not the public internet, for lower latency.
Origin responds; edge caches response
The origin returns the object with HTTP headers (Cache-Control, Expires). The edge server caches the object according to the cache mode (e.g., USE_ORIGIN_HEADERS respects the origin's TTL; FORCE_CACHE_ALL uses a default TTL of 3600s if no cache headers). The response is stored locally in the Tokyo edge.
Subsequent requests served from cache
For the next user requesting the same object, the Tokyo edge serves it directly from cache, reducing latency from ~100ms (cross-region) to ~10ms (edge). The cache hit continues until the object expires or is invalidated.
Scenario 1: Global E-commerce Platform
A company runs a global e-commerce site with product images and static assets stored in a Cloud Storage bucket in us-central1. Users worldwide experience slow load times. Solution: Enable Cloud CDN on the backend bucket attached to an external HTTP(S) load balancer. Configure cache mode CACHE_ALL_STATIC with a default TTL of 86400s (1 day) for images. Use signed URLs for private product images (e.g., for logged-in users). Result: 90% cache hit ratio, page load times drop from 3s to 0.5s for users in Asia and Europe. Misconfiguration: If TTL is too short (e.g., 60s), cache hit ratio drops, increasing origin load. If signed URLs are not used for private content, unauthorized users may access cached items.
Scenario 2: Private VMs Accessing External APIs
A financial services company runs data processing workloads on Compute Engine instances without external IPs (for security). These instances need to call external APIs (e.g., credit scoring services) and download updates from the internet. Solution: Create a Cloud NAT gateway in the same region as the VMs, using a pool of 5 NAT IPs for high throughput. Configure minimum ports per VM to 4096 to avoid port exhaustion during peak loads. Enable NAT logging (10% sample) to monitor outbound connections. Misconfiguration: If NAT IPs are auto-allocated and the pool is too small (e.g., 1 IP), port exhaustion occurs, causing connection failures. If idle timeout is set too low (e.g., 10s), long-lived connections (e.g., database connections) are prematurely dropped.
Scenario 3: Hybrid Cloud with On-Premises Access
A company uses Cloud VPN to connect its on-premises network to GCP. On-premises servers need to access the internet via GCP's Cloud NAT for centralized egress logging. Solution: Configure Cloud Router with custom route advertisements and set up Cloud NAT on the VPC. Add firewall rules to allow outbound traffic from on-premises IP ranges (via VPN) to the internet. Use NAT rules to restrict outbound traffic to specific destination IPs (e.g., only trusted SaaS providers). Misconfiguration: If the Cloud Router does not advertise the NAT IP range to on-premises, return traffic may not route correctly. If firewall rules are too permissive, security risks increase.
The ACE exam tests Cloud CDN and Cloud NAT under Objective 2.1 (Planning Solutions) and also appears in 2.3 (Configuring Network Services). Key areas: 1) Cloud CDN cache modes: Know the three modes (USE_ORIGIN_HEADERS, FORCE_CACHE_ALL, CACHE_ALL_STATIC) and when to use each. Common wrong answer: 'CACHE_ALL_STATIC caches all content including dynamic pages' – it only caches static file extensions (e.g., .jpg, .css). 2) Signed URLs vs. Cookies: Signed URLs are for specific paths; signed cookies for broader access. Exam may ask which to use for a video streaming site (signed cookies) vs. downloadable files (signed URLs). 3) Cloud NAT port exhaustion: The default max ports per VM is 64,000 per NAT IP. Candidates often confuse this with the total ports per NAT gateway (which is 64,000 * number of NAT IPs). Trap: 'If a VM needs 80,000 connections, you need to increase max ports per VM to 80,000' – actually, you can add more NAT IPs or increase the port range (up to 65,535 per IP). 4) Cloud NAT and Private Google Access: Private Google Access does not require Cloud NAT; it uses the default route (0.0.0.0/0) with a special next hop for Google APIs. Cloud NAT is for other internet destinations. Many candidates think Cloud NAT is required for all outbound traffic, but it's only for non-Google destinations. 5) Invalidation limits: 1000 invalidation paths per day per project. A common question: 'You need to invalidate 2000 URLs daily' – answer: you need to request a quota increase or use a different strategy (e.g., versioned URLs). 6) Cache key customization: You can include query parameters, headers, or cookies. Exam may ask how to serve different content based on user-agent (include User-Agent header in cache key). 7) Idle timeout values: Default 30s for TCP/UDP, 5min for ICMP. Configurable range 10s-120s for TCP/UDP. Trap: 'ICMP timeout is also 30s' – wrong, it's 5 minutes. 8) NAT logging: Can be enabled with a sample rate (0-100%). Exam may ask about debugging intermittent connection issues – enable NAT logging at 100% sample rate.
To eliminate wrong answers, always check the underlying mechanism: CDN caches at edge; NAT translates private IPs. If a question involves 'outbound internet from private VMs', it's Cloud NAT. If it's about 'reducing latency for global users', it's Cloud CDN.
Cloud CDN caches static and dynamic content at over 200 edge locations; cache modes: USE_ORIGIN_HEADERS, FORCE_CACHE_ALL (default TTL 3600s), CACHE_ALL_STATIC (static extensions only).
Cloud NAT provides SNAT for private VMs; requires Cloud Router; default max ports per VM is 64,000 per NAT IP.
Cloud CDN invalidation limited to 1000 paths per day per project; use versioned URLs to avoid invalidation needs.
Cloud NAT idle timeout: TCP/UDP 30s (configurable 10-120s), ICMP 5min.
Cloud NAT does not allow inbound connections; use load balancers or external IPs for inbound.
Cloud CDN supports only external HTTP(S) and internal HTTPS load balancers.
Private Google Access does not require Cloud NAT; Cloud NAT is for non-Google internet destinations.
Signed URLs are for specific paths; signed cookies for broader access (e.g., entire site).
NAT logging can be enabled with sample rate 0-100%; useful for debugging connection drops.
Cloud CDN cache key can include query parameters, headers, or cookies; default is host+scheme+path.
These come up on the exam all the time. Here's how to tell them apart.
Cloud CDN
Caches content at edge locations for inbound traffic.
Reduces latency and origin load.
Works with HTTP(S) load balancers.
Supports signed URLs and cookies for access control.
Default TTL 3600s for FORCE_CACHE_ALL.
Cloud NAT
Translates private IPs to public IPs for outbound traffic.
Enables internet access for VMs without external IPs.
Works with Cloud Router and VPC networks.
Supports NAT rules for traffic filtering.
Default idle timeout 30s for TCP/UDP.
Mistake
Cloud CDN caches all content by default.
Correct
Cloud CDN caches only content that is cacheable per HTTP headers (Cache-Control: public, max-age) or if cache mode is set to FORCE_CACHE_ALL or CACHE_ALL_STATIC. Without cache headers and with USE_ORIGIN_HEADERS mode, content is not cached.
Mistake
Cloud NAT provides inbound access to private instances.
Correct
Cloud NAT only supports outbound traffic. Inbound connections cannot be initiated to private instances through Cloud NAT. For inbound, use a load balancer or external IPs.
Mistake
Cloud NAT requires a Cloud Router only if using BGP.
Correct
Cloud NAT always requires a Cloud Router, even if not using BGP. The Cloud Router manages NAT mappings and IP address allocation.
Mistake
You can use Cloud CDN with any load balancer.
Correct
Cloud CDN is only supported on external HTTP(S) load balancers and internal HTTPS load balancers (for internal HTTPS). It is not supported on TCP/UDP load balancers or SSL proxy load balancers.
Mistake
Invalidation removes content from all edge locations instantly.
Correct
Invalidation is a global operation but takes a few minutes to propagate to all edge locations. During that time, some edges may still serve the old cached content.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Cloud CDN can cache content from any HTTP(S) backend, including Compute Engine instance groups. You need to enable CDN on the backend service and configure cache policies. The instance must serve content with appropriate Cache-Control headers (or use FORCE_CACHE_ALL mode) to be cached.
Port exhaustion occurs when all available source ports are used. Solutions: 1) Increase the number of NAT IPs (up to 64 per gateway). 2) Increase the minimum or maximum ports per VM (up to 65,535 per IP). 3) Reduce idle timeout to free ports faster. 4) Use multiple NAT gateways in different regions. Monitor with Cloud Monitoring metrics.
A signed URL gives access to a specific URL (e.g., a single file) for a limited time. A signed cookie gives access to a set of URLs (e.g., all files in a directory) for a session. Use signed URLs for individual downloads, signed cookies for streaming or accessing multiple files.
Cloud CDN works with the internal HTTPS load balancer (for internal traffic) but not with internal TCP/UDP load balancers. It also works with external HTTP(S) load balancers. For internal TCP/UDP, CDN is not supported.
Yes, but it's not typical. If a VM has an external IP, it can directly access the internet without NAT. However, Cloud NAT can still be used if you want to force all outbound traffic through a specific IP for logging or security, but you must ensure the VM's external IP is not used for outbound (e.g., by setting the VM's IP forwarding or using a custom route with a lower priority).
Invalidation marks the cached object as stale. New requests will fetch from origin. In-flight requests that are already being served from cache may still receive the old content. The invalidation propagates globally within minutes, after which all edges will fetch fresh content.
Use NAT rules. When creating or updating the NAT gateway, you can specify a list of destination IP ranges that are allowed. For example, to allow only traffic to 203.0.113.0/24, use the `--nat-custom-subnet-ip-ranges` and `--nat-allowed-destination-ranges` flags. You can also combine with firewall rules for additional filtering.
You've just covered Cloud CDN and Cloud NAT — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?