注：本篇文章翻译自英文博客，点击这里可访问原文！
去年（译注：2012年）11月份拉斯维加斯AWS re:Invent大会上，Amazon CTO，Werner Vogels在其主题演讲中提到一个非常有趣的观察，那就是“一个EC2实例并不是一台服务器，它其实是一个构建模块（building block）”。这听起来非常让人生疑，就如同一家知名的汽车制造商想说服你他们的车不仅仅是一台车。但是Vogels在演讲中对此的一些解释让我非常好奇。我从EC2公开测试就开始使用它，明白他在演讲中对此的简短描述也确实正确，但是我还是没有理解为什么他会这么说。直到几个月后，当我汇合多个方面的理解后才真正清晰明白EC2是什么，它又不是什么。
从所有的表象甚至功能来说，一个EC2示例确实就像一台虚拟服务器。人们可以通过SSH（或者Remote Desktop）方式登录它，并可以安装任何需要的应用程序。其实，以我个人的观察，超过95%的开发人员也正是这样使用AWS的。但是，这显然是对于AWS这个平台比较浅显的看法，而大多数对于AWS的抱怨（不稳定，成本高，难用等）也恰恰都是来自那些把EC2当成本地数据中心中传统服务器来使用的那些人。
为了真正理解AWS，我们必须要回到亚马逊的基因。在2002~2003年（诞生EC2的前几年），Bezos强力要求整个公司全面拥抱面向服务（SOA）的技术架构。不同于面向对象的编程方式，SOA要求每个功能模块都单独封装在一个独立的构建模块（building block），并且这些组件通过事先达成的接口相互连接。举例来说，这就像软件设计中程序员完全不需要理解一个第三方库内部的工作方式就可以直接使用它。SOA的这套理论也被用于亚马逊的组织架构上。Bezos授权所有的事业部划分它们的运营部门，并通过良好定义并文档化的接口（例如,SOAP/RESTful APIs）相互沟通。
对于像亚马逊这样规模的公司，这种变化是个非常大的事情。这个公司在过去十几年里面成为互联网领域的领导者。如此同时，公司规模也在非常快的增长。于是会出现采购和物流中心都在共享一台数据库服务器，但是相互都不知道谁应对这台服务器最终负责，IT部门对于工资记录这样的敏感数据都可能有未被记录的root访问权限，等等。公司组织的膨胀给它来如同“面条式”遗留代码一样的混乱。Bezos为重组公司核心运营模式的决定付出巨大的努力，但最终带来了更容易扩张和管理的组织。作为SOA革新的结果，在2006年，南非的一个小团队发布了一个服务，该服务可以通过API来按需创建计算资源，亚马逊弹性计算云（EC2）就此诞生了。和S3一起，它们是新创建的AWS部门最早的一批产品。
AWS可以说是这个世界上最有抱负和最成功的SOA架构案例。这个原则一直驱动着AWS的产品创新并用于引导用户对其产品的使用方式。当类似于Rackspace这样的竞争对手把“持久性”作为其竞争优势对外宣传时，它们其实已经忘记了AWS的出发点。和传统方式中购买一台服务器，精心配置成一件独特的艺术品，然后确保它在退休前不会被中断不同，EC2恰恰走向其对立面。EC2被设计成給一个大的应用程序提供动态计算资源且可随时抛弃的构建模块（building blocks）。这个应用程序会跨越多个EC2实例（自动伸缩组）并且很有可能还要使用其他AWS产品（如DynamoDB，S3等），不同组件通过如简单队列服务（SQS），简单通知服务（SNS）和云监控（Cloud Watch）黏合在一起。当一台EC实例出现异常，它应该被自动杀死并自动替换掉，而不是去修复它。当一个应用需要更多资源，它应该自己知道如何去创建更多资源，而不是需要在半夜通过寻呼机叫醒一个工程师来处理这个事情。
通过一组松耦合的组件相连组成整个系统是为运行在AWS上的应用设计的正确架构。在EC2上不按照SOA方式构建一个系统就像仅拿一块乐高积木来玩耍一样毫无效率（也毫无乐趣）。