Newbie to AWS, I have a t2.micro EC2 instance supporting my Elastic Beanstalk application. It was created while I deployed my WAR file to Elastic Beanstalk.
My EB application does not need to run 24 hrs a day so it only needs to work during a specific period of time a day. When I tried to stop it from the AWS EC2 management console by selecting "Actions -> Instance state -> Stop", the instance was terminated instead but a new instance was created and initialized and then running automatically later.
How can I stop an EC2 instance properly to suit my need? Thanks.
Your EB application is utilizing an Auto Scaling group to ensure your EC2 instance stays running.
When you stop your EC2 instance, Auto Scaling sees that as an unhealthy instance and terminates it, then replaces it with a new, healthy instance.
You cannot stop EC2 instances that are part of an Auto Scaling group. The best you can do is to edit your Auto Scaling group policy to set min=desired=0. This will terminate the instance and keep it terminated. When you want to get your instance running again, edit your Auto Scaling group and reset min=desired=1.
Related
I think you have 2 scaling
1 for ec2 instance
1 for ecs task
So I think flow goes like
You get more requests
Your tasks need more resources (cpu/memory)
Your ecs task autoscaling kicks in and creates more task
your ec2 autoscaling also kicks in and creates more ec2
Questions
your ecs needs to know newly launched ec2 (from ec2 autoscaling group) is the host that it can run on (how?)
I want the number of ec2 instance starts from one.
I think one instance is already running in the ecs cluster
Do I make ec2 autoscaling group start from 0?
ec2 autoscaling group has pricing option to use spot instance, but I didn't see such option when I created ecs cluster instances. To be clear, can I make ecs cluster with 0 ecs-instance, and let ec2 autoscaling group starts with 1 instance?
Your ecs task autoscaling kicks in and creates more task
your ec2 autoscaling also kicks in and creates more ec2
Your ECS task scale if there is a memory so fine it will scale and launch new container, if not enough memory then it will not launch an instance, you need to configure cloud watch alarm to scale ECS cluster based on the task scaling.
Tutorial: Scaling Container Instances with CloudWatch Alarms
your ecs needs to know newly launched ec2 (from ec2 autoscaling group)
is the host that it can run on (how?)
ECS agent registers the new instance with the same cluster, and the new task can be placed in any instance that have available resources to handle and launch the container.
I want the number of ec2 instance starts from one. I think one
instance is already running in the ecs cluster Do I make ec2
autoscaling group start from 0?
You should start from 1 otherwise no container will launch and will throw error no instance found in the cluster. if you do not want run container for now then you can start from 0.
ec2 autoscaling group has pricing option to use spot instance, but I
didn't see such option when I created ecs cluster instances. To be
clear, can I make ecs cluster with 0 ecs-instance, and let ec2
autoscaling group starts with 1 instance?
You can read about spot ECS cluster instance here.
Amazon ECS is a highly scalable, high performance, container
management service that supports Docker containers and allows you to
run applications on a managed cluster of Amazon EC2 instances easily.
ECS already handles the placement and scheduling of containers on EC2
instances. When combined with Spot fleet, ECS can deliver significant
savings over EC2 on-demand pricing.
Wanted to know more about internals of AWS when we autoscale an instance from one tier to another. Does AWS creates an image and spins up new instance and restores the image ? or what exactly happens inside. ?
Amazon EC2 Auto Scaling will either Launch a new instance or Terminate an existing instance. This is known as horizontal scaling. No instance is "upgraded".
In fact, it is not possible to "upgrade" an Amazon EC2 instance. Instead, you need to Stop the instance, change the Instance Type, then Start the instance again. This will launch the instance on a different host, which is dedicated to running the new Instance Type.
The disks used on Amazon EC2 are (typically) Amazon Elastic Block Store (EBS) volumes. These are network-attached volumes that exist separately to the EC2 instance. Thus, the disks are preserved when the instance is stopped and they are automatically reattached to the instance when it is started again.
When I'm using AWS Cloud9, an EC2 instance is running in the background hosting it. By default, the EC2 instance hibernates after 30m, but sometimes I just want to use the IDE for 2 minutes and not have the EC2 instance running for 30m afterwards. Can I reduce the threshold for hibernation further or hibernate the EC2 instance manually?
Assuming you have Cloud9 running on its own on-demand EC2 instance (the default setting during setup), you can find the EC2 instance backing it in your EC2 management console and shut down the instance manually when you're done with it.
I am working on building a quick start and trying to understand below statement from https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html
"If your instance is in an Auto Scaling group, the Amazon EC2 Auto Scaling service marks the stopped instance as unhealthy, and may terminate it and launch a replacement instance. For more information, see Health Checks for Auto Scaling Instances in the Amazon EC2 Auto Scaling User Guide."
Can someone help cases that may lead to termination or is it always a termination?
I had to stop my m3.medium EC2 instance from the AWS console to resize it to m3.large. However, after it stopped, it automatically created a new instance.
Any idea why this is happening? It caused some big troubles for me.
Your AutoScaling group with minimum size = 1 spun up a new instance because there were no instances in the 'running' state available to respond to requests, particularly health checks. Your instance was deemed 'unhealthy' and replaced by the ASG.
If your instance storage was ephemeral, I'm afraid it is gone forever unless you recently saved an AMI. If your instance storage was backed by EBS, you can recover it by attaching the EBS volume to a new instance.
In the future, consider configuring your autoscaling group's launch configuration to have everything you need ahead of time, by either bootstrapping the instance or by baking an AMI.
For 'bootstrapping' an instance:
Create a new launch configuration with a standard AMI avaialble from Amazon.
Add user data to the launch configuration to handle installation and configuration of your desired programs.
For 'baking' an AMI:
Install your desired programs and configuration on a new EC2 instance.
Take an image (AMI) of that EC2 instance.
Use that image in your new launch configuration.
Manually working on an instance within an ASG and expecting the instance to persist indefinitely is dangerous, as you've just discovered.
Further Reading:
EC2 Documentation - AutoScaling Health Checks
EC2 Documentation - Amazon Machine Images