立刻来评估一下领先的云平台成本，包括且不仅限于Cloudflare、Amazon Web Services、Google cloud、Microsoft Azure、阿里巴巴云、Oracle和IBM云。这个工具的设计目的在不会向你提出大量专业的技术问题的情况下来评估成本
评测结果应该会为您的无服务器应用的托管提供一个大致的成本。但是低效的代码架构，冗余的代码和糟糕的DevOps会影响到该工具最终预估的准确度。同样的，有着优秀优化的应用也会影响到最终的准确度。
我们为您提供免费的咨询，回答您的任何问题，并且协助您，为您的评估申请进行调整。
此页面是开发预览。请不要共享此页。内容可能更改，待验证。
有关每个参数的更多详细信息，请参见以下部分。
让我们想象一下，有两个应用程序的保有数据需求截然不同，一个是像Netflix这样的视频流应用程序，另一个是物流管理应用程序。视频流应用程序的数据存储将针对相对较大的数据块进行优化，这些数据块以较低的级别管理，除了读取数据块的频率之外，没有特别重要的意义。应用程序有一个简单的视频存储键的需要。另一方面，物流管理应用程序会有许多复杂的计算和大量的关系数据。物流应用程序的持久数据存储需求将是针对关系数据优化的数据库，可能超过数千个数据点。
根据大多数云平台的定价差异，这些地区分为全球、澳大利亚和中国。对中国来说，还有监管方面的原因。有关更多信息，请阅读带宽选项卡。
此工具不适用于具有大量不常访问数据的任何应用程序。如果你仍然希望使用这个工具来获得一个大概的数字，但是如果替换成一个更合适的数据存储解决方案可能只花费估计量的十分之一。
为了提供尽可能少的问题的评估，我们正在使用一种方法，将您的输入详细信息自动匹配到众多预定义模型中的一个，然后将其用作评估的基础。
大多数应用程序的架构和软件工程需求可简单化为少数几个模型。例如视频流应用程序的需求与物流规划应用程序截然不同。
包括GCP、AWS、阿里巴巴云和微软Azure在内的云服务提供商提供了许多不同的数据存储服务，这些服务与不同应用的需求相关。这种情况不仅存在于数据存储领域，而且存在于几乎每一个方面，这使得为您的应用程序需求确定合适的服务有点像雷区。一个服务到另一个服务在性能和成本上可能会有很大的不同。简化的模型用于定义各种云服务提供商提供的适用服务，然后可以根据您的输入参数计算成本。
最终，需要将所有这些指标分解为请求、数据存储、带宽和地区的基本计费单位，以便提供易于理解的标准化比较。
这些基本的计费单元都有各自的复杂之处，需要在复杂的计算中得到最终的估计。此外，不同供应商如何计算一个单位的价格的标准是不同的。
同样，预定义的应用程序模型被用于指定不同云提供商各自计算最终单价所需的所有复杂细节的方式。
即时估计工具将首先计算调整后的全球平均价格（不包括澳大利亚和中国），因为这两个地区有者更高的带宽费率。此外，在中国，每种云平台都有其自身的复杂性，这些复杂性导致了不同解决方案的不同定价。
该工具提供了输入选项来指定澳大利亚和中国的用户百分比。澳大利亚/中国的用户数是为澳大利亚/中国用户提供服务的额外成本总和。但在某些情况下，中国的部分完全从请求、数据存储和带宽中减去，然后集中到中国估算中，因为需要一个完全不同的解决方案，而不适用于各个供应商的估算。
为澳大利亚和中国的用户提供服务所产生的成本超出了其他地区，因此额外成本的总和在估算结果中显示为单独的一行。对于区域估计的简化示例，假设全球带宽率为0.12美元/GB，但澳大利亚地区的带宽为0.19美元/GB，因此每GB额外的0.07美元计入澳大利亚地区的总和。
对于请求单元的计算，每个云平台都有自己的复杂之处。下面是计算单个请求成本的每个云平台方法的简化分解。因为所有的云平台都计算标准不统一，所以在这个细分中，这些请求的数量将被标准化为百万分之一的成本。
为了简化比较，以下所有表都是根据5ms CPU时间和128MB内存分配计算的，但是即时估计工具根据应用程序模型和输入参数，使用CPU时间和 GB-秒 的动态计算。
请考虑5ms的CPU时间与真实时间是不同的。有时甚至会经历数百毫秒的挂机时间，一些云平台（如GCP）将根据挂机时间向您收取Ghz-s费用，尽管在等待I/O或API子请求时大部分处于空闲状态。
我们在下面的成本表中没有考虑现实时间，因为在我们开发无服务器应用程序的方式中，现实时间和CPU时间几乎没有区别。此工具中使用的模型定义了我们如何开发无服务器应用程序，对于我们来说，我们通过以不同方式处理子请求的任何需要，并仔细考虑Javascript如何工作以实现超高的CPU利用率，消除了现实时间和CPU时间之间的巨大差距，并并行处理多个事情，尽管是单线程的。
任何时候你需要使用I/O或者通过网络发送一些东西，这将比你在CPU上处理的时间要长几百倍，因此对于初学者来说，让我们关注一个典型的中间件案例，它涉及到你的面向客户的API必须与你的本地后端API通信。
让我们设想一种情况，您正在运行自己的内部架构来发送短信。你有一个API，客户可以从后端以JSON的形式按需发送短信。
通常情况下，我们会将无服务器页面用作中间件来处理边缘上的最小逻辑，并向后端发出子请求，等待响应，然后最终根据子请求的最终结果返回对客户API请求的响应。
这个典型的中间件请求-响应周期的问题是，当API通过internet连接到本地服务器并等待响应时，它可能会等待数百毫秒。
因此，如何加快API响应并减少大量的挂机时间，是通过将所有验证逻辑移到边缘来实现的。因为保证成功的子请求所需的所有逻辑都已移动到边缘，所以不需要立即处理子请求，而是可以立即响应客户的API请求并将其SMS排队以异步发送。
从您的内部架构出发，它将接触到边缘节点，并从队列中获取任意SMS，以便在配置的并发时您的内部基础架构能够处理。
正确地实施，短信将比以前发送不再需要任何多余时间，所以将削减大量的现实时间，巧妙地增加了对需求激增的保护。
根据您的团队开发无服务器应用程序的方式，差异可能会有所不同。
Cloudflare Workers每个请求的上限为50ms，每个请求的固定内存分配为128MB。与AWS和GCP不同的是，调整内存分配没有灵活性，如果不转移到Workers的非绑定产品上，50ms的CPU时间就无法延长，而该产品的成本要高得多。也就是说，128MB的内存分配和50ms的CPU时间是非常慷慨的，在大多数情况下是足够的。一般时间的时间限制是15分钟。
| 1,000,000 请求 x 0.0000005 = $0.50 |
| 每百万0.50美元 |
亚马逊的Lambda@Edge对每个请求收取基本价格，外加GB秒。CPU时间与Lambda@Edge因为GB秒度量是基于现实时间的。挂机时间通常为GB秒，因为在执行代码的整个过程中都需要分配内存，即使进程在等待I/O或API响应时大部分处于空闲状态。
| 1000000个请求 x 0.0000006 = 0.60美元 |
| 625.00 GB-s x 0.00005001 = $0.03 |
| 每百万0.63美元 |
谷歌的托管功能对每一个请求加上Ghz秒和GB秒收取一个基础价。这里需要注意的一点是，Ghz秒和GB秒都是基于现实的，并且每一个请求都四舍五入到100ms；这是难以理解的，因为Ghz秒是CPU时间的一个度量值，将每个请求的两个度量值凑到100ms可能会使您的账单与您的期望有很大的差异。
详细的解释一下上述内容；想象一下，你在超市购物时，他们不是把你的总数凑成元，而是把每一个商品凑成向上取整凑成元。
| 1000000个请求 x 0.0000004=0.40美元 |
| 20,000 GHz-s x 0.0000025 = $0.05 |
| 12,800 GB-s x 0.0000100 = $0.128 |
| 每百万0.578美元 |
上表为一级定价，仅包括3个美国、2个欧洲和3个亚洲销售点。启用第二级区域将使您获得额外的14个存在点，包括在澳大利亚的存在。二级定价是：
| 1000000个请求 x 0.0000004 = 0.40美元 |
| 20,000 GHz-s x 0.0000035 = $0.07 |
| 12,800 GB-s x 0.0000140 = $0.1792 |
| 每百万0.6492美元 |
保有数据存储的计算首先取决于哪个存储解决方案适合您的应用程序，对于这个评估工具，我们将选项进行简化，只包括每个云提供商提供的键值解决方案和关系数据库解决方案。
在规划和开发阶段，需要仔细和彻底地关注数据结构、行为和交互。糟糕的数据结构决策和草率的交互会对应用程序的性能和运营成本造成严重影响。
尽管评估工具只考虑每个提供商的2个解决方案，但大多数云服务提供商提供了各种各样的数据解决方案，这些解决方案也应该得到充分考虑。
Cloudflare只提供一个用于持久数据存储的本机解决方案，这是一个简单的键值存储。对于任何无法以加密方式解析的真正复杂的关系数据，则有必要使用第三方关系数据库服务。
| 每百万次读取 | $0.50 |
| 每百万次写入 | $0.50 |
| 每百万删除 | $5 |
| 每百万个列表 | $5 |
| 每百万个列表 | $5 |
| 每GB带宽 | 不适用 |
| 每千兆字节传输 | 免费 |
一个成本示例，将100MB文件存储在Cloudflare Workers KV上，并为该文件提供一次服务，达到1000个用户。考虑到单个KV存储区的最大大小为25MB，文件需要分成4部分。根据文件的性质，您甚至可能希望将其划分更多次，以优化KV存储区、工作节点和用户之间的交付。
| 100MB存储量 | $0.05/月 |
| 1个worker调用来处理用户保存文件的请求 | $0.0000005 |
| 将100MB文件以每部分25MB写入KV | $0.00002 |
| 1000个辅助进程调用来处理用户下载文件的请求 | $0.0005 |
| 4000次读取，因为文件被分成25MB的部分 | $0.002 |
| KV和Worker之间的数据传输 | No charge |
| Worker和用户之间的带宽 | No charge |
| 总计 | $0.0525205 |
Cloudflare不提供任何跨多个区域的数据复制和扩展控制，而是根据每个项目的读取频率和从哪个区域读取来自动处理。Cloudflare在跨多个区域和数据中心复制和扩展数据时不收取任何额外费用。跨地区不适用。
对于键值性质的持久数据存储，我们将在本例中使用Amazon S3 标准。我们将使用新加坡的位置，请注意，价格将因地区而异。
| 每GB存储 | $0.025 |
| 每百万次读取 | $0.40 |
| 每百万次写入 | $5 |
| 每百万次删除 | No charge |
| 每百万次列表 | $5 |
| 每GB带宽 | $0.12 |
| 每GB传输 | $0.09* |
在S3标准上存储一个100MB文件，并向1000个用户提供一次该文件的成本示例。在这个例子中，我们假设真相的来源是在新加坡，但所有1000个用户请求都来自世界其他地方，这意味着将产生跨地区数据传输费用。该示例适用于结合使用S3标准和Lambda@Edge。
| 100MB保有存储 | $0.0025/月 |
| 1个lambda调用来处理用户保存文件的请求 | $0.00005061 |
| 从Lambda到S3的同一区域带宽 | 免费 |
| 将100MB文件写入S3 | $0.000005 |
| 1000个lambda调用来处理用户下载文件的请求 | $0.05061 |
| 跨区域从S3到Lambda节点的1000次读取 | $0.0004 |
| S3和Lambda之间跨区域的数据传输 | $9 |
| Lambda与用户之间的带宽 | $12 |
| 总计 | $21.05356561 |
*S3存储和在同一区域中为请求提供服务的节点之间的数据传输不会产生任何成本，但这在应用程序中可能很复杂，很可能访问持久性数据的数据传输成本仍然是一个巨大的成本。从S3直接向用户传输数据，或非amazon服务器传输数据将按每千兆字节0.12美元的费率收费。
Amazon Aurora是一个用于云应用的SQL关系数据库。我们将很快添加一个定价表和场景成本示例。
相较于键值对存储的数据中的保有数据，我们将在本例中使用Google Firestore。价格在两个层次的地区有所不同。对于定价表，我们将使用香港区，因为没有新加坡选项。香港区位于第一级别，比第二级别便宜。
| 每GB存储 | $0.18 |
| 每百万次读取 | $0.60 |
| 每百万次写入 | $1.80 |
| 每百万次删除 | $0.20 |
| 每百万个列表 | 不支持 |
| 每GB带宽 | $0.14* |
| 每千兆字节传输 | $0.14* |
在Firestore上存储一个100MB文件，并向1000个用户提供一次该文件的成本示例。对于这个例子，我们假设来源是在香港，但所有1000个用户请求位于其他地方，但不是在澳大利亚或中国，因为这将招致更高的成本。
| 100MB保有存储 | $0.018/month |
| 1个云函数调用来处理用户保存文件的请求。 | $0.0000129 |
| 从云功能到Firestore的同一区域带宽 | 免费 |
| 将100MB文件写入Firestore | $0.0000018 |
| 1000个云函数调用来处理用户下载文件的请求 | $0.0129 |
| 从Firestore到云函数的1000次跨区域读取 | $0.0000006 |
| Firestore和云功能之间跨区域的数据传输 | $14 |
| 云功能与用户之间的带宽 | $14 |
| 总计 | $28.0309153 |
*每千兆字节的带宽和传输价格取决于您所在真实来源的地区，例如，如果您地区在美国，并且您需要在位于美国的其他地区之间移动数据，则每千兆字节的成本仅为0.01美元；在同一个多区域之间传输数据是免费的。上表中引用的每千兆字节带宽和传输成本适用于您的用户不在您的真实来源地区，但不在澳大利亚或中国有自己的费率。对于澳大利亚，如果您的数据不在澳大利亚，每千兆字节的价格为0.19美元。对于中国来说，每千兆字节的价格是0.23美元，你的数据不会在中国大陆，因为谷歌在那里没有数据中心。每千兆字节的价格会随着您的容量的增加而降低。
谷歌的云原生关系数据库。我们将很快添加一个定价表和场景成本示例。
直连是一个或多个网络之间的免结算协议，用于直接连接和交换流量，而无需向第三方支付费用即可通过internet“传输”流量。直连涉及到网络的物理互连，因此传输无法完全避免，但传输所需的越少，带宽成本就越低。因为这最终是对他们能够与哪些网络进行物理互联的物理限制，所以它成为一个数字游戏，在这个游戏中，拥有最大全球影响力的云平台通常会拥有最大的优势。
地区的形状和大小由3个主要影响因素决定。有来自于国家和省份的原因；有来自于这些地区的通信和网络运营商的原因；还有来自于云平台存在点的原因。
云平台对这些地区的实际上以每千兆字节的价格进行规划。同一税率、无特殊监管要求的多个边境地区可以作为一个地区制定。各个地区的云平台各不相同，因为他们能够从每个地区的电信和网络运营商那里获得的费率取决于很多因素。
一个拥有数百个分布在全球各地的数据中心的云平台能够重塑其区域，因为它们在更多的网络中拥有更大的影响力。在每个数据中心的战略位置和建设中，他们能够与该地区的本地网络运营商签订协议，并直接访问他们的网络，以便最终用户和他们最近的数据中心之间的通信能够在同一网络中进行。
与集中式基础设施相比，设计良好的无服务器体系结构的带宽成本几乎总是成本的一小部分，因为有了多个存在点，您的用户可能会处于同一个区域。
网络质量是指延迟、吞吐量、数据包丢失和一致性。用户之间的物理延迟通常是由于用户之间的物理距离
评估结果表中显示的网络评级不考虑价格因素。评级由我们在全球数百个实际地点进行的测试给出。
高分组丢包仅仅是评级中的一个小考虑，因为这可以在几乎不影响用户体验的情况下得到缓解。丢包每增加15%扣1分。对于一部分用户来说，实际的高丢包率是可以预期的，一些数据包丢失的原因超出了云提供商的能力范围。
一些超出云平台责任范围的高数据包丢失示例包括：
用户体验到的吞吐量、下载速率不一定与距离有关，但在数据传送到用户时，它可能与路由或所经历的堵塞点有关。
积分是从10/10开始计算的，我们根据以下公式减去积分：
| 丢包率 | 每15%丢包减1分。 |
| 延迟 | 每100毫秒延迟减去1分。 |
| 吞吐量(速度) | 每比基准慢10%，就减去1分。基准由测试地点最快的云平台设置。 |
| 通畅度 | 对于在一天中不同时间进行的测试，相对于偏差幅度，最多减去2分。 |
吞吐量是通过在每个测试位置测量超过千兆字节的下载速度来测试的。最快的云平台设定了所有其他结果的评分基准。例如，如果云A获得95Mbps，云B获得28Mbps，那么云B将被降低7个点，因为它比设置最快基准的云A慢70%。我们总是将结果四舍五入到10的增量中，因此72%的结果是最低到70%，68%的结果是最低到60%。
云平台施加的人为限制在万兆连接上最为明显，这些人为限制对云提供商的影响很小，但在所有测试位置平均下来，最多只能减少1-2个百分点。
例如，如果一个测试点有一个2.5Gbps的连接，云a设置了一个2.1Gbps的基准，而云B由于人为的限制被限制在100Mbps，那么云B将被降低9个点，因为它比云a慢95%。但是，如果其他测试结果都是肯定的，那么平均所有测试地点的最终分数可能仍然很高，为9/10的网络质量评级。