359

I have an Amazon EC2 micro instance (t1.micro). I want to upgrade this instance to large.

This is our production environment, so what is the safest way to do this?

Is there any step by step guide to do this?

Andrew Koster
  • 1,550
  • 1
  • 21
  • 31
gandil
  • 5,398
  • 5
  • 24
  • 46
  • With EBS root device or with the instance store? – stivlo May 05 '11 at 13:19
  • I think ebs root device. I see EBS under Root Device Menu item on aws console. – gandil May 05 '11 at 13:24
  • 2
    Did any of you consider the fact that a t1.micro, m1.small etc can be 32 bit architecture and that a large instance is 64 bit arc ? Will it not cause any problems ? As of now, I think we will have to do everything again (create a new large instance and install all the application again) ? Is it not the case when there is a change in architecture ? – M-D May 27 '12 at 04:24
  • 1
    That just bit me in the a**. Last time I will choose 32 bit for anything. Now we have a server that needs more memory that 4gb and the 32 bit architecture can't handle it. If fact in the Amazon Control Panel in EC2 there is no option to launch to a large type, it only goes up to medium. – Tom Gruner Jun 28 '12 at 16:04
  • 4
    Why the question is flagged as *off topic*? Its a valid helpful question with acceptable answers. – UsamaAmjad Nov 08 '18 at 22:44
  • My edits got approved, and yet here the question is, still stuck in "off topic" purgatory. Can anyone explain what is required to bring it "on topic"? – Andrew Koster Aug 19 '21 at 00:29

5 Answers5

521

Using AWS Management Console:

  • Right-Click on the instance
    • Instance Lifecycle > Stop
    • Wait...
    • Instance Management > Change Instance Type
Marcel de Castilho
  • 5,812
  • 2
  • 20
  • 19
  • 4
    this is a way easier method.. – box86rowh Dec 12 '11 at 22:15
  • 22
    I agree this is simpler, but the benefit of the accepted method is that you could manage to have the new server up and running in parallel to the existing server before switching elastic IP over and incur little or no downtime. – rmontgomery429 Jan 03 '12 at 16:48
  • 3
    I did this but HDD space did not increase (Windows 2008 server, x64, micro->large). Tried running Disk Management, but found no unallocated space either. Any ideas? – gorzan Feb 06 '12 at 22:11
  • 17
    Do know that when Marcel says "Wait...", you are going to be waiting for a LONG time. This method is terrible if downtime is an issue. If downtime doesn't matter, it is easy, but this doesn't involve a small amount of downtime. Plan for about a half hour. – Jake Mar 10 '12 at 16:20
  • How long (roughly) is the waiting period? – surj Nov 02 '12 at 20:21
  • 8
    less than 5 minutes for me... mw.small to m1.medium running SQL 2012 Web – azcoastal Dec 10 '12 at 02:48
  • 4
    And the disk size issue? – Adrian Salazar Apr 30 '13 at 21:07
  • 2
    I just changed m1.small to m1.medium, about 2 minutes downtime. – xpda Oct 07 '13 at 23:20
  • However well accepted the answer is, process doesn't sound so safe to me. If things go wrong is there a plan B ? – abhishek77in Nov 18 '13 at 09:46
  • @abhishek77in: If things going wrong is unacceptable to you, you should go with the accepted answer, which minimizes downtime: create an AMI, bring up another machine, swap out DNS, and then shut down this machine. – Vic Dec 01 '13 at 04:54
  • 3
    BEFORE you do this, make sure to note the elastic IP of this instance. You will have to manually reconnect it after the upgrade (for some strange reason). – Tal Weiss Dec 15 '13 at 08:02
  • @RyanMontgomery: Amazon actually discourages taking AMI snapshots of running instances. But then, maybe you shouldn't depend too much on AMIs at all for this process. In any case, it should be noted that all data on instance storage will be flushed when you stop the instance. – Jaap Haagmans Mar 12 '14 at 09:25
  • tried to upgrade from t1.micro to t2.micro, however, t2.micro nor t2.small are available in the drop down list. – Michael Z Jul 15 '14 at 21:39
  • Be noted this will only work when your root device type is ebs. If your root device type is instance store, you should follow Lostsoul's steps. – Tim Chen Aug 29 '14 at 06:44
  • 1
    As of 2017 the menu has changed to INSTANCE STATE and INSTANCE SETTINGS – jim smith Mar 30 '17 at 11:09
  • is there a way to do this automatically when the cpu utilization reaches a certain threshold? – A Israfil Jan 12 '18 at 20:05
  • 2
    beware! this changes the IP address. – Peter Mar 15 '18 at 13:53
  • The easiest and best answer. – Pankaj Prakash Dec 25 '18 at 12:17
  • This option do not include new genration EC2 types – Ramratan Gupta Jan 30 '19 at 13:19
  • There is no "Instance Management" menu. – Andrew Koster Aug 17 '21 at 19:02
305

From my experience, the way I do it is create a snapshot of your current image, then once its done you'll see it as an option when launching new instances. Simply launch it as a large instance at that point.

This is my approach if I do not want any downtime(i.e. production server) because this solution only takes a server offline only after the new one is up and running(I also use it to add new machines to my clusters by using this approach to only add new machines). If Downtime is acceptable then see Marcel Castilho's answer.

