entityMap|blocks|key|3h452|text|在您发疯并尝试设计高SLA系统之前，请仔细考虑。99.9%25的正常运行时间是相当容易实现的，成本适中。超过这一点，你的成本就会迅速上升。对于每增加9个，考虑成本增加10倍到100倍。此成本包括云基础设施、管理、监控和警报软件以及人员成本。您将花费大量时间来管理提供大于3个9+(99.9%25)的SLA的系统。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|74tbb|99.99%25的utime意味着每周只有1分钟的停机时间。这包括你需要花在修补操作系统、更新软件、备份等方面的时间。你能在每周1分钟内完成所有这些工作吗？如果不是，你不会得到4个9+(99.99%25)。犯了一个错误，你的4个9的目标就会变成2个9。|fptae|亚马逊CloudFront提供99.9%25的正常运行时间。这是非常好的。为了达到更高的要求，您需要提供多个源(+CloudFront缓存并交付给最终用户的数据源)。您的原始成本只是价格的两倍，这还不包括保持两个原始成本24x7完全同步的工作负载。任何停机时间或你的起源和你的4个9的问题都被抛在了脑后。|an50f^0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|H|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|I|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|J|9|@]|A|@]|B|$]]|$2|G|4|-4|6|7|8|K|9|@]|A|@]|B|$]]]]

Before you go crazy and try to design high SLA systems, think it through. 99.9% uptime is fairly easy to achieve at moderate cost. Go beyond that and your costs go up rapidly. For each addition 9, think 10x to 100x cost increase. This cost includes cloud infrastructure, management, monitoring and alerting software and the person costs. You will spend a lot of time managing systems that provide an SLA greater than 3 nines (99.9%).

99.99% utime means only 1 minute per week of downtime. This includes time that you need to spend patching operating systems, updating software, backing up, etc. Can you do all of that in 1 minute each week? If not, you won't achieve 4 nines (99.99%). Make a mistake and your 4 nines goal will become two nines.

Amazon CloudFront provides for 99.9% uptime. This is pretty good. To go higher, you need to provide multiple origins (sources for data that CloudFront caches and delivers to end users). Your origin costs just doubled in price not counting the workload to keep both origins exactly in-sync with each other 24x7. Any downtime or problems with your origins and your 4 nines just went out the window.

entityMap|blocks|key|8oef1|text|正如其他人提到的，这将引入更多的成本和复杂性，所以我的想法如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6i0rv|您可以借助Route53+(其SLA为100%25)来提高可用性。|f24p2|首先，我会将您在Cloudfront上提供的对象的副本放在不同的服务上，例如EC2+(请参阅复杂性如何开始增长)。|e74ns|然后，您需要设置故障转移路由策略。基本上，Route53会检查您的Cloudfront发行版的健康状况，如果它不健康，那么流量将故障转移到EC2。|7aba2|现在你的服务水平协议将上升到99.89%25+(99.99%25+EC2+*99.9%25CloudFront)|6j0tr^0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|L|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|M|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|N|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|O|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|P|9|@]|A|@]|B|$]]|$2|K|4|-4|6|7|8|Q|9|@]|A|@]|B|$]]]]

As others mentioned, this will introduce more costs and complexity, so here goes my idea:

You can increase availability with the help of Route53 (which has a SLA of 100%).

First, I would have a copy of the objects you're serving on Cloudfront on a different service, for example, EC2 (see how complexity starts to grow).

Then you'd need to setup a failover routing policy. Basically Route53 would check the health of your Cloudfront distribution and if it's not healthy then the traffic would failover to EC2.

Now your SLA will go up to 99.89% (99.99% EC2 * 99.9% Cloudfront)

entityMap|blocks|key|frik1|text|可以将CloudFront视为CDN+(类似于Akamai和其他CDN)。即，它是可以驻留在S3或其他源上的静态内容的高速缓存。即使CloudFront关闭，您的系统仍然99.99%25可用(如果这样设计的话)，因为您的系统边界是VPC边缘，而不是CloudFront、Route53、S3等(这些接口被您的系统视为外部接口，并且处于公共区域，除非您与它们建立专用连接)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|ccovm^0|0^^$0|$]|1|@$2|3|4|5|6|7|8|D|9|@]|A|@]|B|$]]|$2|C|4|-4|6|7|8|E|9|@]|A|@]|B|$]]]]

Think of CloudFront as CDN (similar to Akamai and other CDN). I.e. it is a cache for static content that can reside on S3 or other origins. Even if CloudFront goes down your system is still 99.99% available (if designed that way), because your system boundary is VPC edge and not CloudFront, Route53, S3 etc. (these are regarded as external interfaces by your system and are in public zone unless you build a private connection to them).

I'm trying to design a system on AWS cloud with a certain level of SLA (say 99.99). 
One of the elements of my architecture is CloudFront and at this point, I'm struggling to understand if it's possible to increase the availability of it by introducing redundancy. Usually, it works, e.g. ECS containers or EC2 instance or RDS, but it's not possible for cloudfront (as far I a found).

What I've got so far: 

<a href="https://aws.amazon.com/ru/cloudfront/sla/" rel="noreferrer">here</a> it says that SLA is from 99 to 99.9

<a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html" rel="noreferrer">and here</a> it says that I can increase the availability having multiple Origins (CDNs), but to me, it seems like I would increase the availability of CDN, but not CloudFront service itself, wouldn't I?

Could somebody correct my understanding if it's wrong or/and explain the correct way of increasing SLA for CloudFront service?

AWS Cloudfront availability SLA

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

 我正在尝试在AWS云上设计一个具有一定SLA级别(比如99.99)的系统。我的架构的元素之一是CloudFront，在这一点上，我正在努力理解是否可以通过引入冗余来增加它的可用性。通常，它可以工作，例如ECS容器或EC2实例或RDS，但这对于cloudfront是不可能的(据我所知)。 到目前为止，我得到的是： he...

问AWS Cloudfront可用性SLA
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问AWS Cloudfront可用性SLAEN