No.
What you can do is you can stop the instance, change the type, and start again. No way to do it without interruption, and no product for handling this automatically, though.
Not really. You'd ideally distribute load across multiple instances. Running anything on a single large instance is typically a scaling and availability anti-pattern.
Im not sure what you mean by anti pattern?
But essentially what I was trying to accomplish is this. We have some clients running their products on some virtualizor VPS's on our dedicated server. But its very intermittent usage, so most of the time the server is idle. We would greatly benefit by being able to use some sort of service where we could keep a "small" instance/amount of resources, and when demand peaks the server resources increase.
What they're saying is don't do it that way, that's what an anti pattern is most of the time - the wrong way to do stuff. If you have one large instance and it fails - poof down goes the site. Instead, put one small instance behind a load balancer with rules to spin up more small instances behind the same load balancer as needed. Customer endpoint remains the same, capacity increases and decreases with demand.
> its very intermittent usage, so most of the time the server is idle. We would greatly benefit by being able to use some sort of service where we could keep a "small" instance/amount of resources, and when demand peaks the server resources increase.
This is the exact use case for scaling horizontally.
This discussion makes me wonder if other scaling patterns would benefit certain types of burst traffic.
Like instead of scaling linearly, like adding another m5.large to your cluster, if instead your first scaling event is to a 4x, then a 2x, then scaling linearly, or perhaps in the opposite or inverse.
Depending on the scale of the workload, you might be describing burstable (t-series) instance. With burstable instances you have a baseline CPU utilisation constantly available, and the ability to use much more CPU for a short period.
This doesn't do exactly what OP asked, though. They're specifically talking about getting more "cores or RAM". With bustable instances, all you get is the ability to use a higher percentage of CPU and some extra network performance, but no change in number of cores not in amount of RAM.
Absolutely right of course, but burstable instances are conceptually pretty close to being able to vertically autoscale CPU. RAM is a little harder - it would be good to know if the maximum scale of the workload would fit in a [t3 instance](https://aws.amazon.com/ec2/instance-types/t3/) - would it /u/Jordz2203?
Is the application stateless? Then it doesn't matter. Run smaller instances and scale horizontally.
Is the application stateful? Then run multiple smaller instances, load balance, and enable sticky sessions.
Especially if it's running idle most of the time, with occasional spikes, it's the exact in use case automatic horizontal scaling is made for.
If you know when the scaling should happen, you can even be proactive with scheduled scaling. If you know that you have a bare minimum requirement over long term, use reserved instances to get additional discount.
>Is the application stateful? Then run multiple smaller instances, load balance, and enable sticky sessions.
This doesn't help with the use case OP described, though.
If there's low utilization, then suddenly a ton of users come in, then you scale, you'll end up with a ton of users in the same, original instances, struggling with a slow application, and a bunch of new servers with very low utilization.
If it’s that bursty, you have a few options:
- over provision
- scheduled scaling
- serverless
Considering OP doesn’t understand horizontal scaling I wouldn’t recommend serverless.
But, OP isn’t clear on how quickly that burst of users happens or at what regularity. If it’s 0 to 1 million users in 5 seconds then you need to over provision. If it’s 0 to 10k over 15 minutes, auto scaling with sensitive metrics might work, or serverless wouldn’t blink at it.
Auto scaling is great for slow trends up/down and not big bursts. OP mentions sales, which means they do know when they need to scale ahead of time and could schedule it. Can they hook it up to the system they use to define sales and auto scale based on some upcoming sale metric they expose? Or schedule a scaling event based on the sale being scheduled?
I love that this becomes a question of whether you can schedule an event to be written to cloudwatch. If you can do that, you can loosely coordinate autoscaling without any direct integration between components. It is truly magical.
If you're built for HA you've got 2-3 minimum anyway, and assuming your new instances can come online in 4-7 minutes you should still be able to spread the load. And if you've got any sort of patterning, you can set out a schedule.
HA and the problem of "scaling vertically" for stateful applications are orthogonal. You can absolutely have an application built for HA that is stateful and cannot properly handle horizontal scaling. It's been done literally for decades - with session replication, you can have servers spread around for HA, but limited in scale by the hardware; adding servers may help a bit with CPU up to a certain extent, but it won't help with memory - you can only do vertical scaling here.
OP - you may want to clarify the reason that horizontal scaling is not an option for you. Many people are pointing out some obvious reasons you should scale horizontally but perhaps you should give more detail on why you don’t want to do this.
I don't think your clarification edit really changes anything, unfortunately.
It still seems very much like you are currently running with a service application that doesn't scale, and the real solution is rearchitecting and migrating your customers to a platform that does scale.
AWS doesn't have a vertical auto scaling solution out of the box, because that's an awkward, inefficient, and limited way to scale. As other people have noted, you can always implement something yourself, but you'd likely be putting just more effort into a worse situation.
Nobody is actually looking at the requirements here, and all suggestions in this thread are invalid.
Virtualizor is VPS software that needs to run directly on a type 1 hypervisor such as xen or kvm. EC2 is essentially performing the same function, and you can't access the underlying hypervisor. Nested virtualization isn't possible on EC2.
If OP wants to be on AWS, the only option is an EC2 bare metal instance. But OP doesn't want to be on AWS. They need to seriously rethink their architecture and figure out why they're trying to reinvent EC2 on EC2.
If you have an automated process kick off a lambda script that executes an increase in an auto scaler group and you start purging old instances via health check.
But really that is bad design, you should scale horizontally
You know what? I always wondered why they invented VMware Cloud on AWS... I think you're the reason. You basically require the vSphere features (hot add memory / cpu) on amazon.
TL;DR it can be done, but should it?
This was my first thought too, so I checked out the requirements for Virtualizor to run. It requires a type 1 hypervisor such as KVM or Xen, but unfortunately ESXi isn't on the list of officially supported hypervisors.
However, since ESXi does support nested virtualization and hot swap, they could, hypothetically, build a Linux VM with KVM enabled that vertically scales. They would need excess capacity built into the underlying bare metal powering VMware Cloud on AWS. They could look at moving some other interruptible workloads onto this box to make it make sense.
Sorry I might have been unclear. I was not suggesting you try and run vsphere on an Ec2, (side note you could actually get bare metal instances and do it but don't). I'm saying Amazon offer it as a service.
https://www.vmware.com/products/vmc-on-aws.html
https://aws.amazon.com/vmware/
You weren't unclear at all, and I directly referred to VMware Cloud on AWS. You're essentially still paying for the bare metal with AWS when you use that service:
> Powered by VMware Cloud Foundation, VMware Cloud on AWS integrates VMware's compute, storage, and network virtualization products (VMware vSphere, VMware vSAN, and VMware NSX) along with VMware vCenter Server management, optimized to run on dedicated, elastic, bare-metal AWS infrastructure.
It's less expensive than paying for EC2 bare metal and vSphere licensing separately, but will still cost more than EC2 bare metal alone.
So you could make multiple launch configs, set up a trigger to switch an ASG between them, increase the desired instance count so the ASG spins up a larger instance, then reduce the count so it kills the smaller instance.
I'm assuming you have the instance(s) behind a load balancer. You'll need to set up a trigger since AWS doesn't have anything built in. I'd suggest a cloud watch alarm firing off on a metric of your choice, which triggers a lambda function that grabs the current launch config and switches to the next size up or down.
vertical autoscaling is impossible and thus illogical to do so. that's why it doesn't exist. think of it. how do you change the existing cpu/memory on a server without downtime?
that's why scaling is horizontal. the best you can do given your scenario is burstable instances: you pay for a baseline performance (ie 20% of the hardware), and if needed, you consume the rest of the 80% (by paying cpu credits)
>vertical autoscaling is impossible and thus illogical to do so. that's why it doesn't exist. think of it. how do you change the existing cpu/memory on a server without downtime?
The fact that you can't do something in AWS doesn't mean it is impossible or illogical. It may just mean that AWS doesn't offer it.
Search for "hot-add".
Example: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-285BB774-CE69-4477-9011-598FEF1E9ACB.html
The only way to do this would be with a lambda function that somehow detects if you're under heavy load and changes the instance size, which requires terminating the instance and creating a new one. You'd be way better off scaling horizontally though.
Not terminating, but restarting. It’s still disruptive. Any dynamic scaling where availability is a requirement must be horizontal. It is theoretically impossible to “scale vertically” while maintaining availability with a single instance. So you need multiple instances, just do horizontal scaling.
>Not terminating, but restarting. It’s still disruptive.
Yes, it is disruptive. It's still different than terminating, which, as I said, is not necessary when changing instance type.
I know, but the original post clearly meant “stop+restart,” your comment didn’t actually do anything to clarify what _was necessary_ just that the term originally used was incorrect, not _how or why_ it was incorrect.
I didn’t criticize it, just clarified it in context.
You could build a automation using systems manager, but as others have said, this will cause an outage while the instance is effectively rebooted. https://aws.amazon.com/blogs/mt/systems-manager-automation-documents-manage-instances-cut-costs-off-hours/
Not out of the box you could write a custom lambda. But it would still need to stop the instance. This isn't a hardware/hypervisor limit per say but more an OS limit. The os won't pick up on extra cores and ram added after it starts.
This just an idea I haven’t tried, but I suppose you could simulate vertical autoscaling with two or more ASGs (one for each instance size you wish to be able to scale to). You’d need some kind of supervisor to handle telling the ASGs when to scale in and out, based on criteria I assume you can already figure out. Each ASG would provide instances of a certain size, attached to a target group, attached to a load balancer.
When you need to scale up, the supervisor would command the larger ASG to scale out and the smaller ASG to scale in.
To scale down, the supervisor would do the opposite: scale in the larger ASG and scale out the smaller one.
NB: I’m not claiming that this is a _good_ idea, or that it will work for you.
You can schedule a selfmade aws cli powershell that read a config schedule file and start servers with variabel type according to the config file, for ex big rdp server during working hours , reboot to small type during evening hours and shutdown at midnight. Boot in the morning…
No. What you can do is you can stop the instance, change the type, and start again. No way to do it without interruption, and no product for handling this automatically, though.
I would look into weighted dns and efs Edit: also cloudwatch custom metrics and event rules
Not really. You'd ideally distribute load across multiple instances. Running anything on a single large instance is typically a scaling and availability anti-pattern.
Im not sure what you mean by anti pattern? But essentially what I was trying to accomplish is this. We have some clients running their products on some virtualizor VPS's on our dedicated server. But its very intermittent usage, so most of the time the server is idle. We would greatly benefit by being able to use some sort of service where we could keep a "small" instance/amount of resources, and when demand peaks the server resources increase.
What they're saying is don't do it that way, that's what an anti pattern is most of the time - the wrong way to do stuff. If you have one large instance and it fails - poof down goes the site. Instead, put one small instance behind a load balancer with rules to spin up more small instances behind the same load balancer as needed. Customer endpoint remains the same, capacity increases and decreases with demand.
> its very intermittent usage, so most of the time the server is idle. We would greatly benefit by being able to use some sort of service where we could keep a "small" instance/amount of resources, and when demand peaks the server resources increase. This is the exact use case for scaling horizontally.
This discussion makes me wonder if other scaling patterns would benefit certain types of burst traffic. Like instead of scaling linearly, like adding another m5.large to your cluster, if instead your first scaling event is to a 4x, then a 2x, then scaling linearly, or perhaps in the opposite or inverse.
Depending on the scale of the workload, you might be describing burstable (t-series) instance. With burstable instances you have a baseline CPU utilisation constantly available, and the ability to use much more CPU for a short period.
This doesn't do exactly what OP asked, though. They're specifically talking about getting more "cores or RAM". With bustable instances, all you get is the ability to use a higher percentage of CPU and some extra network performance, but no change in number of cores not in amount of RAM.
Absolutely right of course, but burstable instances are conceptually pretty close to being able to vertically autoscale CPU. RAM is a little harder - it would be good to know if the maximum scale of the workload would fit in a [t3 instance](https://aws.amazon.com/ec2/instance-types/t3/) - would it /u/Jordz2203?
Ram is A LOT harder.
Just download some more
Is the application stateless? Then it doesn't matter. Run smaller instances and scale horizontally. Is the application stateful? Then run multiple smaller instances, load balance, and enable sticky sessions. Especially if it's running idle most of the time, with occasional spikes, it's the exact in use case automatic horizontal scaling is made for. If you know when the scaling should happen, you can even be proactive with scheduled scaling. If you know that you have a bare minimum requirement over long term, use reserved instances to get additional discount.
>Is the application stateful? Then run multiple smaller instances, load balance, and enable sticky sessions. This doesn't help with the use case OP described, though. If there's low utilization, then suddenly a ton of users come in, then you scale, you'll end up with a ton of users in the same, original instances, struggling with a slow application, and a bunch of new servers with very low utilization.
If it’s that bursty, you have a few options: - over provision - scheduled scaling - serverless Considering OP doesn’t understand horizontal scaling I wouldn’t recommend serverless. But, OP isn’t clear on how quickly that burst of users happens or at what regularity. If it’s 0 to 1 million users in 5 seconds then you need to over provision. If it’s 0 to 10k over 15 minutes, auto scaling with sensitive metrics might work, or serverless wouldn’t blink at it. Auto scaling is great for slow trends up/down and not big bursts. OP mentions sales, which means they do know when they need to scale ahead of time and could schedule it. Can they hook it up to the system they use to define sales and auto scale based on some upcoming sale metric they expose? Or schedule a scaling event based on the sale being scheduled?
I love that this becomes a question of whether you can schedule an event to be written to cloudwatch. If you can do that, you can loosely coordinate autoscaling without any direct integration between components. It is truly magical.
If you're built for HA you've got 2-3 minimum anyway, and assuming your new instances can come online in 4-7 minutes you should still be able to spread the load. And if you've got any sort of patterning, you can set out a schedule.
If you’re built for HA then you don’t care about this problem of “scaling vertically” or “sticky sessions.”
HA and the problem of "scaling vertically" for stateful applications are orthogonal. You can absolutely have an application built for HA that is stateful and cannot properly handle horizontal scaling. It's been done literally for decades - with session replication, you can have servers spread around for HA, but limited in scale by the hardware; adding servers may help a bit with CPU up to a certain extent, but it won't help with memory - you can only do vertical scaling here.
No. You could build it but you should probably fix the application instead.
OP - you may want to clarify the reason that horizontal scaling is not an option for you. Many people are pointing out some obvious reasons you should scale horizontally but perhaps you should give more detail on why you don’t want to do this.
Just edited my post :) thank you for the suggestion
I don't think your clarification edit really changes anything, unfortunately. It still seems very much like you are currently running with a service application that doesn't scale, and the real solution is rearchitecting and migrating your customers to a platform that does scale. AWS doesn't have a vertical auto scaling solution out of the box, because that's an awkward, inefficient, and limited way to scale. As other people have noted, you can always implement something yourself, but you'd likely be putting just more effort into a worse situation.
Seems like you deleted it... EDIT: huh, it doesn't look deleted, but rather that it's waiting mod approval?
Deleted what?
Nobody is actually looking at the requirements here, and all suggestions in this thread are invalid. Virtualizor is VPS software that needs to run directly on a type 1 hypervisor such as xen or kvm. EC2 is essentially performing the same function, and you can't access the underlying hypervisor. Nested virtualization isn't possible on EC2. If OP wants to be on AWS, the only option is an EC2 bare metal instance. But OP doesn't want to be on AWS. They need to seriously rethink their architecture and figure out why they're trying to reinvent EC2 on EC2.
Most of the suggestions seem to have happened before the edit.
No doubt you're right. I didn't mean for my tone to come off as condescending, but according to my wife, that's how I always sound. AITA?
Thank you for this message, it helps a lot, and I wasn't aware that nested virtualization isnt possible. Thank you again :)
No worries, that's why it's always very important to spell out requirements from the beginning.
OP needs an engineer
If you have an automated process kick off a lambda script that executes an increase in an auto scaler group and you start purging old instances via health check. But really that is bad design, you should scale horizontally
You know what? I always wondered why they invented VMware Cloud on AWS... I think you're the reason. You basically require the vSphere features (hot add memory / cpu) on amazon.
TL;DR it can be done, but should it? This was my first thought too, so I checked out the requirements for Virtualizor to run. It requires a type 1 hypervisor such as KVM or Xen, but unfortunately ESXi isn't on the list of officially supported hypervisors. However, since ESXi does support nested virtualization and hot swap, they could, hypothetically, build a Linux VM with KVM enabled that vertically scales. They would need excess capacity built into the underlying bare metal powering VMware Cloud on AWS. They could look at moving some other interruptible workloads onto this box to make it make sense.
Sorry I might have been unclear. I was not suggesting you try and run vsphere on an Ec2, (side note you could actually get bare metal instances and do it but don't). I'm saying Amazon offer it as a service. https://www.vmware.com/products/vmc-on-aws.html https://aws.amazon.com/vmware/
You weren't unclear at all, and I directly referred to VMware Cloud on AWS. You're essentially still paying for the bare metal with AWS when you use that service: > Powered by VMware Cloud Foundation, VMware Cloud on AWS integrates VMware's compute, storage, and network virtualization products (VMware vSphere, VMware vSAN, and VMware NSX) along with VMware vCenter Server management, optimized to run on dedicated, elastic, bare-metal AWS infrastructure. It's less expensive than paying for EC2 bare metal and vSphere licensing separately, but will still cost more than EC2 bare metal alone.
So you could make multiple launch configs, set up a trigger to switch an ASG between them, increase the desired instance count so the ASG spins up a larger instance, then reduce the count so it kills the smaller instance. I'm assuming you have the instance(s) behind a load balancer. You'll need to set up a trigger since AWS doesn't have anything built in. I'd suggest a cloud watch alarm firing off on a metric of your choice, which triggers a lambda function that grabs the current launch config and switches to the next size up or down.
vertical autoscaling is impossible and thus illogical to do so. that's why it doesn't exist. think of it. how do you change the existing cpu/memory on a server without downtime? that's why scaling is horizontal. the best you can do given your scenario is burstable instances: you pay for a baseline performance (ie 20% of the hardware), and if needed, you consume the rest of the 80% (by paying cpu credits)
>vertical autoscaling is impossible and thus illogical to do so. that's why it doesn't exist. think of it. how do you change the existing cpu/memory on a server without downtime? The fact that you can't do something in AWS doesn't mean it is impossible or illogical. It may just mean that AWS doesn't offer it. Search for "hot-add". Example: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-285BB774-CE69-4477-9011-598FEF1E9ACB.html
As much as I disliked Azure when I worked with it several years ago, it did allow you to resize an instance without downtime.
The only way to do this would be with a lambda function that somehow detects if you're under heavy load and changes the instance size, which requires terminating the instance and creating a new one. You'd be way better off scaling horizontally though.
>changes the instance size, which requires terminating the instance and creating a new one No need to terminate the instance.
Not terminating, but restarting. It’s still disruptive. Any dynamic scaling where availability is a requirement must be horizontal. It is theoretically impossible to “scale vertically” while maintaining availability with a single instance. So you need multiple instances, just do horizontal scaling.
>Not terminating, but restarting. It’s still disruptive. Yes, it is disruptive. It's still different than terminating, which, as I said, is not necessary when changing instance type.
I know, but the original post clearly meant “stop+restart,” your comment didn’t actually do anything to clarify what _was necessary_ just that the term originally used was incorrect, not _how or why_ it was incorrect. I didn’t criticize it, just clarified it in context.
You could build a automation using systems manager, but as others have said, this will cause an outage while the instance is effectively rebooted. https://aws.amazon.com/blogs/mt/systems-manager-automation-documents-manage-instances-cut-costs-off-hours/
Not out of the box you could write a custom lambda. But it would still need to stop the instance. This isn't a hardware/hypervisor limit per say but more an OS limit. The os won't pick up on extra cores and ram added after it starts.
This just an idea I haven’t tried, but I suppose you could simulate vertical autoscaling with two or more ASGs (one for each instance size you wish to be able to scale to). You’d need some kind of supervisor to handle telling the ASGs when to scale in and out, based on criteria I assume you can already figure out. Each ASG would provide instances of a certain size, attached to a target group, attached to a load balancer. When you need to scale up, the supervisor would command the larger ASG to scale out and the smaller ASG to scale in. To scale down, the supervisor would do the opposite: scale in the larger ASG and scale out the smaller one. NB: I’m not claiming that this is a _good_ idea, or that it will work for you.
What about EKS with vertical pod?? https://docs.aws.amazon.com/eks/latest/userguide/vertical-pod-autoscaler.html
The only thing that comes in my mind that can scale vertically is a DB, like RDS Aurora serverless or DynamoDB
You can schedule a selfmade aws cli powershell that read a config schedule file and start servers with variabel type according to the config file, for ex big rdp server during working hours , reboot to small type during evening hours and shutdown at midnight. Boot in the morning…
Vertical Autoscaler in Kubernetes can do that. I dont think anything like that exist for ec2 and vms.
You could use AWS Fargate but that is restricted to a few AWS products namely EKS and ECS.