AlpinaShop's network is already built: alpinashop-vpc with its subnets, the firewall that only lets through what is needed, Cloud NAT for egress and the database on a private IP. But the catalogue is still served from one particular machine's address. If that machine goes down, the shop goes down. If traffic grows, there is nothing to spread it. And there is no HTTPS, no domain, and no single point at which to apply security. This lesson puts in front of it the piece that solves all of that at once: the load balancer.

Cloud Load Balancing is not an appliance nor a virtual machine you administer. It is a distributed service, implemented in Google's own network infrastructure, with no instances to size or scale. Its global version has a property worth understanding well because it changes the design: a single anycast IP address announced from more than a hundred points of presence around the world, so that a customer in Madrid and one in Helsinki each enter at their nearest point and travel the rest of the way over Google's private network.

On top of that, the load balancer is where everything else plugs in: the TLS certificate (03-07), the Cloud CDN cache (03-03) and the Cloud Armor application firewall (03-05) are all configured on it. Building it properly is the precondition for the next four lessons.

In this lesson you will learn to find your way around the load balancer catalogue without getting lost in the naming, you will assemble AlpinaShop's global external HTTP(S) load balancer piece by piece with gcloud, you will route /imagenes/* straight to the alpinashop-catalogo bucket and everything else to the alpinashop-web-mig MIG, and you will master health checks, which are the cause of 90 % of the problems with a freshly created load balancer.

1. Why a load balancer and what problems it solves
2. Google Cloud's load balancer catalogue and how to choose
3. Anatomy of a global external HTTP(S) load balancer
4. Groundwork: health check and named port
5. The backend service over the MIG
6. The backend bucket for the images
7. The URL map: routing by path
8. Target proxy and forwarding rule
9. Health checks in depth: why they fail
10. Balancing policies, capacity and session affinity
11. Redirecting HTTP to HTTPS
12. Global scaling: why there is no need to "pre-warm"
13. Internal load balancers for internal services
14. Serverless NEGs: Cloud Run behind the same load balancer
15. Load balancer logging and metrics

A load balancer does far more than spread requests around. In AlpinaShop's case it simultaneously solves:

The key idea: the load balancer is the edge of your architecture. Everything you want to do once for all traffic — encrypt, filter, cache, measure — is done at the edge.

This is where many people get lost, because the naming has changed over the years and the names are long. Let us sort it out with three questions.

Question 1: layer 7 or layer 4? That is, does the load balancer understand HTTP (paths, headers, cookies) or does it just move TCP/UDP packets?

Question 2: external or internal? Is it called from the internet or only from inside your VPC?

Question 3: global or regional? A single IP for the whole world or one IP per region?

With those three answers, the load balancer is determined:

Two distinctions worth being clear about:

• Proxy versus passthrough. A proxy load balancer terminates the client's connection and opens another one towards the backend; the backend sees the load balancer's IP and receives the client's in the X-Forwarded-For header. A passthrough load balancer terminates nothing: the packet arrives at the backend with the original source IP.
• Global versus regional. The global one uses anycast and a single URL map for all regions; the regional one lives in a single region and so does its IP. The global one is the one that allows CDN and Cloud Armor at worldwide scale.

A practical rule for choosing: if it is public web traffic, it is the global external Application Load Balancer. You only step down from there for a specific requirement: data residency, a protocol that is not HTTP, or the need to preserve the source IP at packet level.

The load balancer is not an object: it is a chain of objects created separately and linked together. Understanding the chain is understanding the service.

Piece by piece, from the outside in:

They are built from the inside out: first the health check, then the backend services, then the URL map, the proxy and finally the forwarding rule. If you try it the other way round, gcloud complains that the referenced resource does not exist.

AlpinaShop's Flask application listens on port 8080 under gunicorn and exposes a health path. First of all, make sure that path exists and is cheap:

That nuance deserves an explanation, because it is an architectural decision and not a detail:

• If /salud does not query the database, a database problem leaves the backends "healthy" and customers receive 500 errors from the application. Bad, but contained.
• If /salud does query the database, a database problem marks all the backends as unhealthy at once, the load balancer runs out of destinations and returns 502 to everybody. Worse: you have turned a partial failure into a total outage.

The usual practice is to have two paths: a shallow /salud (for the load balancer) and a deep /salud/completo (for the monitoring in 06-04, which alerts but does not take anything out of rotation).

Now, the health check and the named port:

