Publishing in the cloud does not change what a reverse proxy does, but it changes who operates it, what you can configure on it and what it costs. This last lesson is for someone who has just published a service behind Nginx, Traefik or HAProxy and wonders what stays true with a cloud provider. It separates three things: the concepts that survive, the settings that change hands (file, then API), and the subjects the training had no reason to teach: billing, quotas, availability zones, the managed edge. No provider-specific action is taught here.
What you will learn
The lesson starts from what you already know how to do by hand, and says for each piece which of three things happens to it: it survives as is, it changes operator, or it gives way to a subject that self-hosting did not raise.
- Say which concepts of the training remain valid with a managed load balancer
- Translate a file setting into an API or console setting
- Name what the cloud adds: bill, quotas, zones
- Explain why the machines stay private and only the edge is public
Prerequisites
This lesson closes the training: it assumes that you have published at least one service behind a reverse proxy. Three notions are enough to read it: the reverse proxy, the health probe and the firewall.
- What a reverse proxy is, and the difference between a name, a port and a backend: see Reverse proxy: definition, role and which tool to choose.
- What a health probe is: see Choose the load-balancing algorithm and measure health checks.
- What a firewall does in front of a service: see Link interfaces, ports, firewalls and exposure.
No account with a provider is needed: the lesson therefore has no lab, only a quiz.
What stays true when you publish with a cloud provider?
The concepts of the training remain accurate: only the operator changes. A managed load balancer receives connections on a public address, picks a backend, terminates TLS if asked to, probes its backends and stops sending traffic to the one that fails. This is exactly the contract that the training had you check by hand: a name, a certificate, a path from the request to the backend, a cutover.
Three skills are therefore as useful as before. Reading a probe: a probe
that only checks that a port answers lets a stuck application through, as with
HAProxy. Understanding a cutover: the detection delay is the product of the
interval by the failure threshold, whether the setting is a fall line or an
API field. Knowing where the visitor's address goes: behind a load balancer
that relays requests (L7), the backend generally sees the load balancer's
address, and the real address travels in a header, to be trusted only if it
comes from the previous layer. Some layer 4 load balancers keep the source
address: the product documentation settles it.
The distinction between an L4 and L7 load balancer, an API gateway and an ingress is not redone here: it is laid out in Load balancer, API gateway, ingress: telling them apart (in French). This lesson picks up where that page stops, with the move from a component you install to a service you consume.
What changes hands with a managed service?
What you wrote in a file becomes an API setting, and what you watched in the logs becomes a provider metric. You no longer deploy a binary, you no longer update it and you no longer carry its availability: that is the gain. In return, you no longer have access to the program, and therefore to the options the provider has not exposed: that is the loss.
The table translates the objects of the training into their managed equivalent, without product names since these vary from one provider to another.
| In the training | With a managed load balancer |
|---|---|
nginx.conf file, haproxy.cfg or Traefik dynamic configuration | Resources described by the API, the console or an infrastructure-as-code tool |
server block or router by domain name | Listener and routing rule of the load balancer (L7 only) |
| Certificate obtained by ACME and reloaded | Certificate managed or imported by the provider, renewed by the provider |
| Probe written in the configuration | Probe declared as a resource, with path, interval and threshold |
stub_status, JSON logs, exporter | Platform metrics and access logs to enable |
| Binary update (security patch) | Done by the provider, on its own schedule |
The trap of this translation is to believe that every setting has an equivalent. A very precise directive, a fine-grained header rewrite or a dynamic module may have no corresponding setting. Before migrating, list the directives your service depends on: it is this list, not a preference for a tool, that decides whether a managed service is enough. The cases of layer 4 or layer 7 load balancers, TLS termination and probes are detailed in Load Balancing: L4, L7 load balancing and TLS termination (in French).
Why do the bill and quotas become a design subject?
A managed service is billed, and the bill often depends on your traffic: it is an architecture constraint, not just an accounting one. With a reverse proxy on your own machine, the cost of the component is that of the machine, fixed. With a managed service, the bill is generally made of a fixed part, due as long as the service exists, and a variable part depending on traffic or on the number of connections, but the models differ: some providers bill traffic, others show a fixed price without billing the traffic processed. Traffic between zones may be added. Read the product's price list before assuming the structure. A load balancer forgotten in front of a staging environment keeps paying its fixed part, even with no visitor; only the variable part follows traffic.
Quotas, or service limits, are the other surprise. A provider caps the number of resources of a given type, per account or per region depending on the provider. Some limits can be raised on request, others are fixed: the product documentation says which. The moment you discover the limit is the worst one: when you add a resource to absorb a peak. The question to ask, before going to production, is therefore not only "how many load balancers?" but "which limits apply, can they be raised, and how do I ask for more?".
Three reflexes are enough to keep control. Estimate the cost from the expected traffic, before going live. Alert on budget overrun rather than discovering it at the end of the month. Delete the resources of an ephemeral environment with it, because an orphaned load balancer keeps being billed. An application attack can also make an elastic infrastructure grow without breaking anything, as the guide Exposing an application (in French) details.
What does splitting into availability zones change?
An availability zone is a datacenter, or a group of datacenters, isolated from the others within a region: availability is decided by choosing in how many zones you place each component. With your own reverse proxy on a single machine, the question did not arise: the machine was the point of failure, and the training had you measure it. In the cloud, it arises for every building block, including the one you no longer manage.
This is where careful reading is needed: depending on the provider, a load balancer can be zonal (it goes down with its zone) or regional (the provider spreads its nodes over several zones itself), and only the product page says which of the two models applies. The consequence is worth stating: two backends in two zones behind a zonal load balancer do not tolerate the loss of the load balancer's zone, and the care taken to spread the backends is then useless. The principle is detailed in Load Balancing: L4, L7 load balancing and TLS termination (in French), in the section "Un répartiteur survit-il à la perte de sa zone ?" (does a load balancer survive the loss of its zone?).
The name of the service remains the other link of the path. Cutting over to a second load balancer goes through DNS, with the cache delays you studied in preparing a DNS cutover. A managed DNS provides the same records and the same time to live, as well as an automatic failover whose limit is described in Managed DNS: zones, records, TTL and failover (in French).
Why keep your machines private in the cloud?
The right default position in the cloud is to give no machine a public address and to publish only through an edge service. The principle, named "private by default", reduces the attack surface to a single watched door. In the training, you closed ports on a machine; here, the machine simply has no address reachable from the Internet, and the only inbound path goes through the load balancer, possibly preceded by a CDN and a web application firewall.
These edge services, CDN, WAF and anti-DDoS, almost never exist at home: nobody hosts a content delivery network in their garage. They are already described in CDN, WAF, anti-DDoS: reading edge services (in French), which also recalls the bypass to avoid: if the origin stays directly reachable, the edge protects nothing. The guide Exposing an application: edge, CDN, WAF and anti-DDoS (in French) gives the method to enable them without blocking your own users, and Cloud edge computing: from the CDN to edge functions (in French) explains how far the edge can run code.
Two special cases extend this position. When the traffic must not go through the Internet at all, for example between your application and a managed service, a private endpoint (in French) keeps the flow inside the provider's network. And if your exposure is made of API calls with authentication and per-consumer quotas, the question "do I need a gateway?" has its own answer in Do you need an API gateway in front of your cloud application? (in French).
Should you keep your reverse proxy or take the managed service?
Take the managed service as long as your needs fit in its settings, and keep
your reverse proxy when a function that you cannot express with the provider is
at the heart of the service. The decision is made on three criteria, in this
order: the list of functions actually used (see above), the operating cost you
accept to carry (updates, configuration backup, on-call duty), and portability.
An API configuration is written for one provider's vocabulary and is almost
entirely rewritten to change provider. An Nginx file moves more easily,
without being universal: it depends on the version, the compiled modules and
the layout of the package, as this training showed with the nginx.org
packages, which do not lay out the same directories as the Debian ones.
The two are often combined. A managed load balancer in front, which carries the availability of the front door and the certificate, can send to a reverse proxy that you operate for fine-grained routing inside the private network. In this setup, everything the training taught you keeps serving as is on the second tier, and reading a probe or a cutover applies to both tiers. In Kubernetes, the ingress plays this role of internal reverse proxy: that is the subject of the Kubernetes training, not of this one.
What you must not do is choose out of habit: neither the managed service for fear of operations, nor self-hosting out of attachment to a tool. Each has a cost that you can write down before deciding.
Key points
- The concepts of the training remain true: a managed load balancer terminates TLS, probes and cuts over as your reverse proxy did.
- The setting changes hands: a file becomes an API setting, and you lose access to the binary, and therefore to some options.
- You no longer carry the availability of the component, but you carry its bill and its quotas.
- Availability is decided by zones: a zonal load balancer goes down with its zone, wherever the backends are.
- In the cloud, machines stay private and publication goes through the edge.
- The choice between managed and self-hosted is made on the functions used, the operating cost and portability.
Knowledge check
Check that you have mastered the essentials of this guide. The questions cover only what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
A new full quiz with random questions
Work again only on the questions you missed