Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am trying to clone/transfer an EC2 instance from one AWS account to another by creating an AMI on the first account and sharing it with the second account. Then I can use that AMI to start another EC2 instance (w/ the same data/setup/EBS volumes/etc.) on the second account.
I am having trouble locating the AMI image on the second account. I tried creating another AMI and listing it publicly, still can't find it from the second account.
How would I transfer or clone an EBS-based EC2 instance from one AWS account to another?
I think you can only share the image. The files are encrypted with your private account key, so you can't just move the files.
You could try migrating an AMI to the same region to see if it creates a new one: (but I doubt it)
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-MigrateImage.html
The big picture: You should NOT be manually creating AMIs. Use something like Chef, Puppet or Ansible to build your servers. This new breed of tools is declarative, so it's much easier than building with raw shell scripts. And it would make "rebuild under a different account" trivial.
I like to say:
Level 1: check your source code into version control
Level 2: check your server build script into version control
Level 3: check your "launch/manage my infrastructure" script into version control
Not sure its still actual... But you have to add destination's account number to the AMI permissions and than, if you check "Shared with me" checkbox, you should be able to create instance from that shared AMI image.
This might be bit late but you can achieve this by,
Give launch permissions for Account A for Account B's AMIs
Create you EC2 Client by using Account A credentials
Now, call DescribeImages method by filtering with ExecutableUsers parameter with self
This way you will be able to find the AMI images shared with your account by Account B. Keep in mind the AMI-Id will be different from Account B's AMI Id. Check the other Tag names to ensure the correctness of the image.
The process to clone/transfer/move an EC2 to another account includes:
Create a new AMI (Amazon Machine Image) from the source EC2 instance using the CLI command create-image in the source region.
Optional: Copy the AMI image to the target region using the copy-image CLI command. This process will take a while so check that copy was completed before you share the new AMI image or the process will fail. Depending on how close regions are and the size of an EC2 instance can take from 10 minutes to hours.
Share the AMI image with the AWS target account. AMIs are a regional resource, so to make an AMI image available in a different region, copy the AMI to the region and then share it. To share the AMI image, we need to use the modify-image-attribute CLI command.
Launch a new EC2 instance from the shared AMI image, using the run-instances CLI command.
The whole process is a little more complicated and involves up to 16 steps if you want to clone security groups, tag the instances and delete temporary AMIs.
I wrote a blog explaining all these steps in detail at https://medium.com/#gmusumeci/how-to-move-an-ec2-instance-to-another-aws-account-e5a8f04cef21
Guillermo
Create an AMI of the ec2 instance
Share the AMI with the accountid
In the 2nd aws account
-create instance, choose AMI (shared with me) you should be able to see the
shared AMI
-Launch instance
Related
We have an EC2 instance running in AWS EC2 instance. We have our ML algorithms and data that. We have also hosted a web-based interface also in that machine.
Now there are no new developments happening in that EC2 instance. We would like to terminate AWS subscription for a short period of time (for the purpose of cost-reduction and exploring new cloud services). Most importantly, we want to be in a position where we can purchase a new EC2 instance with a fresh AWS subscription, use the backup which we take now, and resume all operations (web-backend, SMS services for our app which is hosted in AWS, etc.).
What is the best way to do it? Is temporary termination of AWS subscription advisable?
There is no concept of an "AWS Subscription". AWS is charged on-demand, which means you only pay when you use resources.
If you temporarily do not want the Amazon EC2 instance, you could:
Stop the instance, which is like turning off the power. You will not be charged for the instance, but you will still pay for the disk storage attached to the instance. You can simply Start the instance again when you wish to use it. You will only be charged while the instance is running. OR
Create an image of the instance, then terminate the instance. This will create an Amazon Machine Image (AMI), which contains a copy of the disks. You can then launch a new Amazon EC2 instance from the AMI when you wish to use it again. This is a lower-cost option compared to simply stopping the instance, but it takes more effort to stop/start.
It is quite common for companies to stop Amazon EC2 instances at night or over the weekend to reduce costs while they are not needed.
EDIT: Just thought of a third option. Will test it and be back. Not worth it; it would involve creating an image from the EC2 instance and then convert that image to a VM image, storing the VM image in S3. There may be some advantages to this, but I do not see them.
I think you have two options, both of them very reasonably priced. If you can separate the data from the operating system, then your best option would be to use an S3 bucket as a file system within the EC2 instance. Your EC2 instance would use this bucket to store all your "ML algorithms and data" and, possibly, even your "web-based interface". Whenever you decide that you no longer need the processing capacity of the EC2, you would unmount the S3 bucket file system from the EC2 instance and terminate that instance. After configuring an appropriate lifecycle rule for the S3 bucket, it would transition to Glacier, or even Glacier Deep Archive [you must considerer the different options of long term storage]. In the future, whenever you want to work with your data again, you would move your data from Glacier back to S3, create a new EC2 instance, install your applications, mount your S3 bucket as a file system and you would have access to all your data. I think this is your least expensive and shortest recovery time objective option. To implement this option, look at my answer to this question; everything you need to use an S3 bucket as a regular folder inside the EC2 instance is there.
The second option provides an integrated solution, meaning the operating system and the data stay together, and allows you to restore everything as it was the day you stopped processing your data. It's made up of the following cycle:
Shutdown your EC2 and make a note of all the specs [you need them further down].
Export your instance to a virtual image, vmdk for example, and store it in your S3 bucket. Something like this:
aws ec2 create-instance-export-task --instance-id i-0d54b0682aa3998a0
--target-environment vmware --export-to-s3-task DiskImageFormat=VMDK,ContainerFormat=ova,S3Bucket=sm-vm-backup,S3Prefix=vms
Configure an appropriate lifecycle rule for the S3 bucket so that it transitions to Glacier, or even Glacier Deep Archive.
Terminate the EC2 instance.
In the future you will need to implement the inverse, so you will need to restore the archived S3 Object [make sure you you can live with the time needed by AWS to do this]
Import the virtual image as an EC2 AMI, something like this [this is not complete - you will need some more options that you saved above]:
aws ec2 import-image --disk-containers
Format=ova,UserBucket="{S3Bucket=sm-vm-backup,S3Key=vmsexport-i-0a1c382e740f8b0ee.ova}"
Create an EC2 instance based on the image and you're back in business.
Obviously you should do some trial runs and even automate the entire process if it's something that will be done frequently. I have a feeling, based on what you said, that the first option is a better option, provided you can easily install whatever applications they use.
I'm assuming that you launched an EC2 instance from a base Amazon Machine Image and then added your own software and models to it. As opposed to launched an EC2 instance from an AWS Marketplace offering.
The simplest thing to do is to create an Amazon Machine Image (AMI) from your running EC2 instance. That will capture the current state of the instance and persist it in your AWS account. Then you can terminate the instance. Later, when you want to recreate it, launch a new instance, selecting the saved AMI instead of a standard AMI.
An alternative is to avoid the need to capture machine state at all, by using standard DevOps practices to revision-control everything you need to recreate the state of a running machine.
Note that there are costs associated with an AMI, though they are minimal ($0.05 per GB-month of data stored, for example).
I had contacted AWS customer care regarding this issue. Given below is the response I received. Please add your comments on which option might be good for me.
Note: I acknowledge the AWS customer care team for their help.
I understand that you require some information on cost saving for your
Instance since you will not be utilizing the service for a while.
To assist you with this I would recommend checking out the Instance
Stop/Start link here:
==>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html .
When you stop an Instance, you do not lose any data & you are not
charged for the resources any further. However please keep in mind
that you will still be charged for any EBS Storage Volumes attached to
the stopped Instance(s).
I also recommend checking out the below links on how you can reduce
your costs.
==>https://aws.amazon.com/premiumsupport/knowledge-center/reduce-aws-bill/
==>https://aws.amazon.com/blogs/compute/10-things-you-can-do-today-to-reduce-aws-costs/
That being said, please note that as I am in the billing department,
for the best assistance with the various plans you will require the
assistance of our Sales Team.
The Sales Team will be able to assist with ways to save while
maintaining your configurations.
You will be able to reach the Sales Team here:
==>https://aws.amazon.com/websites/contact-us/.
Once you have completed the details in the link, a member of the team
will be in touch with you at their soonest.
I want to copy the EC2 instance that i have to one amazon account to another one account that i have now.At the first account,at the EC2 instance i am running a website.I want exactly the same website to be copied at the new account that i have,because my second account is for testing purposes and i want to do changes to the website without affecting the first account,the website that is online.I don't know very well of the Amazon services and how can i manage them,I ask for your understanding.Can i do this?And if i can do it,which are the steps? But if i can make a copy inside the first account,that has the online website,and testing this copy without affecting the main website again,is accepted and i can do it,just tell me how can i do this. Thanks in advance
The following AWS KB article describes the process. It's not possible to copy the instance, but you can create an AMI of the instance and share it with the other AWS account. Then you create another instance from that AMI in the other account.
https://aws.amazon.com/premiumsupport/knowledge-center/account-transfer-ec2-instance/
Stop Instance(if possible) and create AMI from it
Copy AMI from Account A to Account B .
launch Instance from AMI and you are good to go.
You can read about it here
Also, if you want to automate this then you can visit Botmetric
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.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have some machines created with my account. Some of them uses S3 storage, some EBS.
Now I need to move these machines to my company account to let it pay for.
As I know I can start each machine as my company user and create an image.
I wonder if there is a way to simple copy these machines?
You can copy an EBS boot AMI from one EC2 account to another using the technique I wrote about here:
Copying EBS Boot AMIs Between EC2 Regions
http://alestic.com/2010/10/ec2-ami-copy
The commands I list are for copying an EBS boot AMI from one region to another, but if you simply use the right commands with different accounts instead of different regions, you can accomplish your goal. Note that you'll have to upload your personal ssh key to both accounts following these instructions:
Uploading Personal ssh Keys to Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys
Copying S3 based AMIs from one account to another is a bit convoluted and involves commands like:
ec2-download-bundle
ec2-unbundle
(switch accounts)
ec2-bundle-vol
ec2-upload-bundle
ec2-register
Alternatively, you hopefully documented the exact steps you took to create the original AMIs. Simply follow these instructions to create the AMIs in the new account.
You can also share the AMIs with your other account. Then launch instances on the new account and create AMIs that will then be associated with the new account.