Deploy a Global External HTTPS Load Balancer using an Unmanaged Instance Group Backend, SSL Certificate, Health Checks, and HTTP-to-HTTPS Redirect.

---

Introduction

In modern cloud environments, applications are rarely exposed directly to the internet through individual virtual machines. Instead, organizations use Load Balancers to provide:

• High availability
• Scalability
• Secure HTTPS communication
• Health-based traffic routing
• Protection against backend failures

Google Cloud provides a powerful solution called Global External Application Load Balancer, which allows applications running across Google Cloud regions to be accessed globally using a single public IP address.

In this hands-on guide, we will configure:

• Global static external IP address
• SSL certificate
• Unmanaged Instance Group
• Backend Service
• Health Check
• Global External HTTPS Load Balancer
• HTTP to HTTPS redirection

We will also troubleshoot real issues encountered during implementation:

• Empty backend service
• Missing named ports
• SSL certificate stuck in PROVISIONING state
• HTTPS handshake failure (SSL_ERROR_SYSCALL)
• Certificate replacement challenges

If you are working with infrastructure automation, you can also learn how Terraform simplifies cloud resource deployment in my Terraform beginner-to-advanced guide.

---

What is Google Cloud External Application Load Balancer?

What is a Load Balancer?

A Load Balancer is a networking service that distributes incoming client requests across multiple backend servers.

Load Balancers are an important part of modern DevOps architectures. Check my guide on CI/CD pipeline automation to understand how applications move from development to production.

In a traditional architecture, users directly access a single server:

User
 |
 |
Web Server

The problem with this approach:

• If the server fails, the application becomes unavailable.
• A single server has limited capacity.
• Traffic spikes can overload the application.
• Maintenance becomes difficult.

Google Cloud provides detailed documentation for External Application Load Balancers.

A load-balanced architecture introduces a layer between users and backend servers:

              Users
                |
                |
        Load Balancer
                |
       -----------------
       |               |
    Server 1        Server 2

The Load Balancer receives requests and forwards them to healthy backend servers.

---

Why Do We Need Load Balancing in Cloud?

Modern applications need:

1. High Availability

A production application cannot depend on a single VM.

Example:

Without Load Balancer:

Application Server
       |
    Failure
       |
 Application Down

With Load Balancer:

             Load Balancer

          /              \
      VM-1              VM-2

       X                 ✓

              Traffic
             goes to VM-2

If one backend fails, traffic automatically moves to healthy instances.

---

2. Scalability

Cloud applications experience changing workloads.

Example:

Normal day:

1000 requests/minute
       |
       |
  2 backend servers

During a sale event:

100,000 requests/minute
       |
       |
Multiple backend servers

The Load Balancer distributes the increased traffic across available resources.

---

3. Global Access

Google Cloud External Application Load Balancer is a global Layer 7 load balancer.

This means users from different geographic locations can access the same application endpoint.

Example:

              User India
                  |
                  |
              Global IP
                  |
        Google Front End (GFE)
                  |
        ---------------------
        |                   |
   Backend US          Backend Europe

Google Cloud uses Google’s global network infrastructure to route traffic efficiently.

---

What is Google Cloud External Application Load Balancer?

Google Cloud External Application Load Balancer is a managed Layer 7 load balancing service that distributes HTTP and HTTPS traffic from the internet to backend applications hosted on Google Cloud.

It operates at the:

OSI Layer 7 - Application Layer

Because it understands HTTP/HTTPS protocols, it can make routing decisions based on:

• URL path
• Host name
• HTTP headers
• Cookies

Example:

https://example.com/products
                  |
                  |
              URL Map
                  |
        -------------------
        |                 |
    Product Backend   User Backend

---

Types of Google Cloud Load Balancers

Google Cloud provides different load balancers based on application requirements.

Load Balancer	Layer	Traffic Type	Use Case
External Application Load Balancer	Layer 7	HTTP/HTTPS	Web applications
Internal Application Load Balancer	Layer 7	Internal HTTP/HTTPS	Internal services
External Network Load Balancer	Layer 4	TCP/UDP	High performance applications
Internal Network Load Balancer	Layer 4	TCP/UDP	Internal workloads

