In this blog post, we’re going to compare Windows Azure Blob Storage Service and Amazon Simple Storage Service (S3) from core functionality point of view. In this blog post we’re going to focus on core concepts, pricing and feature comparison between blob containers and buckets (defined below). In Part II of this blob post we’ll focus on comparing blobs and objects (defined below).
For the sake of brevity, we’re going to refer Windows Azure Blob Storage as WABS and Amazon Simple Storage Service as AS3 in the rest of this blog post.
From fundamental functionality point of view, both WABS and AS3 provides similar functionality. Simply put, both can be considered as file system in the cloud allowing you to store huge amount of unstructured data (usually in form of files).
In both systems, you can create one or more blob containers or buckets which will hold zero or more blobs or objects respectively.
Both systems provide a REST based API for working with files and folders and other higher level language libraries which are essentially wrappers implementing REST API. Over the years, both systems have evolved in terms of functionality provided. In both systems, each release of the API is versioned and is specified as a date. At the time of writing this blog, the service version number for WABS is 2011-08-18 while that of AS3 is 2006-03-01.
At a very high level, both systems provide similar functionality. Here are some of them:
- Both systems in essence are file system in the cloud with two levels of hierarchy.
- Both systems allow you to store large amount of data reliably and cheaply.
- Both systems allow you to protect your content from unauthorized access.
- Both systems allow you to keep multiple versions of a same object however they way versioning is implemented is different in both systems.
- Both systems allow you to expose the contents of a blob container and bucket through their respective content delivery networks (CDN) for lower latency and content caching.
- Both systems provide access control mechanisms to protect data stored. AS3 has many options (like Amazon Identity and Access Management (IAM), Bucket Policies, ACLs and Query String Authentication) where as WABS provide ACLs and Shared Access Signatures.
- Both systems allow you to keep many versions of an object however the implementation of versioning is different.
There are a few differences as well. We’ll talk more about it later in the blog post, but here are some of the major differences:
- WABS only support HTTP (via REST) protocol however AS3 supports HTTP (via REST and SOAP) as well as BitTorrent protocol for doing peer-to-peer distribution of content.
- AS3 has public mechanisms in place to import and export extremely large amount of data (Amazon Import/Export). This feature is not publicly available in WABS yet.
- In AS3 you can set objects to auto delete after a certain amount of time. This feature is not currently available in WABS.
- AS3 allows you to charge your customers for their usage of AS3 resources stored in your account using Amazon DevPay. This is a great enabler for building SaaS applications. This feature is not currently available in WABS. Yet another feature available in AS3 which is not available in WABS is Requester Pay Buckets where users accessing the data stored in your buckets pay for the usage.
- AS3 allows you to encrypt the data stored using Server Side Encryption (SSE). This feature is not available in WABS.
- AS3 supports both virtual-hosted-style (e.g. http://mybucket.s3.amazon.com/myobject) and path-style (e.g. http://s3-eu-west-1.amazonaws.com/mybucket/myobject) whereas WABS only support path-style (e.g. http://myaccount.blob.core.windows.net/myblobcontainer/myblob).
- AS3 offers a Reduced Redundancy Storage (RRS) feature where in customers can opt to store their data at lower level of redundancy (99.99% durability and 99.99% availability) than AS3’s standard redundancy (99.999999999% durability and 99.99% availability) thus lowering their storage costs. I think it’s pretty neat to have this option to lower my storage costs if my data is not critical and easily reproducible. WABS offer one level of redundancy.
Concepts
Before we talk about these two services in greater detail, I think it is important to get some concepts clear. If you’re familiar with the basic foundation concepts of WABS and AS3, you may want to skip this section.
Blob Containers and Buckets: If these services are file system in the cloud, think of a blob container (in WABS) or a bucket (in AS3) as folder or directory. In a storage account (in WABS) or an account (in AS3), you can have zero or more blob containers and buckets respectively and these will contain blobs or items respectively.
A few comments about blob containers and buckets:
- There is no concept of nested blob containers and buckets. Both WABS and AS3 support 2-level hierarchy only and nested folders are not allowed. However, both systems allow you to create an illusion of folder hierarchy using something called “prefix”.
- There is no limit on number of blob containers and buckets you can create in each system.
- Both systems allow you to host a static website in a blob container and a bucket however AS3’s implementation is much neater as it allows you to define a root and index document as well as customizes error pages for 4xx errors (e.g. 404 error).
- Both AS3 and WABS provide capability where you can log the requests made against the resources. This feature is called “logging” in AS3 and “Storage Analytics” in WABS. The difference is that the logging works at a bucket level in AS3 while storage analytics work at storage account level in WABS. Furthermore the logging in AS3 puts the data in a separate user defined bucket where as in WABS the storage analytics data goes into predefined tables and blob containers which are created automatically for you once you enable storage analytics on your storage account.
Blobs and Objects: Simply put blobs (in WABS) and objects (in AS3) are the files in your cloud file system. They go into blob containers and buckets respectively.
A few comments about blobs and objects:
- There is no limit on the number of blobs and objects you can store. While AS3 does not tell you the maximum storage capacity allocated for you, the total number of blobs in WABS is restricted by the size of your storage account (100 TB currently).
- The maximum size of an object you can store in AS3 is 5 TB where as the maximum size of a blob in WABS is 1 TB.
- In WABS , there are two kinds of blobs – Block Blobs and Page Blobs. Block Blobs are suitable for streaming payload (e.g images, videos, documents etc.) and can be of a maximum of 200 GB in size. Page Blobs are suitable for random read/write payload and can be of a maximum of 1 TB in size. A common use case of a page blob is a VHD mounted as a drive in a Windows Azure role. In AS3, there is no such distinction.
- Both systems are quite feature rich as far as operations on blobs and objects are concerned. You can copy, upload, download and perform other operations on them.
- While both systems allow you to protect your content from unauthorized access, the ACL mechanism is much granular in AS3 where you can set custom ACL on each object in a bucket. In WABS, it is at a blob container level.
Pricing
Before we dig deep into the functionality, let’s take a look at the pricing. In both systems, there are no upfront costs. The pricing model is rather simple and consumption based. In both systems, you are charged on usage basis and there are three components:
- Transaction: You’re charged for the for the number of transactions you performed against each system. Simply put, a single transaction can be defined as one call to the functionality in each system. However there is one significant difference in the way this pricing is calculated in each system. While in WABS the cost per transaction is fixed (currently $0.01 for 10,000 transactions), in AS3 it varies based on the type of transaction performed. So if you perform PUT, COPY, POST, or LIST operations you pay a higher price / transaction (e.g. $0.01 for 1,000 transactions in US Standard Region) and for GET and all other Requests you pay a lower price / transaction (e.g. $0.01 for 10,000 transactions in US Standard Region). One important thing to notice is that all the delete requests are free in AS3.
- Storage: You’re charged for the amount of data you store in each system. With AS3, you can either store objects with standard redundancy or reduced redundancy. You pay for storage based on the redundancy level you have chosen (lesser for reduced redundancy).
- Data Transfer: You’re charged for the amount of data transferred from/to each of the system. At the time of writing this blog, both systems offer free ingress (i.e. data coming from outside) but charge a fee for data egress (i.e. data going out). Data transferred between AS3 and Amazon EC2 within a single region is free of charge (i.e., $0.00 per GB). Data transferred between AS3 and Amazon EC2 in different regions will be charged at Internet Data Transfer rates on both sides of the transfer. Similarly in WABS, only the data going out of a data center is charged.
There is also a concept of specialized pricing and both systems offer different pricing packages and offers which you can avail. For more details on pricing, please refer to https://www.windowsazure.com/en-us/pricing/details/ for WABS and http://aws.amazon.com/s3/pricing/ for AS3.
Function/Feature Summary
Following table summarizes the list of functions provided by WABS and AS3.
Now we’ll explore these functions in somewhat more details.
Create Container/PUT Bucket
| WABS | AS3 | |
| Create Container/PUT Bucket | Yes | Yes |
As the name suggests, this function creates a new blob container and a bucket in WABS and AS3 respectively.
One important thing to understand is that blob containers in WABS are scoped within a storage account while buckets in AS3 are scoped within an Amazon account. When you create a storage account in WABS, you specify the location (data center) of that storage account. Thus all your blob containers are within a particular data center (geographic location constrained). Where as when you create a bucket in AS3, you can specify in which region you wish this bucket to be created. Thus in essence you could have your buckets spread over all data centers in AS3 if there is a need for such a requirement. To accomplish the same in WABS, you would need to create storage accounts in different data centers first and then create blob containers in each storage account.
There are few rules when it comes to naming a blob container/bucket. Following table summarizes these rules:
| WABS | AS3 | |
| Minimum/Maximum length | 3/63 | 3/63 |
| Case Sensitivity | Lower case | Lower case |
| Valid Characters | Alphanumeric, and Dash (-) | Alphanumeric, Dash (-) and Period (.) |
There are few other rules for naming a blob container/bucket:
- Blob container names must start with a letter or number i.e. it can’t start with a dash (-) character. Furthermore every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names.
- When naming buckets in AS3, they must be a series of one or more labels separated by a period (.) where each label must start and end with a lowercase letter or number. Also bucket names must not be formatted as an IP Address (e.g. 127.0.0.1).
- If you create a bucket in “US Standard” region, AS3 follows a less strict naming convention by allowing you to have bucket name between 3 and 255 characters long and containing mixed case letters, numbers, periods (.), dashes (-) and underscores (_).
There are a few other things:
- If no location is specified in which region a bucket should be created, AS3 creates a bucket in “US Standard” region.
- When creating a blob container/bucket, you can also set the ACL for that blob container/bucket as well. Setting ACL at the time of creation is optional and if not specified, by default both systems create a “Private” blob container/bucket which is only accessible to the owner by default.
- WABS allow you to specify custom metadata for a blob container. Metadata essentially is a name/value collection. The maximum size of all name/value pairs in metadata can be 8KB. AS3 does not allow you to have custom metadata on a bucket.
List Containers/GET Service
| WABS | AS3 | |
| List Containers/GET Service | Yes | Yes |
As the name suggests, this function returns the list of all blob containers in a storage account in WABS and all buckets owned by the authenticated sender of the request.
A few comments about List Containers:
- A single call to List Container functionality in WABS return a maximum of 5000 blob containers. If there are more than 5000 blob containers, WABS also return a continuation token using which next set of blob containers. By default WABS return up to 5000 blob containers but you can instruct WABS to return lesser number of blob containers as well. However the maximum is 5000.
- You can also perform server side filtering by instructing WABS to return only those blob containers whose names starts with a specified “prefix”.
- You can also instruct WABS to optionally return blob container metadata with the blob containers list as well.
Delete Container/DELETE Bucket
| WABS | AS3 | |
| Delete Container/DELETE Bucket | Yes | Yes |
As the name suggests, this function deletes a blob container and a bucket in WABS and AS3 respectively.
A few comments about this functionality:
- It might appear that Delete Container operation is a synchronous operation, in reality it is not. When you send a request to delete a blob container in WABS, it is marked for deletion by the system and is no longer accessible. The blob container is deleted through a garbage collection process. The actual time for deleting a blob container would among other things depend on the size of the data present in the blob container. In my experience, deleting a very large blob container could take hours. During this time an attempt to create a blob container by the same name would result in an error(Conflict error – HTTP Status Code 409). Thus a forethought must be put regarding the impact of this while deleting a table.
- In AS3, a bucket must be empty before it can be deleted. You would need to first delete all objects from a bucket before you can perform this operation on a bucket.
List Blobs/GET Bucket (List Objects)
| WABS | AS3 | |
| List Blobs/GET Bucket (List Objects) | Yes | Yes |
This function is used to get the list of blobs and objects in a blob container and bucket respectively. Both functions are almost identical in the sense that:
- In both functions you can limit how many number of blobs you want each function to return.
- Both functions have an upper limit on how many blobs the service will return. In case of WABS, it is 5000 while in case of AS3, it is 1000. What this means is that in a single call to this service, WABS can return a list consisting of a maximum of 5000 blobs while AS3 can return a list consisting of a maximum of 1000 objects.
- Both functions support the concept of a delimiter. In both systems, a delimiter is a character to group blobs or object. Most commonly used delimiter is “/”. As mentioned above, both WABS and AS3 support only two level hierarchy. Using a delimiter can create the illusion of a folder like hierarchy. For example, let’s say you have following blobs (or objects): images/a.png, images/b.png, images/c.png, logs/1.txt, logs/2.txt, files.txt. When you invoke this function and provide “/” as delimiter, both systems return the following: images, logs, and files.txt.
- Both functions support the concept of server side filtering the list by making use of what is called prefix. When your request contains a prefix, both systems will return the items which starts with that prefix. In the example above, if we provide prefix as “images” (and no delimiter) both systems will return the following: images/a.png, images/b.png, and images/c.png.
- Both functions support the concept of marker which is kind of a continuation token to instruct both systems to start listing the items from this marker.
- Both systems return items alphabetically.
There are a few differences as well:
- As mentioned above, in a single call to this function WABS can return a maximum of 5000 blobs while AS3 can return a maximum of 1000 objects.
- When fetching the list, you can instruct WABS to return snapshots for the blobs as well. In AS3, there is a separate function (GET Bucket Object versions) which is described below.
- When fetching the list, you can instruct WABS to return metadata for blobs as well. AS3 does not support metadata for blobs, thus it is not possible to fetch this information.
- When fetching the list, you can instruct WABS to return the list of blobs which are not yet committed (i.e. partially uploaded). AS3 only returns the objects which are fully uploaded.
Set Blob Service Properties/PUT Bucket logging
| WABS | AS3 | |
| Set Blob Service Properties/PUT Bucket logging | Yes | Yes |
As mentioned above, both systems provide the capability where you can log the requests made against your blob containers and buckets. This feature is not enabled by default and you would need to enable it manually. You would use this functionality to enable logging. It is known as Storage Analytics in WABS (or rather Windows Azure) and is for all three components of Windows Azure Storage (Table, Queue, and Blob Storage).
There are a few differences in the way logging is implemented in each system:
- In WABS the logging is enabled at blob storage level where as in AS3 it is done at a bucket level. What this means is that when you enable logging in WABS, it is enabled for all blob containers in a storage account where as when you enable logging in AS3, it is only enabled for a particular bucket. AS3 actually goes one level down also where you could enable logging for certain objects which start with a predefined “prefix”. For example, lets say you have a bucket called “data” and it contains objects of type say “images” and “errors”. If you have written image type objects with prefix say “siteimages”, then you could enable logging only for “siteimages” prefix. In this case AS3 would log only the requests against objects where the object name starts with “siteimages”.
- In WABS the logging data is stored in system defined Windows Azure Storage Table ($MetricsTransactionsBlob) and Blob Container ($logs) where as in AS3 this data is stored in a user defined bucket.
- In WABS you can only store up to 20 TB data as part of storage analytics. Furthermore the data is kept for a period of a maximum of 365 days after which it is purged. However when configuring storage analytics, you can instruct Windows Azure to keep this data for a smaller amount of time as well (say 30 days). In that case, data older than 30 days will be purged automatically by Windows Azure. Logging in AS3 does not have this restriction.
- In WABS only account owner has access to this data where as in AS3 you can provision for a fine grained control over who has access to this data and the rights (Full/Read/Write) over that data.
Get Blob Service Properties/GET Bucket logging
| WABS | AS3 | |
| Get Blob Service Properties/GET Bucket logging | Yes | Yes |
This function is used to get the information about logging configuration in each system. Since in AS3, a user other than the owner can also have access to this data, GET Bucket logging returns that information also along with the logging status.
Set Container ACL/PUT Bucket acl
| WABS | AS3 | |
| Set Container ACL/PUT Bucket acl | Yes | Yes |
This function is used to set the ACL for a blob container and a bucket. For a blob container in WABS, you can also define one or more access policies as well.
Possible ACL values for a blob container are:
- Full public read access (Container): Container and blob data can be read via anonymous request. Clients can enumerate blobs within the container via anonymous request, but cannot enumerate containers within the storage account.
- Public read access for blobs only (Blob): Blob data within this container can be read via anonymous request, but container data is not available. Clients cannot enumerate blobs within the container via anonymous request.
- No public read access (Private): Container and blob data can be read by the account owner only.
Possible ACL values for a bucket are:
- READ: When this ACL is granted on a bucket, it allows grantee to list the objects in the bucket.
- WRITE: When this ACL is granted on a bucket, it allows grantee to create, overwrite, and delete any object in the bucket.
- READ_ACP: When this ACL is granted on a bucket, it allows grantee to read the bucket ACL.
- WRITE_ACP: When this ACL is granted on a bucket, it allows grantee to write the ACL for the applicable bucket.
- FULL_CONTROL: When this ACL is granted on a bucket, it allows grantee the READ, WRITE, READ_ACP, and WRITE_ACP permissions on the bucket.
One neat thing about setting ACL in AS3 is that it is very fine grained in the sense that you can grant different set of permissions to different users. For example, I can set READ ACL for user1 while WRITE ACL for user 2. This flexibility is not there in WABS. You can only set only one kind of permission on a blob container there.
One neat thing about this function in WABS is that apart from setting the ACL, you can also set one or more (up to a maximum of 5) container level access policy. A container level access policy allows you to specify a time bound set of permissions. For example, you could create an access policy with “Write” permissions on a blob container which is valid for a day. Using this policy, you could then generate a URL which you can share with your users who would then be able to write to that blob container but only for the time period the policy is valid. Another advantage with using a container level access policy is that it gives you more flexibility in issuing Shared Access Signatures. A shared access signature permit you to provide access rights to blob containers and blobs at a more granular level than by simply setting a blob container’s permissions for public access. By specifying a Shared Access Signature, you can grant users access to a specific blob or to any blob within a specified container for a specified period of time.
Get Container ACL/GET Bucket acl
| WABS | AS3 | |
| Get Container ACL/GET Bucket acl | Yes | Yes |
This function is used to get the ACL for a blob container and a bucket. In case of WABS, this function also returns the access policies defined for that blob container.
List Blobs/GET Bucket Object versions
| WABS | AS3 | |
| List Blobs/GET Bucket Object versions | Yes | Yes |
As I mentioned above, both WABS and AS3 support versioning of blobs (called snapshots) and objects respectively albeit in an entirely different manner. This function is used to get the list of blob snapshots and object versions. In AS3, this function only returns versioned objects however in WABS the same can be accomplished through List Blobs functionality described above (by instructing WABS to return snapshots of blobs along with blobs).
Cool Tip: If you only want to fetch a list of snapshots of a blob in WABS or versions of a single object in AS3 you could call this function and pass the full name of the blob as prefix.
List Blobs/List Multipart Uploads
| WABS | AS3 | |
| List Blobs/List Multipart Uploads | Yes | Yes |
As I mentioned above, both WABS and AS3 support uploading a blobs and objects in chunks. In WABS when uploading “Block” blobs, you can split the blobs in blocks and then upload these blocks. Once all the blocks are uploaded you can then commit these blocks and then the blob will be available for consumption. Similarly in AS3 you can upload an object by splitting it into multiple parts and upload these parts. When all the parts are uploaded you can then complete the upload process by committing these parts.
List Multipart Uploads functionality in AS3 tells you the multipart uploads which are in progress i.e. an upload where object being uploaded is divided into parts and the process of uploading parts has started but is not either completed or aborted. WABS provide the same functionality through List Blobs functionality described above (by instructing WABS to return uncommitted blobs along with committed blobs).
Set Container Metadata
| WABS | AS3 | |
| Set Container Metadata | Yes | No |
This function is used to set one or more user defined name/value pairs for a blob container in WABS.
A few comments about this functionality:
- This function overwrites the existing metadata thus it is not possible to update just one name/value pair.
- The maximum size of metadata can be 8 KB.
- The metadata name must be a valid C# identifier.
Get Container Metadata
| WABS | AS3 | |
| Get Container Metadata | Yes | No |
This function is used to get the user defined metadata for a blob container.
PUT Bucket versioning
| WABS | AS3 | |
| PUT Bucket versioning | No | Yes |
Versioning allows you to maintain multiple copies of an object. This function allows you to enable versioning on every object in a bucket. Any time a PUT, POST, COPY, or DELETE operation is called on an object, a new version of an object is created which is the object just before the operation was performed on an object. By default this is not enabled on a bucket and you would use this function to enable the versioning. To disable/suspend versioning, you would again call this function.
I have mentioned that WABS does not support this functionality however that is not entirely true. WABS offer a feature called “Snapshot Blob” which when invoked creates a read only copy of the most current version of the blob.
However there are a few differences in the way versioning works in two systems:
- In AS3 it is specified at bucket level. Once versioning is enabled, it is applicable for all objects in that bucket and AS3 automatically starts keeping versions of objects as and when a PUT, POST, COPY, or DELETE operation is performed on those objects. Snapshot Blob feature in WABS work at blob level and you would need to call this function explicitly to take a snapshot. In this sense, WABS provide more flexibility as it works at individual blob level however it becomes the developer responsibility to create a snapshot of the blob.
- In WABS, once main blob is deleted all of its snapshots (read versions) are deleted as well. In AS3, that is not the case. In that sense, AS3 provides better protection against accidental deletes.
- As far as storage charges are concerned, in WABS you are only charged for the snapshot blocks which are different than the blocks in original blob. In AS3, each version of an object is treated like an object thus you pay same storage charges as you pay for an object.
GET Bucket versioning
| WABS | AS3 | |
| GET Bucket versioning | No | Yes |
This function is used to get the versioning state (Enabled or Suspended) of a bucket in AS3. An empty response is sent in case versioning is never enabled or suspended on a bucket.
PUT Bucket lifecycle
| WABS | AS3 | |
| PUT Bucket lifecycle | No | Yes |
AS3 has this neat feature where you can instruct it to delete objects from a bucket automatically after a certain period of time. For example, let’s say you are storing logs as objects in a bucket however you would want logs older than 30 days to delete automatically. AS3 can do it for you.
By default objects remain in bucket forever till the time you delete them. To have AS3 delete it for you, you use this functionality. Using this functionality you can either enable or disable automatic object deletion in a bucket by AS3. When you enable this functionality, you specify the number of days (let’s call it expiration date). Once lifecycle of a bucket is set, AS3 will automatically delete objects older than expiration date.
Another interesting thing about this function is that it is applicable at folder level. For example, let’s say you’re storing access logs and error logs in your “logs” bucket. For the sake of argument, let’s say you are storing all access related logs in “accesslogs” folder (i.e. logs are prefixed with “accesslogs”) and error related logs in “errorlogs” folder. In this functionality you have the capability to specify the lifecycle for all objects in just “accesslogs” folder. In this case AS3 will only remove objects from “accesslogs” folder automatically after they expire (i.e. AS3 will automatically delete objects with prefix “accesslogs” in “logs” bucket which have expired).
You can not however use this functionality if you have ever set versioning on a bucket.
GET Bucket lifecycle
| WABS | AS3 | |
| GET Bucket lifecycle | No | Yes |
This function returns the lifecycle configuration information set on the bucket.
DELETE Bucket lifecycle
| WABS | AS3 | |
| DELETE Bucket lifecycle | No | Yes |
This function deletes the lifecycle configuration information set on the bucket.
PUT Bucket policy
| WABS | AS3 | |
| PUT Bucket policy | No | Yes |
As mentioned above, AS3 provides many mechanisms to protect your buckets and object from unauthorized access. Bucket policy is one of them. Simply put a bucket policy defines access rights for AS3 resources. Using a bucket policy, a bucket owner could:
- Allow or deny any bucket level permissions.
- Grant or deny permission on any objects in a bucket.
To learn more about bucket policy, click here.
GET Bucket policy
| WABS | AS3 | |
| GET Bucket policy | No | Yes |
This function returns the policy for a bucket.
DELETE Bucket policy
| WABS | AS3 | |
| DELETE Bucket policy | No | Yes |
This function deletes the policy set on the bucket.
PUT Bucket notification
| WABS | AS3 | |
| PUT Bucket notification | No | Yes |
This is again a neat feature in AS3 where AS3 can send messages to an Amazon Simple Notification Service (SNS) topic when Amazon S3 detects a key event on a bucket. Subscribers to this topic can have messages for bucket events delivered to an endpoint such as a web server, e-mail address, or an Amazon Simple Queue Service queue.
In its current implementation, there is only one event for which notification will be sent out. That event is called “s3:ReducedRedundancyLostObject” and it is raised when AS3 detects it has lost all replicas of an object and can no longer service requests for that object.
You use this function to enable or disable the notification on bucket state change.
GET Bucket notification
| WABS | AS3 | |
| GET Bucket notification | No | Yes |
This function returns the notification configuration for a bucket.
PUT Bucket requestPayment
| WABS | AS3 | |
| PUT Bucket requestPayment | No | Yes |
By default the bucket owner pays for downloads from a bucket. However AS3 has this neat concept where a bucket owner can configure another account to pay for the downloads from a bucket. This function is used for that purpose. Using this setting, a bucket owner can specify that the person requesting the download will be charged for download. For more information regarding this, click here.
GET Bucket requestPayment
| WABS | AS3 | |
| GET Bucket requestPayment | No | Yes |
This function returns the request payment configuration for a bucket.
PUT Bucket website
| WABS | AS3 | |
| PUT Bucket website | No | Yes |
Yet another neat feature in AS3 is the capability to host static websites in buckets. It’s true that the same can be achieved with WABS as well but what you can’t do there is specify a default document, an error document as well as you can’t point a custom domain name to that website. All of this you can do here in AS3. To learn more about hosting static websites in a bucket in AS3, click here.
Using this function, you can configure a bucket to be used as a static website. You can provide a default document for your website as well as documents when an error occurs (e.g. 404 error).
GET Bucket website
| WABS | AS3 | |
| GET Bucket website | No | Yes |
This function returns the website configuration for a bucket.
DELETE Bucket website
| WABS | AS3 | |
| DELETE Bucket website | No | Yes |
This function removes the website configuration for a bucket.
HEAD Bucket
| WABS | AS3 | |
| HEAD Bucket | No | Yes |
This simple function can be used to identify if a bucket exists and the caller has permission to access the bucket.
Summary
While fundamentally both services provide similar kind of functionality, IMO Amazon S3 is more rich when it comes to features. It is partly because Amazon had 2+ years of head start. I sincerely hope that Windows Azure Blob Storage catches up with them and provide some of the features that are currently missing and are desperately needed. Personally the features I really liked in Amazon S3 which are either not there or could be improved upon in Windows Azure Blob Storage (not in the order of preference):
- Ability to host static websites like Amazon S3.
- Fine grain access control.
- Automatic content deletion.
- Better versioning especially even if you delete the base item the version stays.
- Something similar to Reduced Redundant Storage.
Likewise I would like to see the following in Amazon S3:
- Being able to delete a bucket without deleting objects first. IMO it’s a major operation overhead.
- Consolidation of some functions e.g. Get Bucket, Get Bucket versioning, and List Multipart Uploads can be easily consolidated into one function.
A few comments (Disclaimers)
- It is not the intent of the blog post to prove that one service is superior over other. I just wanted to have a very objective comparison of these two services.
- I make my living using Windows Azure Platform (if you wish, you can call me Windows Azure fan boy
). This does not mean that I have negative things to say about Amazon Cloud Computing Platform. It’s just that I never had a chance to play with Amazon just yet. - Since I haven’t played with Amazon platform just yet, the information I have presented in this blog post about Amazon S3 is solely based on my understanding of this service based on the documentation. Very likely, I may be wrong about some of things I have written here. Please note that it is not done intentionally and you can blame my lack of knowledge for that. If you find such issues, please let me know and I will fix them ASAP.
