I'm trying to run an AWS Instance for as cheap as possible and I can see from the pricing history that in availability zone us-east-1d the current price is at $0.25 but in us-east-1a the price is $9.60.
I put in a request for $0.3 and it's saying my request is lower than the minimum fulfillment price of $9.60. There was nowhere to specify the availability zone in the request wizard but there must be a way to get it cheaper than $9.60 which is way over the on-demand price!
Am I doing it wrong somehow or is there a way to do this?
Edit: added image of wizard, where's the option to specify availability zone?
On step 3 you should have the option to set your availability zone preference. Default option is "No Preference".
Faced the same question recently, AWS spot instance wizard is not very intuitive in this regard.
My case was a default VPC, the same as is in the initial question. Therefore to "select availability zone" one needs just to select a corresponding subnet from drop down field.
The official AWS documentation states:
Launching Spot Instances in an Availability Zone Group
Specify an Availability Zone group in your Spot Instance request to
tell the Spot service to launch a set of Spot Instances in the same
Availability Zone. Note that the Spot service need not terminate all
instances in an Availability Zone group at the same time. If the Spot
service must terminate one of the instances in an Availability Zone
group, the others remain running.
Note that although this option can be useful, adding this constraint
can lower the chances that your Spot Instance request is fulfilled.
If you specify an Availability Zone group but don't specify an
Availability Zone in the Spot Instance request, the action taken by
the Spot service depends on whether you specified the EC2-Classic
network, a default VPC, or a nondefault VPC. For more information
about EC2-Classic and EC2-VPC, see Supported Platforms.
EC2-Classic
The Spot service finds the lowest-priced Availability Zone in the
region and launches your Spot Instances in that Availability Zone if
the lowest bid for the group is higher than the current Spot Price in
that Availability Zone. The Spot service waits until there is enough
capacity to launch your Spot Instances together, as long as the Spot
Price remains lower than the lowest bid for the group.
Default VPC
The Spot service uses the Availability Zone for the specified subnet,
or if you don't specify a subnet, it selects an Availability Zone and
its default subnet, but it might not be the lowest-priced Availability
Zone. If you deleted the default subnet for an Availability Zone, then
you must specify a different subnet.
Nondefault VPC
The Spot service uses the Availability Zone for the specified subnet.
Related
I am trying to spin up a on demand d2.8xlarge instance in the us-east-1 region.
However for the past 2 days I have consistently received the error:
“We currently do not have sufficient d2.8xlarge capacity in the Availability Zone you requested (us-east-1c). Our system will be working on provisioning additional capacity. You can currently get d2.8xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a,us-east-1b etc"
My question is:
I am not specifying an availability zone - I am only specifying the region "us-east-1"
so is aws checking availability across all availability zones in the region specified or is it randomly choosing a availabilty zone to try within the region?
If it is choosing an availability zone in the region to try, how can I specify that it should try availability across all zones in my code which is as follows:
https://github.com/NREL/OpenStudio-server/blob/develop/bin/openstudio_meta#L761
OK I'm trying to create an internal Network Load Balancer.
On the console, it says:
Mappings
Select at least two Availability Zones and one subnet per zone.
And at the same time it also says:
Your internal load balancer must have a private subnet.
I have created a new subnet (NLB-subnet, or subnet subnet-084f41a2d64bd25ad, as shown in the picture above) in my VPC, just for the NLB.
When you create a new subnet, you must choose the zone in which your subnet will reside. And you can only choose one in the AWS console. So I did, and I chose ap-northeast-1a.
However, when it asks me to Select at least two Availability Zones and one subnet per zone., I am confused like a 2 year old:
I have selected the AZ ap-northeast-1a for the NLB mapping, and that's where my new subnet resides, no problem.
But then I have to select a second AZ???
The seconds AZ has no subnet just for the NLB, because you can only choose one AZ for the subnet!
What does it want me to do?
Do I have to create a new private subnet in every one of the 3 Availability Zones, just for the NLB?
what? why?
You don't need to place your NLB in two AZs, if you don't want. NLB works fine in a single AZ as well. Only for ALB it is required to have two AZs. From docs:
You enable one or more Availability Zones for your load balancer when you create it. If you enable multiple Availability Zones for your load balancer, this increases the fault tolerance of your applications.
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 ?
I am looking for how to specify the zone I want to deploy to in a single instance deployment, with autoscaling, while also having automatic failover to another zone -- Do any options exist to achieve this?
More context
Due to how reserved instances are linked to a single availability zone (AZ), we find it to be a good strategy (from an "ease of management"/simplicity perspective), when buying reserved instances for our dev environment, to buy them all in a single zone and then launch all dev instances in that single zone. (In production, we buy across zones and run with autoscale groups that specify to deploy across all zones).
I am looking for how to:
Specify the AZ that I want an instance to be deployed to, so that I can leverage the reserved instances that are tied to a single (and consistent) AZ.
while also having
The ability to failover to an alternate zone if the primary zone fails (yes, you will pay more money until you move the reserved instances, but presumably the failover is temporary e.g. 8 hours, and you can fail back once the zone is back online).
The issue is that I can see how you can achieve 1 or 2, but not 1 and 2 at the same time.
To achieve 1, I would specify a single subnet (and therefore AZ) to deploy to, as part of the autoscale group config.
To achieve 2, I would specify more than one subnet in different AZs, while keeping the min/max/capacity setting at 1. If the AZ that the instance non-deterministically got deployed to fails, the autoscale group will spin up an instance in the other AZ.
One cannot do 1 and 2 together to achieve a preference for which zone an autoscale group of min/max/capacity of 1 gets deployed to while also having automatic failover if the zone the server is in fails; they are competing solutions.
This solution uses all AWS mechanisms to achieve the desired effect:
Launch the instance into the preferred zone by specifying that zone's subnet in the 1st autoscale group's config; this group's min/max/capacity is set to 1/1/1.
Create a second autoscale group with the same launch config as the 1st, but this other autoscale group is set to a min/max/desired of 0/1/0; this group should be configured with the subnets in every available zone in the region except the one specified in the 1st autoscale group.
Associate the 2nd autoscale group with the same ELB that is associated with the 1st autoscale group.
Set up a CloudWatch alarm that triggers on the unhealthy host alarm for #1's autoscale group; have the alarm change the #2 autoscale group's to a min/max/desired of 1/1/1. (As well as send out a notification so that you know this happened).
If you don't expect to get unhealthy host alarms except in the cases where there is an actual host failure or if the AZ goes down -- which is true in our case -- this is a workable solution.
As you have already figured out, (as of mid-2015) that's not possible. Auto-scaling doesn't have the concept of failover, strictly speaking. It expects you to provide more than one AZ and machines enough in each one if you want to have high availability. If you don't, then you aren't going to get it.
The only possible workaround I can imagine for this is setting up a watchdog yourself which changes the auto-scaling group's subnet once an AZ becomes unavailable. Not so hard to do, but no so reliable as well.
As I understand in order to take advantage of reserved instance pricing, the AZ of the reserved instance must match the AZ of my Elastic Beanstalk's EC2 instance.
In order to achieve this I figure I would need to limit my EB app to just one availability zone. This would guarantee my main instance is running in the discounted AZ.
But by doing this additional instances would also be locked into this zone potentially reducing availability.
Are these assumptions correct? And if so how can I work around them so that my main instance is always in the discounted zone, and additional instances can be in another zone?
You assumptions are right.
Reserved instances are bound to the availability zone (though they recently started allowing the AZ modification before the tenure expiry - http://aws.amazon.com/about-aws/whats-new/2013/09/11/amazon-ec2-now-offers-reserved-instance-modifications/).
The only thing you can ensure is that out of the many AZ which you choose in beanstalk, keep them as much same as the Reserved instances. In AWS words "If you purchased Reserved Instances, you need to specify the same Availability Zone(s) that you specified when you purchased your Reserved Instances"
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.as.html
Are you could buy two RI and put them in two different AZ and limit your EB to those two AZ then at least you have some redundancy.