Okay, it's time to get hands-on. Let's take a look at scaling groups. So first, how do we create a scaling group? Well, it's pretty straightforward. So from the scaling group list page, we click on create scaling group, then we give the scaling group a name. We choose the maximum and minimum size for the group. We enter the default cool-down time, removal policy and network type, and then we select any server load balancers and RDS databases that we want to associate with the scaling group. And keep in mind that step is optional.

A scaling group can exist even if it doesn't have an attached load balancer or RDS database, that's just fine. Whatever you set the minimum size of the group to be, when the group is enabled, that number of ECS instances will be automatically created and placed into the group. So let's see that in the console. All right, so here we are in the Alibaba Cloud Console, let's go ahead and set up a scaling group. So I'll click on create scaling group here. You can see I'm in the scaling groups section of the auto scaling console. I'll click on create scaling groups, and then I have three options, I can create from scratch, I can create from an existing ECS instance, or I can create from a launch template.

If I have existing ECS instances, I can use them as the sort of template for launching new ECS instances. I don't, so I won't be using this option. Create from launch template assumes that I've created a launch template, which is a configuration for the ECS instance that specifies it's CPU, memory, disc configuration and operating system. I don't have a launch template, so I'll go with create from scratch, and then I'll click on start creation, this will bring up the create scaling group dialogue.

The first thing I need to do is give the scaling group a name, which I'll do up here. And then I can, if I want, optionally add tags. Tags are a way to filter and group resources in the Alibaba Cloud Console, I will skip that for this demo. I then have to choose a removal policy. This specifies how I remove instances from the group, in my case, I've chosen to remove instances based on creation order, so the oldest instances in my group are the ones that I remove first when it's time to remove instances.

I can also choose to enable deletion protection for the scaling groups so that it cannot be accidentally deleted. I'll leave that off for the demo, and I can enable health checks, which means that the scaling group will check to see if any of its ECS instances are unhealthy and will then remove them from the group and replace them if they failed a health check. I'll leave that on. I then need to choose a maximum and minimum size for my scaling group.

Let's go with two as the minimum and five as the maximum. What this means is my group can not contain any more than five instances and it can never be smaller than two ECS instances. So when I enable the scaling group later, it will automatically add two ECS instances to make sure it reaches this minimum. If I want to maintain a particular number of ECS instances on average, then optionally, I can set this expected number of instances. What will happen is auto scaling will then always try to achieve that goal.

So I can say put three or four in here and auto-scaling will try to hit that target by adding or removing instances as needed. I also need to choose a default cool-down time. This is how long the group waits before scheduling or executing new scaling activities. I'll set it down to two minutes, 120 seconds. The network type that I'll be using is VPC virtual private network. I will use a multi-zone scaling policy, and you can see, I have three: priority, balanced, and cost optimization, so what's the difference? So with priority policy, you assign most of the instances to a particular zone.

With balanced, you distribute them across multiple zones, and with cost optimized, you try to deploy new instances into whichever zone has the lowest price for the instance class they deploy. I'm going to go with balanced. Release mode, I will use release because if I use shut down and reclaim, my instances will be removed from the group and shutdown, but they won't be released, so I'll continue to be charged for them. I'd rather use regular release mode, which will delete any instances that are removed from the group, thereby saving me money.

I need to choose a VPC group that all of the instances will belong to. I'll choose my Singapore VPC, and then I need to choose one or more VSwitches within that VPC. And I have three VSwitches, one each in Singapore zone A, B, and C, so I'll choose all of those. This way, the instances that are added to the group can be distributed across all three zones. I can also optionally configure a server load balancer or an RDS database to attach to this group. In my case, I will skip this step because it's optional.

A scaling group does not need to have a server load balancer instance or an RDS instance attached, it can be standalone. And then I'll click okay to go ahead and create the group, and it says, "Operation successful." Now I can click okay, and you can see that the group is disabled, there is a very good reason for that. The group doesn't have a scaling configuration yet so it doesn't know what type of ECS instances it can create. In order for me to allow this group to be enabled, to turn on this group, I need to have a scaling configuration, this way, when the group is enabled, it will know what type of ECS instances it needs to create. So we also need to be able to query and modify a scaling group.

So scaling groups have three life cycle states: active, inactive, and deleting. When you're modifying a scaling group, the region SLB and RDS database settings cannot be modified, but you can modify some of the other settings for the group, such as the minimum and maximum size. Modify operations can only be executed for scaling groups that are in the active or inactive states. If the number of ECS instances in the scaling group doesn't meet the new max size or min size settings, auto-scaling will add or remove ECS instances to or from the group until the max size or min size value is reached. 

Let's go back to the console and see how we can view or modify the scaling group's configuration. So we're back in the console, here's our scaling group. If we want to see more information about the group, we can either click on details or we can click on the scaling group ID. That's what I'll do, I'll click on the ID. From here, I can see the current state of the group, it's inactive or disabled, and I can see in the overview that no instances have been launched, nothing is being added or removing. That makes sense because the group is disabled and you can see the network settings here, associated SLB and RDS instances and scaling configuration settings. And most of this can be modified, for instance, if I want to modify the minimum or maximum size of the group, I can do that by clicking on this little pencil and here I can change the minimum and maximum sizes as well as the cool-down. And then when I'm done, I click okay. That's how you view and modify the settings for a scaling group.

Enabling and disabling scaling groups. You can only enable inactive scaling groups if they have an active scaling configuration. A single scaling group can only have one active scaling configuration at a time, although it can also have several inactive scaling configurations that could replace the active configuration with later. You can enable a scaling group such that if the existing number of ECS instances is less than the minimum size value of the enabled or active scaling group, then auto scaling will create new Pay-As-You-Go ECS instances to reach that minimum size value, that's what I just talked about earlier. In plain English, if you change the minimum size of the group, if you increase the minimum size of the scaling group, then auto scaling will automatically add new instances to the group to reach that new minimum size.

In terms of disabling scaling groups, you should keep in mind that a scaling group can be disabled only when it is not executing any scaling activity and this operation can only be executed for active scaling groups. Since we haven't set up a scaling configuration yet we cannot enable our groups, so let's save that for later in the course. I do want to point out that any operations that take place within your scaling group can trigger cloud monitor, MNS topic, or MNS queue notifications. So you can be notified when a state change occurs in your scaling group, either by email, or by SMS, or other methods. So you can use that information to monitor and control the activities that take place in your scaling group.

You can also enable what are called lifecycle hooks which mean that when a instance is added or removed from your instance pool, you can have certain operations take place on that instance to set it up, to serve requests and potentially to finish up any requests that the instance is handling before it's removed from the pool and released. By default, a scaling group is deleted in what we call ForceDelete mode, so when you delete your scaling group from the console, we use ForceDelete mode. What that means is everything within the group will be deleted as well.

Now, deleting a scaling group also deletes it's scaling configurations, scaling rules, scaling activities, and any scaling requests. Deleting a scaling group does not delete scheduled tasks, cloud monitor alarm tasks, server load balancers or RDS database instances. Those things all live outside the group. In the next section, we'll take a look at how to set up a scaling configuration.