The definition of the vpc_zone_identifier parameter is a list of subnet IDs to launch resources in. Subnets automatically determine which availability zones the group will reside.
So suppose I list eu-west-1a and eu-west-1c for that parameter and a desired capacity of 3.
Is my ASG going to deploy my desired capacity randomly across the AZs (e.g. 2 + 1) or it will deploy 3 per AZ?
There will be only 3 instances distributed across the two AZs if the selected AZs have enough capacity. AWS tries to prioritize high-availability, so it will try to place the instances evenly across the AZs (2+1 in your case). Exact details are:
Amazon EC2 Auto Scaling attempts to distribute instances evenly between the Availability Zones that are enabled for your Auto Scaling group. Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. If the attempt fails, however, Amazon EC2 Auto Scaling attempts to launch the instances in another Availability Zone until it succeeds. For Auto Scaling groups in a VPC, if there are multiple subnets in an Availability Zone, Amazon EC2 Auto Scaling selects a subnet from the Availability Zone at random.
Related
There is set of rules to terminate instance for Auto Scaling when we have multiple AZ.. Same way if we wanted scale up if we have multiple available zones, where exactly instances will be created .. is there any hierarchy?
According to aws docs, if you have multiple availabilty zones for an autoscaling group, aws try to distribute the instance in evenly manner. So if your desired capacity is 8 and there are 4 instances in az-1 and 3 in az-2, the remaining one instance will be created in az-2.
When one Availability Zone becomes unhealthy or unavailable, Amazon EC2 Auto Scaling launches new instances in an unaffected Availability Zone. When the unhealthy Availability Zone returns to a healthy state, Amazon EC2 Auto Scaling automatically redistributes the application instances evenly across all the Availability Zones for your Auto Scaling group. Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. If the attempt fails, however, Amazon EC2 Auto Scaling attempts to launch in other Availability Zones until it succeeds.
You can read more about this here.
My AWS solution spans over 3 availability zones. In my backend the user is able to trigger a heavy compute job with beefy px instances. Therefore I wrote a CFN template, which provision all resorucess to execute the compute job (secret store, IAM Role, EC2 instance, log group). However when I try to create the template, it returns with a 500 and states that no capacity for my instance type is available for the availability zone i choose. My template provides a subnet for the EC2 instance and an availability zone for the attached volume. In the end I don't care in which availability zone the ec2 is provisioned as long it is in one of my subnets. Does someone know a way to provision an EC2 instance and it's volume (with cloudforamtion) by not specifically choosing one availability zone, but rather provide a range of subnets/availability zones ?
TLDR:
Does someone know a way to provision an EC2 instance and it's volume (with cloudforamtion) by not specifically choosing one availability zone, but rather provide a range of subnets/availability zones ?
How can I make sure ASG is scaling EC2 instances in a correct Zone sequence, i.e when I scale ASG from 3 instances to 5 instances, it needs to have 2 nodes in Zone-A, 2 in Zone-B and 1 in Zone-C. But in our case, it ends up in 2 nodes in Zone-A, 1 node in Zone-B and 2 nodes in Zone-C.
AWS ASG launches new instances in all Availability zones you enabled for that particular ASG. This is an extract from the official documentation.
Amazon EC2 Auto Scaling attempts to distribute instances evenly between the Availability Zones that are enabled for your Auto Scaling group. Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. If the attempt fails, however, Amazon EC2 Auto Scaling attempts to launch the instances in another Availability Zone until it succeeds
If you increase the desired capacity to say 9 (and you have 3 AZ's), you'll see there's a high chance there will be 3 instances on each AZ.
There is no way to control which AZ the AutoScaling Group will launch instances in.
The only work around I can think of is that you could make 1 ASG per AZ and then control the desired on your own via a script instead of using a scaling policy. I would recommend trying to make sure your application is as ephemeral as possible without zonal dependencies so that instances can be added in any zone
I have configured an AWS auto-scale group with 2 available zones: us-east-1a and us-east-1c . Today, with the issue AWS had on us-east-1a, I noticed that new instances are not created on us-east-1c zone.
Any clues on what I should check on?
Thank you.
Amazon EC2 Auto Scaling can deploy EC2 instances across multiple Availability Zones within one region.
It cannot deploy instances across multiple Availability Zones.
If you wish to implement redundancy across regions, you would need to configure Amazon Route 53 with a health check to route traffic to instances or load balancers in different regions. However, Auto Scaling would continue to operate independently in each region.
considering the statement :
When adding an RDS instance to VPC, there needs to be three subnets in
the subnet group across three different AZs for that VPC
what is the difference between three subnets and AZs here?
I know that we need AZs for any RDS instance and it is created automatically by amazon at deployment time. So, this of course means that there should be one subnet in each three AZs to enable access to RDS replicas and instances. Or it means that each AZ should have three subnets created within to enable that?
Amazon provides 99.95% RDS availability
Multi-AZ configurations for MySQL, MariaDB, Oracle, and PostgreSQL are covered by the Amazon RDS Service Level Agreement ("SLA"). The RDS SLA affirms that AWS will use commercially reasonable efforts to make Multi-AZ instances of Amazon RDS available with a Monthly Uptime Percentage of at least 99.95% during any monthly billing cycle.
In order to achieve that database has to be replicated in three different AZ. That is the reason why Amazon requires three subnets in three AZ. The relationship is:
The region has more than one AZ
AZ belongs only to one region
AZ has more than one data center
AZ can have more than one subnets. However, there is a soft limit of 200 subnets per AZ. You can ask Amazon for more than 200 if you need.
Subnet belongs only to one AZ
VPC belongs only to one region. You can have more than one VPC per region. However, there is a soft limit of 5 VPCs per region. You can ask Amazon for more than 5 if you need.
VPC can span more than one AZ.
You can have as many Subnets as you like in each AZ. By default AWS creates one VPC containing one Subnet in each AZ. The number of AZ varies from region to region.
The quote you gave in your question is saying that you must have three subnets, that these three subnets must all be be in different AZ but all three subnets must be in the same VPC.