通过阅读Windows Azure Drives whitepaper，我能够回答我的一些问题，其中详细解释了如何使用Page Blobs 创建 Azure 驱动器。这意味着它应该包含在Windows Azure Storage SLA 之下，该声明指出：
Windows Azure 对计算和存储有单独的 SLA。对于计算，我们保证当您在不同的故障和升级域中部署两个或多个角色实例时，您面向 Internet 的角色将至少在 99.95% 的时间具有外部连接。此外，我们将监控您的所有个人角色实例，并保证 99.9% 的时间我们会检测到角色实例的进程何时未运行并采取纠正措施。
对于存储，我们保证至少 99.9% 的时间我们将成功处理我们收到的格式正确的添加、更新、读取和删除数据的请求。我们还保证您的存储帐户将连接到我们的 Internet 网关。
这为需要访问 Azure 驱动器的存储或角色提供了大约 26.28 minutes 的年度停机时间窗口（用于 Web/工作角色）和 52.56 minutes 用于需要访问 Azure 驱动器的存储或角色。 Windows Azure 具有类似于 Amazon AWS 提供的区域，但在区域内它们没有不同的可用区。相反，他们有Upgrade Domains and Fault Domains，用于推出更新和定位role instances on different hardware racks。故障域不是用户可配置的，因此如果您想要更高级别的可用性，您必须在另一个区域设置单独的服务。
我找不到关于如何创建 Amazon EBS 驱动器的类似描述，但它们似乎是 actually NOT backed by Amazon S3，而是一个单独的存储系统。 Amazon S3 SLA 提供99.999999999% durability and 99.99% availability，但针对 EBS 提到的只是：
Amazon EBS 卷放置在特定的可用区内，然后可以附加到同一可用区内的实例。
每个存储卷都会自动复制到同一个可用区内。这可以防止由于任何单个硬件组件故障而导致数据丢失。
Amazon EBS 还提供创建卷的时间点快照的功能，这些快照会持久保存到 Amazon S3。这些快照可用作新 Amazon EBS 卷的起点，并保护数据以实现长期持久性。同一个快照可用于实例化任意数量的卷。
他们还指出，与典型的硬盘驱动器每年大约 4% 的故障率相比，EBS 的预期年故障率在 0.1% 到 0.5% 之间。由于 EBS 卷完全基于一个可用区，因此为备份创建快照也很重要：
EBS 卷具有内置冗余，这意味着如果单个驱动器发生故障或发生其他一些单一故障，它们不会发生故障。但它们不像 S3 存储那样冗余，后者将数据复制到多个可用区：一个 EBS 卷完全存在于一个可用区中。这意味着制作存储在 S3 中的快照备份对于长期数据保护非常重要。
最近EBS/EC2 outage 的事后报告有更多关于 EBS 架构的详细信息，并表明触发是无效的网络配置更改。这一变化导致许多卷与它们的镜像解除关联，quickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica. 这与一些竞争条件、不正确的回退超时和软件错误相结合，导致了影响多个可用区的长时间中断。亚马逊表示，他们正在采取一些措施来防止这种情况在未来发生，包括使 EBS 控制平面更能容忍各个可用区中的故障。
最后，designed to expect and tolerate failures 的系统受 AWS 中断的影响要小得多。至少，任何使用 Azure Drives 或 Amazon EBS 的系统都应该使用提供的快照功能创建定期备份，甚至可能需要考虑将快照传送到单独的区域或完全独立的存储提供商。