---

Why Are We Using External Application Load Balancer in This Lab?

Our requirement:

“Expose web applications running on VM instances to the public internet securely using HTTPS.”

Therefore we need:

• Public IP address
• HTTPS termination
• SSL certificate
• HTTP routing
• Backend health checking

The Google Cloud External Application Load Balancer provides all these capabilities.

---

Components Involved in External Application Load Balancer

The Load Balancer is not a single resource. It is a combination of multiple components.

Architecture:

Each component has a specific responsibility:

Component	Purpose
Static External IP	Provides permanent public endpoint
Forwarding Rule	Receives traffic on ports 80/443
Target Proxy	Handles HTTP/HTTPS connection
SSL Certificate	Encrypts HTTPS traffic
URL Map	Determines traffic routing
Backend Service	Defines backend behavior
Health Check	Monitors backend availability
Instance Group	Contains backend VMs

Architecture Overview

Before starting the implementation, let’s understand the architecture.

How Google Cloud External HTTPS Load Balancer Works Internally (Request Flow)

Before configuring the Load Balancer, it is important to understand what happens internally when a user accesses an application through a Google Cloud External HTTPS Load Balancer.

A Load Balancer is not just forwarding traffic from one IP to another. Multiple Google Cloud components work together to process every request.

---

Complete Request Flow of External HTTPS Load Balancer

When a user opens:

https://8.233.151.62

the request follows this flow:

---

Step 1: User Sends HTTPS Request

The user accesses the application:

https://application-domain.com

The DNS name resolves to the Load Balancer’s external IP address.

Example:

application-domain.com
             |
             |
             v
       8.233.151.62

The request reaches Google’s global edge infrastructure.

---

Step 2: Global External IP Receives Traffic

The static external IP address acts as the single entry point for users.

Why use a static IP?

Because users, DNS records, and applications need a stable endpoint.

Without static IP:

Load Balancer IP
       |
       |
   Changes after recreation
       |
       |
Application unavailable

With static IP:

Application DNS
       |
       |
Permanent Load Balancer IP
       |
       |
Backend Servers

---

Step 3: Forwarding Rule Processes the Request

The forwarding rule decides:

• Which IP address accepts traffic
• Which port is allowed
• Which proxy handles the request

Example:

HTTPS rule:

IP:
8.233.151.62

Protocol:
TCP

Port:
443

Target:
webserver-https-proxy

The forwarding rule receives:

Incoming Request

8.233.151.62:443

and sends it to:

Target HTTPS Proxy

---

Step 4: Target HTTPS Proxy Handles HTTPS Traffic

The Target HTTPS Proxy is responsible for:

• Managing HTTPS connections
• Selecting SSL certificates
• Connecting the request to the URL map

The proxy performs TLS termination.

---

What is TLS Termination?

TLS termination means the Load Balancer decrypts HTTPS traffic before forwarding it to backend servers.

Example:

Client side:

Browser
   |
   |
HTTPS
Encrypted Traffic
   |
   |
Load Balancer

After SSL termination:

Load Balancer
        |
        |
HTTP
Internal Traffic
        |
        |
Backend VM

In our architecture:

Client → Load Balancer:

HTTPS :443

Load Balancer → VM:

HTTP :80

---

Why Terminate SSL at the Load Balancer?

There are several advantages:

1. Centralized Certificate Management

Instead of installing certificates on every VM:

VM1 → Certificate
VM2 → Certificate
VM3 → Certificate

we manage one certificate:

Load Balancer
       |
       |
 SSL Certificate

---

2. Reduced Backend Complexity

Backend servers do not need to handle:

• SSL negotiation
• Certificate renewal
• Encryption overhead

They only process application traffic.

---

3. Better Performance

Google Cloud’s edge infrastructure handles TLS processing using optimized systems.

---

Step 5: URL Map Determines Traffic Routing

The URL Map decides where the request should go.

