# Create an Internal Load Balancer - GSP216

## Overview

Google Cloud offers Internal Load Balancing for your TCP/UDP-based traffic. Internal Load Balancing enables you to run and scale your services behind a private load balancing IP address that is accessible only to your internal virtual machine instances.

In this lab you create two managed instance groups in the same region. Then, you configure and test an Internal Load Balancer with the instances groups as the backends, as shown in this network diagram:

![Network_Diagram.png](https://cdn.qwiklabs.com/k3u04mphJhk%2F2yM84NjgPiZHrbCuzbdwAQ98vnaoHQo%3D align="left")

### Objectives

In this lab you learn how to perform the following tasks:

* Create HTTP and health check firewall rules
    
* Configure two instance templates
    
* Create two managed instance groups
    
* Configure and test an internal load balancer
    

## Setup and requirements

### Before you click the Start Lab button

Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click **Start Lab**, shows how long Google Cloud resources are made available to you.

This hands-on lab lets you do the lab activities in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials you use to sign in and access Google Cloud for the duration of the lab.

To complete this lab, you need:

* Access to a standard internet browser (Chrome browser recommended).
    

**Note:** Use an Incognito (recommended) or private browser window to run this lab. This prevents conflicts between your personal account and the student account, which may cause extra charges incurred to your personal account.

* Time to complete the lab—remember, once you start, you cannot pause a lab.
    

**Note:** Use only the student account for this lab. If you use a different Google Cloud account, you may incur charges to that account.

### How to start your lab and sign in to the Google Cloud console

1. Click the **Start Lab** button. If you need to pay for the lab, a dialog opens for you to select your payment method. On the left is the Lab Details pane with the following:
    
    * The Open Google Cloud console button
        
    * Time remaining
        
    * The temporary credentials that you must use for this lab
        
    * Other information, if needed, to step through this lab
        
2. Click **Open Google Cloud console** (or right-click and select **Open Link in Incognito Window** if you are running the Chrome browser).
    
    The lab spins up resources, and then opens another tab that shows the Sign in page.
    
    ***Tip:*** Arrange the tabs in separate windows, side-by-side.
    
    **Note:** If you see the **Choose an account** dialog, click **Use Another Account**.
    
3. If necessary, copy the **Username** below and paste it into the **Sign in** dialog.
    
    ```apache
    student-02-73684dcbc023@qwiklabs.net
    ```
    
    You can also find the Username in the Lab Details pane.
    
4. Click **Next**.
    
5. Copy the **Password** below and paste it into the **Welcome** dialog.
    
    ```apache
    ZcHl0noKXN6t
    ```
    
    You can also find the Password in the Lab Details pane.
    
6. Click **Next**.
    
    **Important:** You must use the credentials the lab provides you. Do not use your Google Cloud account credentials.
    
    **Note:** Using your own Google Cloud account for this lab may incur extra charges.
    
7. Click through the subsequent pages:
    
    * Accept the terms and conditions.
        
    * Do not add recovery options or two-factor authentication (because this is a temporary account).
        
    * Do not sign up for free trials.
        

After a few moments, the Google Cloud console opens in this tab.

**Note:** To access Google Cloud products and services, click the **Navigation menu** or type the service or product name in the **Search** field.

![Navigation menu icon and Search field](https://cdn.qwiklabs.com/9Fk8NYFp3quE9mF%2FilWF6%2FlXY9OUBi3UWtb2Ne4uXNU%3D align="left")

## Task 1. Configure HTTP and health check firewall rules

Configure firewall rules to allow HTTP traffic to the backends and TCP traffic from the Google Cloud health checker.

### Explore the my-internal-app network

The network `my-internal-app` with subnet-a and subnet-b along with firewall rules for RDP, SSH, and ICMP traffic have been configured for you.

1. In the console, navigate to **Navigation menu** > **VPC network** > **VPC networks**.
    
2. Scroll down and notice the **my-internal-app** network with its subnets: **subnet-a** and **subnet-b**
    
    Each Google Cloud project starts with the **default** network. In addition, the **my-internal-app** network has been created for you, as part of your network diagram.
    
    You will create the managed instance groups in **subnet-a** and **subnet-b**. Both subnets are in the `us-central1` region because an Internal Load Balancer is a regional service. The managed instance groups will be in different zones, making your service immune to zonal failures.
    

### **Create the HTTP firewall rule**

Create a firewall rule to allow HTTP traffic to the backends from the Load Balancer and the internet (to install Apache on the backends).

1. Still in **VPC network**, in the left pane click **Firewall**.
    
2. Notice the **app-allow-icmp** and **app-allow-ssh-rdp** firewall rules.
    
    These firewall rules have been created for you.
    
3. Click **\+ Create Firewall Rule**.
    
4. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | app-allow-http |
    | Network | my-internal-app |
    | Targets | Specified target tags |
    | Target tags | lb-backend |
    | Source filter | IPv4 Ranges |
    | Source IPv4 ranges | 10.10.0.0/16 |
    | Protocols and ports | Specified protocols and ports, and then *check* tcp, *type:* 80 |
    

**Note:** Make sure to include the **/16** in the **Source IPv4 ranges** to specify all networks.

5. Click **Create**.
    

### Create the health check firewall rules

Health checks determine which instances of a Load Balancer can receive new connections. For Internal load balancing, the health check probes to your load balanced instances come from addresses in the ranges `130.211.0.0/22` and `35.191.0.0/16`. Your firewall rules must allow these connections.

1. Still in the **Firewall rules** page, click **\+ Create Firewall Rule**.
    
2. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | app-allow-health-check |
    | Network | my-internal-app |
    | Targets | Specified target tags |
    | Target tags | lb-backend |
    | Source filter | IPv4 Ranges |
    | Source IPv4 ranges | 130.211.0.0/22 and 35.191.0.0/16 |
    | Protocols and ports | Specified protocols and ports, and then *check* tcp |
    

**Note:** Make sure to enter the two **Source IPv4 ranges** one-by-one and pressing SPACE in between them.

3. Click **Create**.
    

Click Check my progress to verify the objective.

Configure HTTP and health check firewall rules

**Check my progress**

## Task 2. Configure instance templates and create instance groups

A managed instance group uses an instance template to create a group of identical instances. Use these to create the backends of the Internal Load Balancer.

### Configure the instance templates

An instance template is an API resource that you can use to create VM instances and managed instance groups. Instance templates define the machine type, boot disk image, subnet, labels, and other instance properties. Create an instance template for both subnets of the **my-internal-app** network.

1. In the Console, navigate to **Navigation menu** > **Compute Engine** > **Instance templates**.
    
2. Click **Create instance template**.
    
3. For **Name**, type **instance-template-1**.
    
4. For **Location**, Select **Global**.
    
5. For **Series**, select **E2**.
    
6. For **Machine type**, select **Shared-core** > **e2-micro**.
    
7. Click **Advanced options**.
    
8. Click **Networking**.
    
9. For **Network tags**, specify **lb-backend**.
    
    **Note:** The network tag **lb-backend** ensures that the **HTTP** and **Health Check** firewall rules apply to these instances.
    
10. For **Network interfaces**, click the dropdown icon to edit.
    
11. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Network | my-internal-app |
    | Subnetwork | subnet-a |
    | External IPv4 Address | None |
    
12. Click **Done**.
    
13. Click **Management**.
    
14. Under **Metadata**, click **Add item** and specify the following:
    
    | **Key 1** | **Value 1** |
    | --- | --- |
    | startup-script-url | gs://cloud-training/gcpnet/ilb/startup.sh |
    

**Note:** The **startup-script-url** specifies a script that will be executed when instances are started. This script installs Apache and changes the welcome page to include the client IP and the name, region and zone of the VM instance. Feel free to explore [this script](https://storage.googleapis.com/cloud-training/gcpnet/ilb/startup.sh).

15. Click **Create**.
    
16. Wait for the instance template to be created.
    

### Configure the next instance template

Create another instance template for **subnet-b** by copying **instance-template-1**:

1. Still in **Instance templates**, check the box next to **instance-template-1**, then click **Copy**. Make sure to update the name as **instance-template-2**.
    
2. Click **Advanced options**.
    
3. Click the **Networking** tab.
    
4. For **Network interfaces**, click the dropdown icon to edit.
    
5. Select **subnet-b** as the **Subnetwork**.
    
6. Click **Done** and then click **Create**.
    

### **Create the managed instance groups**

Create a managed instance group in **subnet-a** and one **subnet-b**.

**Note:** Identify one of the other zones in the same region as **subnet-a**. For example, if your zone of **subnet-a** is `us-west2-a`, you could select `us-west2-b` for **subnet-b**.

1. Still in **Compute Engine**, in the left pane click **Instance groups**, and then click **Create Instance group**.
    
2. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | instance-group-1 |
    | Instance template | instance-template-1 |
    | Location | Single-zone |
    | Region | `us-central1` |
    | Zone | `us-central1-c` |
    | Autoscaling > Minimum number of instances | 1 |
    | Autoscaling > Maximum number of instances | 1 |
    | Autoscaling > Autoscaling signals (click the dropdown icon to edit) > Signal type | CPU utilization |
    | Target CPU utilization | 80 |
    | Initialization period | 45 |
    

**Note:** Managed instance groups offer **autoscaling** capabilities that allow you to automatically add or remove instances from a managed instance group based on increases or decreases in load. Autoscaling helps your applications gracefully handle increases in traffic and reduces cost when the need for resources is lower. You just define the autoscaling policy and the autoscaler performs automatic scaling based on the measured load.

3. Click **Create**.
    
    Repeat the same procedure for **instance-group-2** in the different zone of same region as **subnet-a**:
    
4. Click **Create Instance group**.
    
5. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | instance-group-2 |
    | Instance template | instance-template-2 |
    | Location | Single-zone |
    | Region | `us-central1` |
    | Zone | Zone (Use the different zone in same region as subnet-a) |
    | Autoscaling > Minimum number of instances | 1 |
    | Autoscaling > Maximum number of instances | 1 |
    | Autoscaling > Autoscaling signals (click the dropdown icon to edit) > Signal type | CPU utilization |
    | Target CPU utilization | 80 |
    | Initialization period | 45 |
    
6. Click **Create**.
    

### Verify the backends

Verify that VM instances are being created in both subnets and create a utility VM to access the backends' HTTP sites.

1. Still in **Compute Engine**, click **VM instances**.
    
2. Notice two instances that start with `instance-group-1` and `instance-group-2`.
    
    These instances are in separate zones and their internal IP addresses are part of the **subnet-a** and **subnet-b** CIDR blocks.
    
3. To create a new instance, click **Create Instance**.
    
4. In the **Machine configuration**.
    
    Select the following values:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | utility-vm |
    | Region | `us-central1` |
    | Zone | `us-central1-c` |
    | Series | `E2` |
    | Machine Type | `e2-micro` (1 shared vCPU) |
    
5. Click **Networking**.
    
    For **Network interfaces**, click **Toggle** to Edit network interface.
    
    Specify the following:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Network | my-internal-app |
    | Subnetwork | subnet-a |
    | Primary internal IPv4 address | Ephemeral (Custom) |
    | Custom ephemeral IP address | 10.10.20.50 |
    
6. Click **Done** and then click **Create**.
    

Click Check my progress to verify the objective.

Configure instance templates and create instance groups

**Check my progress**

7. Note that the internal IP addresses for the backends are `10.10.20.2` and `10.10.30.2`.
    

**Note:** If these IP addresses are different, replace them in the two **curl** commands below.

8. For **utility-vm**, click **SSH** to launch a terminal and connect.
    
9. To verify the welcome page for `instance-group-1-xxxx`, run the following command:
    

```apache
curl 10.10.20.2
```

The output should look like this:

```apache
<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname:
 instance-group-1-1zn8<h2>Server Location</h2>Region and Zone: us-central1-a
```

10. To verify the welcome page for `instance-group-2-xxxx`, run the following command:
    

```apache
curl 10.10.30.2
```

The output should look like this:

```apache
<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname:
 instance-group-2-q5wp<h2>Server Location</h2>Region and Zone: us-central1-b
```

Which of these fields identify the location of the backend?Server HostnameServer LocationClient IP

**Submit**

**Note:** The **curl** commands demonstrate that each VM instance lists the Client IP and its own name and location. This will be useful when verifying that the Internal Load Balancer sends traffic to both backends.

11. Close the SSH terminal to **utility-vm**:
    

```apache
exit
```

## Task 3. Configure the Internal Load Balancer

Configure the Internal Load Balancer to balance traffic between the two backends (**instance-group-1** and **instance-group-2**), as illustrated in this diagram:

![Network Diagram showing the Internal Load Balancer balancing traffic between the 2 backends](https://cdn.qwiklabs.com/k3u04mphJhk%2F2yM84NjgPiZHrbCuzbdwAQ98vnaoHQo%3D align="left")

### Start the configuration

1. From the Navigation Menu, select **View All Products**. Under **Networking**, select **Network Services**.
    
2. Select the **Load balancing** page.
    
3. Click **Create load balancer**.
    
4. For **Type of load balancer**, select **Network Load Balancer (TCP/UDP/SSL)**.
    
5. For **Proxy or passthrough**, select **Passthrough load balancer**.
    
6. For **Public facing or internal**, select **Internal**.
    
7. Click **CONFIGURE**.
    
8. For **Name**, type `my-ilb`.
    
9. For **Region**, select `us-central1`.
    
10. For **Network**, select **my-internal-app**.
    

### Configure the regional backend service

The backend service monitors instance groups and prevents them from exceeding configured usage.

1. Click on **Backend configuration**.
    
2. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (select option as specified)** |
    | --- | --- |
    | Instance group | instance-group-1 |
    
3. Click **Add a backend**.
    
4. For **Instance group**, select **instance-group-2**.
    
5. For **Health Check**, select **Create a health check**.
    
6. Set the following values, leave all other values at their defaults:
    
    | **Property** | **Value (select option as specified)** |
    | --- | --- |
    | Name | my-ilb-health-check |
    | Protocol | TCP |
    | Port | 80 |
    

**Note:** Health checks determine which instances can receive new connections. This HTTP health check polls instances every 5 seconds, waits up to 5 seconds for a response and treats 2 successful or 2 failed attempts as healthy or unhealthy, respectively.

7. Click **Save**.
    
8. Verify that there is a blue check mark next to **Backend configuration** in the Cloud Console. If not, double-check that you have completed all the steps above.
    

### Configure the frontend

The frontend forwards traffic to the backend.

1. Click on **Frontend configuration**.
    
2. Specify the following, leaving all other values with their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Subnetwork | subnet-b |
    | Internal IP | Under **IP address** select **Create IP address** |
    
3. Specify the following, leaving all other values with their defaults:
    
    | **Property** | **Value (type value or select option as specified)** |
    | --- | --- |
    | Name | my-ilb-ip |
    | Static IP address | Let me choose |
    | Custom IP address | 10.10.30.5 |
    
4. Click **Reserve**.
    
5. In **Port number**, type `80`.
    
6. Click **Done** .
    

### **Review and create the Internal Load Balancer**

1. Click on **Review and finalize**.
    
2. Review the **Backend** and **Frontend**.
    
3. Click on **Create**. Wait for the Load Balancer to be created, before moving to the next task.
    

Click Check my progress to verify the objective.

Configure the Internal Load Balancer

**Check my progress**

## Task 4. Test the Internal Load Balancer

Verify that the `my-ilb` IP address forwards traffic to **instance-group-1** and **instance-group-2**.

### **Access the Internal Load Balancer**

1. In the Cloud Console, navigate to **Navigation menu** &gt; **Compute Engine** &gt; **VM instances**.
    
2. For **utility-vm**, click **SSH** to launch a terminal and connect.
    
3. To verify that the Internal Load Balancer forwards traffic, run the following command:
    

```apache
curl 10.10.30.5
```

The output should look like this:

```xml
<h1>Internal Load Balancing Lab</h1><h2>Client IP</h2>Your IP address : 10.10.20.50<h2>Hostname</h2>Server Hostname:
 instance-group-1-1zn8<h2>Server Location</h2>Region and Zone: us-central1-a
```

**Note:** As expected, traffic is forwarded from the Internal Load Balancer (10.10.30.5) to the backend.

4. Run the same command a couple more times.
    

In the output, you should be able to see responses from **instance-group-1** in `us-central1-c` and **instance-group-2** in the different zone of same region.

---

## Solution of Lab

### New Solution

```apache
curl -LO raw.githubusercontent.com/ePlus-DEV/storage/refs/heads/main/labs/GSP216/lab.sh
source lab.sh
```

### Old Solution

%[https://youtu.be/YYjgT20H7-Q] 

```apache
curl -LO raw.githubusercontent.com/Techcps/Google-Cloud-Skills-Boost/master/Create%20an%20Internal%20Load%20Balancer/techcps216.sh
sudo chmod +x techcps216.sh
./techcps216.sh
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1757232215796/f32753d7-b3d4-46f7-9ad1-aaad0347bae9.png align="center")