AWS Cloudfront 可用性 SLA
AWS Cloudfront availability SLA
我正在尝试在 AWS 云上设计一个具有特定级别 SLA（比如 99.99）的系统。
我的架构的元素之一是 CloudFront，此时，我正在努力了解是否可以通过引入冗余来提高它的可用性。通常，它有效，例如ECS 容器或 EC2 实例或 RDS，但它不可能用于云端（据我所知）。
到目前为止我得到了什么：
here 它说 SLA 是从 99 到 99.9
and here 它说我可以增加具有多个来源 (CDN) 的可用性，但对我来说，我似乎会增加 CDN 的可用性，但不会增加 CloudFront 服务本身，不是吗？
有人可以纠正我的理解吗or/and解释增加 CloudFront 服务 SLA 的正确方法？
在您发疯并尝试设计高 SLA 系统之前，请三思而后行。以适中的成本很容易实现 99.9% 的正常运行时间。超出这个范围，您的成本就会迅速上升。对于每增加 9，认为成本增加 10 倍到 100 倍。该成本包括云基础设施、管理、监控和警报软件以及人员成本。您将花费大量时间管理提供大于 3 个九 (99.9%) 的 SLA 的系统。
99.99% 的 utime 意味着每周只有 1 分钟的停机时间。这包括您需要花在修补操作系统、更新软件、备份等方面的时间。您能否每周在 1 分钟内完成所有这些工作？否则，您将无法获得 4 个九 (99.99%)。犯了一个错误，你的 4 个九的目标将变成两个九。
Amazon CloudFront 提供 99.9% 的正常运行时间。这很好。为了更上一层楼，您需要提供多个来源（CloudFront 缓存并交付给最终用户的数据来源）。您的源站成本刚刚翻了一番，这还不包括保持两个源站 24x7 完全同步的工作量。您的起源和您的 4 个九的任何停机时间或问题刚刚消失 window。
正如其他人提到的，这会带来更多的成本和复杂性，所以我的想法是：
您可以借助 Route53（其 SLA 为 100%）提高可用性。
首先，我会在其他服务（例如 EC2）上获得您在 Cloudfront 上提供的对象的副本（看看复杂性如何开始增长）。
然后您需要设置故障转移路由策略。基本上 Route53 会检查您的 Cloudfront 分配的健康状况，如果它不健康，那么流量将故障转移到 EC2。
现在您的 SLA 将达到 99.89%（99.99% EC2 * 99.9% Cloudfront）
将 CloudFront 视为 CDN（类似于 Akamai 和其他 CDN）。 IE。它是静态内容的缓存，可以驻留在 S3 或其他源上。即使 CloudFront 出现故障，您的系统仍具有 99.99% 的可用性（如果以这种方式设计），因为您的系统边界是 VPC 边缘，而不是 CloudFront、Route53、S3 等（这些被您的系统视为外部接口，位于 public 区域，除非您与它们建立专用连接）。
我正在尝试在 AWS 云上设计一个具有特定级别 SLA（比如 99.99）的系统。 我的架构的元素之一是 CloudFront，此时，我正在努力了解是否可以通过引入冗余来提高它的可用性。通常，它有效，例如ECS 容器或 EC2 实例或 RDS，但它不可能用于云端（据我所知）。
到目前为止我得到了什么：
here 它说 SLA 是从 99 到 99.9
and here 它说我可以增加具有多个来源 (CDN) 的可用性，但对我来说，我似乎会增加 CDN 的可用性，但不会增加 CloudFront 服务本身，不是吗？
有人可以纠正我的理解吗or/and解释增加 CloudFront 服务 SLA 的正确方法？
在您发疯并尝试设计高 SLA 系统之前，请三思而后行。以适中的成本很容易实现 99.9% 的正常运行时间。超出这个范围，您的成本就会迅速上升。对于每增加 9，认为成本增加 10 倍到 100 倍。该成本包括云基础设施、管理、监控和警报软件以及人员成本。您将花费大量时间管理提供大于 3 个九 (99.9%) 的 SLA 的系统。
99.99% 的 utime 意味着每周只有 1 分钟的停机时间。这包括您需要花在修补操作系统、更新软件、备份等方面的时间。您能否每周在 1 分钟内完成所有这些工作？否则，您将无法获得 4 个九 (99.99%)。犯了一个错误，你的 4 个九的目标将变成两个九。
Amazon CloudFront 提供 99.9% 的正常运行时间。这很好。为了更上一层楼，您需要提供多个来源（CloudFront 缓存并交付给最终用户的数据来源）。您的源站成本刚刚翻了一番，这还不包括保持两个源站 24x7 完全同步的工作量。您的起源和您的 4 个九的任何停机时间或问题刚刚消失 window。
正如其他人提到的，这会带来更多的成本和复杂性，所以我的想法是：
您可以借助 Route53（其 SLA 为 100%）提高可用性。
首先，我会在其他服务（例如 EC2）上获得您在 Cloudfront 上提供的对象的副本（看看复杂性如何开始增长）。
然后您需要设置故障转移路由策略。基本上 Route53 会检查您的 Cloudfront 分配的健康状况，如果它不健康，那么流量将故障转移到 EC2。
现在您的 SLA 将达到 99.89%（99.99% EC2 * 99.9% Cloudfront）
将 CloudFront 视为 CDN（类似于 Akamai 和其他 CDN）。 IE。它是静态内容的缓存，可以驻留在 S3 或其他源上。即使 CloudFront 出现故障，您的系统仍具有 99.99% 的可用性（如果以这种方式设计），因为您的系统边界是 VPC 边缘，而不是 CloudFront、Route53、S3 等（这些被您的系统视为外部接口，位于 public 区域，除非您与它们建立专用连接）。