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.
Related
Consider I have installed a software in an Amazon EC2 machine, activated it successfully. Now I make this as an Amazon Machine Image (AMI) and then launch multiple instances.
How can the software identify that this is not the original machine where the product was activated?
Usually we use Hard disk, RAM and other hardware details to identify activation and then enabled the Software, but I am not sure how to proceed with Amazon images.
Each Amazon EC2 instance has an InstanceId in the form i-0c9c9b24b3583afdc.
These IDs are unique and are not reused.
For example, the cloud-init process that runs a User Data script no first boot uses this technique to determine when to run the script. It checks whether the script has run for the given Instance ID. If it has, then the script is not run again. If an AMI is made of the instance and a new instance is launched from the AMI, it notices that the Instance ID has changed and the script runs. So, it actually runs "once per Instance ID".
I have created a Windows EC2 instance on AWS, and I have loaded it up with all of my needed software. My intention is to use this instance to create an image, so that I can (in the very near future) load up a much more powerful instance type using this image, and run a bunch of computations.
However, I also need to have a centralized location to store data. So, I created an EFS drive on AWS, and now I am trying to connect my instance to the EFS using a symbolic link that will persist to every other instance I load up in the future. I want to eventually have an army of instances, all of which use the centralized EFS drive as their primary storage device so that they can all load and save data, which can then be used by other instances.
I've been running Google searches all morning, but I'm coming up empty on how to do this. Any resources or tips would be greatly appreciated.
Thanks!
EFS is basically a managed NFS server. In order to mount this to a Windows instance, you will need to find an NFS client for windows.
An alternative would be to mount the EFS to a linux-based instance, and export the file system using Samba which could then be mounted on your Windows instances. Doing this you would lose out on a lot of the benefits of EFS (your linux instance is a single point of failure, and for high-bandwidth requirements will be a bottleneck) but it might be possible.
You don't say what you are trying to accomplish, but I would suggest designing a solution that would pull data from S3 as needed. That would also allow you to run multiple instances in parallel.
I have a php/mysql website that I want to deploy on AWS. Ultimately, I'm going to want auto-scaling (but don't need it right away).
I'm looking at an EBS based AMI. I see that by default the "Root Device Volume" is deleted when an instance "terminates". I realize I can also attach other EBS devices/drives to an instance (that will persist after termination) but I'm going to save most user content in S3 so I dont think that's necessary. I'm not sure how often I'll start/stop vs when i would ever want to terminate. So that's a bit confusing.
I'm mostly confused with where changes to the system get saved. Say I run a YUM install or update. Does that get saved in the "root device volume"? If i stop/start the instance, the changes should be there? What about if I setup cron jobs?
How about if I upload files? I understand to an extent that it depends where I put the files and if I attached a second EBS. Say I just put them in the root folder "/" (unadvised, but for simplicity sake). I guess that they are technically saved in the "root device volume"? If I start/stop the instance, they should still be there?
However, if I terminate an instance, then those changes/uploads are lost. But if I set the "root device volume" to not delete on termination, then I can launch a new instance with the changes there?
In terms of auto-scaling. Someone said to leave the "root device volume" to default delete so that when new instances are spun up/shut down, they don't leave behind zombie EBS volumes that are no longer needed (and would require manual clean-up)?
Would something like this work: ?
Setup S3 bucket (for shared image uploads)
Setup Amazon RDS / mysql
Setup DynamoDB (for sharing php sessions)
Launch EBS-backed AMI (leave as default to delete "root device volume" on
termination). Make system updates using yum/etc. Upload via sftp
PHP/HTML/JS/CSS files (ex: /var/www/html). Validate site can save
images to S3, share sessions via DynamoDB, access mysql via RDS.
Make/clone your own AMI image from your currently running/configured
one. Save it with a name that indicates site version/date/etc.
Setup auto-scaling to launch the image created in #5
I'm mostly concerned with how to save my configuration so that 1) changes are saved in-case i ever need to terminate an instance (before using autoscale) and 2) that auto-scaling will have access to the changes when I'm ready for it. I also don't want something like the same cron-job running on all auto-scaling instances.
I guess I'm confused with "does creating my own AMI image in #4" basically replace the "saving EBS root device volume" on termination? I can't wrap my head around the image part of things vs the storage part of things.
I get even more confused when I read about people talking about if you use "Amazon Linux" then the way they deploy updates every 6 months makes it difficult to use because you are forced to use new versions of software. How does that affect my custom AMI (with my uploaded code)? Can I just keep running yum updates on my custom AMI (for security patches) and ignore any changes to amazon's standard AMIs? When does the yum approach put me at risk for being out-of-date?
I know there are a host of things I'm not covering (dns/static IPs/scaling metrics/etc). That instead of uploading files then creating an AMI image, some people have their machine set to pull files from git on startup (i dont mind my more manual approach for now). Or that i could technically put the php/html/css/js on S3 too.
Sorry for all of the random questions. I know my question might not even be totally clear, but I'm just looking for confirmation/advice in-general. There are so many concepts to tie-together.
Thanks and sorry for the long post!
Yes, if you install packages, upload files, set up cron jobs, etc. and then stop the EBS-based instance, everything will still be there when you restart it.
Consequently, if you create an AMI from that instance and then use it for your autoscaling group, all the instances of the autoscaling group will run the cron jobs.
Your steps look good. As you are creating an AMI, your changes will be saved in that AMI. If the instance is terminated, it can be recreated via the AMI. The modifications made on that instance since the AMI creation will not be saved though. You need to create an AMI or take a snapshot of the EBS volume if you want a backup.
If you make a change and want to apply it to all the instances in the autoscaling group, you need to create a new AMI and apply it to your autoscaling group.
Concerning the cron jobs, I guess you have 2 options:
Have 1 instance that is not part of the autoscaling group running them (and disable the cron jobs before creating the AMI for the autoscaling group)
Do something smart so only one instance of the autoscaling group runs them. Here is the first page I hit on Google: https://gist.github.com/kixorz/5209217 (not tested)
Yes, creating your own AMI image basically replaces the "saving EBS root device volume" on termination.
An EBS boot AMI is an EBS snapshot of the EBS root volume plus some
metadata like the architecture, kernel, AMI name, description, block
device mappings, and more.
(From: AWS Difference between a snapshot and AMI)
Yes, you can automatically run yum security updates. To be completely identical to the latest Amazon Linux AMI, you should run all yum updates (not only security). But I wouldn't run those automatically.
Let me know if I forgot to answer some of your questions or if some points are still unclear.
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
i'd like to have a remote PC where i could install Visual Studio & other softwares that it would be permanent
all i've tried for now is volatile so i can't reinstall everything every time i want to use the remote PC.
i've searched online but all solutions talked about EBS (Elastic Block Store)
i even went to http://aws.amazon.com/ebs/ but i can't find EBS in the AWS panel...
where can i get EBS? or is there another way to get a permanent Windows on EC2?
thanks
Jeff
When you launch an EC2 instance you get a root volume (c:) on EBS by default, it would only be transient if you are using instance storage. To check that, verify the "root device type" property of your Windows image (AMI).
Additional EBS or Instance Store volumes can be added in the "Add Storage" section of the launch wizard.
You can also create an image from the existing instance (Actions > Create Image) and then launch it as many times as you'd like.
Additionally, for persistent desktop sessions, check Amazon Workspaces.