Can’t Start 64-bit AMI on t1.micro instance on AWS

However I cannot see where to specify that my instance requires 64-bit architecture in the template file.

Assuming you are addressing the example template downloadable via Create a Load-Balanced Apache Website, the instance type and architecture mappings are wired via these two tables:

  "Mappings" : {
    "AWSInstanceType2Arch" : {
      "t1.micro"    : { "Arch" : "64" },
      "m1.small"    : { "Arch" : "32" },
      "m1.large"    : { "Arch" : "64" },
      "m1.xlarge"   : { "Arch" : "64" },
      "m2.xlarge"   : { "Arch" : "64" },
      "m2.2xlarge"  : { "Arch" : "64" },
      "m2.4xlarge"  : { "Arch" : "64" },
      "c1.medium"   : { "Arch" : "32" },
      "c1.xlarge"   : { "Arch" : "64" },
      "cc1.4xlarge" : { "Arch" : "64" }
    },
    "AWSRegionArch2AMI" : {
      "us-east-1" : { "32" : "ami-6411e20d", "64" : "ami-7a11e213" },
      "us-west-1" : { "32" : "ami-c9c7978c", "64" : "ami-cfc7978a" },
      "eu-west-1" : { "32" : "ami-37c2f643", "64" : "ami-31c2f645" },
      "ap-southeast-1" : { "32" : "ami-66f28c34", "64" : "ami-60f28c32" },
      "ap-northeast-1" : { "32" : "ami-9c03a89d", "64" : "ami-a003a8a1" }
    }
  },

This wiring works as follows:

• The AWSInstanceType2Arch mapping table specifies the desired architecture per instance type ( which is matching your needs already [i.e. "t1.micro" : { "Arch" : "64" }]).

• The AWSRegionArch2AMI mapping table specifies the architecture specific AMIs per region. i.e. which AMI is actually providing the correct architecture mapped above.

For example, if you are starting a t1.micro instance in the eu-west-1 region with this template, it will first deduce the architecture 64 from AWSInstanceType2Arch and then the AMI identifier ami-31c2f645 from AWSRegionArch2AMI in turn.

The example should work correctly in principle (though I haven't tested it myself right now), so AWSRegionArch2AMI is the fragment you would need to customize by replacing the example AMI identifiers with the correct architecture bound ones you want to use for your t1.micro 64bit instances; however:

"The requested instance type's architecture (i386) does not match the architecture in the manifest".

The error message suggests that the AMI which is used to start the instance is a 32-bit AMI in fact - could it be that you accidentally replaced the 64-bit AMI identifiers in the example with 32-bit ones?

The problem you see is because the command 'ec2-bundle-vol' is for creating S3-backed AMIs. You have therefore, taken your EBS backed AMI - created, uploaded, and registered its contents as an S3 backed AMI, and then launched that S3 backed AMI in the new region.

Unfortunately, there is no built in way to migrate an AMI with an EBS root between regions. You need to go about it the long way.

• Firstly, create a snapshot of the root volume you want to migrate
• Then, start up an instance in the source and destination regions.
  • if you don't want to have different keys for the instances (since they are in different regions), you should import your own keypair first.
• Create an EBS volume from your snapshot, and attach it to the instance in your source region.
• Create a new (empty) EBS volume, in the destination region, and attach to the instance you started there.
• Format the EBS volume in the destination region with the desired file system
• Copy the data between the EBS volumes
  • rsync over SSH is likely the way to go
• Create a snapshot of the new (destination) EBS volume
• Register an AMI based on that snapshot
• Terminate the instances you started, when you are done with them

You will incur costs for the instances, the data transfer, and the EBS I/O.

There is actually another option that might be better suited to your needs.

S3-backed AMIs can be downloaded and unbundled, yielding an image of the original disk - you can then write that image to your EBS volume, and should be good to go.

Essentially, you would perform the same first steps as you already have:

• ec2-bundle-vol ...
• ec2-migrate-manifest ...
• ec2-upload-bundle ...

Then, in the destination region:

• Start a new instance, and attach a sufficiently sized EBS volume
  • You will also need enough free space on the instance to store the image temporarily (the ephemeral storage on a small instance should be ample).

• Download your bundled volume to the instance:

  ec2-download-bundle -b BUCKET_NAME -m MANIFEST.xml -d TARGET_DIRECTORY

  • You also need to either pass your ACCESS_KEY, SECRET_ACCESS_KEY, and PRIVATE_KEY, or have then set as environment variables.

• Unbundle the volume:

  ec2-unbundle  -m /local/path/to/manifest.xml -s SOURCE_DIRECTORY -d DESTINATION_DIRECTORY

• Copy to EBS Volume:

  dd if=/path/to/image of=/dev/NAME