10 ms·

A compelling reason for our use case to switch from S3 is their support for lots of buckets coupled with CNAME support: http://code.google.com/apis/storage/doc

by zbailey 15y ago

A compelling reason for our use case to switch from S3 is their support for lots of buckets coupled with CNAME support: http://code.google.com/apis/storage/docs/reference-uris.html http://code.google.com/apis/storage/docs/reference-uris.html Due to Amazon's limitation of 100 buckets per account and the coupling between bucket name and CNAME, hosting files for our clients and supporting custom CNAMEs has not been possible for us. If we were to move to Google Storage, it would be.

ceejayoz 15y ago
I just wish either one would support SSL for CNAMEd buckets.
- dsl 15y ago
  That is a limitation of SSL. If you don't like it, ask your browser vendor to support section 3.1 of RFC 3546.
  - ceejayoz 15y ago
    It should be possible via a combination of Amazon's elastic IPs and the SSL offloading that their ELBs already do.
  - hartror 15y ago
    Shouldn't that be ask your user's browser vendor to support section 3.1 of RFC 3546?
deleted 15y ago
[deleted]
joeyh 15y ago
Another good reason for certain use cases is its support for resumable uploads: http://code.google.com/apis/storage/docs/developer-guide.html#resumable http://code.google.com/apis/storage/docs/developer-guide.htm... Afaik S3 can't do that.
- spicyj 15y ago
  No, S3 (essentially) can as well: http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-upload.html http://aws.typepad.com/aws/2010/11/amazon-s3-multipart-uploa...
  - snewman 15y ago
    Multipart uploads only sort-of address this. For one thing, the minimum "part" size is 5MB, so you can only resume at 5MB boundaries (or whatever part size you use). You also have to manage more state yourself.