Example:

User requests:

https://example.com/products

URL Map:

/products
      |
      |
Product Backend

Another request:

https://example.com/users

URL Map:

/users
      |
      |
User Backend

In our lab:

We have a simple configuration:

All Traffic
     |
     |
cepf-webserver-backend

because we have only one application.

---

Step 6: Backend Service Receives Traffic

The backend service defines:

• Backend instances
• Protocol
• Health checks
• Load balancing method
• Connection settings

Our backend service:

cepf-webserver-backend

contains:

webserver-instance-group

---

Step 7: Health Check Determines Available Servers

Before sending traffic, Google Cloud continuously checks backend health.

Example:

Health Check:

Protocol:
HTTP

Port:
80

Request:
/

Backend status:

webserver1  HEALTHY
webserver2  HEALTHY

Traffic distribution:

              Load Balancer

              /          \

       webserver1      webserver2

        HEALTHY        HEALTHY

---

If a server fails:

              Load Balancer

                    |

              webserver2

              HEALTHY


       webserver1

        UNHEALTHY

Traffic automatically stops going to the unhealthy instance.

---

Step 8: Backend VM Processes Request

Finally, the request reaches the application server.

Example:

The response follows the reverse path:

---

Complete End-to-End Flow Summary

Step	Component	Responsibility
1	User Browser	Sends HTTPS request
2	Static IP	Provides public endpoint
3	Forwarding Rule	Receives traffic on port 443
4	HTTPS Proxy	Handles SSL/TLS
5	SSL Certificate	Encrypts communication
6	URL Map	Selects backend
7	Backend Service	Manages backend traffic
8	Health Check	Validates VM availability
9	Instance Group	Provides VM pool
10	VM	Serves application

---

Interview Perspective

A common cloud networking interview question is:

“Explain the request flow when a user accesses an application behind Google Cloud External HTTPS Load Balancer.”

A strong answer should mention:

1. DNS resolves the domain to the load balancer IP.
2. Forwarding rule receives traffic.
3. Target HTTPS proxy handles TLS termination.
4. URL map selects backend service.
5. Backend service forwards traffic to healthy instances.
6. Health checks continuously monitor backend availability.

---

Lab: Prerequisites

Before starting:

• Google Cloud Project
• Cloud Shell access
• Two running VM instances:
  • webserver1
  • webserver2

Both VMs should host a web application on port 80.

---

Task 1: Create Global Static External IP Address

The first step is creating a static IP address.

Why do we need a static IP?

A Load Balancer requires a fixed public endpoint. If we use an ephemeral IP, the address can change after resource modifications.

Create static IP:

gcloud compute addresses create cepf-static-ip \
--ip-version=IPV4 \
--global

Verify:

gcloud compute addresses list --global

Example output:

NAME              ADDRESS
cepf-static-ip    8.233.151.62

---

Task 2: Create SSL Certificate

For HTTPS communication, the Load Balancer requires an SSL certificate.

The lab provides a special domain format:

IP Address → qlencrypt.com domain

Example:

IP:

8.233.151.62

Converted format:

8-233-151-62.qlencrypt.com

Create certificate:

gcloud compute ssl-certificates create webserver-cert \
--description=WebserverCertificate \
--domains=8-233-151-62.qlencrypt.com \
--global

Verify:

gcloud compute ssl-certificates list

---

Task 3: Create Unmanaged Instance Group

What is an unmanaged instance group?

Google Cloud provides two types of instance groups:

One of the important decisions while designing a Google Cloud infrastructure is choosing the correct type of Instance Group.

Google Cloud provides two types of Instance Groups:

1. Managed Instance Group (MIG)
2. Unmanaged Instance Group

Both are used to group multiple VM instances together and integrate them with services like Load Balancers, but their management capabilities are very different.

---

What is an Instance Group?

An Instance Group is a collection of Virtual Machine (VM) instances that are managed together as a single entity.

Instead of configuring each VM individually:

VM-1
VM-2
VM-3

