Skip to content

Traffic ingress

Our boilerplate prefers the use of Cloud Run to host web applications. Applications hosted via Cloud Run can receive traffic from the outside world either via the default .run.app URL generated by Cloud Run or via a Cloud Load Balancer. This page documents when and how to use each.

Our Cloud Run module

We have a standard module which we use to configure applications hosted in Cloud Run. Since version 9.0.0 the module can create and manage a Cloud Load Balancer itself: setting the enable_load_balancer variable to true provisions the load balancer, serverless network endpoint group and associated resources alongside the Cloud Run service. See the module's documentation for more details.

In our gcp-deploy-boilerplate this is wired to the local.webapp_use_cloud_load_balancer local, which defaults to true for new deployments. The load balancer is therefore the standard ingress for our web applications.

Which ingress to use

This section helps you select which ingress style to use.

No ingress

If no load balancer is configured, a URL will be generated for the application under the .run.app domain, for example https://webapp-xxxxxxxxxx.europe-west2.run.app. This is unlikely to be a human-friendly name but may suffice for test or development instances, or for services which are only ever called by other Google Cloud resources.

The module's ingress variable controls where traffic may come from. Possible values are INGRESS_TRAFFIC_ALL, INGRESS_TRAFFIC_INTERNAL_ONLY and INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER. In addition, the allow_unauthenticated_invocations variable can be set to false to require callers to authenticate as a Google identity with the Cloud Run invoker role. Together these suit services which are only ever called from within the parent Google project, for example a service invoked by Cloud Scheduler to perform actions at regular intervals.

Load balancer

A Cloud Load Balancer is the standard ingress for externally available applications. It provides:

  • A static ingress IP address, useful for long-lived DNS records and for callers who require IP allow listing. IPv6 addresses can optionally be enabled.
  • Google-managed TLS certificates for the domains listed in the module's dns_names variable, with TLS termination and HTTP to HTTPS redirection handled at the load balancer frontend. By default a "MODERN" SSL policy is applied which restricts connections to TLS 1.2 or greater.
  • The ability to bring your own TLS certificates. This is often needed when transitioning a service from on-premises to Cloud or when EV/OV certificates are required.
  • Traffic shaping and filtering via Cloud Armor rules, content caching via Cloud CDN and the use of Identity Aware Proxy to restrict resources to particular identities.

When the load balancer is enabled, the module sets the Cloud Run service's ingress to INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER by default so that the application can only be reached via the load balancer and not via its .run.app URL. This can be overridden by setting the ingress variable explicitly.

Note that the module does not create DNS records; the dns_names variable only ensures the Google-managed TLS certificate is generated with the required Subject Alternative Names. Our boilerplate creates an A record for the application in the project's DNS zone pointing at the load balancer's external IP. Records for "friendly" domains such as those under .cam.ac.uk must be created by other means — typically a CNAME from {service}.apps.cam.ac.uk to the per-environment record, managed in the University's IP Register database.

The traffic ingress architecture diagram shows the standard load balancer ingress arrangement in more detail.

Domain mapping (no longer supported)

Removed in version 9.0.0

Older versions of our Cloud Run module supported Cloud Run domain mapping as an alternative ingress. Domain mapping has been in Pre-GA for multiple years, has latency issues which make it unfit for production use, and is unavailable in some regions including europe-west2 (London) where we host most of our applications. Therefore, since version 9.0.0 of the module, custom domains are only supported when using a Cloud Load Balancer.

If you maintain an older deployment which still uses domain mapping, see the explanation of the version 9.0.0 changes and the migration how-to for details of moving to the load balancer ingress.

Costs

Load balancers incur additional monthly costs beyond those of the Cloud Run service itself. This is accepted as the cost of a production-ready ingress; for test or development instances which do not need a custom domain, the free .run.app URL may suffice.

Summary

In summary:

  • The Cloud Load Balancer, created by our standard Cloud Run module when enable_load_balancer is true, is the standard ingress for externally available applications. Our boilerplate enables it by default.
  • The load balancer provides a static ingress IP, managed TLS certificates, HTTP to HTTPS redirection and optional Cloud Armor, Cloud CDN and Identity Aware Proxy integration.
  • Cloud Run domain mapping is no longer supported; it was removed in version 9.0.0 of our standard module.
  • Services which are only called from within the parent Google project can forgo an ingress entirely and use the generated .run.app URL, restricting traffic via the module's ingress and allow_unauthenticated_invocations variables.
  • DNS records are not created by the module itself; our boilerplate creates records in the project's DNS zone and records under .cam.ac.uk are created by other means.