Overview

Google Cloud HTTP(S) load balancing is implemented at the edge of Google's network in Google's points of presence (POP) around the world. User traffic directed to an HTTP(S) load balancer enters the POP closest to the user and is then load-balanced over Google's global network to the closest backend that has sufficient capacity available.

Google Cloud Armor IP deny/allow rules enable you to restrict or allow access to your HTTP(S) load balancer at the edge of the Google Cloud, as close as possible to the user and to malicious traffic. This prevents malicious users or traffic from consuming resources or entering your virtual private cloud (VPC) networks.

In this lab, you will configure an HTTP load balancer with global backends, as shown in the diagram below. Then you stress test the load balancer and deny the stress test IP with Google Cloud Armor.

Objectives

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

• Create a health check firewall rule
• Create two regional NAT configurations using Cloud Router
• Configure two instance templates
• Create two managed instance groups
• Configure an HTTP load balancer with IPv4 and IPv6
• Stress test an HTTP load balancer
• Deny an IP address to restrict access to an HTTP load balancer

Setup and requirements

For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.

1. Sign in to Qwiklabs using an incognito window.

2. Note the lab's access time (for example, 1:15:00), and make sure you can finish within that time.
   There is no pause feature. You can restart if needed, but you have to start at the beginning.

3. When ready, click Start lab.

4. Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.

5. Click Open Google Console.

6. Click Use another account and copy/paste credentials for this lab into the prompts.
   If you use other credentials, you'll receive errors or incur charges.

7. Accept the terms and skip the recovery resource page.

Activate Google Cloud Shell

Google Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud.

Google Cloud Shell provides command-line access to your Google Cloud resources.

1. In Cloud console, on the top right toolbar, click the Open Cloud Shell button.

   

2. Click Continue.

It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. For example:

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

• You can list the active account name with this command:

gcloud auth list

Output:

Credentialed accounts: - @.com (active)

Example output:

Credentialed accounts: - google1623327_student@qwiklabs.net

• You can list the project ID with this command:

gcloud config list project

Output:

[core] project =

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: Full documentation of gcloud is available in the gcloud CLI overview guide .

Task 1. Configure a health check firewall rule

Health checks determine which instances of a load balancer can receive new connections. For HTTP 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.

Create the HTTP firewall rule

Create a firewall rule to allow HTTP traffic to the backends.

1. In the Cloud console, navigate to Navigation menu () > VPC network > Firewall.

2. Notice the existing ICMP, internal, RDP, and SSH firewall rules.

   Each Google Cloud project starts with the default network and these firewall rules.

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	default-allow-http
   Network	default
   Targets	Specified target tags
   Target tags	http-server
   Source filter	IPv4 Ranges
   Source IPv4 ranges	0.0.0.0/0
   Protocols and ports	Specified protocols and ports, and then check TCP, type: 80

Make sure to include the /0 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 Application 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 policies 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	default-allow-health-check
   Network	default
   Targets	Specified target tags
   Target tags	http-server
   Source filter	IPv4 Ranges
   Source IPv4 ranges	130.211.0.0/22, 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 press SPACE in between them.

3. Click Create.

Click Check my progress to verify the objective. Configure health check firewall rule

Task 2. Create two NAT configurations using Cloud Router

The Google Cloud VM backend instances that you set up in task 3 will not be configured with external IP addresses.

Instead, you will set up the Cloud NAT service to allow these VM instances to make outbound requests in order to install Apache Web server and PHP when they are launched. You create a Cloud Router for each managed instance group, one in and one in the region, which you will configure in the next task.

Create the Cloud Router instance

1. In the Cloud Console, in the Navigation menu () click View All Products and navigate to Network services > Cloud NAT.

2. Click Get started.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Gateway name	nat-1
   Network	default
   Region

4. Click Cloud Router and select Create new router.

5. For Name, type nat-router-1.

6. Click Create.

7. In Create a cloud NAT gateway, click Create.

Note: Wait until the NAT Gateway Status changes to Running before moving onto the next task.

Repeat the same procedure for nat-2.

8. Click Create Cloud NAT Gateway.

9. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Gateway name	nat-2
   Network	default
   Region
   Cloud Router > Create new router	Specify the name nat-router-2

10. Click Create.

11. In Create a NAT gateway, click Create.

