您是否为您的公司使用亚马逊云服务？

Question

我阅读了很多关于Amazons Cloud计算的可能性，例如S3或EC2，我想知道是否有人将此实际用于任务关键型应用程序。您是否在云中托管公司网站？你在那里存储文件吗？您是否在云中运行构建服务器？

已经有一些服务如Scalr或WeoCeo可以帮助您完成此任务，但我不知道管理层是否已经处于真正的问题......

---

编辑我想补充一点：您认为AWS许可证中存在隐藏问题会导致您（和/或您公司）从应用程序外包甚至应用程序的部分到云端？

编辑您是否了解一些统计信息，比较S3或EC2与您自己或第三方托管服务的整体停机时间？

Answer 1

我在EC2上设置了我的应用程序的两个实例，并且一直使用S3作为本地到AWS的备份和媒体资产交付。我们在6月中旬将约15％的应用程序内容/流量转移到了EC2。结果好坏参半，我们正在将内容繁重的使用实例移回我们的托管数据中心，现在正在调查其他内容交付选项。

请注意：

1. 我的应用程序是带宽饥饿的（每个实例以100mbps开始）
2. 我和我的公司都在瑞士，这肯定会对我们的评估产生影响。
3. 我将带宽定义为流量（mbps等），将流量定义为流量（mb，gb等）

优点：

• 中低容量的流量成本，假设每月可能低于1TB。超过那条模糊线，要么自己动手，要么找到合适的CDN
• 活跃用户社区
• 使用S3 / CloudFront提供的内容实现无限带宽
• 灵活性（启动实例并让它在几分钟内运行）
• 实例中可用的CPU电源，即使是小型实例类型，也足以满足我的应用需求。对于那些需要它的人，还有其他高CPU实例类型。

缺点：

• 我们有一个实例无法访问（并非闻所未闻），并执行了我们的灾难恢复程序。 12小时。
• S3和EC2的网络延迟可能高得令人无法接受（100毫秒）
• EC2实例带宽有限。尽管经过了数小时的搜索，但我从来没有找到一个用户可以预期的硬编号的官方声明。最初我们在测试中看到最多约250mpbs，但这似乎有了显着改善。
• 每个HTTP连接带宽可能低得令人无法接受。即使是我们的瑞士数据中心也能提供1-2mbps的连接，并且具有800mpbs的连接和质量对等。编辑：我们最近看到我们的数据中心和EC2之间的比率在3-4mpbs范围内。
• S3不是'普通'文件系统，需要特殊软件。我们选择了JungleDisk，我现在发现它不适合24/7，中等大小的数据集服务器环境。奇怪的事情会发生（文件列出两次'ls'命令）和意外崩溃。 使用EBS表示持久数据，尽管这是not without caveats。
• S3 不是CDN。与许多其他公司一样，我的公司已尝试将Amazon S3用作CDN。还有其他低成本替代品。 （Akamai，voxel.net，easycache.com）

我是云概念的粉丝，我们将继续运行EC2中的实例，但我们发现它不适合我们当前形式的主要生产需求。 AWS有一些问题需要解决。

Answer 2

我目前正在使用S3进行视频托管，我喜欢它。如果您正在使用.NET，请给自己一点时间，以便在您的站点中集成设置。我会高度推荐他们的服务。

我发现粗暴的唯一一件事就是你必须花费> 100才能获得银级服务，我们的网站最终会花费那么多，但我们还没有进入测试阶段。我没有问题，我只想看看他们的支持是什么样的。

支持很棒，而且非常有帮助，但我本来希望能够在不必掏腰包的情况下提出一些问题（而不是老板的口袋）

哦，我没有遇到任何许可证问题。

相比之下，对于这笔钱，我会选择S3高于其他托管服务，因为他们的覆盖范围非常广泛且价格指向它如此之低。

Answer 3

关于可靠性

我没有在云服务上运行任何内容，但我想解决可靠性问题。

我确信亚马逊团队拥有比我更多的经验和资源来运行重型网站。他们上周停工了几个小时，但我相信他们的正常运行时间将比我们拥有的经验和资源水平更好。

Answer 4

我正在使用S3进行图像托管（目前超过500万个文件）和服务器备份。我使用EC2进行图像处理，使用SQS协调这些任务。我必须说我已经删除了EC2，因为对于那个特定的任务，非虚拟化服务器被证明是快10倍。我使用mysql编写了自己的排队解决方案，事实证明它更快，并且没有与AWS建立紧密联系。

Coding Aloud [http://www.codingaloud.com/2008/01/going-bankrupt-with-amazon-s3.html]上有一篇重要帖子，名为Going Bankrupt With Amazon S3，请看看。

Answer 5

免责声明：我是UCSB的一名研究生，他推出了我要提及的软件。

如果您担心云所有权（例如，不是实际拥有云盒），您可能需要查看Eucalyptus。它符合EC2 API，允许您使用服务器，它是开源的，因此您可以准确地看到发生了什么。

但是对于实际的问题，不，我们不会在云中托管我们的网站，尽管我们当然有很多想法可以用来做。

Answer 6

要进行第二次修改，请查看CloudStatus。它监控AWS内容和Google App Engine的中断和性能。亚马逊还在http://status.aws.amazon.com/跟踪他们的中断。

Answer 7

我们将公司文件存储在S3上，以便随时随地访问员工。非常便宜和容易。在S3上访问文件的应用程序很多。我们使用的是一个不错的在线文件管理器：S3fm。

Answer 8

我和一群朋友正在研究一个存在于云中的应用程序。但是，它所居住的云部分在我们的控制之下。我永远不会相信第三方为我的申请做那种解除，因为我无法控制它。最近的Amazon S3中断是一个很好的说明原因。

我绝对，肯定地说，永远不会把我的基础设施的任何部分放在（例如）亚马逊的服务器上。构建服务器，源代码等始终受到严格控制。不仅因为潜在的不可靠性，而且因为我发现这些服务的许可证对服务提供商过于宽松。除此之外，一个不道德的主机*可能会使用我的源代码并将其用于他们自己的目的，即使这样的东西没有通过许可协议合法化我将不得不接受以使用该服务。

*可能不适用于亚马逊，但我从来没有听说过你提到的其他两个，直到它们已经存在了十年左右，我可能不会相信它们，或者像他们这样的任何服务