云最重要的一个特色就是在多个用户中共享资源。缺少了共享和资源优化的能力，云服务供应者就无法给业务提供可扩展性及对“规模经济”的支持。IaaS在包含了计算能力、储存和网络设施的同时还包含了它的“云魔法”。而这些资源的使用必须经过充分优化用以满足用户需求，因此他们只能在用户中共享。
什么是Steal Time?
衡量服务器对CPU利用的基本标准就是闲置能力 —— CPU的空闲量。CPU的使用率由下面几种分配决定：
User —— 运行的应用程序
System —— 操作系统
Interrupt —— 硬件中断
Wait —— 等待I/O操作的完成
Steal —— 与虚拟机无关的周期
Idle —— 未进行任何作业
Steal Time(ST)通常还被称作“Stolen CPU”，存在于虚拟计算环境 —— CPU使用内部虚拟机运行任务的时间，由Hypervisor将CPU周期分配给其他“外部任务”产生;而这些外部任务很可能就是你吵闹的邻居(云端共享同一片资源的用户)递交的。
AWS上的Steal Time
通过在AWS社区上的研究发现，在CPU达到峰值的一段时间后：系统会自动的将CPU收缩至一定的使用比例，那么你剩下的CPU就被“窃取”了。这种情况通常是云端对自己的保护，以避免崩溃的威胁。
你可以找到更多关于AWS上Micro Instance信息的常见问题解答：“Micro实例会一直提供少量的CPU资源;而当额外的周期空闲时，AWS允许你将CPU资源扩充到2 ECU。它们非常适合那些吞吐量较低的应用程序;以及定期拥有大量的计算周期，而其它时间只为后台进程和守护进程提供少量CPU资源的网站”。
在亚马逊开发者社区，你可以发现：
“举个例子：当我想做一个“yum update”的时候，系统在一分钟之内都没有响应;预想中这个操作会耗时3到5分钟，通常也需要这么久;但是今天只花了30秒到1分钟左右时间。”
亚马逊并没有详述Xen配置，尽管它们说：“实例根据CPU的使用率在本质上划分为两个级别：基础的低标准等级、以及在这个等级上拥有短暂飙升能力的等级。”(点击查看更多了解我获悉的)使用标准的监测工具去监测CPU可能会误导云用户，举个例子：由于虚拟化层在底层的基础设施上，Linux实例不会报告CPU的正确使用率。为了得到EC2基础设施上正确的CPU利用率，云用户只能使用CloudWatch来测量。
另一个影响CPU使用率的重要方面在于任务的模型。这里必须区分两个负载模型：批处理和实时。前者能够更大程度上容忍资源的短缺，并可以等待一段可观的时间。批处理模型描述的任务一般都会生成一个稳定的使用率或者集合成一个总的CPU使用率，所以一旦CPU负载过重，批处理将会被顺延。而实时模型从不会被顺延，并且云供应商也会约束它的负载。此外，像亚马逊AWS这些云供应商更趋向去设计更多的批处理负载模型来控制它们服务器的负载。
为了更好的利用AWS的Micro Instance，你必须有能力控制你的在线资源。当然你也可以去做网络服务器配置的尝试，举个例子：限制用户数量。你需要使用S3来储存静态文件，比如：图像、视频和音频。使用其他AWS服务扩充你的应用性能需求可以将一些负载转移到其他的云资源上，从而降低你EC2实例的CPU消耗负载。总而言之，这里的重点不在于资源的多少，而是能使用有效的手段去控制负载的平衡。
