通过阅读Windows Azure 驱动器白皮书，我能够回答我的一些问题，该白皮书详细解释了如何使用Page Blobs创建 Azure 驱动器。这意味着它应包含在Windows Azure 存储 SLA中，该 SLA 规定：
Windows Azure 对计算和存储有单独的 SLA。对于计算，我们保证当您在不同的故障和升级域中部署两个或多个角色实例时，您面向 Internet 的角色将至少在 99.95% 的时间具有外部连接。此外，我们将监控您的所有个人角色实例，并保证 99.9% 的时间我们将检测到角色实例的进程何时未运行并启动纠正措施。
对于存储，我们保证至少 99.9% 的时间我们将成功处理我们收到的添加、更新、读取和删除数据的格式正确的请求。我们还保证您的存储帐户将连接到我们的 Internet 网关。
这为 web/worker 角色提供了大约26.28 分钟的年度停机时间窗口，为需要访问 Azure 驱动器的存储或角色提供了52.56 分钟的停机时间窗口。Windows Azure 具有类似于 Amazon AWS 提供的区域，但在区域内它们没有不同的可用区。相反，它们具有升级域和故障域，用于在不同的硬件机架上推出更新和定位角色实例。故障域不是用户可配置的，因此如果您想要更高级别的可用性，您必须在另一个区域设置单独的服务。
我无法找到有关如何创建Amazon EBS驱动器的类似描述，但似乎它们实际上不受 Amazon S3 支持，而是一个单独的存储系统。Amazon S3 SLA 提供99.999999999% 的持久性和 99.99% 的可用性，但 EBS 提到的只是：
Amazon EBS 卷放置在特定的可用区中，然后也可以附加到同一可用区中的实例。
每个存储卷都会在同一可用区内自动复制。这可以防止由于任何单个硬件组件的故障而导致数据丢失。
Amazon EBS 还提供创建卷的时间点快照的能力，这些快照被持久化到 Amazon S3。这些快照可用作新 Amazon EBS 卷的起点，并保护数据以实现长期持久性。同一个快照可用于实例化任意数量的卷。
他们还指出，与典型的硬盘驱动器每年大约 4% 的故障率相比，EBS 的预期年故障率在 0.1% 到 0.5% 之间。由于 EBS 卷完全基于一个可用区，因此为备份创建快照也很重要：
EBS 卷具有内置冗余，这意味着如果单个驱动器发生故障或发生其他一些单一故障，它们不会发生故障。但它们不像 S3 存储那样冗余，后者将数据复制到多个可用区：一个 EBS 卷完全存在于一个可用区中。这意味着制作存储在 S3 中的快照备份对于长期数据保护非常重要。
最近EBS/EC2 中断的事后报告有更多关于 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 控制平面更能容忍单个可用区的故障。
最后，旨在预期和容忍故障的系统受 AWS 中断的影响要小得多。至少，任何使用 Azure Drives 或 Amazon EBS 的系统都应该使用提供的快照功能创建定期备份，甚至可能需要考虑将快照传送到单独的区域或完全独立的存储提供商。