I have t1.micro (PV) and I am trying to update (resize) to t2.medium (HVM).
However, when I created AMI from t1.micro and tried to attach to t2.medium, I did not get instance under list. So could not attached AMI to t2.medium.
So may I know how can I attached AMI to new instance from EC2 Console? Also, how can I take care of SSH , SSL , Cron , multi domains while migrating?
Resource I refereed: http://www.nixhat.com/2014/01/migrate-aws-pv-to-hvm-instance/
Thanks
I think you are misunderstanding the directions on that page. Let me highlight part of it.
Launch any HVM based centos.
Create a volume snapshot from your PV based instance
Attach the snapshot to the HVM
Copy kernel and other boot files from HVM to PV snapshot volume
Stop the instance
Detach root disk from HVM
Attach the PV snapshot to the instance as root device
Launch the instance
Note you are not attempting to launch your PV instance on a t2 machine, you are launching a new HVM instance. You are responsible to find and copy any configuration that you've changed, such as crons and configuration.
Note this question goes against the principle of "treat your servers like cattle, not pets". It appears you don't have a way to recreate your server/configuration from scratch, which should be a red flag- instances go down, people accidentally break their configuration, and so on.
Related
Is it not possible to create an EC2 instance from a snapshot in AWS?
I tried to create volume, but then i was stuck starting an EC2 instance with that volume. Should that not be an easy process? I don't even know, if this way is correct. I am just guessing.
What steps are necessary to create a EC2 instance only from the snapshot?
"create ec2 instance from snapshot"
Your almost there. The option is called "Create image". So:
Go to your snapshot.
Right click and choose "Create image" (assume the volume is bootable and it works).
Fill out the info required.
Image (aka AMI) will be created based on your snapshot and the info you will provide.
Launch an instance from the AMI.
More details in Create a Linux AMI from a snapshot.
I am trying to shrink the root volume of an AMI (ami-0a6b7e0cc0b1f464f) in us-east-1 region. The shrinking itself is successful i.e. I have created a smaller snapshot which works correctly. But when I create an AMI from this snapshot, the instances of that AMI does not have ENA (Enhanced Networking with the Elastic Network Adapter) enabled in it.
Below are the high level steps I performed.
Created a new instance t3.micro and ensured that ENA is enabled in this instance.
Created a new snapshot of the root volume - "source" and a shrunken volume - "target".
Copied all files and partitions from source to target volume.
Created a snapshot of the target volume. Created an AMI from this snapshot. Tried to launch a t3 instance which I cannot because ENA is not enabled.
As per AWS Docs
Amazon Linux 2 and the latest versions of the Amazon Linux AMI have the module required for enhanced networking installed and have the required enaSupport attribute set. Therefore, if you launch an instance with an HVM version of Amazon Linux on a supported instance type, enhanced networking is already enabled for your instance.
So if I am using Amazon Linux 2, and I am taking a snapshot of a volume that has all files copied from its previous volume, why is ENA not enabled? Probably networking components are applied some other way so simple copy does not work?
I still don't know the logical reasoning behind this, but the way I successfully produced an AMI which has ENA enabled is by:
First creating a target volume as mentioned in my question.
Then to stop and detach all volumes (including the root volume) from the EC2 instance that I used to create the target volume. Note that this instance had ENA enabled.
Attach the target volume as root and start the EC2 instance. Since the target volume contains the same files as root, the ec2 instance should have no issues starting up. What we essentially did here was to swap the root volume with target volume.
Verify ENA is enabled on the machine, and your volume size is shrunk. Then create an AMI from the running instance (right click -> image -> create image).
So if I am using Amazon Linux 2, and I am taking a snapshot of a volume that has all files copied from its previous volume, why is ENA not enabled? Probably networking components are applied some other way so simple copy does not work?
You can consider AMI as a definition file which includes information about ENA. Snapshots do not know about AMI, they are 'storage'. Yes, they may include a file system, OS, drivers etc but that's not necessarily including the information AWS need to give you what you want == ENA enabled networking. The solution is actually simple. When you are creating an AMI, you tell AWS to enable ENA. As an example if you are using AWS cli to register an image, simply add --ena-support as in
aws ec2 register-image --ena-support ...
Now, AWS does say that if you create an AMI from an instance has ENA enabled, they will automatically infer this information from running instance. However, that's different than using a snapshot to create the image. It worked for you finally b/c you had a running instance with ENA drivers installed and AWS was able to detect it.
I want to create an AWS AMI with t2.micro - CentOS 7 with my custom app and other configs
Create an AMI out of it and then launch with "r4.2xlarge" or "r4.xlarge",
is it possible?
Yes, it is possible. Instance type used for creating the AMI is not imposed when Creating new Instances using the Image. But
If you customized your instance with instance store volumes or EBS
volumes in addition to the root device volume, the new AMI contains
block device mapping information for those volumes. When you launch an
instance from this new AMI, the instance automatically launches with
those additional volumes.
I have received an email about an EC2 instance that is to be retired on the 1/12/2015. I can provide more details on the case if need be. I have gone through this process before (approx a year ago), and it all went smoothly. The only difference this time is in the instructions. Last time, according to the instructions, all I had to do, was just restart my instance. Now, I have to create an AMI from my instance, and launch a new instance with that AMI. Please, note that in both cases my instances were/are EBS backed.
Do I really need to create an AMI and launch a new instance or just restarting the instance would do? Please, keep in mind, that I need to keep my EBS data intact.
Cheers,
Iraklis
From the AWS EC2 documentation:
Managing Instances Scheduled for Retirement
You can perform one of the actions listed below in order to preserve
the data on your retiring instance. It's important that you take this
action before the instance retirement date, to prevent unforeseen
downtime and data loss.
Warning If your instance store-backed instance passes its retirement
date, it's terminated and you cannot recover the instance or any data
that was stored on it. Regardless of the root device of your instance,
the data on instance store volumes is lost when the instance is
retired, even if they are attached to an EBS-backed instance.
An instance is scheduled to be retired when AWS detects irreparable
failure of the underlying hardware hosting the instance. When an
instance reaches its scheduled retirement date, it is stopped or
terminated by AWS. If your instance root device is an Amazon EBS
volume, the instance is stopped, and you can start it again at any
time. Starting the stopped instance migrates it to new hardware. If
your instance root device is an instance store volume, the instance is
terminated, and cannot be used again.
Instance Root Device Type: EBS
Action: Wait for the scheduled retirement date - when the instance is
stopped - or stop the instance yourself before the retirement date.
You can start the instance again at any time. For more information
about stopping and starting your instance, and what to expect when
your instance is stopped, such as the effect on public, private and
Elastic IP addresses associated with your instance, see Stop and
Start Your
Instance.
Instance Root Device Type: EBS
Action: Create an EBS-backed AMI from your instance, and launch a
replacement instance. For more information, see Creating an Amazon
EBS-Backed Linux AMI.
Instance Root Device Type: Instance store
Action: Create an instance store-backed AMI from your instance using
the AMI tools, and launch a replacement instance. For more
information, see Creating an Instance Store-Backed Linux
AMI.
Instance Root Device Type: Instance store
Action: Convert your instance to an EBS-backed instance by
transferring your data to an EBS volume, taking a snapshot of the
volume, and then creating an AMI from the snapshot. You can launch a
replacement instance from your new AMI. For more information, see
Converting your Instance Store-Backed AMI to an Amazon EBS-Backed
AMI.
Seems selecting t2.micro for an ElasticBeanstalk instance throws Beanstalk into an infinite loop. Been an hour since creating the Beanstalk instance, 20min since the last event update in the Beanstalk management console.
Does anyone know how to kill a Beanstalk instance deploy?
Turns out this is what happens when you try to take a t1 (ParaVirtualization) AMI and deploy it on a t2 (HVM) ElasticBeanstalk instance. The Beanstalk instance failed/retried for about an hour and a half before it finally errored out.
for me i used the t1.micro but once this resources was too weak for the pipeline i had to change it to the next cheapest thing, m3.medium, you can use the link to compare prices (its already selected on the relevant instances just press compare)
the thing is you have to use HVM instance and not all instance families are HVM
you can see this table of Amazon AMI Instance Type Matrix:
https://aws.amazon.com/amazon-linux-ami/instance-type-matrix/
Instance Family:
1. HVM EBS-Backed 64-bit
2. HVM Instance Store 64-bit
3. PV EBS-Backed 64-bit
4. PV Instance Store 64-bit
and for cost you can look here:
http://www.ec2instances.info/?selected=t1.micro,m3.medium,c3.large,r3.large