The named port is a common source of confusion. The backend service does not say "send the traffic to 8080"; it says "send the traffic to the port called http-catalogo", and each instance group translates that name into a number. The advantage is that you can change the application's port without touching the load balancer. The drawback is that if you forget to define the named port, the load balancer uses the default http (port 80), finds nothing and everything shows up as unhealthy.

The check's parameters, explained:

With these values, a broken instance takes about 30 seconds to leave rotation and a recovered one about 20 to come back. Lowering the interval detects sooner but generates more load; raising the failure threshold avoids evictions caused by a transient spike.

The backend service is the central piece: it defines how traffic is spread, which check is used, how long to wait for a response, whether there is CDN and whether there is Cloud Armor.

Important options:

• --load-balancing-scheme=EXTERNAL_MANAGED: this is the scheme of the current global external Application Load Balancer, based on Google's Envoy proxy. The old EXTERNAL value corresponds to the classic load balancer. Always use EXTERNAL_MANAGED for new work: it supports advanced routing, retries, header rewriting and traffic mirroring.
• --timeout=30s: how long the load balancer waits for the complete response from the backend. If the application has any slow operation (a catalogue export, for instance), raise it or move that operation to an asynchronous process. A 502 with backend_timeout in the logs is exactly this.
• --connection-draining-timeout=60s: when an instance leaves the group (through autoscaling or an update), the load balancer stops sending it new requests but gives it 60 seconds to finish the ones in flight. Without draining, every autoscaling scale-down cuts live connections.
• --balancing-mode=RATE with --max-rate-per-instance=80: each instance is considered "full" at 80 requests per second. We develop this in section 10.

The 60 GB of catalogue images must not go through the Flask application. A backend bucket connects the load balancer directly to alpinashop-catalogo: Google serves the object with no instance involved at all.

Advantages over serving them from the application:

For the bucket to be servable by the load balancer, its objects must be publicly readable or else accessible through signed cookies (covered in 03-03). AlpinaShop's product images are public by nature — they are in the shop — so:

Notice the IAM condition: it makes public only the web/ and thumb/ part of the path convention we settled in 02-02, leaving original/ private. IAM conditions are explained in 03-04; here they serve to avoid exposing the high-resolution originals by accident.

The URL map is the load balancer's brain: it looks at the host and path of each request and decides which backend serves it.

The result can be viewed and edited as YAML, which is the clearest way to reason about it:

How a request is evaluated, with real AlpinaShop examples:

Three details that save hours of debugging:

