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.
Related
I am looking to use CloudFormation templates alongside AMI's for which I installed and configured my software to simplify deployment of software setups to a handful of regions and maybe other AWS accounts.
One issue is that the AMI for creating EC2 instances must be in the region, and also the ID gets changed when copying it. Since this is only for a small number of deployments, and most of the images are not needed after the instance is created, I would like to avoid having to copy (and pay for) every image to every region just in case.
Instead is there some way to have my template copy the AMI (e.g. copy-image CLI ) and then use that with the Instance? Ideally it would also delete the AMI afterwards (e.g. deregister-image and delete-snapshot) where being used for persistent EC2 instances or on stack deletion/rollback.
we can take the back up of server which is running in AWS. that is called AMI.
How AWS handles our custom AMI ? where it will be stored ? can we access the Custom AMI Location ? I searched lot but could not get the answer. please let me know if there is any documentation about Custom AMI location. if it stored in S3 buckets can we see it ? or otherwise how can we know about out custom AMI.
An Amazon Machine Image (AMI) is stored in Amazon S3, but it is not directly accessible. Instead, you must use API calls or the Management Console to use an AMI.
The reality is that an AMI might actually contain content from other AMIs -- for example, if you launch an instance from a standard AWS-provided AMI, then add one file and create a new AMI, only the blocks that your instance changed would be stored -- the remaining (unchanged) blocks simply point to the original AMI content. This means that AMIs can often be quite small and you will not pay the cost of storing the complete disk. All of this is invisible to users.
You can see your 'custom' AMI in the AMIs section of the management console, or via the describe_images API call.
I use Apache Brooklyn 0.8.0-incubating to create d2.xlarge instance on AWS with the following Blueprint:
location:
jclouds:aws-ec2:
region: eu-central-1
...
provisioning.properties:
imageId: eu-central-1/ami-7bcddf17 # Redhat 6.6
hardwareId: d2.xlarge # with 2TB EBS
On the machine are only 10GB total storage. After some research I found the instance volume under /dev/xvdb unpartioned.
Can me anybody explain how I can use instance storage instead of creating a new volume for the machine on AWS?
Best Regards,
Felix
This is the expected behaviour for VMs in AWS EC2.
As described in http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/add-instance-store-volumes.html:
"After you launch the instance, you must ensure that the instance
store volumes for your instance are formatted and mounted before you can use them. Note that the root
volume of an instance store-backed instance is mounted automatically."
"the instance type determines which instance store volumes are mounted for you and which are available for you to mount yourself"
For your instance type, it looks like the instance store volume is attached unformatted.
The EC2 docs talk about running lsblk, mkfs and mount to format and mount the instance store volume.
Expected behaviour also depends on the AMI: "Each AMI has a block device mapping that specifies the block devices to attach to an instance when it is launched from the AMI. An AMI that Amazon provides includes a root device only."
Note that what you get working on one AMI might not work on all other AMIs (e.g. because of different block device mappings). Sticking with Amazon's own AMIs is often a good idea, for getting sensible default behaviour.
This could be automated in Apache Brooklyn. You have a few options for that:
Implement it in the entity, e.g. if using a SoftwareProcess entity then you could use the config key pre.install.command to execute the bash commands to set up the volume.
Implement it in the location.
This could use a new MachineLocationCustomizer to execute the commands on the machine (and then configure that on the location).
Alternatively, for jclouds locations you could use the setup.script configuration, which takes the URL of a shell script to execute.
Of those approaches, the MachineLocationCustomizer gives you the most power and flexibility.
as title, while I create CFN template, I always check EC2 console for AMI id in different regions.
these ids belong to the same spec image,
ex: all of them are "ubuntu 12.04 64 bit", but in various regions
is there any quick method to check this messages?
thanks a lot!
No, there is no method for identifying matching AMIs across different regions.
Some background...
An Amazon Machine Image (AMI) contains a disk image that is used to boot an Amazon EC2 instance. It is created by using the Create Image command on an existing Amazon EC2 instance, and can also be created from an EBS Snapshot (Linux only).
Each AMI receives a unique ID in the form ami-1234abcd.
AMIs exist in only one AWS region. When an AMI is copied between regions, it receives a new AMI ID. This means that the "same" image will appear with a different AMI ID in each region.
When an AMI is copied between regions, it will retain its name and description, but this is not necessarily unique, so it cannot be used to definitively match AMIs between regions.
AMI creators will often supply a list of matching AMI IDs across regions, for example: Amazon Linux AMI IDs
I'm trying to view an AMI shared from one of my amazon accounts with another amazon account and it's not visible. I've followed all of the instructions here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html
I've been able to share an EBS Volume successfully, but not the AMI. Are there any undocumented issues or steps anyone has run in to which might keep me from viewing the shared AMI?
Alternatively - is there a way to build an AMI from the snapshot?
It's possible that one of your accounts is set to a different region than your other. At least, that's what I just ran into.
AMIs don't cross regions - an AMI created in region A will never show up in any other region. You'll see this if your two accounts are in different regions, or even if you switch regions in one of your accounts.
There are two things you can do:
Just change regions in your target account. The AMI should magically appear - at least, it did for me. Easy, but unsatisfying, if you really like some other region.
In your source account, copy the AMI into the region that you'd like to use it from. Here are the official docs, but it's pretty straightforward. From the console, right-click the AMI, select Copy AMI, choose your region, and press the Copy AMI button. Wait until copied, then set permissions on the newly-generated AMI.
You'll have to wait, but at least you won't have to go through the song-and-dance that you used to.
You need to be in the correct region as well on the left hand side of the filter below launch there is a drop down menu that defaults the AMI's to "Owned by Me". Since you are in the destination account you need to select "Private Images"
All Amazon AWS AMI's are public and visible to all accounts. Are you talking about an AMI that you (or someone else) explicitly created following these steps:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami.html
If so, the instructions for sharing those are here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-sharingamis.html
(I'm not sure the difference between your link and this link. They seem... the same)
EBS Snapshots, which are not AMIs, can be shared with other accounts. The instructions for sharing EBS Snapshots with other accounts are here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
I don't know of any direct way to create an AMI from a snapshot. I don't think there is one.