2

I am attempting to write my first cloudformation template. I am basing it on the ELB example.

In my case I will have 64-bit instances only, t1.micro sized. However I cannot see where to specify that my instance requires 64-bit architecture in the template file. When I attempt to create my new stack, it duly thinks about it for a bit and then fails/rolls back with the error creating the first instance:

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

It's correct that the manifest arch is 64-bit — I think my problem is that because I am not explicitly specifying an architecture, it is defaulting to i386. How can I correct this? There is nothing that jumps out at me in the template reference doc.

Steffen Opel
  • 5,638
  • 37
  • 55
liamf
  • 392
  • 4
  • 10
  • Please come back and mark a correct answer to this question. – Caleb May 10 '11 at 12:40
  • ... is it poor site etiquette to mark my own answer as correct? 'cos it is the correct one ... – liamf May 11 '11 at 16:36
  • If yours is the only correct one and nobody else caught on to the problem or straightened you out, then yes that's fine. In fact it's perfectly fine to ask a question knowing the answer and answer it yourself if you think it will be useful to people to have the question and answer around. You don't earn rep for marking yourself correct, but at least the question is marked as answered and won't show up on the "unanswered" question radar that some experts surf just trying to solve old problems! – Caleb May 11 '11 at 17:41
  • 1
    @Caleb OK, done, plus edited answer to show how exactly to pass the InstanceType – liamf May 11 '11 at 20:22

2 Answers2

3

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?

Steffen Opel
  • 5,638
  • 37
  • 55
  • Nice explanation ... will help other beginners figure out CFN templates. (JSON: I hate JSON). Anyway I figured out my exact problem in that case and followed up with a specific answer below. – liamf May 01 '11 at 20:38
2

Actually, I figured this out. I had followed up with an answer to this on the AWS Cloudformation forum but I forgot (sorry) that this thread was also active.

The issue is that the ELB template example is incomplete - so when I copied it, my example was also incomplete: you need to specify an instance type (t1.micro for example, or m1.large) explicitly, or else a default is assumed.

To quote my post to the AWS forum

The sample ELB template which I copied doesn't specify the InstanceType property for the instances it makes. It uses the InstanceType to look up the AMI, but it doesn't actually specify it.

If you specify the InstanceType along with a matching AMI, all is well.

So for example, this is an extract from a properly specified template:

"Parameters" : {
    "InstanceType" : {
        "Description" : "Type of EC2 instance to launch",
        "Type" : "String",
        "Default" : "t1.micro"
     }

...

"LaunchConfig": {
    "Type": "AWS::AutoScaling::LaunchConfiguration",
     "Properties": {
        "SecurityGroups": [{"Ref": "SecurityGroup" }],
        "KeyName" : { "Ref" : "KeyName" },
        "InstanceType" : { "Ref" : "InstanceType" }
....
  }
},

`

I haven't tried it but I expect the AWS example wouldn't work for all combinations of AMIs without this parameter added either.

Cloudformation is nice, but it's quite early days yet. I've come across several bugs in the documentation so far. So don't assume if you hit a roadblock that you are doing something wrong ... you might not be.

liamf
  • 392
  • 4
  • 10