In this video, you'll learn how to use Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling with Amazon Managed Service for Prometheus.
With this solution, you can migrate existing Prometheus workloads to the cloud
and manage demand and costs by using Prometheus alerting rules to control Amazon EC2 Auto Scaling.
For this example, we’ll scale an Amazon Managed Service for Prometheus workspace based on CPU usage.
This is our Amazon EC2 Auto Scaling group.
We have defined the group's minimum size as two instances, so it has high availability,
but set the maximum size as 10 instances to control cost.
Both EC2 instances contained in this Auto Scaling group are remote-writing metrics to our Amazon Managed Service for Prometheus workspace,
which we'll review momentarily.
We used the Prometheus launch template to launch this instance.
Let's take a look.
The launch template provided the Amazon Machine Image (AMI) ID and instance type.
Let's view the Advanced details tab.
The template also provided the security groups and AWS Identity and Access Management (AWS IAM) instance profile needed for setting up the EC2 instances.
Next, we'll go to the Amazon Managed Service for Prometheus.
Let's find the workspace for our Auto Scaling group.
Here we can see a summary of its status and details.
Let's open the Rules management tab.
We configured an alerting rule to support Auto Scaling of the workspace.
Let's view the rule.
Per the rule code, we established "high" and "low" CPU usage boundaries.
The high CPU load rule is triggered when the average CPU utilization over a five-minute period is greater than 60%.
The low CPU load rule is triggered when the average CPU utilization over a five-minute period is less than 30%.
Any CPU usage measured outside of those boundaries results in a warning
and prompts an event to "scale up" or "scale down" the number of instances.
We also configured an alert manager definition to coordinate with the alerting rule.
Let's take a look.
If CPU usage goes beyond the "high" or "low" boundaries, alert manager sends an alert to a specified Amazon SNS topic.
It shares the alert type and the event type, which, as we defined in the rule, would be a directive to increase or decrease the number of instances.
Let's go to the Amazon SNS console to review the topic.
Let’s find the topic that corresponds with our Amazon Managed Service for Prometheus workspace.
Here we see the details of the topic.
We've subscribed an AWS Lambda function to the topic.
Let's visit the AWS Lambda console to take a look at this function.
In its source code, we can see that the Lambda function inspects the alert sent to Amazon SNS
and determines whether a "scale up" or "scale down" event should happen.
Lambda then sends a request to the Auto Scaling group to increment or decrement the number of instances to the desired capacity.
To visualize how this Auto Scaling solution is manifested, let’s go to Amazon Managed Grafana.
We’ve already built a dashboard for our auto-scaled workload.
Let’s find it.
Here we can see how the CPU and number of EC2 instances changed in response to traffic being sent to the Auto Scaling group.
Let's edit the dashboard.
To review our data more closely, let’s narrow the time range.
We can see from the graph that when CPU usage spiked to 100%, the number of instances increased,
eventually reaching 10 instances, the maximum amount we set in the Auto Scaling group.
Then, as CPU usage gradually declined, so did the number of instances.
You've just seen how to use Amazon EC2 Auto Scaling with Amazon Managed Service for Prometheus.
You can learn more about this topic in the description and links for this video.
Thanks for watching. Now it's your turn to try.