数据存储
虚拟化影响给用户带来直观感受的一大领域在于数据存储。数据库高度依赖于磁盘驱动器的I/O通道速度，而且虚拟化机制下带来的每一丁点额外数据都会拖慢其处理速度。某些云方案在这方面并没有下力气调整，因为他们可能认为大部分用户还是希望能在自己的内部设施中运行数据库。
另一些供应商则建立起自己的特殊数据存储服务。以SoftLayer为例，他们在经过单独调校的虚拟机上运行MongoDB，借此提高数据写入的性能表现。大家应该充分发挥这类特殊服务的性能优势，而不要迷迷糊糊地将MongoDB放在自己的普通实例当中。惠普Cloud与Rackspace Cloud则以同样的方式提供MySQL即服务方案。
不少厂商都在努力把同样的机制推广到更多数据库技术当中。他们将虚拟化层剥离出去，同时创建出各类API、允许用户根据实际数据规模而非虚拟机数量进行存储资源采购。他们希望能在自身经过高度优化的操作系统当中获得远超普通设备的实际运行效果。
其它服务项目也都在强调差异化性能属性。Amazon提供一套广泛的数据存储解决方案，能够将数据内容打包并在需要时进行恢复;不过其中最引人注目的要数Glacier服务，它的设计思路在于以低廉的价格提供“以小时为单位”的数据检索时间——没错，不是毫秒、秒或者分钟，而是小时。
当然，大家也可以额外购买一套内部设备并安装自己最喜爱的存储解决方案;不过这类托管方案仍然拥有显著的吸引力，足以让大家安心地把数据交给其打理。如果某套云体系具备大家喜欢的数据存储层，那么其它工具带来的差异一般说还是可以忍受的。
网络选项
另一个值得探讨的话题就是网络。某些云方案——例如戴尔Cloud以及SoftLayer——提供用于同虚拟机连接的私有网络。在私有网络的支持下，大家往往更容易接受将数据库迁移至云环境当中，毕竟与公共互联网相比、利用私有网络传输业务数据要更安全一些。虽然这项技术本身还称不上完美，云安全目前也仍然是个极具争议的话题，但我们应该将其视为一个良好的起点。
另外一些供应商则从更为具体的地理区划出发提供云服务方案。了解到虚拟机的实际部署位置有助于大家制定数据存储考量以及最终决策。特别是对于那些较为固执的员工而言，将高价值数据副本保存在位于不同区域的云基础设施当中能够有效抵御风暴、火灾以及其它意外灾害所带来的潜在威胁，从而保证企业更为安全地平稳运营。举例来说，谷歌就以非常透明的方式公开了不同数据中心之间的带宽使用成本，因此同一数据中心内部的数据传输流量也可能带来不同的使用成本。
带宽计费制度又是另一大容易引发误解与争议的指标。以戴尔Cloud为例，它不会收取任何带宽使用费，但提供的服务品质自然也不太可能让人满意;这就像是可以免费入住但却蟑螂遍地跑的汽车旅馆——厂商能够借此简化价格计量与核算机制，对价格比较敏感的用户也会对此表示认同。如果大家正打算建立一套像《银河系漫游指南》中那样规模庞大、需要处理海量数据，但却只需要返回单一数值(42)的体系，那么这类方案还是很有竞争优势的。