Click Check my progress to verify the objective. Create two NAT configurations using Cloud Router

Task 3. Configure an instance template and create instance groups

A managed instance group uses an instance template to create a group of identical instances. You will use these to create the backends of the HTTP load balancer.

Configure the instance template

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.

1. In the Cloud Console, in the Navigation menu (), select Compute Engine > Instance templates.

2. Click Create instance template.

3. For Name, type template-1.

4. Choose Region :

5. Click Advanced Options.

6. Click Management.

7. Under Metadata, click + ADD ITEM and specify the following:

   Key	Value
   startup-script-url	gs://cloud-training/gcpnet/httplb/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. You can find out more about this script by referring to the script reference guide.

8. Click Networking.

9. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Network tags	allow-health-checks
   Network interface > Network	default
   Subnetwork	default ()
   External IPv4 address	None

10. Click DONE.

Note: The network tag allow-health-checks ensures that the Health Check firewall rule applies to these instances.

11. Click Create. Wait for the instance template to be created.

12. Now, prepare to create another instance template by copying template-1. Click the template-1. Information about the template-1 appears.

13. Near the top of the page, click CREATE SIMILAR.

14. For Name, type template-2.

15. Choose Region :

16. Click Advanced Options.

17. Click Networking > Network interface.

18. Select default as the Subnetwork, and click DONE.

19. Click Create.

Create the managed instance groups

Create a managed instance group in and one in .

1. In the Navigation menu, select Compute Engine > Instance groups.

2. Click Create Instance group.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Name	mig-1
   Instance template	template-1
   Location	Multiple zones
   Region
   Autoscaling > Minimum number of instances	1
   Autoscaling > Maximum number of instances	5
   Autoscaling > Autoscaling signals	Click CPU utilization, set 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.

4. Click Create.

   Repeat the same procedure for mig-2 in .

5. Click Create Instance group.

6. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Name	mig-2
   Location	Multiple zones
   Region
   Instance template	template-2
   Autoscaling > Minimum number of instances	1
   Autoscaling > Maximum number of instances	5
   Autoscaling > Autoscaling signals	Click CPU utilization, set Target CPU utilization 80
   Initialization period	45

7. Click Create.

Click Check my progress to verify the objective. Configure instance templates and create instance groups

Verify the backends

Verify that VM instances are being created in both regions and access their HTTP sites.

1. In the Navigation menu, click Compute Engine > VM instances.
   Notice the instances that start with mig-1 and mig-2.

   These instances are part of the managed instance groups.

2. In Cloud Console, note the name and the zone of the VM instance located in region. (You will need to use these values in a moment.)

3. On the Google Cloud Platform menu, click Activate Cloud Shell () to open Cloud Shell. If prompted, click Continue.

4. In Cloud Shell, execute this command to execute SSH commands in the VM instance located in region:

gcloud compute ssh <INSTANCE_NAME> --zone <ZONE>

5. If prompted, click Authorize.
6. When asked if you want to continue, enter Y.
7. When prompted for a passphrase, press Enter or Return. This will generate an empty passphrase.
8. To confirm the empty passphrase, press Enter or Return again. After a moment, Cloud Shell uses IAP tunneling to make an SSH connection to the VM instance in . The Cloud Shell command line can now be used as the VM instance's command line.
9. At the command line, enter the following:

curl localhost

You should see the Apache welcome page, which was installed as part of the startup-script-url script that changes the welcome page to include the client IP and the name, region, and zone of the VM instance.

10. Copy the internal IP address of an instance located in the region.
11. Test the connection by running the following command:

curl $IP_Address Note: Replace the value $IP_Address with the internal IP of the instance.

12. Enter exit to close the SSH session.

Task 4. Configure the HTTP load balancer

Next, you will configure the HTTP load balancer to balance traffic between the two backends (mig-1 in and mig-2 in ), as illustrated in the network diagram.

Start the configuration

1. In the Navigation menu () click View All Products and navigate to Network services > Load balancing.
2. Click Create load balancer.
3. Under Type of load balancer, select Application Load Balancer (HTTP/HTTPS), click Next.
4. Under Public facing or internal, select Public facing (external) and click Next.
5. Under Global or single region deployment, select Best for global workloads, click Next.
6. Under Load balancer generation, select Classic Application Load Balancer, click Next.
7. Click Configure.
8. For Load Balancer Name, type http-lb.

