Auditing the Cloud

By Rich Wellner

I've written here about the importance of SLAs for useful cloud computing platforms on a few occasions in the past. The idea behind clouds, that you can get access to resources on demand, is an appealing one. However, it is only part of the total picture. Without an ability to state what you want and go to bed, there isn't much value in the cloud.

Think about that for a minute. With the cloud computing offerings currently available there are no meaningful SLAs written down anywhere. Yet people, every day, run their production applications on an implicit SLA that is internalized something like "amazon is going to give me N units of work for M price".

There are two problems with this.

• Amazon doesn't scale your resources. Your demand may have spiked and you are still running on the resource you signed up for.
  
• There is no audit capability on EC2.
  

In the Cloud Computing Bill of Rights we wrote about three important attributes that need to be available to do an audit.

• Events -- The state changes and other factors that effected your system availability.
  
• Logs -- Comprehensive information about your application and its runtime environment.
  
• Monitoring -- Should not be intrusive and must be limited to what the cloud provider reasonably needs in order to run their facility.
  

The idea here is that rather than just accepting what your cloud provider sends you at the end of the month as a bill, the world of cloud computing is complex enough that a reasonable set of runtime information must be made available to substantiate the providers claim for compensation.

This is particularly true in the world of SLAs. If my infrastructure is regularly scaling up, out, down or in to meet demands it is essential to be able to verify that the infrastructure is reacting the way that was contracted. Without that, it will be very hard to get people to trust the cloud.