Hello,
Based on my knowledge, there are two types of scaling : the up/down scaling and the out/in scaling.
I'm a bit surprised to see that in AWS Courses (so as in AWS Solution Architects Exam Preparation Book) I missed the up/down scaling !
Indeed, I always found that typical example :
- in the "Increase Group Size" Window in the "Take the action" item the CAPACITY UNIT is activated (that is to say, this represents the instance number).
In case of a up/down scaling, we are supposed to modify the CPU and/or the RAM.
But I never see such information in the "Take action" item, is that normal ?
Regards,
(02-03-2023, 07:30 PM)Tucix Wrote: [ -> ]- in the "Increase Group Size" Window in the "Take the action" item the CAPACITY UNIT is activated (that is to say, this represents the instance number).
In case of a up/down scaling, we are supposed to modify the CPU and/or the RAM.
But I never see such information in the "Take action" item, is that normal ?
So, when it comes to scaling, there are 2 types.
1.> Vertical scaling which means you are increasing the size of your machine but the number of machines don't increase.
2.> Horizontal scaling which means the number of machines increases but the size of the machines remain the same.
At the moment, when we say scaling on AWS, it's primarily referring to "horizontal scaling" which means you are adding more instances/ec2 to your environment so as to share the load between the instances. while you can automate "Vertical Scaling", it's not a normal use case as it means you would have to stop the instance, increase the size and start the new sized instance which means there's downtime. While some VMs like VMWare will allow you to do vertical scaling on the fly, it's not possible right now on AWS.
Also, to clarify, the newer scaling methods on AWS where they use the term "capacity units", it doesn't necessarily refer to a new instance. The Target tracking scaling is a black box solution, so you dont' really control the number of instances started/stopped within a scaling process.
Ok Thanks...so in fact you don't recommend to change 'instance type' the AMI (by chossing another more powerful CPU for instance), because this will lead to outage inevitably.
(in addition we should delete the instance, copy the data before etc etc etc ...)
It seems indeed to be very straightforward to implement !
So in practice, it is never implemented in AWS,
(03-03-2023, 03:43 PM)Tucix Wrote: [ -> ]Ok Thanks...so in fact you don't recommend to change 'instance type' the AMI (by chossing another more powerful CPU for instance), because this will lead to outage inevitably.
(in addition we should delete the instance, copy the data before etc etc etc ...)
It seems indeed to be very straightforward to implement !
So in practice, it is never implemented in AWS,
You can stop the instance, modify the size of the instance and start it back up without needing to change AMI or copy data etc. However this takes a few minutes to complete and that is downtime hence not recommended for live production applications. But it's fine for when you are testing things to find the right size of instance you need for your application.
For scaling, it's always recommended to increase number of instances instead of increasing size of instance.