21

You need a NAT. This configuration is commonly used to support private subnets in VPC, there's quite a detailed guide here. Once your VPC is configured to use the NAT instance all the outbound traffic will be attributed to the EIP of the NAT instance. If so, does that instance need to be solely for this purpose or can it be one of the instances that's ...


21

I have written a small script like below to get the IP list: #!/bin/bash for i in `aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASGName | grep -i instanceid | awk '{ print $2}' | cut -d',' -f1| sed -e 's/"//g'` do aws ec2 describe-instances --instance-ids $i | grep -i PrivateIpAddress | awk '{ print $2 }' | head -1 | cut -d"," -f1 ...


17

As alternative, my version without any jq/awk/sed/cut $ aws autoscaling describe-auto-scaling-instances --region us-east-1 --output text \ --query "AutoScalingInstances[?AutoScalingGroupName=='ASG-GROUP-NAME'].InstanceId" \ | xargs -n1 aws ec2 describe-instances --instance-ids $ID --region us-east-1 \ --query "Reservations[].Instances[].PrivateIpAddress" --...


15

The approach discussed above would be a little messy, and not so flexible. The more canonical approach is to just create 2 ASGs (one for spot, one for on-demand) and then register them both with the same ELB (discussed here). This gives you the ability to control each independently rather than trying to muck with LC swaps in a single ASG.


13

I understand this is an old thread - for someone who has a similar use-case now, AWS nat-gateway would be a better solution.


11

Update Our bid price is high, and I don't think the instances should have been terminated due to spot price (based on spot pricing history) Spot price contention is not the only possible cause for an Amazon EC2 Spot Instance being terminated by AWS, another notable one is capacity contention: The capacity of available spot instances depends on the ...


10

The easier way is to increase number of minimum instances in Auto-Scaling Group (ASG) to double of your current count, wait when all of them are started and then change that minimum number of instances down to what it was. ELB will kill older instances and will leave newer instances with code. To achieve that Termination policy should be set to '...


10

I’m not sure how exactly it would work. When there are no healthy ALB targets the ALB returns 503 error, hence your visitors would see an error page instead of your website. That may trigger a Fargate container start but that often takes tens of seconds, sometimes even over a minute. By the time your container is up your visitor is probably gone. If you ...


8

Let's go over your questions. So basically I want my original instance to be running at all times. Then when it starts going over capacity I want the Auto Scaling Group to start launching instances and the Load Balancer to distribute the load across them. Is my thinking here sound? I'd say yes, but I do have a couple reservations. If I understand ...


8

I'd suggest a cron job to publish the current queue length as a CloudWatch custom metric, which will allow you to create auto-scaling alarms based on its value.


7

This can be achieved by using Amazon SDK ( I am almost done with it, will put it on github ), utilizing the SNS, EC2 and Autoscaling service. I have followed the below steps to achieve this: Enable HTTP notification and subscribed my webserver. Added a lifecycle-hook with heartbeat of 1 min (to wait for 1 min before terminating) to my autoscaling group for ...


6

the way i manage this scenario is to use the UpdatePolicy feature of the AWS::AutoScaling::AutoScalingGroup object in cloud formation. when the cloud formation stack is updated it will manage the cycling of the instances. some references. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html http://docs.aws.amazon.com/...


6

I don't have enough reputation to comment on the above answers, but I wanted to add some information you will need to know if using a NAT gateway to achieve this. When you create a NAT gateway, you select a subnet and an elastic IP address. At first, I just added the NAT gateway to the same subnet that my elastic load balancer and EC2 instances were on. ...


5

You could update your configuration with a user-data script that is run when you launch your instance. What you put in the script depends on how you manage your configuration at the filesystem level. I personnaly put my configuration files in a Mercurial repository and simply do a pull to update it.


5

Is this even possible in EC2? No, not using their ASG product. The whole point of using an ASG (and honestly, doing more or less anything on EC2), is that your individual compute instances should not retain any state that you can't easily and quickly re-create. This means: keep data in a database of some sort keep static assets in S3 build a centralized ...


5

