Scenario
I currently have an EC2 instance with a root EBS volume attached to it of 30gb and i have some files stored in that EBS
If i delete the EC2 instance and have delete on termination false then EBS persists.
Desired outcome
I want to provision a new EC2 (provisioned by auto scaling group) instance such that it uses the old EBS volume as its root volume which was detached as a result of me terminating the old instance
Note
I want to have the liberty of choosing OS of newly provisioned EC2 so creating an AMI does not work
You cannot directly launch a new Amazon EC2 instance with an existing Amazon EBS volume. Instead, you would need to:
Launch a new Amazon EC2 instance with a new root volume
Stop the instance
Detach the root volume
Attach the 'old' EBS volume
Start the instance
Storing data in root EBS volume might be a bad idea to start with.
Consider one of the following:
Mount another EBS volume to the instance to store required data only.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html
best performance, highest cost/effort, but your application doesn't
change a bit.
Create EFS and mount it to your instances. https://docs.aws.amazon.com/efs/latest/ug/mounting-fs.html -
reasonable effort, minimal if any changes to the application.
Store data in S3. Ideal from price standpoint; requires changes to the application.
Related
We have a EBS volume from a previous T2 instance, which contains operating system, mysql installation, created users and all configurations.
For launching a new instance (T2), how to use
the pre-existing EBS volume as main bootable disk so that we have the operating system, apps and all configurations? This would save us days of time and efforts.
For a business application, should we choose T2 or T3?
As discussed you can perform the below steps to create an EC2 instance from a pre existing EBS volume.
Create a snapshot from the EBS volume.
Create an AMI from the same.
Look for the AMI in your private AMI.
Create the EC2 instance with desired instance-type from this AMI.
Also you need to care for the EBS volumes with this new EC2 instance with minimum EBS volume size etc.
Please let me know.
For some reason, I would like to restore my EC2 instance. But I don't have any snapshot of that instance. Also, I won't able to SSH login to Ec2 instances. What is the alternate way to change the system settings to default?
You cannot undo an instance termination or restore it without a snapshot. I suggest you enable termination protection on your EC2 instances to protect against accidental termination:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination
I found a way to roll back my instance to a restore default option by changing the root EBS Volume.
Steps to change root EBS volume.
1.stop the instance
2.Create a new EBS volume
3.Detach the existing root EBS Volume
4.Attach the new EBS volume with the device name "/dev/xvda"
5.start the instance"\
I understand that EBS volumes that are restored from snapshots need to be initialized.
Let's say I create an AMI from an EBS snapshot(s).
When I launch a new instance using that AMI, will I need to initialize each volume before I get consistent latency?
When you create an instance from AMI which has EBS based volumes as storage, your instance creates new volume from this volume and continues with launch.
When you use snapshots as source to launch your instance, AWS need to pull these snapshots and write it to volume and then continue with the launch. In this case, pull storage blocks from S3 and write to volume will be the latency some users want to avoid. This is the case where pre-warming is suggested by AWS.
I want to back up the root device (mounted at /) of my t2.micro instance running Ubuntu. I think the instance is EBS-backed as it is a t2 instance. So I was going to take snapshots of my root device to back it up.
However, it is recommended that I detach the root device before I back it up. There are two problems with this:
I have to use umount to unmount it first, which may cause my instance to crash. What is a safe way to handle this?
I want to run these backups as a cron job on the instance itself, but if my instance's root device is unmounted, will the cron job even run?
A more general question is: what is the best way to do this?
A possible solution might be: use AWS Lambda and execute a Lambda function based on a schedule executing the following commands by the use of the AWS SDK:
Stop EC2 instance
Create EBS snapshot
Start EC2 instance
First, I would confirm that your root device is in fact EBS backed.
Here are the basic steps to confirm:
To determine the root device type of an instance using the console
Open the Amazon EC2 console.
In the navigation pane, click Instances, and select the instance.
Check the value of Root device type in the Description tab as follows:
If the value is ebs, this is an Amazon EBS-backed instance.
If the value is instance store, this is an instance store-backed instance.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html#display-instance-root-device-type)
AWS states as a best practice is to use snapshots or a backup tool.
Regularly back up your instance using Amazon EBS snapshots or a backup
tool.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
AWS states in the documentation that root EBS volumes should be shutdown before taking a snapshot.
To create a snapshot for Amazon EBS volumes that serve as root
devices, you should stop the instance before taking the snapshot.
(Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)
So depending on your RPO (Recovery Point Objective), as a general rule it is a good practice to separate your data from your root volume. Store data that you need to keep on a separate EBS volume and take snapshots on the second EBS volume. This way you never have to worry about the instance itself - if it bonks out just launch a new instance and attach your snapshot.
If you have a special case that prevents you from using EBS snapshots, try using a role for your instance(s) that have permissions to read/write data to S3 buckets using your cron job.
I am trying to stop a Amazon EC2 instance and get the warning message
Warning: Please note that any data on the ephemeral storage of your instance will be lost when it is stopped.
My Question
What data is stored in ephemeral storage of an Amazon EC2 instance?
Basically, root volume (your entire virtual system disk) is ephemeral, but only if you choose to create AMI backed by Amazon EC2 instance store.
If you choose to create AMI backed by EBS then your root volume is backed by EBS and everything you have on your root volume will be saved between reboots.
If you are not sure what type of volume you have, look under EC2->Elastic Block Store->Volumes in your AWS console and if your AMI root volume is listed there then you are safe. Also, if you go to EC2->Instances and then look under column "Root device type" of your instance and if it says "ebs", then you don't have to worry about data on your root device.
More details here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html
Anything that is not stored on an EBS volume that is mounted to the instance will be lost.
For example, if you mount your EBS volume at /mystuff, then anything not in /mystuff will be lost. If you don't mount an ebs volume and save stuff on it, then I believe everything will be lost.
You can create an AMI from your current machine state, which will contain everything in your ephemeral storage. Then, when you launch a new instance based on that AMI it will contain everything as it is now.
Update: to clarify based on comments by mattgmg1990 and glenn bech:
Note that there is a difference between "stop" and "terminate". If you "stop" an instance that is backed by EBS then the information on the root volume will still be in the same state when you "start" the machine again. According to the documentation, "By default, the root device volume and the other Amazon EBS volumes attached when you launch an Amazon EBS-backed instance are automatically deleted when the instance terminates" but you can modify that via configuration.
To be clear and answer #Dean's question: EBS-type root storage doesn't seem to be ephemeral. Data is persistent across reboots and actually it doesn't make any sense to use ebs-backed root volume which is 'ephemeral'. This wouldn't be different from image-based root volume.
For EC2 instance
Stop & Start != Reboot
so for ephemeral storage (Instance Store)
Stop cause data lost
Reboot will not
According to AWS documentation [https://aws.amazon.com/premiumsupport/knowledge-center/instance-store-vs-ebs/] instance store volumes is not persistent through instance stops, terminations, or hardware failures.
Any AMI created from instance stored disk doesn't contain data present in instance store so all instances launched by this AMI will not have data stored in instance store. Instance store can be used as cache for applications running on instance, for all persistent data you should use EBS.
ephemeral is just another name of root volume when you launch Instance from AMI backed from Amazon EC2 instance store
So Everything will be stored on ephemeral.
if you have launched your instance from AMI backed by EBS volume then your instance does not have ephemeral.
refer: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes
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 any of the following
circumstances:
- The underlying disk drive fails
- The instance stops
- The instance hibernates
- The instance terminates