Configure the backend

Backend services direct incoming traffic to one or more attached backends. Each backend is composed of an instance group and additional serving capacity metadata.

1. Click Backend configuration.

2. For Backend services & backend buckets, click Create a backend service.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (select option as specified)
   Name	http-backend
   Backend type	Instance group
   Backends > Instance group	mig-1
   Port numbers	80
   Balancing mode	Rate
   Maximum RPS	50
   Capacity	100

Note: This configuration means that the load balancer attempts to keep each instance of mig-1 at or below 50 requests per second (RPS).

4. Click Done.

5. Click Add backend.

6. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (select option as specified)
   Instance group	mig-2
   Port numbers	80
   Balancing mode	Utilization
   Maximum backend utilization	80
   Capacity	100

Note: This configuration means that the load balancer attempts to keep each instance of mig-2 at or below 80% CPU utilization.

7. Click Done.

8. For Health Check, select Create a health check.

9. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (select option as specified)
   Name	http-health-check
   Protocol	TCP
   Port	80

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

10. Click Create.
11. Check the Enable Logging box.
12. Set the Sample Rate to 1.
13. Click Create.

Configure the frontend

The host and path rules determine how your traffic will be directed. For example, you could direct video traffic to one backend and direct static traffic to another backend. However, you are not configuring the host and path rules in this lab.

1. Click Frontend configuration.

2. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Protocol	HTTP
   IP version	IPv4
   IP address	Ephemeral
   Port	80

3. Click Done.

4. Click Add Frontend IP and port.

5. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Protocol	HTTP
   IP version	IPv6
   IP address	Auto-allocate
   Port	80

6. Click Done.

Note: HTTP(S) load balancing supports both IPv4 and IPv6 addresses for client traffic. Client IPv6 requests are terminated at the global load balancing layer and then proxied over IPv4 to your backends.

Review and create the HTTP load balancer

1. Click Review and finalize.
2. Review the Backend services and Frontend.
3. Click Create.
   Wait for the load balancer to be created.
4. Click on the name of the load balancer (http-lb).
5. Note the IPv4 and IPv6 addresses of the load balancer for the next task. They will be referred to as [LB_IP_v4] and [LB_IP_v6], respectively.

Note: The IPv6 address is the one in hexadecimal format.

Click Check my progress to verify the objective. Configure the HTTP load balancer

Task 5. Test the HTTP load balancer

Now that you have created the HTTP load balancer for your backends, it is time to verify that traffic is forwarded to the backend service.

Access the HTTP load balancer

1. Open a new tab in your browser and navigate to http://[LB_IP_v4]. Make sure to replace [LB_IP_v4] with the IPv4 address of the load balancer.

Note: It might take a couple of minutes to access the HTTP load balancer. In the meantime, you might get a 404 or 502 error. Keep trying until you see the page of one of the backends. Note: Depending on your proximity to and , you traffic is either forwarded to a mig-1 or mig-2 instance.

2. If you have a local IPv6 address, try the IPv6 address of the HTTP load balancer by navigating to http://[LB_IP_v6]. Make sure to replace [LB_IP_v6] with the IPv6 address of the load balancer.

Stress test the HTTP load balancer

Next, you will create a new VM to simulate a load on the HTTP load balancer. Then you will determine whether traffic is balanced across both backends when the load is high.

1. In the Cloud Console, in the Navigation menu (), select Compute Engine > VM instances.

2. Click Create instance.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Name	siege-vm
   Region
   Zone

4. Click Create. Wait for the siege-vm instance to be created.

5. At the Cloud Shell prompt, enter the following command to create an SSH connection to the siege-vm:

   gcloud compute ssh siege-vm --zone {{{project_0.default_zone_3|Zone 3}}}

6. Run the following command to install siege:

sudo apt-get -y install siege

7. To store the IPv4 address of the HTTP load balancer in an environment variable, run the following command, replacing [LB_IP_v4] with the IPv4 address:

export LB_IP=[LB_IP_v4]

8. Verify it with echo:

echo $LB_IP

9. To simulate a load, run the following command:

siege -c 250 http://$LB_IP

10. In the Cloud Console, in the Navigation menu () click View All Products and navigate to Network services > Load balancing.
11. Click http-lb.
12. Click Monitoring.
13. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for 2 to 3 minutes.
14. Return to the SSH terminal of siege-vm.
15. Press CTRL+C to stop siege.