Autoscaling does one thing: Spins up/down an AMI based on defined criteria. That's it. Note the lack of a 'pull latest code' step in that list of things it does. Autoscaling assumes you're solving the code-deploy problem outside of Autoscaling. Perhaps by: Creating a new AMI each time you push code, and updating the autoscaling-config to use that new AMI. ...


4

Your link to how to create CloudWatch Alarms is indeed the mechanism you will wind up using if you go the Amazon Auto Scaling route. However, as you state yourself, setting up Windows servers can be quite painful -- not only is connecting to them and getting them up to the state you want rather slow, there is often also a considerable delay just getting them ...


4

First, a disclaimer: this is not the answer you're hoping for, but it is the right answer. I have an EC2 instance running CPM/WHM There's your first problem. Your first step to reaching your goal needs to be removing your dependency on these tools. These control panels are pointy-clicky user tools, not systems administration tools. Remove those and use ...


4

T2 instances should be absolutely avoided in scenarios where your applications consistently consume their credits, precisely due to this kind of issues with the CPU credits system provided by AWS. If your application is CPU intensive in a consistent way, you should better go for C3/C4 instances, which have the same CPU/Memory ratios (except t2.large which, ...


4

Take a look at the fine documentation for the AWS API. E.g. the aws-cli tools aws autoscaling describe-auto-scaling-instances and aws ec2 describe-instances.


4

I had exactly the same problem. What i ended up doing was changing my scale down policy to SimpleScaling reducing by one instance at a time and setting a 10m cooldown. I've also changed my scale down alarm condition to trigger when there are 10 periods of 60 seconds below my threshold of 35% CPU. ( I have detailed cloudwatch metrics enabled ) The idea being ...


4

Think of the min and max as global bounds. The desired capacity can change over time, as you say, in response to a load signal. This number represents the number of instances you want "now."


4

It looks like a fresh EC2 instance takes about 15 to 20 minutes to initialize and start working, but your cooldown is only 5 minutes. So 5 minutes after increasing your desired count, your new EC2 instance is still initializing, but the CPU is checked again by Auto Scaling and it's still high, so Auto Scaling increases the desired count again. Try ...


4

I think you'll want to setup a CodeDeploy and CodePipeline to do this. Codepipeline can monitor the source, s3, and then send the update to codedeploy to update the EC2 instances. http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html http://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html


4

When you are using Auto Scaling and Load Balancing, you want all your EC2 instances to be identical. So they are all (a) rooted on the same AMI image, and (b) proceed through the same initialization steps to end up with the same code and assets on them. This way, they will all respond the same with the same input from your HTTP client. To accomplish this, ...


4

As described in the linked answer you will need an ASG Lifecycle hook to start with. Whenever the Terminating event occurs fire up a Lambda function and in that Lambda deregister your instance from the Target Group using deregister-targets. That should move it to Draining phase, then wait however long you need to wait and once the instance is drained ...


4

If re-writing your app to fit the above response it's not an option or costly, you could look into GCP CloudRun CloudRun it's serverless containers developed by GCP. You can pack your website in a container and then CloudRun only bills you per CPU usage during requests and boot-up. It even has a really good free tier that will make running your app at ...


3

Yes, the Azure management API will allow you to select specific instances to remove. Starting with version 2013-08-01 of the Azure service management API you can use the Delete Role Instances operation to delete a specific instance(s). You can find detailed information in the Microsoft MSDN page at http://msdn.microsoft.com/library/azure/dn469418.aspx. ...


3

It is not possible to update an existing AMI and keep the same AMI id. You will either need to create a new custom AMI and update your launch configuration for the Auto Scaling group, or change your setup to apply changes to the instance after launching an instance of the base AMI as @DavidLevesque suggests. It is a common architecture to download ...


3

As of 6/16/2020 EC2 AutoScaling supports Instance Refresh - a single API call to replace every instance in an ASG safely and autonomously. To use it, update your ASG, setting a Launch Configuration or Launch Template containing your desired AMI, and then call StartInstanceRefresh. https://aws.amazon.com/blogs/compute/introducing-instance-refresh-for-ec2-auto-...


Only top voted, non community-wiki answers of a minimum length are eligible