Cloud computing looks to have turned yet another interesting corner. This time the turn leads towards the development of a liquid, fully electronic new marketplace in “spot instances”.
‘Spot‘ means what you would expect it to in the context of trading: the current pricing for immediate delivery of a commodity. ‘Instance‘ is the atomic element within Amazon’s cloud environment; an instance is the smallest chunk of computing capability which can be provisioned within the cloud.
Amazon is making markets in cores and they’re exposing functionality just as a regular exchange would: both through user interface ‘screens’ as well as programmable APIs.
From their announcement:
Spot Instances enable you to bid for unused Amazon EC2 capacity. Instances are charged the Spot Price set by Amazon EC2, which fluctuates periodically depending on the supply of and demand for Spot Instance capacity. To use Spot Instances, you place a Spot Instance request, specifying the instance type, the region desired, the number of Spot Instances you want to run, and the maximum price you are willing to pay per instance hour. To determine how that maximum price compares to past Spot Prices, the Spot Price history is available via the Amazon EC2 API and the AWS Management Console. If your maximum price bid exceeds the current Spot Price, your request is fulfilled and your instances will run until either you choose to terminate them or the Spot Price increases above your maximum price (whichever is sooner).
While the inclusion of, effectively, a market data service is neat, probably the most interesting aspect of the initial protocol they’ve designed is that it contains embedded optionality and behaves a bit like barrier options. That is, when I setup an ‘order’, I need specify a maximum price I’m willing to pay. When the spot price drops below my max, I get “knocked-into” a contract and instances are allocated to me. If the spot price rises above my max while I’m running, I get “knocked-out” of the contract and my jobs get terminated.
The intent is to allow for low-priority jobs to be dynamically run whenever pricing drops below a user’s threshold, but the (intended?) consequence is that it adds the delicious and malleable tang of path dependency to these instruments…
secondary markets, FIX, arbitrage..?
Amazon currently controls the market entirely, but it’s not hard to imagine a secondary market evolving. Given that others are beginning to copy Amazon’s APIs, one can also imagine markets which operate across providers … perhaps accessed via FIX?…
Who knows? In the not-too-distant future, we may well be able to implement ‘core arb‘ strategies…or make markets in cores… or find that we can effectively hedge with disciplined exposure to the ‘core market’ or …