Let's go through the process. I'll do it via the portal for visual reasons, but I really want to be using ARM, Bicep, or Terraform, or even CLI or PowerShell scripts to do this repeatably.

I've already created a resource group named VMSS Demo RG, in South UK region. Let's head over to the portal.

From the portal's homepage, I'll search for VMSS and select it.

Now I'll click Create and create it in my existing RG. I'll name it VMSS Demo SS.

Deploy to all three availability zones and choose Flexible Orchestration. For my purposes, Uniform would be fine, but I want to go through all the options.

I'll choose Autoscaling and configure it.

I'm going to change the default and minimum to 1 and set the maximum to 5. What I'm saying here is that I don't want to spend any more than that number of instances, however much pressure the set is under. Another way of controlling costs.

Leave the CP thresholds alone and leave the query duration at 10 minutes. So, we need to be under sustained pressure for that long before taking any action.

Similarly, if we're below the 20% threshold for a short period of time, we won't get caught with our pants down.

For a production fleet, I might want to activate Predictive Autoscaling, which uses machine learning to discover patterns.

I'll leave logs as is.

And then I can choose a scale in policy, I can keep the default, which balances across zones and then chooses the instance with the highest ID, assumed to be the newest. Or I can explicitly choose to delete either the newest or the oldest VM.

I'll leave that as is and save my configuration.

For sizes, I've chosen a variety of D2sand D4s to improve my chances. Incidentally, burstables aren't a great choice if we're scaling on CPU. In my case, 80%.

Remember, I'm getting a baseline of about 30%, so that metric won't be triggered often enough for it to be useful for us.

I'll leave the authentication type alone. I don't intend to connect to them.

Now I can configure my spot options. I'll turn it on so that we can explore the options.

I can choose to be evicted only when Azure decide they want the VMs back, or I can specify a maximum price I'm prepared to pay for Spot.

Let's say I don't want to pay more than $0.10 for Spot, and I'll specify an eviction policy of delete rather than stop.

I want to use both VMs and Spot VMs, but I'll always have at least one regular VM, and I can specify a ratio of Spot to regular. I'll leave it at 100% regular because remember there's no guarantee I'll get Spot instances.

Not going to change anything in discs.

In networking, I need to create a load balancer. I'll call it VMSS demo LB. It's public- facing.

That's all fine. Create.

Next is management, that's all fine.

I will create a health monitor. So, if my VMs stop passing the health cheques, the scale set will mark them as unhealthy and terminate and replace them.

I'll configure it to ping the servers at port 80 HTTP and the route path. This is a very simple health check. In reality, I'd more likely configure an endpoint that makes sure the front end can talk to the back end.

Unhealthy threshold is 1 and will ping every 5 seconds. So, if it fails just one of those tests, it'll be marked as unhealthy.

Save.

Not going to configure resiliency.

Let's go to Advanced. I'm going to provide a cloud init script to install Apache on these Ubuntu VMs. That's it.

Next I'll tag all of these resources, the VNET, the load balancer, the scale set, etc, with an app tag with a value of VMSS demo.

Review, and create.

I'll come back when it's done. It will take a little while.

So, that's done. I'll grab the load balancers’ IP address and browse to it, and there it is.

Thanks for watching, hope you found it useful.

Demo: Creating a VMSS

About