> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/networking/network-architecture-gcp.md).

# Network architecture (GCP)

When you create environments, Release sets up network access from the internet to services in your environments. For environments hosted on GCP, connectivity is handled through GCP's networking services.

This is an overview of how Release sets up GCP to allow visitors to access your applications.

## High-level network overview

Release configures the following GCP services to direct traffic to your applications:

* **Cloud DNS** points subdomains at load-balancer frontend IP addresses so that visitors' web browsers know which endpoints to connect to.
* **Google Cloud Load Balancer** acts as a Layer 7 load balancer that terminates visitors' HTTPS requests and routes traffic to backends based on URL maps.
* **URL maps** contain a set of rules against which incoming requests are matched so that requests are routed to the appropriate backends.
* **Load-balancer backends** connect the load balancer to network endpoint groups for your applications.
* Pods in Kubernetes clusters connect to the default project-wide **virtual private cloud (VPC) network** for your Google Cloud project.
* **VPC firewall rules** allow traffic from the external load balancer to IP addresses in your VPC.
* **Google Kubernetes Engine** connects incoming requests to pods within your Kubernetes clusters through an Nginx proxy.

When a visitor opens a URL for one of your services in a web browser, the visitor's browser sends a DNS query for a subdomain in your zone in Google Cloud DNS. A DNS resolver returns the IP address for a GCP load-balancer frontend.

The visitor's browser then connects to the load balancer via HTTPS, and sends a request.

The load balancer forwards this request on to Kubernetes, which serves a response from one of your applications.

![GCP network diagram](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-277bd9209bc364549fdb7eb322bb655c74d3e3cc%2Fnetworking-gcp-diagram.png?alt=media\&token=f1445294-b208-4424-aa3e-52f05f6f6cbd)

We'll use an example to see how GCP networking routes traffic.

## Following a network request to a dynamic service

Our visitor wants to connect to an application running in our Release environment. Let's follow their request to explore Release's network configuration of GCP in more detail.

In a Release environment, each service that is accessible from the internet has a unique URL. You can find the URL for a service by visiting the Environment Details page in Release, as shown below.

![Find a service URL in Release](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-f8463a3f7cb1d2c1c782aae184cd5c25fd457052%2Fwordpress-mysql-detail.png?alt=media\&token=67de8800-eb86-4d6e-82e9-2f45ed0730ab)

To start the request, our visitor clicks on a link or enters the URL in their browser, for example, `https://app-service.staging-env.example.com`.

### 1. DNS resolution

The visitor's web browser queries their DNS resolver for the hostname `app-service.staging-env.example.com`. The visitor's DNS resolver, through a series of DNS servers, queries one of GCP's authoritative name servers for the hostname.

Google Cloud DNS responds to the visitor's DNS resolver with the IP address.

