AWS Autoscaling with Dynamic Policy Demo Step by Step | SNS | Cloudwatch
ฝัง
- เผยแพร่เมื่อ 8 ม.ค. 2023
- A DevOps TH-cam channel is a platform that focuses on providing educational and informative content related to DevOps practices, principles, tools, and technologies. These channels cater to individuals and organizations interested in learning and implementing DevOps methodologies to streamline their software development and operations processes.
![[FULL EP.14] เซียนหรั่ง สอน มาร์ชจุ จับปูนา ฮากระจาย | เฮ็ดอย่างเซียนหรั่ง | One Playground](http://i.ytimg.com/vi/M8mPjd_T2lo/mqdefault.jpg)
excellent. i am impressed.
Thank you for worthy lab Sir.
Good explanation 🎉
Thank you 🙂
Hi Ashiq, I have gone through many videos for autoscaling, but what you teach us thats really too good.
For the same I have one question, can we autoscale instances depend on time interval except cpu utilization. Like 9am autoscaling group will be create ec2 instance and 8 pm instance desired capacity will be zero. if it is possible, please give little bit idea.
For your question about autoscaling instances based on a time interval rather than CPU utilization, AWS Auto Scaling doesn't inherently support time-based scaling like you described. However, you can achieve this by using AWS Lambda functions and CloudWatch Events.
Here's a high-level approach:
Create Lambda Functions:
Create two Lambda functions-one to scale up at 9 am and another to scale down at 8 pm.
Configure CloudWatch Events:
Use CloudWatch Events to schedule the execution of your Lambda functions at the desired times. You can set up a rule that triggers the "scale up" Lambda at 9 am and the "scale down" Lambda at 8 pm.
for scale up
-----------------
import boto3
def lambda_handler(event, context):
autoscaling_client = boto3.client('autoscaling')
# Replace 'your-autoscaling-group-name' and 'desired-capacity-up' with your actual values
autoscaling_client.update_auto_scaling_group(
AutoScalingGroupName='your-autoscaling-group-name',
DesiredCapacity=desired-capacity-up
)
for scale down
-----------------------
import boto3
def lambda_handler(event, context):
autoscaling_client = boto3.client('autoscaling')
# Replace 'your-autoscaling-group-name' with your actual value
autoscaling_client.update_auto_scaling_group(
AutoScalingGroupName='your-autoscaling-group-name',
DesiredCapacity=0
)
@@ashiqummathoordevops Thank you
@@yuvrajjambhle9061 I don't know why he gave that answer but you can do auto scaling as per your time based requirement. Google for "Scheduled scaling for Amazon EC2 Auto Scaling".
How EC2 instance is getting created with a Public IP? I didn't see Public IP being enabled during Launch Template create or during Auto Scaling Group. Please help.
This session is very helpful with could watch integration with auto scaling group.
I should enable on subnet settings
Thanks!! @@ashiqummathoordevops
What is the difference between "Desired" and "Minimum" ? when you say min one then why should I give in Desired 1 ? Can I give Desired 1 and Min 2 ? does it work ?
No, It will not work. Desired signifies current count, minimum signifies how many nodes minimum u want even if u don't have any traffic
3:03 🎉
Give notes
scaling
-------
increasing or decreasing the capacity from existing value is called scaling
***********************
what is auto scaling
--------------------
AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady,
predictable performance at the lowest possible cost.
********************************
type of scaling
---------------
vertical scaling:
-----------------
Vertical scaling refers to adding more resources (CPU/RAM/DISK) to your server as on demand.
horizontal scaling
------------------
Horizontal scaling refers to adding additional nodes or machines to your infrastructure to cope up with new demands.
*************************************
autoscaling group
-----------------
creating a logical group for spinup and spindown instnaces is called autoscaling group.
*************************************
component of auto scaling group
-------------------------------
min: ensures that your group never goes below this size.
max: ensures that your group never goes above this size
desired: expected/desired instance count on current time
scaling policy
--------------
manual scaling
--------------
Manual scaling is the most basic way to scale your resources, where you specify only the change in
the maximum, minimum, or desired capacity of your Auto Scaling group.
Schedule scale
--------------
Scaling by schedule means that scaling actions are performed automatically as a function of time and date.
eg: sunday, big billion days amazon.
dynamic scaling/scale based on demand
--------------------------------------
based on the workload gettign automatically it start to spin up maultiple instance without
any manual intervention.
predictive scaling
------------------
based on past week, month record it will analayze tarffic flow and it will increase sufficient vm's for purticular time.
************************************************************
launch configuration
--------------------
it is template or image of ec2 instnace, whenever creating new instnace in ASG it will create instance based on that
for eg, AMI, keypair, network
it is old method to create instance on ASG, so launch configuration may or maynot be support future autoscaling group
launch template
--------------
Launch Templates is a new capability that enables a new way to templatize your launch requests, based on the behaviour of
launch template it will spin up instnaces.
differences between launch template and launch configuration
--------------- -----------------------
new method old one
can create versions cannot create versions
*****************************************************************************
health check grace period
-------------------------
minimum amount of time to keep instnace inservice to complete health check.
if we not providing suffcient time to check health of instance, it will terminate eventhough it is healthy instance.
default graceperio value 500 console
default grace period value 0 cli
health check type
-----------------
-ec2
------
ec2 having health check capability by using status check (instnace check and system check)
-loadbalancer
-------------
loadbalancer will do health check of instnace using http/https/tcp/udp/tls protocol
instace scale in protection
----------------------------
it will protect from terminating for newly created instance
placement group
----------------
cluster
spread
partition
termination policies
--------------------
to determine which instnace need to terminate while scale in.
By choosing different termination policies, you can control which instances you prefer
to terminate first when a scale-in event occurs.
default termination policy
--------------------------
which instnace using old launch template/launch configuration
it will select which az having more instnaces
which instance is close to next billing hour
suspended process
------------------
that prevent to do auto scaling actions.
The suspend-resume feature is used to temporarily pause scaling activities triggered by your scaling policies
and scheduled actions. This can be useful, for example, when you don't want automatic scaling to potentially
interfere while you are making a change or investigating a configuration issue.
maximum instance life time
----------------------------
maximum amount of time instance can be serve in ASG.
-for increase protection
-to avoid hardware failure
default cool down
------------------
the amount of time to wait for next scaling activity.
default instance warmup
-----------------------
Warm-up value for Instances allows you to control the time until a newly
launched instance can contribute to the CloudWatch metrics,
lifecycle hooks
---------------
it will provide suffcient time to install all necessary packages on instnace before
it put in to inservice.
instnace refresh
----------------
to refersh instnace for rolling update
****************************************************
dynamic scaling
----------------
target tracking policy
-----------------------
it automatically create policy, based on traffic scale out and scale in without any further manual intervention
simple scaling && step scaling
------------------------------
- both are similar, for simple scaling steplscaling we need to select cloudwatch matrix and threshold value.
- step scaling providing more benefits than simple scaling (can add multiple conditions to enhance capacity)
- step scaling is more cost effective for high wokload or sudden spike application
warm pool instnace
------------------
its pre initialized instnaces which helps to reduce latency when required more instances for scale your apps.
userdata
---------
#!/bin/bash
#install apache server
sudo yum install httpd -y
sudo systemctl start httpd
#download website
sudo wget -P /var/www/html www.free-css.com/assets/files/free-css-templates/download/page286/deni.zip
#unzip the file
sudo unzip -o /var/www/html/deni.zip -d /var/www/html/
#copy the file from html directory to apache defualt directory
sudo cp -Rf /var/www/html/html/* /var/www/html
cpu stress command
------------------
sudo yum install dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y
sudo yum install stress -y
sudo stress --cpu 9 --timeout 1200
Ty sir
Thanq sir
Superb session