The output should look like this.

Output:

New configuration template added to /home/student-03-e8562fd77201/.siege Run siege -C to view the current settings in that file { "transactions": 26372, "availability": 100.00, "elapsed_time": 118.46, "data_transferred": 3.39, "response_time": 0.31, "transaction_rate": 222.62, "throughput": 0.03, "concurrency": 68.14, "successful_transactions": 1001, "failed_transactions": 0, "longest_transaction": 13.78, "shortest_transaction": 0.02 }

Task 6. Deny the siege-vm

You will now use Google Cloud Armor to deny the siege-vm from accessing the HTTP load balancer.

Create the security policy

Create a Google Cloud Armor security policy with a deny rule for the siege-vm.

1. In the Cloud Console, in the Navigation menu, select Compute Engine > VM instances.
2. Note the External IP of the siege-vm. This will be referred to as [SIEGE_IP].

Note: There are ways to identify the external IP address of a client trying to access your HTTP load balancer. For example, you could examine traffic captured by VPC Flow Logs in BigQuery to determine a high volume of incoming requests.

3. In the Navigation menu () click View All Products and navigate to Network Security > Cloud Armor > Cloud Armor policies.

4. Click Create policy.

5. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Name	deny-siege
   Default rule action	Allow

6. Click Next step.

7. Click Add rule.

8. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Condition > Match	Enter the SIEGE_IP
   Action	Deny
   Deny status	403 (Forbidden)
   Priority	1000

9. Click Save change to rule.

10. Click Next step.

11. Click Add Target.

12. For Type, select Backend service (external application load balancer).

13. For Target, select http-backend and if prompted confirm Replace.

14. Click Create policy.
    Wait for the policy to be created before moving to the next step.

Note: Alternatively, you could set the default rule to Deny and only allow traffic from authorized users/IP addresses.

Click Check my progress to verify the objective. Deny the siege-vm

Verify the security policy

Next, you will verify that the siege-vm cannot access the HTTP load balancer.

1. Return to the SSH terminal of siege-vm.
2. To access the load balancer, run the following:

curl http://$LB_IP

The output should look like this.

Output:

<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</ title>403 Forbidden Note: It might take a couple of minutes for the security policy to take affect. If you are able to access the backends, keep trying until you get the 403 Forbidden error.

3. Open a new tab in your browser and navigate to http://[LB_IP_v4]. Make sure to replace [LB_IP_v4] with the IPv4 address of the load balancer.

Note: You can access the HTTP load balancer from your browser because of the default rule to allow traffic; however, you cannot access it from the siege-vm because of the deny rule that you implemented.

4. To simulate a load, run the following command:

siege -c 250 http://$LB_IP

The command will not generate any output.

Explore the security policy logs to determine whether this traffic is also blocked.

5. In the Navigation menu () click View All Products and navigate to Network Security > Cloud Armor > Cloud Armor policies.
6. Click deny-siege.
7. Click Logs.
8. Click View policy logs. Logs Explorer is launched. You should see the logs for the http-lb load balancer.
9. Expand a log entry in Query results.
10. Expand httpRequest.

The request should be from the siege-vm IP address. If not, expand another log entry.

11. Expand jsonPayload.
12. Expand enforcedSecurityPolicy.
    Notice that the configuredAction is to DENY with the name deny-siege.

Note: Google Cloud Armor security policies create logs that can be explored to determine when traffic is denied and when it is allowed, along with the source of the traffic.

Congratulations!

In this lab, you have configured an HTTP load balancer with backends in and . Then you stress-tested the load balancer with a VM and denied the IP address of that VM with Google Cloud Armor. In addition, you were able to explore the security policy logs to identify why the traffic was blocked.

End your lab

When you have completed your lab, click End Lab. Google Cloud Skills Boost removes the resources you’ve used and cleans the account for you.

You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.

The number of stars indicates the following:

• 1 star = Very dissatisfied
• 2 stars = Dissatisfied
• 3 stars = Neutral
• 4 stars = Satisfied
• 5 stars = Very satisfied

You can close the dialog box if you don't want to provide feedback.

For feedback, suggestions, or corrections, please use the Support tab.

Copyright 2024 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.