{% hint style="info" %}
**How Release configures this DNS record**: When we created our environment, Release added an `A` record associating `app-service.staging-env.example.com` with the IP address of a load-balancer frontend, for example, `216.239.32.108`, to [Google Cloud DNS](https://cloud.google.com/dns). The hostname used is based on the [hostname templates](/guides-and-examples/advanced-guides/hostnames-and-rules.md#hostnames) configured for our application.
{% endhint %}

### 2. Load balancing and URL maps

The visitor's browser completes a TLS handshake with Google's load-balancer frontend, so that all further traffic between the browser and the load balancer is encrypted.

The domain-verified SSL certificate used for this connection is created in advance by Release by verifying the domain with a certificate authority via DNS-based verification.

After the connection is secured, the browser sends the request:

```http
GET / HTTP/2
Host: app-service.staging-env.example.com
```

The load balancer now matches the request against a URL map, which associates the request with the appropriate load-balancer backend.

In our app's load balancer, the URL map would look like this simplified example:

```json
{
  "hosts": [
    "app-service.staging-env.example.com",
    "*.app-service.staging-env.example.com"
  ],
  "paths": [
    "/",
    "/*"
  ],
  "backend": "release-kn0rp0iie0hndklwzmg9f97ukyz4cd7o"
}
```

Since the host and path in our visitor's request both match this URL map, the load balancer directs the visitor's traffic to the load-balancer backend called `release-kne0hndklwzmg90rp0iif97ukyz4cd7o`.

If for some reason, a request does not match any URL map rules, Release will forward the request to `https://none-such.releasehub.com`.

{% hint style="info" %}
**How Release configures this URL map**: When we created our environment, Release created a [URL map](https://cloud.google.com/load-balancing/docs/url-map-concepts) associating the service's hostname and paths with a load-balancer backend, and added the URL map to the [load balancer](https://cloud.google.com/load-balancing/docs/load-balancing-overview).
{% endhint %}

### 3. Backend services

GCP's load balancer now directs the visitor's traffic to a [backend service](https://cloud.google.com/load-balancing/docs/backend-service).

A load-balancer backend in GCP is responsible for connecting the load balancer to network endpoints. In our example, the network endpoint is a pod in our Kubernetes cluster.

GCP simplifies connecting to multiple endpoints at once by adding endpoints to [network endpoint groups](https://cloud.google.com/load-balancing/docs/negs).

{% hint style="info" %}
Release configures a network endpoint group (NEG) per network zone (for example, `us-west-1-a`, `us-west-1-b`, and `us-west-1-c`) for each environment and adds the internal VPC network IP addresses for servers running in these environments to each group.

If you configure [session affinity](https://docs.releasehub.com/reference-documentation/application-settings/application-template/schema-definition#affinity) for your applications, the backend service keeps track of affinity at the network-zone level. The backend service uses health checks to keep track of healthy endpoints that can handle requests.
{% endhint %}

### 4. VPC network firewall

Because the endpoints in our clusters are connected to a private network, the project-wide default VPC, our backend service needs to pass through the VPC firewall.

The firewall also needs to allow health checks from the load balancer.

{% hint style="info" %}
Release configures VPC firewall rules to accept traffic from Google's load balancing IP ranges: `130.211.0.0/22` and `35.191.0.0/16`.
{% endhint %}

### 5. Kubernetes ingress

Once the visitor's request reaches our Kubernetes cluster, a Kubernetes Nginx ingress controller routes the request to the correct pod to handle the request.

### 6. Request processing and response

For this example, suppose the service at `https://app-service.staging-env.example.com` listens on port 8000. Let's call this service the page-rendering service.

The page-rendering service will handle and process the visitor's request, make any required external requests, and respond with an HTTP response.

To render the page for our visitor, the service may have to communicate with other services in the Kubernetes cluster or cloud-provided services, such as databases.

For example, the page-rendering service may connect to a Redis cache that runs as a service in your Release environment and to a PostgreSQL database hosted on Google Cloud SQL.

### 7. Kubernetes networking

To connect to the Redis cache, Release provides the connection strings, such as hostname and password, to the page-rendering service as environment variables.

Connecting to other services within a single environment follows the same workflow as connecting to services in a single Kubernetes namespace. Services in a namespace are added to a Kubernetes network and can address other services directly by name.

In our example, the Redis cache service might be called `redis`, so the page-rendering service will access Redis directly by connecting to the hostname `redis`.

### 8. Connecting to cloud-hosted databases

If our Cloud SQL database is in the same GCP project and shares the same VPC network as our cluster, no extra steps in GCP are required.

If, however, the database is in a different VPC, we need to set up [VPC network peering](https://cloud.google.com/vpc/docs/vpc-peering) in GCP. VPC network peering allows connections between two different VPCs without requiring public IP addresses for your database.

## Network requests for static files

Release can also build and host static resources on Google Cloud Storage.

Requests for resources served from Google Cloud Storage follow the same DNS and load-balancing steps as dynamic requests, but instead of routing to a Kubernetes ingress controller, requests are routed to Cloud Storage.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/networking/network-architecture-gcp.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.