apointoo.
Request access
HIPAA

Cloud Run Custom Domains: When a Load Balancer Matters

cmsapointoo··7 min read

Short answer: A Cloud Run custom domain decision should compare direct domain mapping with a production load-balancer path against region, ingress control, certificates, logging, failover, and fixed cost. As of 2026-08-15, Google Cloud documents custom-domain options, Cloud Run pricing, and covered-product scope. Neither a working DNS record nor a load balancer proves that the application handles protected data safely.

GCP service fit and regional boundary

Cloud Run custom-domain options are deployment mechanisms, not compliance boundaries. Google’s custom-domain documentation describes domain mapping and other ingress options. Cloud Run pricing supplies request and resource cost inputs, and the Google Cloud HIPAA page describes provider scope and shared responsibility. Compare those facts with the application’s need for WAF, centralized policy, regional routing, certificates, logs, and operational ownership.

Direct mapping may be adequate for a narrow route when its documented limitations are acceptable. A load balancer may be justified when the design needs centralized ingress, routing, policy, or a controlled origin. The choice must be current because product status, regional availability, and pricing can change. Record the option, date, region, and unresolved feature question.

Set the region before binding a domain. The hostname should route by tenant configuration and home region, not by patient IP geolocation or a client-selected parameter. Keep backend, database, files, keys, logs, queues, backups, and support access aligned with that region.

Ingress question Direct mapping Load balancer path
Domain binding Documented mapping flow Forwarding rule and backend configuration
Policy Cloud Run and app controls Central edge policy plus app controls
Cost Mapping and service assumptions Forwarding rule, traffic, and service assumptions
Proof Origin and route tests Edge, origin, failover, and route tests

For region design, see Cloud Run home zones. For runtime migration, read bounded Cloud Run migration, and for protected service scope compare Google Cloud covered products.

Request, data, key, and identity path

The domain path must preserve identity and tenant checks. Trace DNS, certificate, edge or mapping, Cloud Run service, authentication, membership, database, key, log, and backup. Test direct service URLs and alternate hostnames. A load balancer cannot protect an origin that remains publicly reachable unless the configuration and application enforce the intended path.

Do not place tenant or region authority in the hostname alone. The server should resolve membership and immutable home region, then reject a mismatch. A public route can be recognizable by host while still requiring an application-level identity check.

Minimize request data. A generic conversion record may use approved event type, time, currency, value, and an opaque internal reference. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising systems. An ingress feature does not change that data rule.

DNS and certificate
  -> mapping or load balancer
  -> Cloud Run origin
  -> membership and tenant check
  -> approved database and regional logs

Jobs, audit, backup, and failure handling

Test edge failure and origin failure separately. Use expired certificates, wrong host, missing route, WAF or policy denial, direct-origin request, service timeout, backend error, and retry. Inspect error responses, access logs, traces, and queue records for unnecessary request content.

Audit edge policy changes, DNS changes, certificate changes, deployment changes, identity decisions, exports, restores, and support access. Keep logs minimum necessary. A centralized load balancer can simplify review, but it can also create a global logging path or a second region that needs approval.

Backups and support are independent of ingress. Verify that a support engineer cannot bypass tenant membership by calling a backend endpoint, and that restore data is only readable after the application policy is installed. Test a domain migration or rollback without leaving two active origins.

Use synthetic tenants and records. Verify that each home region routes to its intended service and data store, and that a wrong-region host is denied or redirected only through an approved policy. Record observed behavior and date it.

Cost and proof gate

A load balancer has a fixed cost floor that direct mapping may avoid, but cost is not the only axis. Use Cloud Run pricing and current ingress documentation to estimate forwarding rules, traffic, service requests, certificates, logs, monitoring, DNS, and regional duplication. Mark estimates with region and date.

  • List required ingress features and limitations.
  • Confirm current regional and product status.
  • Check direct origin reachability and alternate hostnames.
  • Include edge and backend logs in the data map.
  • Run domain, identity, region, failure, export, and restore tests.

Custom-domain proof checklist

Approve one ingress option only after the route and bypass tests pass.

  1. Bind a synthetic hostname in the approved region.
  2. Verify certificate, TLS, expected route, and tenant membership.
  3. Call the direct origin and alternate hostname and confirm the intended denial.
  4. Trigger edge and backend failures and inspect redacted logs.
  5. Test regional routing, queue, backup, restore, and support paths.
  6. Measure fixed and variable cost assumptions.
  7. Record provider status and legal questions for review.

A custom domain is a presentation and routing feature. The final decision should say what it controls and what remains application, database, identity, and contract work.

Ingress review should end in an explicit origin policy. Name the public hostname, expected edge, Cloud Run service, region, certificate owner, allowed methods, authentication, WAF or policy controls, and direct-origin behavior. If the origin must be private or reachable only through the edge, test that requirement instead of inferring it from DNS.

Compare domain mapping and load balancer options against operational evidence. A load balancer may centralize routing and policy while adding forwarding-rule, traffic, log, and regional costs. Direct mapping may reduce infrastructure but have limitations that matter for production. Product status and pricing are volatile, so date the decision and recheck before release.

Run a controlled hostname with synthetic data. Test normal route, wrong tenant, expired identity, certificate or DNS failure, direct origin, alternate host, backend timeout, rollback, logs, backup, and support. The same route should not expose a broad administrative endpoint because it happens to be behind a working certificate.

Keep customer and counsel review separate from technical proof. The edge proves a routing and policy behavior. It does not decide whether a data path, region, contract, or advertising event is permitted. See covered-product review for the provider and customer boundary.

Frequently asked questions

Is a load balancer required for every Cloud Run custom domain?

No universal answer applies. Compare documented mapping options, required edge controls, production routing, region, cost, and operational proof. Recheck current Google Cloud documentation before choosing.

Does a load balancer protect the backend?

Only if origin access and application authorization are configured and tested. An alternate direct origin, privileged job, or support path can bypass edge policy.

What costs should be estimated?

Include Cloud Run requests and resources, forwarding rules, traffic, certificates, DNS, logs, monitoring, keys, backups, and regional duplication. Label values as estimates with date and region.

What should be tested first?

Run a synthetic domain request, wrong-tenant request, direct-origin request, certificate or route failure, log inspection, regional route, backup, restore, and support access test.

References

Related articles