I'm sorry if it feels like a dumb question to you.But I have to know this.
What is the use of "Attach to Auto-scaling Group" in AWS?
Let me be more specific about this question.
Suppose I have an auto-scaling group with a launch configuration. Lets name it
ABC-asg I used ami-12345 for that launch configuration.
Now I have another instance from ami-56789. Lets name my instance xyz and I've installed some packages in it.
I attached my instance xyz to the autoscaling group ABC-asg.But the new instances launched by that asg are using ami-12345.
My questions are
1.What is the use of attaching my instance to an existing auto-scaling group?
2.If it is about the "different ami" in my instance. So if I attach an instance with "same ami" will my packages replicated to the next instances launched by the asg?
Please someone help me with this question.
The Attach to Auto-scaling Group simply adds the given instance to the Auto Scaling group. This means the instance will be part of the group of instances that can receive traffic from a Load Balancer associated with the group and it also means that Auto Scaling might Terminate the instance when scaling-in a group.
The only different between an instance attached to an Auto Scaling group in this manner is that it was not created by Auto Scaling.
So, why have such a command? Here's a few scenarios:
You have a new version of software or a different server configuration that you wish to test. You can attach the instance to the Auto Scaling group and monitor its performance without having to update the whole group.
You have an instance in an Auto Scaling group that is misbehaving. You can remove it from the group with the Detach Instances command and examine the instance to perform forensic analysis to determine what is going wrong. You could then put it back into the group with the Attach Instances command.
AWS customers asked for the ability
Attaching/detaching an instance in no way affects your Launch Configuration. Any additional instances launched by Auto Scaling will not be impacted by an attach/detach command -- they will launch using the existing Launch Configuration.
Related
I have an instance created by an ASG. SGs are associated with the LB for public network access. I need to attach a SG to the instance for the service that is only available via private network.
I figured the steps are ( using data resource) get the instance_id of the EC2 launched by the autoscale group. Find the primary ENI associated with the EC2 ( again data resource) and then attach the SG to that ENI adapater.
Just wondering if this is the best way of doing it?
Thanks
When you use Terraform to configure EC2 autoscaling, it's becomes the responsibility of the EC2 autoscaling feature to create and configure your individual instances. Terraform is not aware of those individual instances and can instead only configure the settings that EC2 autoscaling itself uses to decide how to configure your instances.
Each autoscaling group has either a Launch Configuration or a Launch Template. These both serve a similar purpose but launch templates are the newer API so that is what I'll describe here.
When you define a launch template one of the available arguments is vpc_security_group_ids, which specifies the set of security group IDs that each newly-created EC2 instance must be associated with.
Each EC2 instance that your autoscaling group creates must have a distinct network interface, because each network interface can be attached to only one EC2 instance. Therefore EC2 autoscaling typically creates a new network interface for each instance it launches, using the network-related settings in the launch template. Although you can in principle choose to associate an already-existing network interface, you would be only able to create one EC2 instance at a time in your autoscaling group and in that case and so it's not a typical configuration.
Thanks in advance....
we have RDS replication with multi-AZ option. Is there any way to replicate our AWS EC2 instances without using Auto-scaling option?
On the EC2 console listing running instances, select the instance you want to replicate and under Actions click Launch More Like This.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-more-like-this.html
Yes, configure your EC2 instance exactly the way you want it to be. Stop the instance and create an AMI of this instance. Then launch as many EC2 instances as you want using the AMI. Each EC2 instance will be almost identical. There will be differences due to licensing, IP addressing, instance ID, etc.
This is the same technique that you would use with Auto Scaling Groups (e.g. new instances are launched from a specific AMI).
Another option is to use Launch More Like This from the EC2 Console. However, this feature does not clone your instance, only replicates some configuration details.
I have an auto-scaling group with EC2 that implement a custom health.
From time to time, the health check fails and instances are terminated and replaced.
The health check itself is implemented as a shell script that runs on the instances. If it detects problems, it will inform the auto scaling group via the AWS API:
aws autoscaling set-instance-health --instance-id $instance --health-status Unhealthy
The problem is only that I have no information about what check failed, beside the notification:
Cause: At 2017-06-13T09:11:47Z an instance was taken out of service in response to a user health-check
What is the recommended way to debug these type of problems. Is there a way to make AWS only stop instances and not terminate them, so their disk state could be inspected?
(First I thought about "enable termination protection", but from my understanding this will not make a difference, here. Autoscaling group will still terminate the instances when the shutdown was requested by a failing custom health check.)
Using the set-instance-health command tells Auto Scaling that the instance is unhealthy and needs to be replaced. Auto Scaling will then terminate the unhealthy instance and launch a new instance to replace it.
If you wish to perform forensic analysis on an unhealthy instance, remove it from the Auto Scaling group with the aws autoscaling detach-instances command:
Removes one or more instances from the specified Auto Scaling group. After the instances are detached, you can manage them independent of the Auto Scaling group.
If you do not specify the option to decrement the desired capacity, Auto Scaling launches instances to replace the ones that are detached.
If there is a Classic Load Balancer attached to the Auto Scaling group, the instances are deregistered from the load balancer. If there are target groups attached to the Auto Scaling group, the instances are deregistered from the target groups.
So, instead of calling set-instance-health, call detach-instances (and optionally replace it). You can then debug the instance. If you wish to send it back into service, use aws autoscaling attach-instances.
Does anyone know what the difference between Automatic Load-based Scaling vs having explicit auto scaling groups on OpsWorks is?
this: http://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autoscaling-loadbased.html
vs https://aws.amazon.com/blogs/devops/auto-scaling-aws-opsworks-instances/
With load-based instances, how does one add one to a target group?
Can you have multiple auto scaling groups in one layer of OpsWorks?
I’m looking at going with an ALB to route our traffic, which cannot act as an independent layer in Opsworks.
So I would need to pipe requests to 1 auto scaling group for one type of requests and the rest to the other other auto scaling group.
I just am not sure what load-based instances are and am perplexed by them not providing a default number of machines to start with.
Which one should I use for ALB routing traffic between the two groups?
OpsWorks is a configuration management tool that utilises Chef to configure your infrastructure. OpsWorks utilises a different approach when it comes to scaling out than a auto-scaling group.
Unlike an auto-scaling group, you have these instances pre-defined on your OpsWorks stack (layer) and they are being launched when a certain metric (threshold) is triggered (CloudWatch data: CPU, memory, load... etc).
OpsWorks will not spawn (create) any new instances, but will only be capable of starting instances you have previously created and set them as load-based instances. This is also only available for OpsWorks and cannot be used for any other service outside of OpsWorks.
AWS EC2 auto-scaling actually can launch very large number of instances (instances which do not need to be created beforehand) into your AWS environment, and same as the OpsWorks load-based scaling, can be triggered by CloudWatch alarms (CPU, memory, Load... etc).
Auto-scaling is not by default available on OpsWorks, and there is no build in way to have an auto-scaling group associated with your OpsWorks stack, but it's possible with a bit of work. Read about it here.
Let me divide the answer for you.
Does anyone know what the difference between Automatic Load-based
Scaling vs having explicit auto scaling groups on OpsWorks is?
Automatic Load-based Scaling:
Amazon Opsworks Service provides you the the feature, automatic load-based scaling where you can add instances to your layer in stack and set the auto scaling configuration policies directly.
Load based scaling scales up or down the instances based upon the load you have set to handle. You need to set the threshold, using the parameters and define the scaling policies.
Explicit Auto Scaling groups on OpsWorks:
Amazon Opsworks Service allows you to add existing instances to your layer in stack. Which means You can set an autoscaling launch configuration and set the scale up and scale down events based on the load. Then create an Autoscaling group and launch instances in it. Then you can go to Opsworks and add these existing instances to your layer in stack. So when the load increases or decreases more or less than the threshold set, the Autoscaling group handles the scaling.
With load-based instances, how does one add one to a target group?
Once you have the Load based Instances Ready either you have launched then directly from Automatic Load-based Scaling in Opsworks or Explicitly using Auto Scaling groups on OpsWork, you can go to Application Load balancer in EC2 Console and configure with necessary configurations and then register the load based instances you have just created with ALB in Register targets TAB.
Can you have multiple auto scaling groups in one layer of OpsWorks?
Yes, you can have multiple auto scaling groups in one layer of OpsWorks.
Which one should I use for ALB routing traffic between the two groups?
You can use any of the group.
so that you can pipe requests to 1 auto scaling group for one type of
requests and the rest to the other other auto scaling group.
Please Refer Autoscaling once.
I just am not sure what load-based instances are
Load Based Instances are the instances which are configured with Load based scaling configuration. You need to set the threshold,configuration and the events to define when to scale up and scale down.
EX: Suppose, If you have 5 instances running at initial stage and as you want your application to be running even your load increases to minimize your downtime, you will set autoscaling configuration such that if average CPU utilization of instances increase more than 70% launch 2 more instances. You can set scale up and scale down on many more factors.
Hope it Helps:)
When you edit an AWS security group, the changes are automatically applied to any EC2 instances associated with the security group.
When you change the launch configuration for your Auto Scaling group, any new instances are launched using the new configuration parameters, but existing instances are not affected.
So, my question is what happens when you edit the security group used by your Auto Scaling launch config? Are the changes applied only to new instances? Or do existing instances get the new security group rules as well?
Thanks!
Existing instances in the Auto Scaling Group will see any rule changes to the security group.