AS is widely used in various business scenarios. This section mainly introduces three typical application scenarios.

Non-periodic Fluctuation Scenario

In case of hot topics, the number of visits to blogs and news websites will spike. After the topics cool down, the number of visits will fall back. The business volume fluctuates irregularly and is difficult to predict. You can set an alarm policy to detect CPU and memory utilization for capacity expansion and reduction of resources.

Example 1: You can set two alarm policy tasks, one for automatically adding N instances when the CPU utilization rate of an instance exceeds 70%, the other for automatically deceasing N instances when the CPU utilization rate of an instance is smaller than 30%,

Example 2: You can set one alarm policy task. The alarm policy is triggered when the CPU usage of the instance reaches about 50%. In case of business fluctuation, the system will automatically add or reduce N instances.

Periodic Fluctuation Scenario

The business peak of livestreaming or online education website is 20:00 to 22:00 and their businesses are regular. You can handle it by configuring two periodic alarm policies. In one periodic task, N instances are automatically added at 19:55 every day. In the other periodic task, N instances are automatically reduced at 22:05 every day. In this way, the business can be properly handled during peak hours and instances will be automatically released after peak hours to avoid resource waste.

High Availability Scenarios

In the event of a server failure and crash, AS can remove the faulty server detected during a health check and quickly start a new healthy instance. Alternatively, when a certain AZ service is unavailable, you can quickly start an ECS instance in other availability zones. Cloud resources can be expanded or reduced across multiple AZs in a region, greatly improving resource utilization and meeting the DR requirements for multiple AZs during service deployment.

Auto Scaling