Sebastian Stadil —— Scalr(云管理工具制造公司)和SVCCG(世界上***的云计算用户组织)创始人，下面我们来了解一下他对两个服务的测试结果。
以下为译文：
测试的背景以及先决条件
自2007年起，Scalr就成为Amazon基础设施服务EC2的用户;在发现帮助AWS客户对EC2进行弹性管理大有前途之后，它们开始着手建立EC2上的相关工具。而随着云服务的发展，各个云服务都相应拥有了自己的用户，Scalr自然就有了自己的跨云端管理工具。为了对服务有更好的了解，Scalr会经常对各种不同的云服务做性能测试。于是在2006年发布，对比EC2拥有相同核心服务的GCE同样也引起了他们的兴趣。
众所周知AWS一直受限于Amazon悲剧的网络以及磁盘性能，而Google在发布GCE的同时做出了性能提升与一致性保障的双承诺，这样一来Scalr就更没有放过GCE的理由了。他们申请了早期访问，并进行了测试。在看结果之前首先看一下测试方法的相关摘要：
测试数据相关摘要
测试基准：一天两次的收集数据，为其4天，然后取平均值。一旦某个点出现巨大差异，会将其记录，然后作为80%观测数据点的间隔。
进入正题，看一下GCE与EC2的区别所在：
简洁明了的API
首先，GCE的API是非常简单，明确并且易于使用的。在GCE里：Google将防火墙就叫做“firewalls”，虚拟局域网就称为“networks”，同样核心程序则是“kernels”;对于熟悉Unix的工作者简直就是“回到了家”一样。
引导速度的差异
GCE虚拟机的部署和启动达到了一个令人匪夷所思的速度(Sclar之前已使用了10个以上的云服务) —— 在输入启动虚拟机后，不到30秒就可以成功登入。而在AWS上，让其达到运行状态就要花掉30秒左右的时间，而之后你仍然需要等待一段很长的引导时间 —— 服务空闲的时候总计为120秒，繁忙的时候总时间则达到了300秒!
无疑，4-10倍的速度，展示了Google强大的工程力量。 #p#
容量上的设置区别
在Amazon的EBS上，可以在任何时候根据需要对实例的容量进行增加和减少;而在GCE上是不可以的，至少当前不允许。这是GCE阻止用户切换磁盘以保障最小停机时间的有效手段：为已运行服务器添加容量允许你跳过引导和配置步骤开启一个新的节点，这在将已存MySQL奴节点提升为主节点时是有帮助的，你只需要置换存储设备。
看完劣势，再看GCE对比EC2的优势。磁盘可以定义给多个实例进行只读，这将比对象存储更加容易使用，特别是对于那些需求本地文件系统类似WordPress和Drupal的软件。同样磁盘也更加的快速、稳定(在Amazon推出Provisioned IOPS之前，其I/O性能一直不是非常稳定)，详情见下表：
两个服务读性能相当的前提下，GCE的写入性能快2-4倍。
#p#
网络性能对比
在这一节上，EC2可以说是完败于GCE。首先看一下用于灾难恢复或者是降低延时的跨区域的文件复制：
在两个不同区域上复制500M文件，AWS需要242秒，而GCE只需要15秒，Google快Amazon 20倍。
其次是同区域复制：同样是500M的文件，AWS需要86毫秒，而GCE只需要20毫秒，GCE又快了AWS 4倍。
GCE的快不仅能提升现有应用程序的性能，而且允许一些新的架构出现，而高负载备份数据库也可能会随之实现。而据说Amazon也在建立自己的跨区域快速网络传输，不得不说这是一个很让人期待的用例。
跨地区快照克隆支持
虽然不清楚为什么AWS会不支持这个功能，但是GAE允许用户在多个地区使用实例的快照对实例进行克隆。这将使灾难恢复和区域性的维护更容易执行。同样这迎合了人们将他们的基础设施部署到多个区域的思想，类似于AWS在实例故障时使用的临时本地磁盘存储。
***，该如何选择?
GCE的强大性能无疑让人向往，然而别忘了其仍处于测试版本，所以强大的性能更该归结于Google本有的底蕴。而巨头Amazon经过多年的发展明显已形成一套完整的服务体系，这就意味着你可以轻松的完成大型应用程序的建立;如果不担心被其锁定，EC2不失为一个很好的选择。
