Installed SW on EBS or Instance Store? - amazon-web-services

I have launched an ec2 RHEL instance and have attached EBS volume to it.
How do I know when I access data from /tmp or /opt or any other directory, whether the data is accessed from Instance Store or EBS?

The t2.medium instance type (mentioned in comments) does not include instance store volumes. You can review all instance types with instance store volumes here. In addition when launching instances with instance store volumes these aren't your root volume and are just available storage you can mount as an additional disk on the instance. For example if you launch a M5d.large instance, by default your instance store NVMe drive is available at /dev/nvme1n1 in linux, but is not used at launch time. You can format and use the instance store volume as you please, after launch.

Related

AWS launch new instance using Ubuntu 22.04: image has more volumes than instances allows

AWS launch new instance using Ubuntu 22.04:
The selected AMI contains more instance store volumes
than the instance allows. Only the first 0 instance
store volumes from the AMI will be accessible from the
instance
What does it mean? does an AMI have volumes?
EC2 instances can have two basic types of volumes: EBS (Elastic Block Store) and Instance Store. This article spells out the differences, but in a nutshell, EBS volumes are network attached storage that are independent of an instance, while Instance Store volumes are local block storage volumes that are not persistent (e.g. when the instance is terminated, the instance store volume is lost).
You ask if an AMI has volumes. An AMI basically is one or more volumes. The AMI is a snapshot of a disk in a particular state. These days, most modern AMIs use EBS storage for the root volume; that is, the volume that contains the operating system kernel that an instance boots from. It used to be commonplace to use Instance Store for the root volume, but EBS has become nearly as fast, more secure, and more reliable than Instance Store, so the use cases for Instance Store volumes are dwindling.
With all that said, I'm quite surprised that you're seeing this error. The error message suggests that the AMI includes Instance Store but the instance type you selected does not support Instance Store (many instance types do not). However, all Ubuntu 22.04 AMIs use EBS, not Instance Store. If you use the Ubuntu Amazon EC2 AMI Locator and search for "22.04", you'll find that all of the results have hvm:ebs-ssd as the instance type. Only very old Ubuntu AMIs have Instance Store volumes.
Make sure you are using the AMI Locator to find the Ubuntu 22.04 AMI. Those AMIs should work with most or all EC2 instance types.

AWS EC2 how to use pre-existing EBS volume as main bootable disk?

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.

AWS EC2: AMI vs instance type EBS selection

While creating EC2 instance on AWS, I see following AMI options:
Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type
macOS Monterey 12.2.1 - ami-00aa9c0d2393d0139 The macOS Monterey AMI is an EBS-backed, AWS-supported image
First option tells that disk storage is SSD volume type which I assume means that storage used is instance's local storage. Second option tells that storage is elastic block storage.
I opt for first one.
Then on next step for instance type:
Why does it displays 'EBS only' for 'Instance Storage(GB)' column as in previous step I opted for non-EBS type? Are those unrelated?
An AMI will always restore to an EBS volume (or multiple EBS volumes). An AMI is really just a snapshot of one or more EBS volumes, plus some metadata. EBS volumes can be SSD or Magnetic. Your assumption that "SSD Volume Type" indicated local instance storage is incorrect.
Instance storage is ephemeral. An EC2 server never boots from an instance storage volume. Certain instance types come with instance storage that are good for things like fast temp folders, caches, etc. But instance storage volumes can't be saved to snapshots or AMIs, can't be persisted across stops/start cycles, and can't be moved between EC2 instances.

Swap space using instance-store in HVM EBS AMI in AWS

On AWS EC2, if we launch and AMI with instance-store, we can attach EBS volume for persisent store. Is the vice-versa possible.
ie.,
Can we add instance-store volume when launching a EBS HVM AMI, the reason behind this is to use it as a swap.
I can't see the option to add Instance store on Storage Configuration, while launching a EBS backed instance.
Please let me know, if there is a method to achieve root volume as EBS and swap volume as instance-store.
many thanks,
Shan
If you are launching an instance class that includes instance store (ephemeral) disks, those should be accessible from Storage Configuration, as in this example, where the instance class provides two ephemeral disks.
See Instance Storage in the EC2 documentation to confirm whether the instance class you're launching includes instance store volumes. Some classes do not, and where that is the case, you can only select EBS as the Volume Type.
If you're launching from an AMI that already contains references to the ephemeral disks, you should see something like this screen shot. If it doesn't include references to the instance store volumes, you can use Add New Volume to include the desired instance store volumes with the new instance. Their sizes are fixed by the specs of the instance class, which is why Size says N/A. Since they are provided at no charge, you should always attach them at launch, even if you have no plan for them, because they can't be added after launching.
AMIs can't be edited, so if you want these included automatically on future launches, you'll need to build a new AMI, which you'll probably also want to be configured (within the OS boot sequence) to create and mount the desired swap space.

What data is stored in Ephemeral Storage of Amazon EC2 instance?

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