we create:

        Instance Group

       /      |       \

    VM-1    VM-2     VM-3

The Load Balancer communicates with the Instance Group instead of individual VMs.

Example:

---

Why Do We Need Instance Groups?

A Load Balancer requires a backend target.

It cannot directly manage individual VM instances efficiently.

Instead of:

Load Balancer
      |
      |
  VM-1
  VM-2
  VM-3

Google Cloud uses:

Load Balancer
      |
      |
Backend Service
      |
      |
Instance Group
      |
      |
VM Instances

The Instance Group provides:

• Logical grouping
• Backend management
• Health monitoring integration
• Load distribution capability

---

1. Managed Instance Group (MIG)

A Managed Instance Group is a collection of identical VM instances managed automatically by Google Cloud.

Google Cloud manages the complete lifecycle of instances.

A MIG uses an Instance Template as the blueprint for creating VMs.

Architecture:

              Instance Template

                     |

                     |

            Managed Instance Group

              /       |        \

            VM-1     VM-2     VM-3

---

What is an Instance Template?

An Instance Template defines VM configuration:

• Machine type
• Boot disk image
• Network configuration
• Startup script
• Labels
• Service account
• Metadata

Example:

Instance Template

Machine Type:
e2-medium

OS:
Ubuntu

Disk:
20 GB

Startup Script:
Install Apache

Whenever MIG creates a new VM, it uses this template.

---

Features of Managed Instance Groups

1. Auto Scaling

MIG can automatically increase or decrease VM count based on workload.

Example:

Normal traffic:

Users: 1000

VM Count:
2

High traffic:

Users: 100000

MIG automatically creates:

VM-1
VM-2
VM-3
VM-4
VM-5

When traffic decreases:

Unused VMs removed automatically

---

2. Auto Healing

MIG continuously monitors VM health.

Example:

Before failure:

MIG

VM-1 HEALTHY
VM-2 HEALTHY
VM-3 HEALTHY

VM-2 crashes:

MIG

VM-1 HEALTHY
VM-2 FAILED
VM-3 HEALTHY

MIG automatically:

Deletes VM-2

Creates replacement VM

---

3. Rolling Updates

MIG supports application updates without downtime.

Example:

Old version:

VM-1 → Application v1
VM-2 → Application v1
VM-3 → Application v1

During deployment:

VM-1 → Application v2
VM-2 → Application v1
VM-3 → Application v1

Eventually:

VM-1 → Application v2
VM-2 → Application v2
VM-3 → Application v2

---

4. Multi-Zone High Availability

MIG can distribute instances across multiple zones.

Example:

              Region

        ------------------

        Zone A       Zone B

        VM-1         VM-3

        VM-2         VM-4

If one zone fails, applications continue running.

---

When Should We Use Managed Instance Groups?

Use MIG when:

• Application requires auto scaling
• High availability is required
• Servers have identical configuration
• Infrastructure follows cloud-native design
• Application is stateless

Examples:

• Web servers
• API servers
• Microservices
• Container hosts

---

2. Unmanaged Instance Group

An Unmanaged Instance Group is a collection of existing VM instances that you manually manage.

Google Cloud does not create, delete, or configure these VMs.

Architecture:

---

Characteristics of Unmanaged Instance Groups

1. No Instance Template

Unlike MIG:

MIG:

Instance Template
        |
        |
VM Creation

Unmanaged:

Existing VM
        |
        |
Add manually to group

---

2. No Auto Scaling

Google Cloud will not automatically add or remove VMs.

Example:

Current:

VM-1
VM-2


Traffic increases:

You must manually create VM-3

---

3. No Auto Healing

If a VM fails:

VM-1 FAILED

Google Cloud does not recreate it automatically.

The administrator must fix it manually.

---

4. Different VM Configurations Allowed

Unlike MIG, unmanaged groups can contain different VMs.

Example:

Unmanaged Instance Group

VM-1
Ubuntu
e2-medium

VM-2
Debian
n2-standard

VM-3
Custom Image

---

When Should We Use Unmanaged Instance Groups?

