亚马逊发布了SLA，但在设计弹性多可用性区域和多区域系统时，是否可以计算总体正常运行时间（如呈现给用户）？
例如，在同一地区的3个不同可用区域中使用ELB的3个EC2实例与2个不同区域中的4个EC2实例相比，可能的正常运行时间是多少？
然后，当我们添加RDS实例，Route 53，Cloudfront等时，可能产生的影响（正面和负面）是什么？
其他因素，例如RDS故障切换时间，云端缓存等，理想情况下应该是计算输入的一部分。
或者 - 假设一个99.9x％的区域和两个区域的数字为99.99x％更好？
编辑 - 我正在尝试计算“精心设计的面向Web的AWS解决方案”的可能停机时间（对于所有/大多数用户）。理想情况下，我会喜欢AWS定价工具（或定价工具输出）来计算每月或一年以上的停机时间。这样我可以计算不同设计的成本和风险，例如RDS真的需要多个AZ，每月额外收费100美元。
答案 0 :(得分：1)
计算系统的理论正常运行时间很困难，因为您需要准确确定“正常运行时间”的含义。
例如，如果有网络中断导致您的某些用户可以访问系统，但有些用户无法访问系统，那么整个系统是否会被视为“宕机”？
另外，：
之间存在差异使用多个可用区是一个很好的设计决策，因为影响一个AZ的中断不应影响另一个AZ 。但是，没有关于AZ正常运行时间的公开声明。 （实际上，整个可用区域没有任何历史中断，但有时一个可用区域内的单个服务可能会受到问题的影响。）
由于可用区是为此目的而设计的，因此也不需要使用多个区域来实现更长的正常运行时间。但是，一些组织确实选择使用多个区域（例如，当飓风桑迪威胁美国东海岸时）。
大多数AWS服务旨在处理故障。例如，亚马逊Route 53有一个"100% Available" SLA，因为它存在于全球50多个地方。
底线：如果您设计的解决方案至少使用了两个可用区并考虑了故障（例如Amazon RDS中的多可用区模式，则在Amazon S3中存储数据会自动在两者之间复制AZs），那么你将拥有一个高度可用的架构，应该能够处理大多数故障。实际上，设计一个高度可用的系统比计算理论百分比要好。