好的，我们在 2010 年 12 月，azure 已经出现了一段不错的时期。当然，我遇到过一些愚蠢的文章，这些文章预测了使用 Azure 运行的成本 (http://robburke.net/2010/01/28/windows-azures-pricing-model-discourages-small-scale-apps/)。但我真正想知道的是谁运行了 Real World Live Azure 应用程序？您的应用程序是什么样的——哪些服务、多少角色、什么存储、多少用户等，最终花费了多少？
现在，试图弄清楚是否要投入 6 个月的时间来开发一个 azure 应用程序看起来很严峻，因为它是一个预测运行应用程序可能成本的黑匣子。
我很惊讶我找不到一个好的现实世界示例集来帮助开发人员在帮助他们购买平台时有更多的可见性......
我认为这是一个公平的问题，但是任何人都很难给你一个答案，因为你的结果总是会有所不同，而且该领域的人的回答对于他们的具体情况来说太具体了。
我有一个在 Azure 中运行的真实解决方案。事实上，如果你决定使用 Azure，请考虑使用它来优化 Azure 的计算实例分配：http: //www.paraleap.com :)
我可以告诉您，您希望预算至少 20% 的额外计算时间，因为您需要在不同的时间将环境部署/重新部署/重新部署到暂存区域（每小时增加额外费用）只是为了找出那是云中的其他东西在开发结构中工作时不起作用。在应用程序的初始不稳定时间尤其如此。如果您有一个大型 QA 团队来破坏您的 Azure-QA 环境，或者您要去客户进行 beta 测试并且他们正在测试您的 Azure-Prod 环境，这并不重要。您需要经常为他们安静地重新部署。此外，正如我已经提到的，计划根据需求调整您的实例计数 - 希望是自动或按计划进行。如果您要编写自己的监控来执行此操作，为此，在开发成本、存储成本和交易成本中添加 /bunch/。外包这仍然会花费一点，因为性能指标需要至少保存一次，至少需要加载一次。这将轻松为您节省高达 50-80% 的计算实例成本，具体取决于您的需求的可变性。
存储成本——如果你知道你的使用模式和目标模式，这些应该很容易估计......问题是，如果你以前使用过关系数据库，现在将使用表存储，计划有 3-4 倍的大小你会认为你的关系数据库有。使用 table-storage 你可以更多地去规范化。3-4 倍的乘数甚至可能太小 - 您的结果可能会有所不同。
交易成本。我发现有了这些，我的估计就更远了。来自关系世界，我并没有完全准备好我需要做的非规范化水平。非规范化不仅会导致更高的存储成本，还会导致对存储的更多调用（更多调用）——导致更高的事务计数。
不幸的是，我的应用程序的性质，我不能很好地使用事务模型。如果您可以使用事务，其中一堆东西存储在一个表中的一个 PartitionKey 中并通过一个事务提交 - 那么成本要低得多。因此，无论您认为您的交易成本是多少——将其乘以 10 左右就处于悲观的一面。
我发现传输成本最容易计划，可能是因为它们是接口的一部分，并且预先定义得更好。你的旅费可能会改变。
最后，诊断数据 - 您将需要保存一些跟踪/性能计数器/等。信息。不要忘记计划它。它有点非规范化，可能会占用大量空间。
SQL Azure 非常棒，因为如果在同一个数据中心内，它不会按交易成本收费，也不会产生传输成本 - 但存储数据的空间和成本非常有限。因此，我将它用于经常查询但很小的数据项。
希望这可以帮助
这是一个非常具体的用例问题，但我会发表以下评论：
我花费 azure 的方式（以非常简单的方式）是每个“计算单元”（1 个 cpu 和标准 RAM 块）约为 90 美元，相比之下，存储和带宽可以忽略不计，因此每个计算节点每月最多 100 美元. 商店已经是多余的，所以你不必担心。因此，典型的 Web 场景包括一对 Web 服务器、一个小型 SQL 数据库和一大块表存储，您每月的费用约为 210 美元。
Check out the SQL Azure pricing calculator: