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.)


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'.

  • 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 – Alex Oct 2 '13 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.