The previous lesson ended with an uncomfortable diagnosis: vm-motor-disponibilidad-dev works, but it is a single machine. If the physical host fails, if Azure applies platform maintenance or if traffic multiplies by ten, there is no plan B. And the third of those is going to happen to Contoso Airlines on a date already marked in the calendar.

Every year, in the middle of February, Contoso opens summer season sales. The first day concentrates around 60% of the month's traffic, with a three-hour spike in the morning during which the Availability API receives roughly fifteen times the requests of a normal day. With their own servers in Barcelona and Palma, the historical answer was to buy hardware for the peak and keep it at 6% utilization the other 364 days. That is, literally, the problem the cloud solves.

In this lesson you will learn to scale compute and to give it high availability: what the difference is between growing upwards and growing sideways, how virtual machine scale sets work, how instances are spread across availability zones, which load balancer to choose among the four Azure offers, and what design requirement all of this imposes on your application: being stateless.

Cost warning: a scale set with two instances bills two VMs, and a Standard Load Balancer has an hourly cost plus a cost per rule. Everything in this lesson is removed at the end with a single deletion of the lab resource group.

1. Vertical scaling versus horizontal scaling
2. The Contoso case: the season-opening peak
3. Virtual machine scale sets (VMSS)
4. Manual, metric-based autoscaling and scheduled scaling
5. Availability zones and availability sets
6. Load balancing in Azure: the four options
7. Health probes
8. Deploying the Availability API behind a Load Balancer
9. Stateless applications: the hidden requirement
10. The resulting architecture and cleanup
11. Common Mistakes and Tips
12. Exercises
13. Conclusion

There are two ways to give a system more capacity.

Vertical scaling is simple and sometimes the right answer: a monolithic relational database usually scales better upwards. But for a web application's compute, the cloud model is the horizontal one, for three reasons:

1. Real elasticity: you can go from 2 to 20 instances in minutes and back to 2 when the peak is over. You pay for what you use, when you use it.
2. Availability: N spread-out instances survive losing one without the service going down.
3. No abrupt ceiling: you do not one day reach the family's maximum size and find yourself with nowhere to go.

The trade-off is the one in the last row of the table, and it is not a small one: if your application stores the user's session in the server's memory or writes files to its local disk, horizontal scaling breaks it. We cover that in section 9.

The numbers Marta Ríos has measured on the current system:

The conclusion is twofold: far higher capacity is needed for a few hours a year and minimal capacity the rest of the time. Sizing for the peak with fixed machines means paying fifteen times what you need for 360 days. Sizing for a normal day means losing sales on the day you sell the most.

The solution we build in this lesson: the Availability API is deployed on a scale set with a minimum of 2 instances spread across two zones, a CPU-based autoscale rule and a scheduled rule that raises the minimum on the morning of the opening, all behind a Load Balancer.

A virtual machine scale set (VMSS) is a resource that manages a group of identical VMs as a single unit: they are created from the same model, they are updated together and they grow or shrink according to rules.

What a VMSS gives you that creating VMs by hand does not:

• A single model: you change the image or the size in the model and it applies to all of them.
• Autoscaling by metric, by schedule or manually.
• Automatic instance repair: if an instance fails the health probe for a while, the set replaces it.
• Automatic distribution across zones and fault domains.
• Batched updates (rolling upgrades) with no service outage.

Flexible is today the recommended mode by default: it gives you set-level management without losing individual control of each VM, and it allows mixing spot-priced instances with normal instances to make peaks cheaper. It is the one we will use.

Autoscaling watches a metric and acts. A complete rule always has these pieces:

Note the deliberate asymmetry between the two rules, which is a good practice and not an oversight:

• You scale out fast and in big blocks (+2 with a 5-minute window): falling short costs sales.
• You scale in slowly and one at a time (−1 with a 10-minute window): reducing too early causes the sawtooth effect, in which the system adds and removes instances non-stop, and each start-up takes minutes and costs money.

If the scale-out and scale-in rules have the same threshold, oscillation is guaranteed. Always leave a wide dead band between the two (here, between 30% and 70%).

When you know when the peak is coming, do not wait for the CPU to prove it: a metric-based reaction always arrives late, because a new instance takes several minutes to boot and be ready.

During that profile, the set never drops below 10 instances and can reach 30 if the CPU calls for it. Outside the window, it goes back to the normal profile (2–20). This combination — scheduled for the predictable, metric-based for the unpredictable — is the pattern most seasonal sales platforms use.

Having several instances is worth nothing if they are all in the same rack and that rack loses power. Azure offers two spreading mechanisms, and they protect against different things.

It spreads the VMs across:

