Revenue strategy for web services

Adobe notes that it's developer revenue isn't really taking off, and interviews from Amazon's Jeff Bezos indicate that he's hopeful that someday, their web services platform will be a major driving force in the company's profit plan. This is something I've been struggling with, too - trying to find that secret sauce to monetizing APIs, RSS feeds, mashup models, and JavaScript imports.

At KUAM, opening up our news data more and more to programmers naturally means we'll need to support more bandwidth to facilitate the additional data transfer from remote clients accessing our stuff. This means more costs to our overhead.

Borrowing from the volume model made popular by Google for Google Maps, I've thought about using free license keys, allowing a certain number of API calls every day. Additional method invocations against the base service would either (a) not facilitate the service thereafter, or (b) apply an overage surcharge. I've even thought about developing tiered rate cards based on similar expected volume/overage levels for high-end consumers.

What revenue model are you using for your web services?