You're not alone in facing this 502 issue with AWS CloudFront + Google Cloud Run. This is a known pain point due to the subtle but critical differences in how CloudFront expects an origin to behave versus how Google Cloud Run serves responses.

           Quick Summary of 502 Causes (Specific to CloudFront + Cloud Run) 

CloudFront returns a 502 Bad Gateway when:

It can't understand the response from the origin (Cloud Run in this case)

There’s a TLS handshake failure, unexpected headers, timeout, or missing response headers

CloudFront gets a non-compliant response format (e.g., too long/short headers, malformed HTTP version)

Even though Cloud Run may respond with 200 OK directly, it does not guarantee compatibility with CloudFront's proxy behavior.

Likely Causes in Your Case

• Here are the most common and probable issues based on your setup:

• Cloud Run's HTTP/2 or Chunked Encoding Response

Problem: CloudFront expects HTTP/1.1 and may misinterpret Cloud Run's chunked encoding or HTTP/2 behavior.

Fix: Force Cloud Run to downgrade to HTTP/1.1 by putting a reverse proxy (like Cloud Run → Cloud Load Balancer or Cloud Functions → CloudFront) in between, or use a Cloud Armor policy with a backend service.

      Missing Required Headers in Response 

Problem: CloudFront expects certain headers (e.g., Content-Length, Date, Content-Type) to be present.

Fix: Log all outbound headers from Cloud Run and ensure the response is fully RFC-compliant. Use a middleware to enforce this.

Random Cold Starts or Latency in Cloud Run

Problem: Cloud Run can scale to zero, and cold starts cause delay. CloudFront times out quickly (~10 seconds default).

Fixes:

• Set min instances in Cloud Run to keep one container warm

• Optimize cold start time

• Increase CloudFront origin timeout (if using custom origin)

TLS Issues Between CloudFront and Cloud Run

Problem: CloudFront uses SNI-based TLS. If Cloud Run isn’t handling it as expected or certificate isn’t valid for SNI, 502 can result.

Fix:

• Use fully managed custom domains in Cloud Run with valid certs

• Check that your custom domain doesn’t redirect to HTTPS with bad certificate chain when coming from CloudFront.

Cloud Run Returns 404 or 500 Internally

Problem: If Cloud Run returns a 404/500, CloudFront may wrap this in a 502

Fix: Log actual responses from Cloud Run for all paths

Best Practice:

• Use a Layer Between CloudFront and Cloud Run

• Instead of connecting CloudFront directly to Cloud Run, use:

• Google Cloud Load Balancer (GCLB) with Cloud Run as backend

• Then point CloudFront to the GCLB IP or domain

This avoids a ton of these subtle issues and gives you more control (headers, TLS, routing).

Diagnostic Checklist

Item Status:

• Cloud Run always returns required headers (Content-Length, Content-Type, Date)

• Cloud Run has min instance (avoid cold starts)

• CloudFront origin protocol set to HTTPS only

• CloudFront timeout increased (origin read timeout = 30s or more)

• Cloud Run domain SSL cert supports SNI

• Logs from Cloud Run show successful 200s

• CloudFront logs show exact reason (check logs or enable logging to S3)

        Community Reports 

Many developers report intermittent 502s when using CloudFront + Cloud Run without a reverse proxy.

Some fixes:

• Moving to Google Cloud CDN instead of CloudFront

• Adding NGINX or Cloud Load Balancer in between

• Avoiding chunked responses and explicitly setting Content-Lengt

Suggested Immediate Actions

• Enable CloudFront logging to S3 to get more detail on the 502s

• Add a reverse proxy (NGINX or GCLB) between Cloud Run and CloudFront

• Force HTTP/1.1 response format from Cloud Run

• Set min_instances=1 to eliminate cold starts

• If nothing helps, consider using Google Cloud CDN for tighter integration with Cloud Run

If you want help debugging further:Please provide:Sample curl -v to Cloud Run endpoint

CloudFront response headers when 502 happens

Cloud Run logs during time of errorLet me know and I can walk you through fixing this definitively.