Comparison of cloud storage services

In the table below I’m trying to compare Amazon AWS S3, Microsoft Azure Storage, Google Cloud Storage, Rackspace CloudFiles.

Hope this is useful.

	Amazon AWS S3	MS Azure	Google Cloud Storage	Rackspace Cloud Files
Max account size	Unlimited?	200 TB per storage account(by default you have 20 storage accounts per subscription) = 4PB	Unlimited?	??
Geo redundancy	+extra price	+extra price	?	-
SLA	Availability SLA: 99.9%Designed to provide 99.999999999% durability and 99.99% availabilityReduced Redundancy:Designed to provide 99.99% durability and 99.99% availability	Availability SLA: 99.9%	Availability SLA: 99.9%	Availability SLA: 99.9%
HTTP	+	+	+	-
HTTPS	+	+	+	+
Container namespace	Global LName collision is possible	Storage account	Global L	Account
Container (bucket) levels	single	single	single	single
Root container	-but with HTTP each bucket can have DNS name (not possible with HTTPS)	+	-but each bucket can have DNS name	-
Cross origin CORS support	+	-	+experimental	+
Max number of containers (buckets)	100	unlimited	Unlimited?	500,000
Container name length	3-63a few limitations, basic form is “my.aws.bucket“in US region:255 bytes[A-Za-z0-9.-_]But DNS-compliant is recommended	3-63 chracters, valid DNS name	3 to 63 charactersvalid DNS nameIf name is dot-separated each component <63 character, and 222 total	256after URL encoding, no ‘/’ character
Max files per container	Unlimited, no performance penalty	unlimited	unlimited	Unlimited, but API throttling begins at 50000 files.
List files, max results	1000	5000	?	10,000
List files returns metadata	-	+(configurable)	-	-
File (BLOB/object) name	1024	1024	1024	1024 bytes after URL encoding
Max file size	5TB	200GB (Block blob)1TB (page BLOB)	5TB	UnlimitedMultiple files in the same container with same name prefix can be joined into single virtual file.
Max upload size	5 GB	64 MB	5 MB?	5GB
HTTP Chunked upload	-	-	+	+
Parallel upload	+	+	?(Resumable Uploads of Unknown Size)	+
Upload Data checksumming	+	+	+
Server-side copy	+(up to 5 GB?)	+supports external sources	+	+
File metadata	2KB, ASCII,no update	8KB	+ (size limit non specified)No update	90 pairs or 4096 bytes total
# data centers	8	8	?	2: ORD, DFW
CDN-enabled	+	+	?	+
Authentication	HMAC-SHA1 signing	HMAC-SHA256signing	OAuth 2.0Google cookie1-hr JWT token	24-hr token obtained from Cloud Authentication Service.
Time-limited shared access	+	+	+	+
File auto expiration	+	-	-	+
Server-side encryption	+AES-256	-	-	-
PRICING
Storage per GB a month	$0.037-$0.093 for reduced redundacny$0.055 – $0.125 for fully redundant	$0.037 – $ 0.093 for locally redundant storage$0.055 – $0.125 for geo redundant	$0.085 – $0.12	$0.10
Outgoing bandwidth per GB	$0.05 – $0.12 (US)1GB /mo is free	$0.05 – $0.12 (UE/EU)$0.12-$0.19 (Asia)	$0.08-$0.12 (US)$0.15-$0.21 (Asia-Pacific)	$0.18
Incoming bandwidth	$0	$0	$0	$0
PUT, POST, LIST	$0.01 per 1000	$0.01 per 100 000 storage transactions	$0.01 per 1000	$0
HEAD, GET, DELETE	$0.01 per 10 000(no charge for delete)	$0.01 per 100 000 storage transactions	$0.01 per 10 000(no charge for delete)	$0

UPDATE (Nov 5, 2012): Azure Strorage now has higher limits, way better internal connectivity network, and higher performance targets, see announcement.

2000 IPOS per partition, 20000 IPOS per storage account.

Brief reference on cloud storage

This is very brief and shallow comparison of data model and partitioning principles in Amazon S3 and Azure Storage. Please also see my feature comparison post of various storage platforms: http://timanovsky.wordpress.com/2012/10/26/comparison-of-cloud-storage-services/
Amazon S3
Getting most out of Amazon S3: http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html
Their storage directory is lexigraphically-sorted, and leftmost characters used as partition key. It is not said, but looks like you need to have your prefix tree balanced in order for partition balancing to work optimally. I.e. if you prefix with 0-9A-F as suggested in the article, amount of requests going to all 16 prefixes must be roughly the same. This underneath might mean that key space is always partitioned evenly – split into fixed amount of equal key ranges. That is totally my speculation, but otherwise I can not explain why such prefixes would matter.

Microsoft Azure Storage
http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2011/11/20/windows-azure-storage-a-highly-available-cloud-storage-service-with-strong-consistency.aspx
Having glanced over MS docs I’m under impression that Azure storage can split key ranges independently based on the load and size.
Update: The following quote shows that Azure is similar to S3, and I was wrong:

A downside of range partitioning is scaling out access to
sequential access patterns. For example, if a customer is writing
all of their data to the very end of a table’s key range (e.g., insert
key 2011-06-30:12:00:00, then key 2011-06-30:12:00:02, then
key 2011-06:30-12:00:10), all of the writes go to the very last
RangePartition in the customer’s table. This pattern does not take
advantage of the partitioning and load balancing our system
provides. In contrast, if the customer distributes their writes
across a large number of PartitionNames, the system can quickly
split the table into multiple RangePartitions and spread them
across different servers to allow performance to scale linearly
with load (as shown in Figure 6). To address this sequential
access pattern for RangePartitions, a customer can always use
hashing or bucketing for the PartitionName, which avoids the
above sequential access pattern issue.