There is a image-type in describe-images filter, and an ImageType in response, however no information about what it stands for, and cannot find any information by googling.
There are three types: machine, kernel, ramdisk, what do they mean?
If you are just using AMI images provided by someone else, you can just ignore them -- you'll only need to use the AMI identifier when booting new instances.
A bit more detailed answer: The ramdisk image (ARI) and kernel image (AKI) are used as part of the boot sequence of a Linux instance.
More accurately:
Hardware virtualized (HVM) instances do not use ARI or AKIs at all. All of the boot sequence is part of the AMI itself. This includes both EBS and instance-store backed instance types.
Paravirtualized (PV e.g. running on Xen) EBS-backed instances need an AKI, and paravirtualized instance-backed instances need both AKI and ARI.
While AMIs are always unique, AKI/ARIs can be reused. For example, the aki-88aa75e1 kernel image is used by (in us-east-1, public images) by 5413 AMIs and the ramdisk ari-a51cf9cc by 683 AMIs. Both of these images are provided by Amazon and are thus trusted by others when they're building AMIs. Also if you bundle an instance-store/paravirtualized machine as an AMI it'll will inherit ARI and AKI from original AMI so many people publishing AMIs will implicitly re-use those.
Also note that Windows requires HVM, so ARI/AKI are not applicable to Windows instances at all.
Some links for more information:
https://forums.aws.amazon.com/thread.jspa?threadID=84096
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html
Related
I am having trouble fully understanding the differences between EBS Snapshots and AMI's in AWS. I understand how to create them and the terminology (Snapshots are backups of Volumes or the disk attached to an EC2 Instance and AMI is the backup of the full EC2 instance with snapshots at given time). But, I'm not sure what exactly is saved in the snapshot.
Assume I have an EC2 instance with LAMP stack installed on it and some data from the database. I understand the snapshot will save all my data and website files. When I create the new EC2 instance and attach the volume backed by my snapshot, do I then have to install Apache, MySQL, and PHP again? Or is that all saved in the snapshot? I am not worried about having to redo the security settings, instance type, etc for the new EC2 instance, but am worried all the configuration files are lost unless I have an AMI.
I understand how to create them and the terminology (Snapshots are backups of Volumes or the disk attached to an EC2 Instance and AMI is the backup of the full EC2 instance with snapshots at given time)
This is kinda correct, but not exactly. A better understanding of the concepts may help you in general, so here it goes.
A snapshot represents the state of an EBS volume at an exact point in time, taken atomically, that you can use to create other EBS volumes from. Those new EBS volumes, created from the snapshot, will start with the exact same content as the original EBS volume at the time the snapshot was taken. So, kind of a "backup of volumes").
One extremely important thing about Snapshots, though, that you seem to be missing based on the rest of your question, is that Snapshots are immutable. Once create, the contents of a snapshot cannot change, ever.
An AMI is an Image — it's used to create an instance from. It's a bunch of metadata, which includes the type of hypervisor required, accounts allowed to use it, and ultimately it contains a list of EBS Snapshots that should be used to create volumes, and where exactly to attach the volumes created from those snapshots.
So, while "creating an AMI" is indeed a strategy some people use to create a "backup of the full EC2 instance", it's not exactly the same thing.
When I create the new EC2 instance and attach the volume backed by my snapshot [...]
I think you're confusing some concepts here.
When a new EBS volume is created from a snapshot (either by you creating the EBS volume directly and selecting a snapshot, or by using an AMI, which implicitly means that EBS volumes are going to be created from the Snapshots as specified in the metadata that the AMI represents), there's no relationship between that snapshot and the new volume anymore. Any changes made to the volume are completely independent of the original snapshot. Remember: snapshots are immutable.
So, this notion of "the volume backed by my snapshot" may be quite unhelpful: there's no link between them.
Hoping this is clear, let's move on...
When I create the new EC2 instance [...], do I then have to install Apache, MySQL, and PHP again? Or is that all saved in the snapshot?
The software that will come pre-installed in the EC2 instance is defined by the contents of the snapshots used when the EBS volumes attached to the instance were created.
In other words, if you create an EC2 instance from a standard AMI (not one that you create) that doesn't come with the software pre-installed, then the software won't be installed.
If you create an AMI from your instance before you install the software you want, then the AMI (or, more precisely, the snapshots referenced by the AMI) won't have the software, so any instances created from that AMI won't come with the software.
Now, here's what you are probably looking for:
If you (1) create an instance, then (2) install the software, and only then (3) you create an AMI, in this order, then any new instances created from that AMI will come with the software pre-installed.
The easiest way to fully and truly understand this is to remember that (A) Snapshots are immutable, and (B) AMIs are immutable references to Snapshots.
All that said, while creating a custom AMI is indeed a completely valid and popular approach to the problem you are dealing with, there's another approach that's also completely valid and popular, but that is more flexible, and could be worth investigating.
Instead of having to create and manage AMIs (*), what you could do is use a user data script.
Essentially, what it does is it allows you to have a script, that will execute as root, on the first boot of a newly created instance. This script is often used to install software, update packages, download configuration files, etc.
This way, if you need to change versions of software, or change configuration files, etc, you don't need to go through all the complexity of managing AMIs. Instead, you simply update the script.
For more info on user data, check this out: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html
(*) "manage AMIs": remember that an AMI is an immutable set of metadata which includes reference to Snapshots, which are also immutable. So if you ever need to change some settings, or have new versions of the software be installed, you will need to create new AMIs. This could become something quite complicated and time-consuming. In fact, there's a ton of tools out there, some by AWS, some by other companies, that try to simplify the process of creating and managing AMIs. So just be aware that, while doable, valid, and popular, it's an approach that can get messy!
I'm bit confused about what purpose does the AMI serve.
Is AMI something which provides a platform with particular OS and other configurations to access the instance?
An Amazon Machine Image (AMI) is basically a copy of the disk that will be attached to a newly-launched instance. It is normally just the boot disk, but an AMI can actually contain multiple disk images.
The AMI is 'copied' to the disk of the newly launched instance. (Not quite accurate, but you can think of it that way.) Changes to the local disk do not impact the AMI.
AWS provides a number of AMIs with pre-loaded operating systems such as Windows, Amazon Linux and Ubuntu. Some of them contain additional software, such as Windows with SQL Server.
There are also community AMIs that are created by somebody other than AMI, but shared to all users. For example, a company might load a demo version of their software onto the AMI, so customers can simply launch an Amazon EC2 instance and it will have all software already loaded and configured.
An AMI is actually just a Snapshot, plus additional metadata. However, a Snapshot can only be restored to an Amazon EBS volume, whereas an AMI can be used to launch an instance. The Amazon EC2 service will then load the disk and attach it to the new instance.
It is pretty much what it's name implies - a machine image. There is, for example, a variety of Linux images. You can use an image to create a Linux instance. The AMI is not "used up" during the use - it can be used any number of times. There are also images that have an operating system such a Linux and software - for example a database server or a closed source server or pretty much anything you can imagine.
Think of the AMI as something you would use as the source for a copy machine. On the source paper there may be a little or a lot. The copier creates a new page that has whatever was on the source page. And you can make any number of copies.
Access to the instance varies on the AMI. A Linux one usually opens an ssh port while a Windows one usually uses some sort of remote desktop. The AWS console can guide you a bit but usually you'll need some documentation to know how to use the instance created from the AMI to know how to use it.
I know this has been asked before, but I have yet to find a workaround or solution for getting the list of possible instance types for a given Amazon AMI. I'm using the .NET SDK. Has anyone been able to figure out a way to do this?
This is not possible.
An AMI is merely an image of a disk. AWS can (usually) detect the Operating System of the AMI (eg Windows, Linux) but it has no knowledge of the software actually installed on the AMI.
In general, any instance type can be used for any AMI. The exception to this is the virtualization type -- some Linux AMIs might only run on PV (Paravirtualization) or HVM (Hardware Virtual Machine).
If you are launching an instance from an AMI provided by AWS, the EC2 Management Console is smart enough to ensure that the correct Instance Type is selected for the given virtualization type.
However, if you (or somebody else) created the AMI, there is no way to know the type of virtualization and therefore no way to know which instances would support it.
These days, the default is HVM, which is supported by all modern instance types (but not m1 for example).
Is there any reasons that AWS AMI are different based on the region?
For example, if I try to launch an EC2 instance in Frankfurt I Got this AMI:
Amazon Linux AMI 2015.03 (HVM), SSD Volume Type - *ami-a8221fb5*
While in Oregon:
Amazon Linux AMI 2015.03 (HVM), SSD Volume Type - *ami-e7527ed7*
Note the different ami-version: ami-a8221fb5 and ami-e7527ed7.
Is there any reasons?
And how can I build a cloudformation template that I can launch on both Frankfurt or Oregon without having to change the ami ?
The reason for different AMIs in different region is related to the fact that you have to have thet actual image available in the region to be able to launch instances. (if you didn't you would basically have to transfer it from where it would be mastered - a transfer between distant regions would take a long time - so it would take a long time to launch new ec2 instances).
in theory, I guess you could have the same image id across multiple regions but that would just make it confusing in case the image bound to the id is not the same. not to mention that you probably don't want to push it to all regions (inter-region traffic is not free).
the choice that ec2 made here to have different ids per region gives you the maximum amount of control and flexibility without a high price.
for launching machines via cloudformation, you can definitely parametrize it the way E.J. Brennan describes it.
You would use parameterized values, such as in this pretty good example:
You can use an input parameter to refer to a specific value in a map
by using the Fn::FindInMap function. For example, suppose you have a
list of regions that map to a specific AMI. You can select the AMI
that your stack uses by specifying a region parameter when you create
the stack.
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-input-conditional-parameters.html
I just pushed a tool to help create mappings for multiple regions (by looking up the corresponding AMI image ID for an image given a source AMI image ID and region). It's written in boto3. You may find it useful. https://github.com/codesolid/ami-lookup.
My instance is t1.micro on Ireland, eu-west-a1, in a VPC, connected to Elastic IP and a Load Balancer and under Termination Protection. Root device type: EBS, Root device: /dev/sda1
I started with t1.micro but now I want it m3.medium because we are going in production. The problem is that I stopped my instance, Actions -> Change instance type :
and the options that are available are only: t1.micro, m1.small, m1.medium, c1.medium.
Meanwhile on other instances I see that can change the instance type to any options.
What makes this instances different from the others, and how can I solve it
You have created the original Amazon EC2 instance with a 32-bit image - these are only available for the few instance types you mentioned and can not be upgraded to 64-bit instance types, I'm afraid you need to reinstall on a 64-bit instance type and migrate your data across.
See e.g. RakeshS' answer to How can I upgrade my 32 bit Amazon EC2 EBS backed instance into 64 bit one? for high level instructions how to manually migrate you data to a fresh 64-bit instance.
Please note that AWS has introduced 64-bit Ubiquity in spring 2012, i.e. every instance type can be used with 64-bit images, which (as you just painfully discovered) will make it easier for you to scale vertically (to larger and smaller instances) without having to maintain parallel (32 and 64-bit) AMIs indeed (see EC2 Updates: New Medium Instance, 64-bit Ubiquity, SSH Client for details).
I strongly agree with Eric Hammond's advise to only Use the Same Architecture (64-bit) on All EC2 Instance Types going forward:
Though t1.micro, m1.small, and c1.medium will continue to also support
32-bit AMIs, it is my opinion that there is virtually no reason to use
32-bit instances on EC2 any more.
This is fantastic news!
Sticking with 64-bit instances everywhere all the time gives you the
most flexibility to switch the instance type of your running
instances, reduces the choices and work necessary when building your
own AMIs, and just makes life simpler.