• Path matching is by prefix with a trailing *, not a regular expression. /imagenes/* matches everything starting with /imagenes/.
• The path is not rewritten by default. A request to /imagenes/productos/moc-40/web/frontal-800.webp looks in the bucket for the object imagenes/productos/moc-40/web/frontal-800.webp, with the imagenes/ prefix included. Since our convention from 02-02 stores objects under productos/<sku>/web/..., without that prefix, we have to rewrite:

With pathPrefixRewrite: /, the request /imagenes/productos/moc-40/web/frontal-800.webp becomes /productos/moc-40/web/frontal-800.webp before reaching the bucket, which is exactly the object's path.

• gcloud compute url-maps validate checks the map before applying it, including routing tests declared in the YAML itself. It is highly recommended in a pipeline (06-01).

The last two pieces. Here we first assemble the HTTP version to validate that everything works; the certificate and the HTTPS proxy belong to 03-07, but we already write down the final form.

End-to-end check:

Be patient: a freshly created global load balancer takes between 5 and 10 minutes to propagate to every point of presence. During that time it is normal to get 404s or 502s. If it is still failing after fifteen minutes, then there really is a problem.

This section is the most profitable one in the lesson. Most broken load balancers are not badly built: they have their backends in UNHEALTHY.

First point, and the one that is most often the cause: health checks do not originate on the internet or in your subnet. Google launches them from two fixed ranges:

• 130.211.0.0/22
• 35.191.0.0/16

If the VPC firewall does not allow them, the check never arrives, the instance is marked unhealthy and the load balancer returns 502 Server Error without saying why. We already created the rule in 03-01 (fw-allow-lb-health-web), but it is worth knowing how to verify it:

A complete checklist for when a backend is UNHEALTHY:

Diagnosis from inside a VM, with no public IP, thanks to IAP:

And the aggregated view, which tells you which specific instance is broken:

There are two kinds of check on the platform and it is important not to confuse them:

If you use the same aggressive check for both things, a transient application failure can make the MIG destroy the whole fleet one machine after another. The recommended practice is for the autohealing check to be more lenient (a higher failure threshold and a simpler path) than the load balancer's.

Each backend declares when it is considered full. There are three modes:

For AlpinaShop, RATE with --max-rate-per-instance=80 means: "each instance is deemed full at 80 req/s". That number is not made up; it is measured. The correct way to obtain it:

1. Run a load test against a single instance.
2. Raise the rate until the 95th percentile latency degrades or errors appear.
3. Take between 60 % and 70 % of that figure as max-rate-per-instance, leaving headroom for spikes.

If the number is too high, the load balancer saturates the instances before overflowing to other regions. If it is too low, autoscaling adds unnecessary machines and pushes the cost up.

--capacity-scaler is a multiplier between 0.0 and 1.0 applied to the declared capacity. It serves to drain a backend without deleting it:

It is the clean way of doing a blue/green deployment or of taking a troubled region out of service.

By default there is no affinity: each request can go to a different instance. That is the right thing for a stateless application, which is how it should be designed.

AlpinaShop does not need affinity, and it is important to understand why: the shopping cart and the session live in Firestore (decided in 02-06), not in the instance's memory. Affinity is a patch for applications with local state, and it always degrades distribution: one instance can end up overloaded while others sit idle, and autoscaling cannot relieve it because the clients are already stuck to it.

Custom headers with variables ({client_region}, {client_city}, {cdn_cache_status}) are very useful: they let the application know which country the customer is coming from without geolocating anything, and let you debug the cache by looking at a response header (we will use this in 03-03).

Serving the shop over unencrypted HTTP is not acceptable. The redirect is done on the load balancer itself, not in the application, so that not a single byte of content travels in the clear.

It is implemented with a dedicated URL map that has no backends, just a redirect action:

The options explained:

• httpsRedirect: true: changes the scheme to https while keeping host and path.
• redirectResponseCode: MOVED_PERMANENTLY_DEFAULT: this is a 301. Browsers cache it, so subsequent visits do not even make the cleartext request. If you are testing and do not want it to stick in the browser, use FOUND (302) in the meantime.
• stripQuery: false: keeps the query string. Setting it to true would break campaign links with utm_* parameters.

The HSTS header, which makes the browser not even attempt HTTP, is emitted by the application and is explained in 03-07.

Anyone coming from other providers is used to "pre-warming" the load balancer before a campaign: telling the provider that traffic is coming so it can expand the load balancer's capacity. In Google Cloud that does not exist and is not needed.

The reason is architectural:

• The global load balancer is not a set of instances belonging to you. It is a function of Google's network infrastructure, the same one that serves Search, YouTube and Gmail. Its capacity is not sized for you.
• The anycast IP is announced from every PoP simultaneously. A traffic spike does not arrive at one point; it is spread geographically by construction.
• The load balancer also absorbs volumetric layer 3 and 4 attacks without you configuring anything, because the mitigation is in the network itself.

What you do have to size is what sits behind it: the alpinashop-web-mig MIG is configured for 2–10 instances, and if the autumn campaign needs more, the limit is raised in the autoscaler. The bottleneck will never be the load balancer; it will be your application or your database.

The practical consequence for the AlpinaShop team: before the campaign, the checklist does not include "warn the load balancer" but raising the MIG's max-num-replicas, reviewing max-rate-per-instance with real data and checking that the Cloud SQL read replica can cope.

Not all traffic is public. When AlpinaShop has internal services — the recommendation engine, the warehouse stock API, Lucía's report generator — those services must not have a public IP. The right piece is an internal load balancer:

Two new things and one warning:

• The scheme is INTERNAL_MANAGED, not EXTERNAL_MANAGED.
• Layer 7 internal load balancers need a proxy-only subnet (--purpose=REGIONAL_MANAGED_PROXY) per region. It is a range that hosts none of your VMs: it is used by Google's proxies. Without it, creation fails with a message that is not always obvious. Room must be reserved for it in the 03-01 addressing plan: here we have used 10.10.10.0/24, inside the free block we set aside.
• Firewall rules: the traffic arrives from the proxy-only subnet's range, not from the original client. You have to allow 10.10.10.0/24 towards the backends.

When to use each one:

In 02-07 we decided (DA-001) that the catalogue will end up on Cloud Run. Cloud Run already gives you an HTTPS URL of its own, so why put a load balancer in front of it? For four reasons you already know:

1. Your own domain and a managed certificate, unified (03-07).
2. Cloud CDN over the application's content (03-03).
3. Cloud Armor: Cloud Run's native URL cannot be protected with a WAF; the load balancer's can (03-05).
4. A single URL map distributing between Cloud Run, the bucket and whatever comes next.

The piece that makes it possible is the serverless NEG (serverless network endpoint group): a backend that points not at machines but at a managed service.

And then migrating from the MIG to Cloud Run is a change in the URL map, not a rebuild:

This is what stops today's work being thrown away tomorrow: the load balancer outlives the change of backend. The IP, the domain, the certificate, the Cloud Armor rules and the CDN configuration all stay; only where the map points changes. The details of Cloud Run belong to 07-02.

There are several types of NEG, and it is worth knowing where they fit:

Without observability, a load balancer is a black box. Enable it from the start:

--logging-sample-rate=1.0 logs 100 % of requests. On a high-traffic site it is lowered to 0.1 to contain the log cost; at AlpinaShop, with peaks of 20 req/s, 100 % is perfectly affordable and makes diagnosis far easier.

Useful queries:

The jsonPayload.statusDetails field is the most valuable one in the load balancer log. It translates the generic 502 into a concrete cause:

The backend_connection_closed_before_data_sent_to_client case deserves a note because it is subtle and very common: the global load balancer keeps persistent connections with the backend for 10 minutes. If gunicorn closes the connection sooner (its default keepalive is 2 seconds), the load balancer finds the connection closed mid-way and returns sporadic 502s, impossible to reproduce by hand. The fix is to configure gunicorn with a keepalive higher than the load balancer's:

Recommended metrics for Marta's dashboard (built in 06-04):

The difference between total_latencies and backend_latencies is what tells you whether the problem is yours or the network's: if the total rises and the backend's does not, the problem is on the way to the client.

• Forgetting the firewall for 130.211.0.0/22 and 35.191.0.0/16. It is the number one cause of a freshly created load balancer returning 502. Before debugging anything else, check that rule.
• Not defining the named port on the MIG. The backend service uses --port-name, and if the group does not declare it, the traffic goes to port 80 and nothing answers.
• Getting impatient. A global load balancer takes between 5 and 10 minutes to propagate. The first 404s and 502s are normal.
• Letting /salud query the database. It turns a partial failure into a total outage: all the backends are marked unhealthy at once.
• Using the same check for the load balancer and for MIG autohealing. A transient failure can make the group destroy and recreate the whole fleet.
• Confusing EXTERNAL with EXTERNAL_MANAGED. For new work use EXTERNAL_MANAGED; mixing them between the backend service and the forwarding rule produces confusing validation errors.
• Forgetting the backend bucket's urlRewrite. If the map sends /imagenes/* to the bucket without rewriting, it looks for an object whose name starts with imagenes/ and you get a systematic 404.
• Enabling session affinity "just in case". It degrades distribution and hides a design problem. If the application needs affinity, what has to be fixed is the state, not the load balancer.
• Setting max-rate-per-instance by eye. Measure it with a load test against one instance and apply a 30-40 % margin.
• Not enabling load balancer logging. Without statusDetails you are debugging blind.
• gunicorn's keepalive too low. It causes sporadic, irreproducible 502s. Set it above the load balancer's 600 seconds.
• Not deleting the resources from a test. The chain has seven objects; they are deleted in the reverse order of creation. Orphaned static IPs keep on being billed.

For each AlpinaShop scenario, say which load balancer it calls for and justify it in one line:

1. The public shop alpinashop.example, with customers across Europe, HTTPS, image caching and a WAF.
2. An internal stock API consumed only by the catalogue instances inside alpinashop-vpc.
3. A warehouse synchronisation service that speaks a proprietary protocol over TCP on port 9000 and needs to see the client's real IP.
4. An internal reporting dashboard for Lucía that routes /informes/* to one service and /exportar/* to another, reachable only from the internal network.

Marta has built the load balancer following the lesson, but curl http://$IP/ returns 502 Server Error and gcloud compute backend-services get-health bs-catalogo-web --global shows every instance as UNHEALTHY. It is known that:

• From another VM in sn-web-euw1, curl http://10.10.0.7:8080/salud returns 200 OK.
• The fw-allow-lb-health-web rule exists and allows tcp:80,tcp:8080 from the correct ranges towards the web-catalogo tag.

Write the sequence of diagnostic commands and the most likely cause.

AlpinaShop wants three new things:

1. That blog.alpinashop.example go to a different backend service called bs-blog.
2. That /api/* have a 120-second timeout because there is a slow export, without changing it for the rest of the site.
3. That /descargas/manual-mochilas.pdf redirect permanently to /imagenes/documentos/manual-mochilas-2026.pdf.

State which resources have to be created or modified for each point and write the URL map YAML fragment for point 3.

Solution 1

1. Global external Application Load Balancer. It is worldwide public HTTP traffic, and it is the only one that supports Cloud CDN and Cloud Armor with a global anycast IP.
2. Internal Application Load Balancer (INTERNAL_MANAGED), regional in europe-west1. It must not have a public IP and path-based routing may be useful later on. It requires a proxy-only subnet.
3. External passthrough Network Load Balancer (layer 4, regional). It is the only one that does not terminate the connection and therefore preserves the real source IP; besides, the protocol is not HTTP, so a layer 7 load balancer is no use.
4. Internal Application Load Balancer. It needs path-based routing (layer 7) and must not be reachable from the internet. If access from outside the office were also needed, the correct alternative would be the global external load balancer protected with IAP (03-04), not opening it up.

Solution 2

Most likely cause: the named port is missing. The firewall is fine and the application answers on 8080 from inside the subnet, so the check packet can indeed get through. What is happening is that the backend service asks for the port called http-catalogo and the instance group does not have it defined, so the load balancer directs the check and the traffic to the default port (80), where nothing is listening.

The second candidate cause would be that the MIG's instance template does not apply the web-catalogo tag to new machines: the rule would exist but would apply to nobody. Command 1 confirms it.

Solution 3

Point 1 — blog.alpinashop.example. You create the bs-blog backend service and add a new hostRule to the map with its own pathMatcher. You also have to include the name in the managed certificate (03-07) and create the corresponding DNS record.

Point 2 — timeout for /api/*. The timeout is a property of the backend service, not of the path rule. So you have to create a second backend service (for example bs-catalogo-api) pointing at the same MIG but with --timeout=120s, and route /api/* to it.

Point 3 — permanent redirect. It is done in the URL map itself, without touching the application:

Note: a pathRule with urlRedirect carries no service. And mind the order: more specific paths must be able to beat generic ones; the load balancer applies the longest match, so /descargas/manual-mochilas.pdf beats /descargas/*.

AlpinaShop no longer depends on a single machine. You have understood Google Cloud's load balancer catalogue by reducing it to three questions — layer 7 or layer 4, external or internal, global or regional — and you know that for public web traffic the answer is almost always the global external Application Load Balancer, with a clear distinction between proxy and passthrough.

You have built the complete chain from the inside out: the hc-catalogo check against /salud on 8080, the http-catalogo named port on the MIG, the bs-catalogo-web backend service with connection draining and RATE mode at 80 req/s per instance, the bb-catalogo-imagenes backend bucket that serves the images from alpinashop-catalogo without touching the application, the alpinashop-url-map map that sends /imagenes/* and /estatico/* to the bucket with pathPrefixRewrite and everything else to the MIG, and the forwarding rule on the global IP alpinashop-lb-ip that we reserved in 03-01.

You have learned to diagnose the one thing that really breaks: health checks, with their list of eight causes headed by the 130.211.0.0/22 and 35.191.0.0/16 ranges, and the distinction between the load balancer's check and the MIG's autohealing check. You know how to tune capacity with a measured max-rate-per-instance, how to drain a backend with capacity-scaler, and why AlpinaShop needs no session affinity: the state lives in Firestore, not in the instances. You have redirected HTTP to HTTPS at the edge, you have seen why nothing needs pre-warming ahead of the autumn campaign, where internal load balancers and their proxy-only subnet fit in, and how a serverless NEG will allow the catalogue to move to Cloud Run (DA-001) by changing only the URL map, keeping the IP, domain, certificate, cache and WAF. And you have enabled logging, which turns an opaque 502 into an actionable statusDetails.

One obvious inefficiency remains. Every time a customer in Lisbon opens a product page, the images travel from europe-west1 to Portugal, even though they are the same bytes sent a minute ago to another customer. With a 60 GB catalogue and customers spread across Europe, that is unnecessary latency and an egress bill that grows with every visit. In the next lesson, 03-03, Cloud CDN, we enable caching on the very backend service we have just built: the images will start being served from the point of presence nearest the customer, you will learn to control what gets cached and for how long, to stop campaign utm_* parameters ruining the hit ratio, and to measure the real saving in latency and in euros.