• Fault domains: groups of servers that share power supply and network switch. If the rack fails, one fault domain goes down. Up to 3 per region.
• Update domains: groups that Azure reboots separately during platform maintenance. Up to 20.

It protects against: rack failure and maintenance reboots. It does not protect against the complete loss of the datacenter.

As you saw in 01-02, a zone is a physically separate datacenter within the same region, with independent power, cooling and networking. Spreading instances across zones protects against the failure of an entire datacenter.

Contoso's decision, consistent with the one from module 1: critical components in at least two West Europe zones, with no multi-region active-active setup (a conscious decision on cost grounds). The Availability API is deployed in zones 1 and 2.

With --zones 1 2, Azure spreads the instances evenly across both zones and maintains that balance as it scales. Important: zones are chosen when the set is created and cannot be added afterwards. If you think you will ever need them, create it with zones from the start.

Having several instances requires something in front to distribute traffic. Azure offers four services and the confusion between them is one of the favorite topics of certification exams (and of badly built architectures).

Selection criteria, in the form of questions:

1. Is it HTTP/S traffic? If it is not (for example, a protocol of the legacy engine's own), your option is Load Balancer or Traffic Manager.
2. Do you need to decide based on the URL (/api/* to one pool, / to another), rewrite headers or offload TLS? Then you need layer 7: Application Gateway or Front Door.
3. Does traffic arrive from all over the world and do you want caching and an edge presence? Front Door.
4. Do you only want to fail over between regions at the DNS level, with any protocol? Traffic Manager.

Two notes on scope, so as not to invade other lessons:

• The global side — Front Door, Traffic Manager, CDN — is developed in lesson 02-06, with the case of the customer buying from South America.
• The web application firewall (WAF), which attaches to Application Gateway or Front Door, is covered in lesson 04-04.

Here we stay regional and at layer 4: Azure Load Balancer in front of the scale set.

The SKUs: Standard (the current one: supports zones, up to 1,000 instances, secure by default) and Basic, now retired. Always use Standard.

A health probe is what separates a load balancer from a blind distributor. Every few seconds, the balancer asks each instance whether it is alive; if it does not respond correctly a certain number of times in a row, it stops sending traffic to it.

Good practices for the health endpoint, which hold for the whole course:

• Make it meaningful: it should check what is needed to serve (is there a database connection?), not always return 200.
• Make it cheap: it runs every few seconds per instance. No heavy queries.
• Do not require authentication from the internal network, or the probe will always fail.
• Separate liveness from readiness: "the process is alive" is not the same as "I can serve requests now".

A badly built probe causes two classic and opposite failures: broken instances receiving traffic (a probe that is too lenient) or healthy instances being pulled out of service in a cascade (a probe that is too strict or has a short timeout).

Let us assemble the whole piece. So as not to touch production while you are learning, use the development group; the example says production because that is the target architecture, but you can replace pro with dev in all the variables.

The init-api.yaml file that installs the API on each instance (the same cloud-init mechanism from the previous lesson, now serving the instance's identity so that you can watch the balancing work):

Checking the balancing: several consecutive calls should return different instance names.

If the same instance always answers, check the rule's session persistence: by default the Load Balancer uses a five-tuple (source and destination IP and port, protocol), and since your source port changes on every request, you should see distribution. If you configure source IP persistence (--load-distribution SourceIP), all your requests will go to the same instance, which is exactly what we do not want, for the reason in the next section.

Horizontal scaling imposes one condition on the application: any instance must be able to serve any request. That means the instance cannot store anything the others need.

The three kinds of state that break scaling and where they should go instead:

The easy temptation is to turn on session persistence in the balancer so that each client always goes to the same instance. It is a patch with three serious side effects: distribution becomes unbalanced, an instance failure kicks its users out, and scaling in loses active sessions. It works as a temporary solution during a migration, never as a design.

That is why the order of this module is not accidental: first scalable compute, then the storage where the things compute cannot keep must live (02-04), and in module 3, the database. Contoso's Availability API is designed stateless from day one: it reads from the database, writes the boarding passes to Storage and keeps nothing locally.

Cleanup (remember that the production group has the no-borrar-produccion lock; in the lab, work against the development group):

And a check you should by now be doing by reflex: az disk list --query "[?diskState=='Unattached']" -o table.

• Setting the same threshold for scaling out and in. It produces the sawtooth effect: the system adds and removes instances non-stop. Leave a wide dead band (30%–70%).
• Scaling in as aggressively as you scale out. Removing two at a time with a 5-minute window leaves the service short exactly when the peak bounces back. Scale out fast, scale in slowly.
• Relying only on metric-based scaling for a known peak. Booting instances takes minutes; the opening peak arrives in seconds. Use a scheduled profile.
• Confusing an availability set with an availability zone. The first protects against rack failure inside a datacenter; the second, against the loss of the whole datacenter.
• Forgetting that zones are fixed when the scale set is created. They cannot be added later. Create it zonal from the start.
• Using Application Gateway where a Load Balancer is enough (or the other way round). If you need neither URL-based decisions nor TLS termination, layer 4 is simpler and much cheaper.
• Probes that return 200 no matter what. A health endpoint that checks nothing guarantees that the balancer sends traffic to broken instances.
• Scaling out an application with state in memory. Intermittent errors appear that are impossible to reproduce. Get the state out before you scale.
• Quota tip: the maximum vCPU count per family and region is a quota, not a physical limit (lesson 01-05). If your rule can reach 20 instances of 4 vCPUs, check that you have 80 vCPUs of quota before opening day.
• Cost tip: for peaks, consider spot-priced instances inside the flexible set. They are much cheaper in exchange for being evictable; they are for extra capacity, never for the minimum.

With the figures measured by Marta Ríos (15 requests per second in the early morning, 120 at normal rush hour, 1,800 at the opening peak), and knowing that one Standard_B2s instance of the API comfortably serves about 100 requests per second:

1. How many instances are needed as a minimum on a normal day at rush hour, with headroom to lose one?
2. How many at the opening peak?
3. Define the minimum, maximum and scheduled profile values you would configure.
4. Explain why the CPU rule alone is not enough for that day.

For each Contoso need, state which load balancing service you would use and why:

1. Distributing the traffic of the legacy availability engine's binary protocol (TCP 8500) across three VMs in West Europe.
2. Sending /api/* to the Availability API and everything else to the bookings website, within the same region, with TLS termination.
3. Serving the public website to customers in South America with the lowest possible latency and image caching.
4. Failing over to North Europe if West Europe stops responding, for a service that is not HTTP.

In a lab group:

1. Create a flexible scale set with 2 instances in zones 1 and 2, with cloud-init that publishes the instance name in /salud.json.
2. Put it behind a Standard Load Balancer with an HTTP probe to /salud.json.
3. Prove with curl that traffic is distributed across both instances.
4. Stop one instance and prove that the service keeps responding and that the probe has removed it from the pool.

Solution 1:

1. Normal rush hour: 120 ÷ 100 = 1.2 → 2 instances, and with headroom to lose one (the N+1 pattern), 3. Since the minimum must also cover the zone that could go down, 2 is the absolute floor and 3 the prudent value.
2. Opening peak: 1,800 ÷ 100 = 18 → 18 instances, plus N+1 headroom → 20.
3. Proposed configuration:

4. Because metric-based scaling is reactive: it needs 5 minutes of high CPU to fire and several minutes more for the instances to boot and pass the probe. The opening peak arrives in less than a minute, so during the first 10 minutes — the highest-selling minutes of the year — the service would be saturated. The scheduled profile leaves the capacity already warm before sales open.

Solution 2:

Solution 3:

After stopping the instance, the probe fails several times in a row and the balancer removes it from the pool: it can take 15-20 seconds to see the effect (probe interval times the number of tolerated failures). That delay is exactly the partial downtime some customers would suffer in a real failure, and it is the argument for not setting long probe intervals.

You now know how to scale and give high availability to compute in Azure. You can tell vertical scaling from horizontal scaling and you understand why the cloud bets on the latter: real elasticity, intrinsic availability and no ceiling. You know what a virtual machine scale set is, the difference between uniform and flexible orchestration, and how to define manual, metric-based autoscale — with asymmetric thresholds and a dead band to avoid the sawtooth effect — and scheduled scaling, which is the only reasonable answer to a peak with a known date such as Contoso's summer season opening. You know the difference between availability sets (fault and update domains inside a datacenter) and availability zones (independent datacenters), with their direct effect on the SLA: 99.9%, 99.95% and 99.99%. You have compared the four load balancing services with clear criteria and you have deployed a Standard Load Balancer with a health probe over a scale set spread across two zones. And you have internalized the hidden requirement behind all of it: the application cannot hold local state.

Now, look at what it took: a scale set, a balancer, a probe, autoscale rules — and you still have to patch each instance's operating system, update the image, manage TLS certificates by hand and build zero-downtime deployment yourself. For the legacy engine there is no alternative. But for a modern web application such as Contoso Bookings or for the new Availability API, Azure offers a service that does all of that for you.

In the next lesson, Azure App Service, you will see why Contoso publishes its applications there instead of maintaining VMs: plans and tiers and what each one unlocks, runtime stacks, deploying code with ZIP and Git, app settings and connection strings, custom domains with managed certificates, autoscaling with no set to administer and, above all, deployment slots with swap and warm-up so that new versions go live without a single customer being unable to buy their ticket.