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.
Related
So currently I have an application running on am m3.medium instance, its just an single instance running in EU/Ireland area.
If I go to EC2 and buy a reserved instance of m3.medium when will my Elastic beanstalk instance starting using it. Does it just happen or do I have to redeploy or do something else ?
Your EC2 instance will start billing at the discounted price immediately. It "just happens" like you said. Reserved instances are just a billing construct. They are just a discount on your monthly bill. You don't have to assign the reservation to a specific EC2 instance or anything like that.
Once you reserve an instance type, AWS checks for running instances in the region/availability zone where you purchased the reserved instances and applies the discount from the moment you purchased the reserved instances.
For example, you have five m3.medium instances running and you purchased three reserved m3.medium instances, AWS will apply discounted rates for three instances and on-demand rates for two instances.
A region has multiple AZs: Regions and Availability Zones. AWS used to offer RIs in AZs, now they made it flexible by offering it in regions and you can convert the RIs. See: Amazon EC2 Convertible Reserved Instances and the Reserved Instance Regional Benefit
Capacity reservation is the capacity or the instance reserved for you. If you choose AZ based reservation, then capacity is guaranteed. ie., if you reserved a m4.large, you are guaranteed to get a m4.large for the entire reservation period - even if you stop the instance. Always a m4.large instance is set aside for you.
By choosing the region based reservation - which is flexible than the more rigid AZ based reservation - your capacity is not guaranteed. ie., if you reserved a m4.large, you are not guaranteed to get a m4.large for the entire reservation period - in case you stop the instance and start it after sometime or launch a new m4.large instance, your request can be denied because AWS may not have m4.large instance to fulfill your request.
Reserved Instances are more of a billing construct. If you have Reserved Capacity in an Availability Zone, you just need to provision your instance in that Availability Zone. If your Reserved Instance is set to Region, you just need to provision your instance in that region. When it comes to billing, it basically credits you for each instance that matches a reservation.
Check out How Do RIs Work for more information
I am about to take my AWS Architect Associate Certification Exam and I have some things on ELB and ASG that I still don't get (or maybe I just did not study enough) and I liked to ask your help to clear things out.
Multi-AZ Autoscaling Group
what difference does it make when I say I have one ASG that will handle
autoscaling for 3 AZs rather than have one ASG for each AZ? If fault tolerance
is the answer then the latter should be the standard setup, why have one ASG
for three or two AZs?
Multi-AZ ELB
same kind of question as I had for #1.
3.
Multi-AZ ASG and one ELB for each AZ
Multi-Az ASG and one ELB that serves multiple AZs
One ASG and One ELB for each AZ
What are the use cases for each?
The answer becomes more obvious when you think about the implications and understand what may be some missing details.
If an ASG crosses multiple availability zones, then it can increase capacity in the healthy zones when the instances in a catastrophically failed AZ become unavailable. With one in each, there would be no coordination like this.
The same thing is true for ELB. In both Classic and Application load balancers, when you deploy a single ELB in multiple AZs, you actually get balancer hardware allocated from the beginning in each AZ -- yet the price is the same. If an AZ fails, it fails, and you still have working hardware in the remaining zones.
ELBs and ASGs in a single AZ would not be fault tolerant, and there's no reason to provision separate ones for each AZ, when you can provision just one, and have it handle the failure of an entire availability zone (unlikely, but not impossible) by scaling out (deploying more hardware) capacity in the healthy zones that remain.
Recently I have purchased a reserved instance EC2 t2.medium.
There is no option to start and stop, whereas my freetire has all the features including stop, start, with public ip, etc.
Please Suggest me, how to use and work around reserved instance||
Reseverd instances are not started or stopped, they merely present the reservation of an on-demand instance at a reduced price. In order to use your reserved instance, you just need to have an instance of the same type as your reserved one already launched, or launch an on-demand instance of the same type and the reservation will be allocated to your instance. The only thing you need to make sure is that the servers will be started in the same availability zone as your reserved instance (for example - if your reserved instance is for us-east-1c AZ you have to choose the same AZ for your on-demand instance)
To make sure you are using the full amount of reserved instances at your disposal, you can check the reports section of your ec2 dashboard. the EC2 Reserved Instance Utilization reports will show you the amount of reserved instance being utilized.
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.
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.