1

It is my understanding that in order to make use of EC2 spot instances, the AMI for the instances must be configured to start doing whatever it's supposed to do immediately upon bootup, and continue doing it until it's done or the instance is terminated.

That's not a problem in itself, but I will be needing periodically to update the AMI with new software and/or configuration scripts, so I'll occasionally need to bring up a regular instance that I can ssh into and tinker, which won't play nice with boot scripts that immediately start trying to Do Stuff (for instance, while I am updating the AMI for a bunch of compute workers, the associated control server will probably be down).

Is there a way to configure two (or more) boot modes for the same AMI? Sort of like good old-fashioned SysV run levels ... which would work fine for this application, in fact, except I don't see any way to control the kernel command line from the EC2 web or CLI interfaces.

(Operating system inside the AMI is Linux, if that matters.)

Improve this question

1 Answer 1

Reset to default
2

Use the user-data field and set a flag to disable execution.

For example, have your startup script check the user-data for the instance and if that data is set to 'no-run', then abort your startup scripts.

Then when you need to launch a "maintenance" instance, ensure your user-data is set to 'no-run'.

Improve this answer
1
  • 1
    Just a little more detail: user-data that you pass into an instance at launch will be available through the instance metadata service. You can get at it with curl http://169.254.169.254/latest/user-data
    – Alex
    Oct 2, 2013 at 13:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .