I wanted to take a pre-existing t2.medium EC2 instance and essentially clone it. Knowing no exact feature exists within AWS I scoured their documentation, asked people I know and came up with:
Create snapshot of said EC2 instance
Create AMI of snapshot
Build EC2 instance from AMI
When I went to build the new EC2 I was only given the option for a t1.micro OR m3.medium and above. I tried both (in and out of same region as original) and kept getting "insufficient data" under Status Checks.
Any ideas on what is going on here?
It sounds like you selected "paravirtual" as the virtualization type when you created the AMI, when you should have selected "hvm".
If you are doing this from the console you can create an AMI directly from the pre-existing EC2 instance, skipping the manual snapshot step, which should automatically use the correct settings for the AMI.
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 have 4 existing AWS EC2 instances that have been running well.
I changed the instance type on all of them at the same time and following the same process.
I went from t3.small to t3.large as well as the EBS type, going from gp2 to gp3.
It worked for 3 instances but 1 is now having this error:
EC2 can't retrieve the platform because the AMI was either deleted or made private.
I cannot SSH anymore with this instance nor "Connect" to it via the AWS Console, but it's still running well.
I tried reverting to t3.small, and launch the AWSSupport-TroubleshootSSH automation script, but none worked.
Any clues on how to fix this besides launching a new instance? Thank you!
In my workplace, we have a process of changing the EC2's AMI every month with the new patched private AMI.
Our internal operations team makes these patched AMI available for us as private AMI for EC2.
In our terraform script, we change the name of the AMI to the new one before executing the script via Jenkins.
However, we have noticed that after the script is executed EC2 instance is not affected by the AMI name change, we have to manually terminate each EC2 instance for the AMI change to take effect.
What I want to know is-
Is this a problem someone has faced before?
Is there a way to remove the manual termination of instance in Terraform OR is there a way in Terraform by which the changes will be taken cared of automatically?
The instances in ASG are not being updated with the new AMI because by default, only your launch configuration (LC) or launch template (LT) are updated with the new AMI. This does not automatically causes an update of the instances to use the new LC/LT.
However, since not too long ago, AWS has introduce instance refresh to combat this specific issue. Subsequently, this functionality was added to terraform and is configured using instance_refresh block of aws_autoscaling_group resource.
Thus, you could setup instance_refresh in your aws_autoscaling_group and specify what triggers it. Usually the trigger would be changes to the associated launch_configuration or launch_template.
I am using "MariaDB 10.0.10 on Ubuntu 14.04" on an m1.large instance. I am unable to update to m3.large due to the fact that it is unsupported by the AMI. How can I bypass this?
I have tried making an image directly from the instance. I tried making a snapshot from the volume then making an AMI from it. Both did not work.
Zed, since I can't comment, I'll let you know here AWS knows that the AMI is a MariaDB AMI because it's specified in the metadata.
Unfortunately, there isn't any way you can bypass this problem save by rebuilding that machine yourself. I'm sure there's a reason SkySQL Ab doesn't want their customers to use m3.large.
I am trying to downgrade our m1.small instance to the new t2.micro instance.
When the instance is stopped, and I try to change instance type, it will not display the t2.micro as an option.
I suspect it has to do with the new way the t2 instances virtualize (PV vs. HMV).
Anyone has an idea on how to perform the downgrade? Is it necessary to take a snapshot/image of the m1.small instance, and start a new t2.micro instance?
Here is a complete guide which you can use to change your existing PV instance to HVM instance. Just follow the steps carefully and you would be able to do it. Create an Image of your existing instance before you follow the guide
Okay, so after a few minutes of trying stuff in the AWS dashboard, I found the following solution. For anyone having the same problem, please perform the following steps:
create a snapshot of your PV-based instance (in my case, m1.small).
select your snapshot, and choose "create image". then, you can select the option to create a HMV-based image (which is needed for my case, as t2.micro only supports HMV).
Launch a new HMV-based instance (for example t2.micro) from your newly created image.
Hope somebody finds this useful! :-)
This does not seem to work, as the instance crashes when trying to be launched using the AMI.
Client.InstanceInitiatedShutdown: Instance initiated shutdown
Anyone has an idea on how to perform the downgrade / change PV->HMV?