Use unmanaged groups when:

• Existing VMs are already deployed
• Migrating legacy applications
• Servers have different configurations
• Manual control is required

Examples:

• Legacy applications
• Lift-and-shift migrations
• Existing production servers

---

Managed vs Unmanaged Instance Group Comparison

Feature	Managed Instance Group	Unmanaged Instance Group
VM creation	Automatic	Manual
Instance template	Required	Not required
Auto scaling	Supported	Not supported
Auto healing	Supported	Not supported
Rolling updates	Supported	Not supported
VM configuration	Identical	Can be different
Multi-zone deployment	Supported	Limited
Cloud-native applications	Recommended	Less suitable
Legacy applications	Less suitable	Recommended

---

Why Did We Use an Unmanaged Instance Group in This Lab?

In this lab scenario:

Cymbal’s application team already created:

webserver1

webserver2

The requirement was:

“Expose these existing VM instances to the public internet using a Global External Application Load Balancer.”

We were not asked to create new VMs or configure auto scaling.

Therefore, creating a Managed Instance Group would introduce unnecessary complexity.

The correct architecture:

Existing VM Instances

        |
        |

Unmanaged Instance Group

        |
        |

Backend Service

        |
        |

External HTTPS Load Balancer

---

Real-World Recommendation

For new cloud-native applications:

Application
     |
     |
Managed Instance Group
     |
     |
Load Balancer

is the preferred architecture.

For migration projects:

Existing Servers
     |
     |
Unmanaged Instance Group
     |
     |
Load Balancer

is often the first step.

Managed Instance Group (MIG)

Automatically manages:

• VM creation
• Auto healing
• Auto scaling
• Rolling updates

Unmanaged Instance Group

You manually manage:

• VM lifecycle
• Instance membership

Used when existing VMs already exist.

In this lab, we already have:

webserver1
webserver2

so we create an unmanaged group.

---

Create instance group:

gcloud compute instance-groups unmanaged create webserver-instance-group \
--zone=us-west1-a

Verify:

gcloud compute instance-groups unmanaged describe webserver-instance-group \
--zone=us-west1-a

---

Add VM Instances

Add existing servers:

gcloud compute instance-groups unmanaged add-instances webserver-instance-group \
--instances=webserver1,webserver2 \
--zone=us-west1-a

Verify:

gcloud compute instance-groups unmanaged list-instances webserver-instance-group \
--zone=us-west1-a

Output:

webserver1
webserver2

---

Configure Named Port

This is a very important step.

The Load Balancer does not directly know which port your application uses.

We define:

http → 80

Command:

gcloud compute instance-groups unmanaged set-named-ports \
webserver-instance-group \
--zone=us-west1-a \
--named-ports=http:80

Verify:

gcloud compute instance-groups unmanaged describe webserver-instance-group \
--zone=us-west1-a

Expected:

namedPorts:
- name: http
  port: 80

---

Task 4: Create Backend Service

The backend service defines:

• Where traffic should go
• Health checking
• Load balancing behavior

Create health check:

gcloud compute health-checks create http webserver-health-check \
--port 80

---

Create backend service:

gcloud compute backend-services create cepf-webserver-backend \
--protocol HTTP \
--health-checks webserver-health-check \
--global

---

Attach Instance Group

gcloud compute backend-services add-backend cepf-webserver-backend \
--global \
--instance-group=webserver-instance-group \
--instance-group-zone=us-west1-a

Verify:

gcloud compute backend-services describe cepf-webserver-backend \
--global

Expected:

backends:
- webserver-instance-group

---

Check Backend Health

Before exposing the application, verify backend health.

Command:

gcloud compute backend-services get-health \
cepf-webserver-backend \
--global

Expected:

webserver1 HEALTHY
webserver2 HEALTHY

---

Task 5: Configure Load Balancer

The Load Balancer requires:

1. URL Map
2. Target Proxy
3. Forwarding Rule

---

Create URL Map

gcloud compute url-maps create webserver-url-map \
--default-service=cepf-webserver-backend