Lostsoul
  • 25,013
  • 48
  • 144
  • 239
  • 1
    then delete small the instance before? – gandil May 05 '11 at 13:25
  • Once your sure everything is running fine, you can delete the other instance if you like(there's no dependency between the two). – Lostsoul May 05 '11 at 13:27
  • I run an web application on this instance. Until now there was just demo of the application. But since last week our customer started to use intensively. So upgrading is a must. – gandil May 05 '11 at 13:39
  • 1
    IP address of new instance will be different. Am I right? So we need to change dns record ? – gandil May 05 '11 at 13:40
  • 12
    If you are using elastic IP as you should, assign the elastic IP to the new server. The new server will then have the same IP address. This procedure will be useful also if your server crashes and you've to start a new one. – stivlo May 05 '11 at 16:10
  • yes we are using elastic IP's. What is procedure for assign elastic IP to new instance? – gandil May 05 '11 at 17:08
  • when you launch the new instance..go to the elastic ip section(on the right hand menu) then disassociate the ip with the old instance and then associate it with the new one(these are menu options within the elastic ip section. – Lostsoul May 05 '11 at 18:03
  • Finally; 1.Create a snapshot of current instance image 2.Launch the new instance as a large instance at that point. 3.Disassociate the ip with the old instance and then associate it with the new one(elastic ip section, we also have elastic ip, This procedure will be useful also if our server crashes and we’ve to start a new one) 4.Once if sure everything is running fine, delete the old instance (because there's no dependency between the two instance). Ok? – gandil May 05 '11 at 20:47
  • Yes, thats what I have done in the past and has worked for me! Good luck! (p.s. I can't comment too much because I've not set it up fully yet but look into load balancers if you expect alot of traffic..it can spread your traffic automatically between different servers..and using cloudwatch you can spawn new servers if the load becomes too high. End result is if too much load is on a server, cloudwatch creates another one, and loadbalancer directs traffic there. Might be something to think about for the future). Good luck! – Lostsoul May 05 '11 at 21:03
  • I create an ami and then try to launch new instance from that ami. As I said before I want upgrade from micro to large(7.5 GB Memory etc) but there is an problem. The choices are micro, small and high cpu with max 1.7 GB Ram. Micro (t1.micro)Up to 2 ECUs1 Core613 MB Small (m1.small)1 ECU1 Core1.7 GB High-CPU Medium (c1.medium)5 ECUs2 Cores1.7 GB... Why? – gandil May 06 '11 at 09:20
  • yikes..I think i know why..I just am not sure if there's any easy way to fix it. When you setup your server, you set it up as a 32 bit instance. The large instance is 64 bit(http://aws.amazon.com/ec2/instance-types/) I had this problem and ended up rebuilding the server, but there maybe an another way. I'm not familiar with the tools but ask the ppl here if there's a way to migrate a server over(some sort of back up/restore tool), build it on a 64 bit micro, and then once your ready follow the above steps you had to move to large. – Lostsoul May 06 '11 at 13:51
  • now amazon giving zero downtime option – Hardik Sondagar Mar 13 '14 at 08:00
  • I had a kernel panic when I did this, I recommend the Change Instance Type method in the other answer. – Ayberk Özgür May 03 '14 at 23:23
  • @AyberkÖzgür was it 64bit to 64bit OS upgrade? – Lostsoul May 06 '14 at 15:32
  • Of course, it was 64bits to 64bits. – Ayberk Özgür May 07 '14 at 07:14
  • @AyberkÖzgür not sure then, I still follow this approach when I do not want downtime. – Lostsoul May 07 '14 at 14:15
  • 1
    Not a very reliable method, the server state might change if it's under stress (which is very likely considering the need to scale it up), and the new, larger server will be a few minutes/hours older than the actual running server. – AbiusX Oct 18 '16 at 00:18
  • 2
    If the snapshot is of the root volume, Amazon recommends stopping the instance before taking the snapshot: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html – Taterhead Dec 08 '16 at 09:38
  • 1
    Something to keep in mind is to assign your new instance to the correct security group otherwise even after you switch the elastic IP your new instance won't be visible if the right ports aren't open. – Marcin Aug 03 '18 at 20:09
48

Using the AWS Management Console

  • Go to "Volumes" and create a Snapshot of your instance's volume.
  • Go to "Snapshots" and select "Create Image from Snapshot".
  • Go to "AMIs" and select "Launch Instance" and choose your "Instance Type" etc.
Styelz
  • 489
  • 4
  • 2
  • This allows you to change architecture and instance type. – Styelz Feb 06 '12 at 15:21
  • Thanks for actually putting the steps here, and making it clear, this is the best method, unless you are in the early stages where downtime doesn't matter. – Jake Mar 10 '12 at 16:21
  • 2
    I tried this but in my case new instance didn't start with AMI from older instance, had some kernel panic issue. – zeeshan Apr 25 '14 at 04:14
17

Use the AWS EC2 console, not ElasticFox.

First Way:

  • Create a new AMI of the instance
  • Launch it

Alternative Way:

  • Make a snapshot of the disk
  • Launch a large EBS instance with the same AMI type (please note that at this point the disk will contain the data that was present when this AMI was created, not your latest changes)
  • Once is fully booted, stop the new instance
  • Detach the root volume from the stopped instance
  • Create a virtual disk from the snapshot created before in the same availability zone of the new instance
  • Attach the root volume to /dev/sda1
  • Start the new instance again
stivlo
  • 83,644
  • 31
  • 142
  • 199
8

Create AMI -> Boot AMI on large instance.

More info http://docs.amazonwebservices.com/AmazonEC2/gsg/2006-06-26/creating-an-image.html

You can do this all from the admin console too at aws.amazon.com

kieran
  • 2,304
  • 4
  • 28
  • 44
  • I want to do this on aws console. is there any howto document with image ? – gandil May 05 '11 at 13:22
  • Right click on your instance and click "create AMI" - then go into AMIs on the console display (on the left hand side) and click "launch AMI" on the one you want to launch – kieran May 05 '11 at 13:27