你使用亚马逊云服务为您的公司？
我读了很多关于亚马逊云计算的可能性，比如S3或者EC2 ，我想知道是否有人真的把它用于任务关键型应用程序。 你是否在云中托pipe你的公司网站？ 你在那里存储文件？ 你是否在云中运行你的构build服务器？
已经有一些像Scalr或者WeoCeo这样的服务可以帮助你完成这个任务，但是我不知道pipe理层是否已经处于真正的问题之中了。
编辑我想补充一点：您认为AWS许可证中存在隐藏的问题，使您（和/或您的公司）无法将应用程序甚至部分应用程序外包到云中？
编辑你知道一些统计比较S3或EC2和你自己或第三方托pipe服务的总体停机时间吗？
我在EC2上设置了两个应用程序实例，并且已经使用S3作为本地到AWS备份和媒体资产传送。 我们在六月中旬将约15％的应用内容/stream量转移到了EC2。 结果是混合的，我们正在将内容繁重的使用实例移回到我们的托pipe数据中心，现在正在调查其他内容交付选项。
请注意：
- 我的应用程序是带宽饥饿（从每个实例100mbps开始）
- 我和我的公司都在瑞士，这对我们的评估肯定有影响。
- 我将带宽定义为stream量（mbps等）和stream量（mb，gb等）
优点：
- 低到中等stream量的交通成本，假设每月不到1 TB。 超过这个模糊的线路，要么自己做，要么find一个合适的CDN
- 活跃的用户社区
- 使用S3 / CloudFront交付的内容实现无限带宽
- 灵活性（启动一个实例并在几分钟内运行）
- 实例中可用的CPU功率，即使是小实例types，对于我的应用程序来说也是足够的。 还有其他高CPU实例types的人需要它。
缺点：
- 我们有一个实例变得无法访问（一个不为人知的事件），并执行我们的灾难恢复程序。 12小时。
- 对于S3和EC2，networking延迟可能会高得令人无法接受（100 ms）
- EC2实例带宽有限。 尽pipe经过了几个小时的search，我从来没有发现一个用户可以预期的硬编码的官方声明。 最初我们在testing中看到了最大〜250mpbs，但似乎已经大大改善。
- 每个HTTP连接带宽可能会低得令人无法接受。 甚至连我们的瑞士数据中心也能提供1-2mbps的连接和800mpbs的连接质量。 编辑：我们最近看到我们的数据中心和EC2在3-4mpbs范围内的利率。
- S3不是“普通”的文件系统
，需要特殊的软件。我们select了JungleDisk，现在我发现它不适合于全天候，适中大小的数据集服务器环境。奇怪的事情会发生（文件列出两次与'ls'命令）和意外的崩溃。使用EBS持久数据，虽然这不是没有警告 。 -
S3 不是 CDN。和其他公司一样，我的公司也试图将Amazon S3用作CDN。还有其他低成本的select。（Akamai，voxel.net，easycache.com）
我是云计算概念的爱好者，我们将继续从EC2中运行一个例子，但是我们发现它不适合我们目前的主要生产需求。 AWS有一些问题需要解决。
我目前使用S3进行video托pipe，我喜欢它。 如果你使用.NET，给自己一点点时间让设置集成到你的网站。 我会高度推荐他们的服务。
我发现的唯一的事情是，你必须花费超过100美元才能获得银级服务，我们的网站最终将花费这么多钱，但是我们还没有进入testing阶段。 我没有问题，我只是想看看他们的支持是什么样的。
支持非常好，而且非常有帮助，但是我希望能够提出一些问题，而不必进入我的口袋（而不是放在老板的口袋里）
哦，我没有遇到任何许可问题。
相比之下，为了钱，我会selectS3以上的其他托pipe服务，因为他们的范围是如此之大，价格指向如此之低。
关于可靠性
我没有运行任何云服务，但我想解决可靠性问题。
我敢肯定，亚马逊团队拥有比我更多的经验和资源来运行一个重型网站。 上周他们已经下了好几个小时了，但是我认为，总体来说，他们的正常运行时间要比我们自己拥有的现有水平的经验和资源更好。
我正在使用S3进行图像托pipe（目前有超过五百万个文件）和服务器备份。 我使用EC2进行image processing，并使用SQS来协调这些任务。 我必须说我已经删除了EC2，因为对于这个特定的任务，非虚拟化的服务器certificate是10倍的速度。 而且我使用mysql编写了我自己的排队解决scheme，事实certificate，这个scheme要快得多，并没有和AWS紧密结合。
在Coding Aloud上有一个重要的post，叫做“去破产”，用Amazon S3看看。
免责声明：我是一名UCSB的研究生，他提出了我即将提到的软件。
如果你担心云的所有权（例如，没有物理拥有你的云盒子），你可能要看看桉树 。 这是EC2 API兼容，可以让你使用你的服务器，它是开源的，所以你可以看到到底发生了什么事情。
但是，对于实际问题，不，我们不在云端托pipe我们的网站，虽然我们当然有很多想法来做这件事。
要进行第二次编辑，请查看CloudStatus 。 它监控AWS的内容和Google App Engine的停机和性能。 亚马逊还在http://status.aws.amazon.com/跟踪他们的中断。;
我们将公司文件存储在S3上，以便随时随地可以访问员工。 极其便宜和简单。 大量的应用程序访问您的S3上的文件。 我们使用的是一个不错的在线文件pipe理器： S3fm 。
我和一群朋友正在研究一个生活在云中的应用程序。 然而，它所居住的那部分云是在我们的控制之下的。 我永远不会相信第三方为我的应用程序做这样的提升，因为我无法控制它。 最近的亚马逊S3中断是一个很好的例子。
我绝对肯定地说，决不会把我的基础设施的任何部分放在（例如）亚马逊的服务器上。 构build服务器，源代码等始终是严格控制的。 不仅因为潜在的不可靠性，而且因为我发现这些服务的许可证过于宽容服务提供商。 除此之外，一个不择手段的主机*可能会拿走我的源代码并将其用于他们自己的目的，即使这样的事情没有被我为了使用服务而必须接受的许可协议合法化。
*可能不适用于亚马逊，但我从来没有听说过你提到的其他两个，直到他们约十年左右，我可能不会相信他们，或任何类似的服务。
