Question

I’m using the .NET SDK and attempting to tag a new instance immediately after creating it – CreateTags immediately after RunInstances.

Most of the time it just works, but occasionally I’ll get an error that the instance ID is not valid (subsequently checking in a console or trying again, it is valid).

I understand that with SQS, SDB etc they are ‘eventually consistent’ and it may be necessary to retry calls (although I believe the SDK does that for you anyway) – but with general calls to create instances I didn’t think it was necessary. What’s more I don’t think it’s a good thing to do; looking for a specific exception and retrying almost infinitely until it works.

If the process of creating an instance and tagging it has to be entered into a distributed workflow with redundant centralised system for polling and retrying I think that’s a bad situation!

I can’t seem to find anything relevant in the documentation about this. I figured if I call RunInstances and get a response with an instance ID, that instance ID should be immediately valid for tagging.

My thoughts for possible solutions so far:

• Fixed delay of a few seconds after RunInstances (bad, arbitrary delay)
• Try immediately, else delay 5sec and retry, up to ‘n’ times (OK but arbitrary)
• Create distributed workflow to handle any chained API calls like this, would need central redundant farm of EC2 instances to manage to be reliable (bad, massively overengineered)
• Find some other explanation where I can call another API method or set something on the request to either call to make it work

Has anyone else experienced this, have any knowledge in that area, etc?

(I’ve a thread on AWS community forums here, nothing yet: https://forums.aws.amazon.com/thread.jspa?threadID=80489&tstart=0)

Answer 1

I’m afraid you’re right with your first option – it takes a finite, variable time after the call to RunInstances before the instance is assigned a reservation identity, begins running, and becomes available for further calls against it.

My control software simply sleeps for 5-second intervals on the launcher thread until the instance enters the 'Running' state, at which point I can begin issuing other calls.