SQL Server Database is a relational database not a generic storage system. In relational databases the emphasis is returning and manipulating direct relationships. You can store Blobs or anything else in the intersect of the relational attributes but
you cannot manage this as an indexed file system, for example. In the case of SDS it is about moving large amounts of data quickly and efficiently in bulk between locations. Simialr to the indexed file system where we could store random pictures, documents
and other items together under some search criteris SDS uses a simplified attribute structure to move and retrieve this type of information.
In the case of EC2 this works well for an individual program or when I need storage for a specific problem. When managing many processes that are coordinating together coding this in Amazon's API is a more difficult process. ASP, BPO, and SaaS ISV's have
to manage this next layer of difficulty. Distributing the results back to your customer is more than renting a box. Azure attempts to solve some of these issues.
That being said the original Azure is targeted to MS data centers to provide services. I do not think that Micorosoft is going to go through another round of anti-competitive lawsuits making that their only option. They could make it more convenient to
use their centers but still enable all the services to other providers. We shall see how this is handled moving forward.
Microsoft has been the expert when it comes to this middle arena between applications and the infrastructure. That is their core capability and one that Azure looks primed to take advantage of. If I were to look into the next couple of years the idea of
writing an interface between Azure and Amazon's hosting services would be right within this "sweet spot".