I am investigating disaster recovery for an RDS database.
If I want to use a snapshot or point-in-time recovery for my DB instance, naturally a new instance is created.
My instance is a reserved instance, would the resulting instance also be a reserved instance or an on-demand instance? Or can I make the new instance use the reserved instance and then delete the old one?
Reservations aren't tied to specific servers. Your current server isn't really a "reserved instance". It is simply an instance that matches your reservation, thus you are being charged less. If you removed it and created another server that matches your reservation, you would get the price discount on the new instance.
Related
I am currently running an instance on a reserved instance.
That instance now I dont want to use but I want to still not lose that instance. Just shutdown.
How can I move the reserved instance that I paid long term to a newly created instance ?
Thanks.
From docs:
Reserved Instances are not physical instances, but rather a billing discount that is applied to the running On-Demand Instances in your account. The On-Demand Instances must match certain specifications of the Reserved Instances in order to benefit from the billing discount.
So you can terminate your current instance and if the new one match with your reserve (instance type, region, etc) then the reserve is applied automatically.
I have a an Ubuntu-14.04 EC2 instance running with EBS volume
I regularly take snapshot
I launched a new instance Ubuntu-16.04.
I detach the root volume
I created a EBS volume from snapshot above
I re-attached the volume.
I see all the data and my servers seem to work on the new instance. For eg. mongo, app servers etc.
My question is (other than app data):
What are the differences between the new instance and the instance launched via an existing EBS?
Is the existing-EBS-launched instance supposed to work like the old instance without any changes, out-of-the-box?
What are the differences between the new instance and the instance launched via an existing EBS?
Answer- first of all, understand what EBS is, in a simple language, it is a block storage volume for use with Amazon EC2 Instance.
So Whenever you launch a new Instance via an existing EBS, all the stuff/ any manual changes on the disk which you have done previously will be automatically reflected in your new Instance, as you are using the same disk (Block Storage). It's just when you want any kind of modification like wants to change the key pair at that time we detach the volume, do the modifications and again attach the volume (disk).
Is the existing-EBS-launched instance supposed to work like the old instance without any changes, out-of-the-box?
Answer- yes Existing EBS launched instance work as the old instance, its just what kind of modification you have provided to the new instance. Suppose while launching you have changed the Type of instance, key pair, attach different security group. So all these changes will be reflected and all the manual operations done on Disk will remains same.
I have a small query on AWS Auto Scaling.
For auto scaling group, we need to set minimum (1 server) and maximum no of instances to scale.
Question:
Lets assume, I already have a reserved instance running 24x7.
I will create an AMI of the reserved instance and use this AMI for auto scaling.
I want to make this reserved instance as part of auto scaling group (this become my minimum 1 server in the auto scaling group).
But I don't want this reserved instance to terminate at all (as I have my elastic IP taken for this) when I scale down, but other instances can terminate as the load comes down.
How can I achieve this?
Kindly suggest.
Thanks in advance.
Instances reservations are not tied to a specific EC2 instance. As long as you have an instance running that matches your reservation, you will be charged the reservation's hourly rate.
This reserved instance should not be in the auto-scaling group. You only want it to be in the instances used under the Elastic Load Balancer. The auto-scaling group should only contain instances that are dynamic.
You can set this instance under the load balancer and it will never be terminated.
Remember to set the auto-scaling group minimum to zero, so when the load is low on the reserved instance, the auto-scaling group would call the decrease instance policy, and you would lessen the charges.
The concept of a Reserved Instance is always confusing.
A Reserved Instance is a pre-payment for a certain capacity (Instance Type, OS, optional AZ). For example, let's say you purchase a 1-year Reserved Instance for an m4.large Linux instance. This means that, for every hour of the year, you can run an m4.large Linux instance at no hourly charge, because you have pre-paid it annually or monthly.
Please note that you do not choose which instance receives this billing benefit. Rather, each hour of the year, if an instance is running that matches the Reserved Instance purchased, it is not charged for that hour.
Therefore, you can't really say things like "I want to make this reserved instance as part of auto scaling group" or "create an AMI of the reserved instance" because you have no knowledge nor control over which instance receives the billing benefit. Simply be happy in the knowledge that an instance running that matches the Reserved Instance will receive the benefit.
So, if you have one Reserved Instance and you are running at least one EC2 instance of the matching Instance Type and OS in a given hour, then one of those instances will not receive an hourly charge. It doesn't have to be a specific instance that you nominate.
Side-note: Stopping and Starting an instance triggers a new billing hour. Only one hour is not charged each hour per Reserved Instance purchased. So, if Auto Scaling launching an instance, terminates it, then launches another within the same hour, there will be a charge. Only the first billable hour per Reserved Instance owned will be "not charged".
(I recall seeing something that said that the Reserved Instance benefit is typically applied to the instance with the earliest Launch Time and that if it is stopped/terminated, the benefit goes to the instance with the next earliest Launch Time -- but that might not be accurate.)
Last night there was an error on my EB instance. The instance was removed and a new one was added. Because of that I lost data from the non-persistent instance storage. I don't have a backup / snapshot. A big beginner's mistake.
My question: Is there any chance to recover the instance's data from 12 hours ago? Maybe with the help from the AWS staff?
When an instance is stopped or terminated, the ephemeral volumes are gone. Terminating an instance releases the hardware for use by another customer. Stopping an instance does the same thing -- that's part of why you don't pay for stopped instances. The same instance will actually come up on physically different hardware if stopped and started.
Aside from the documentation...
The data in an instance store persists only during the lifetime of its associated instance. If an instance reboots (intentionally or unintentionally), data in the instance store persists. However, data in the instance store is lost under the following circumstances:
The underlying disk drive fails
The instance stops
The instance terminates
Therefore, do not rely on instance store for valuable, long-term data.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
...there are also numerous support forum posts on this topic, with responses by AWS personnel, indicating that the answer is "no."
Here's one example:
Once an instance that has Ephemeral (or Instance Store) volumes has been Stopped or Terminated, we are unable to recover the data that was on that volume. When you Stop or Terminate such an instance, those volumes are securely wiped and this is to ensure the security and confidentiality of your data that was on that volume.
This is as per: http://aws.amazon.com/instance-help/
And: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
https://forums.aws.amazon.com/thread.jspa?messageID=501815񺠷
And another:
Ephemeral (instance-store data) is the local host's hard drive and when an instance is migrated (moved) to new hardware (from a stop/start) the ephemeral data is scrubbed as part of the process as the instance will have new ephemeral storage as part of the new host.
All that said, there is not any way to get the data back from the ephemeral location.
https://forums.aws.amazon.com/thread.jspa?messageID=396680񠶈
We’ve purchased an Amazon Web Services (AWS) reserved instance for an Amazon Elastic Compute Cloud (EC2) instance that is critical to our infrastructure. This instance starts and stops every day at certain time interval.
I see that purchasing a reserved instance 'guarantees' that this instance will reliably start even when AWS is under heavy load, but is there any way to specifically tie this reserved instance to the instance we want to associate with it?
What happens if we add another instance that matches the exact criteria of the reserved instance we’ve purchased?
You don't need to worry or do anything in associating the instance and the purchased Reserved Instance; all those are done automatically by AWS.
The reserved Instance is purely a billing and cost related and it doesn't relate to the technology aspect of an EC2 instance. If any of your running instance matches with any of your purchased Reserved Instance then you benefit from the reduced costing. There isn't any commitment on the SLA or changes at the Instance level which involves Reserved Instance. The same case works when you have 2 reserved instances; if there 2 instances running in your account which matches your reserved instance purchase they the reduced cost would be applied.
Analogy - Super Market Coupon Offer
If the Offer Says, buy 2 units of Product A and get one Product B
absolutely Free. So you look into the offer and take 2 units of
Product A and one Unit of Product B. During the billing as well, the
Point of Sales Person also doesn't look into each and every product
and try to check it offers; rather he or she directly keeps scaning
each and every product against the bar-code scanner and that't it -
when these 3 are scanned, the price for Free-Product is automatically
reversed.
So similarly, you buy the Reserved Instance (Coupon) choosing the AMI,
Region, AZ, Duration etc. You would do all your tech stuff as usual
like deploying, patching, monitoring etc. During the billing, if the
instance(s) you launched matches the Reserved Instance, then the
Reserved pricing would be applied; if not that would be charged at
'On-Demand-Pricing'.
If there is a mismatch between what instance you are running and what instance you have reserved; you will not be using the benefit of Reserved-Instance pricing
and be charged with On-Demand-Pricing. Also you will be wasting the
investment done for the Reserved-Instance
As implied in Naveen's answer, there is no direct way to associate an instance with a reservation.
If you want the reliability, then you must launch instances with unique set of properties (instance type, az and AMI). There is no other way at the moment.
This is supposed to be a comment in Naveen's reply. But as I had no reputation yet to commen, I am adding it as an answer.