---

Configure HTTPS Proxy

gcloud compute target-https-proxies create webserver-https-proxy \
--url-map=webserver-url-map \
--ssl-certificates=webserver-cert

---

Create HTTPS Forwarding Rule

gcloud compute forwarding-rules create https-content-rule \
--global \
--address=cepf-static-ip \
--target-https-proxy=webserver-https-proxy \
--ports=443

---

Configure HTTP to HTTPS Redirect

Create redirect proxy:

gcloud compute url-maps create http-redirect-map \
--default-url-redirect-https

Create HTTP proxy:

gcloud compute target-http-proxies create http-redirect-proxy \
--url-map=http-redirect-map

Create HTTP forwarding rule:

gcloud compute forwarding-rules create http-content-rule \
--global \
--address=cepf-static-ip \
--target-http-proxy=http-redirect-proxy \
--ports=80

---

Troubleshooting Journey

Now let’s discuss the real issues encountered during implementation.

---

Issue 1: Backend Service Showing Empty Backend

Error

NAME: cepf-webserver-backend

BACKENDS:

Cause

Backend service was created but no instance group was attached.

Solution

Attach backend:

gcloud compute backend-services add-backend \
cepf-webserver-backend \
--global \
--instance-group=webserver-instance-group \
--instance-group-zone=us-west1-a

---

Issue 2: Duplicate Instance Group Error

Error:

Duplicate instance groups in backend service

Cause

The backend was already attached.

Verify:

gcloud compute backend-services describe \
cepf-webserver-backend \
--global

No action required.

---

Issue 3: Missing Named Ports

Without named ports:

Load Balancer
      |
      X
Backend

Solution:

gcloud compute instance-groups unmanaged set-named-ports \
webserver-instance-group \
--zone=us-west1-a \
--named-ports=http:80

---

Issue 4: SSL Certificate Stuck in PROVISIONING

Problem:

TYPE: MANAGED

STATUS: PROVISIONING

HTTPS failed:

SSL_ERROR_SYSCALL

Root Cause

Google Managed Certificates require domain validation.

DNS lookup:

nslookup 8-233-151-62.qlencrypt.com

returned:

SERVFAIL

The certificate could not become ACTIVE.

---

Issue 5: Replacing Certificate

Because the certificate was attached:

Certificate
      |
HTTPS Proxy

Deletion failed:

ssl_certificate is already being used

Dependency order:

Forwarding Rule
        |
HTTPS Proxy
        |
Certificate

Delete resources in reverse order.

---

Issue 6: HTTPS Handshake Failure

Testing:

curl -k -I https://8.233.151.62

Returned:

SSL_ERROR_SYSCALL

Troubleshooting:

Verified:

✔ Forwarding rule
✔ HTTPS proxy
✔ Backend health
✔ Certificate attachment

Finally replaced the managed certificate with a self-managed certificate.

---

Final Validation

HTTP Redirect Test

Command:

curl -I http://8.233.151.62

Result:

HTTP/1.1 301 Moved Permanently

Location:
https://8.233.151.62:443/

Success.

---

Backend Health

Command:

gcloud compute backend-services get-health \
cepf-webserver-backend \
--global

Result:

webserver1 HEALTHY
webserver2 HEALTHY

Success.

---

Key Learnings

Through this implementation we learned:

✅ How Global External Application Load Balancer works
✅ Difference between Managed and Unmanaged Instance Groups
✅ Importance of Backend Services
✅ How Health Checks work
✅ SSL certificate lifecycle
✅ Dependency management in Google Cloud
✅ Real troubleshooting methodology

---

Conclusion

Google Cloud External Application Load Balancer provides a production-ready solution for exposing applications securely to the internet.

Although creating a Load Balancer involves multiple components, understanding the relationship between:

• Forwarding Rules
• Target Proxies
• SSL Certificates
• URL Maps
• Backend Services
• Instance Groups

makes troubleshooting much easier.

Real cloud engineering is not only about creating resources — it is about understanding how each component communicates and diagnosing failures systematically.