We would like to share a first hand experience of ours with you as a "use case"
As stated in Zettar Company Overview, since early 2008 we have been working intensely in creating storage cloud federation technologies to support our mission. As part of our effort, we have created a unique userspace concurrent virtual filesystem that represents one or more storage clouds with just a single filesystem in userspace.
Such an approach brings significant benefits in easy usage and management. For example, when running the software in Microsoft Windows® environment, a user never needs to remember the relation of a drive letter and a backend storage cloud. An administrator doesn't need to worry about drive letter collisions either - a strong contrast to similar efforts done at elsewhere.
Nevertheless, while working on the early versions of said virtual filesystem, we indeed, like nearly all other AWS cloud application developers, used AWS S3 directly for our development (there were no alternatives!). Our own first hand experience showed us that this approach is not only counter-productive, but also expensive if a software bug is not caught early.
Any transaction to AWS S3 carries a price tag, and log retrieval is always delayed. In our situation, the saying "to err is human, but to really fouls things up requires a computer" indeed proved to be true - one re-try logic related bug costed us a small fortune in an automated QA test that we ran overnight.
After this incidence, we said NO to this "developing and testing against the real storage cloud" approach. We created our own local AWS S3 sandbox, and have been happy ever since.
If you are developing any serious cloud applications that involve many storage related transactions, we encourage you to check out our sandbox. We are confident that our experience is not an exception. You will be delighted by having the sandbox just as much as, or more so, as we are.