Let’s put this all to bed right now.  We’re going to look at the issues around multi-tenancy, security, pricing, and positioning.

Market Positioning
I’ll go into depth on this in the near future as it’s tightly related to my recent postings and presentations on ‘enterprise clouds’ (cloud-washed enterprise computing & virtualization systems).  Right now though, the key thing to understand is that AWS is *already* in the business of servicing enterprise customers regardless of security concerns.

Enterprises, like most other businesses, have two key adoption types: greenfield applications and legacy applications.  Greenfield enterprise applications have been adopting AWS and other commodity clouds for some time now.  During that same time, AWS has been very busy adding enterprise friendly features to increase the ability for legacy enterprise applications to adopt EC2.

A great example of this is Virtual Private Cloud (VPC), which originally provided simple layer-2 VLAN/Ethernet emulation combined with a VPN termination point.  Now, as of their latest release it also allows creating complex networking topologies, just like in a traditional enterprise datacenter.

Dedicated Instances are yet another arrow in the AWS quiver that reduces friction for enterprise adoption of existing legacy applications.  This is an enterprise focused feature.  It reduces concerns around security of the hypervisor and ‘sharing’.  Reduces, not eliminates.

It’s also worth noting that while billed as ‘Dedicated Instances’, Amazon has already been effectively selling dedicated VMs/instances in their HPC offering. [1]

Hypervisor Security
Whether you or I believe hypervisor security issues are relevant doesn’t matter.  Some people clearly do and not sharing the hypervisor may be a requirement in some regulatory and audit situations.  Providing customers a dedicated physical server and reducing sharing to only the network and (maybe) storage[2] is seen as a win by some security and compliance people.

For large enterprises, getting over that security and compliance hump is important. Frankly, my recent observation is that when a massive disruption is happening the incumbents will focus on creating Fear, Uncertainty, and Doubt (FUD) in key areas.  One is security.  Many of the threatened enterprise IT vendors specifically throw this up as a reason to avoid adopting public commodity clouds or using their same approaches to build your own cloud.  Dedicated Instances remove this obstacle.

Multi-Tenancy
Perhaps the most pernicious idea out there is that this is somehow ‘Uncloudy’ because the hypervisor is not shared.  I’m not sure how this kind of thing gets started, but at it’s roots it assumes that multi-tenancy is a core property of infrastructure clouds and that it is only achieved via the hypervisor.  Taking aside the definition of ‘multi-tenancy’ and whether it’s a core property, it should be noted that clouds ‘share’ many resources, of which the CPU/server is only one.  They also can share storage, networking, billing systems, etc.

Don’t misunderstand me.  I *do* think some kind of multi-tenancy is important, but there is a spectrum of multi-tenancy from ‘a little’ to ‘a lot’.  Also, what you call a ‘tenant’ is critical.  Finally, tenancy happens differently in SaaS from PaaS and IaaS.  The tenancy models are very very different.

So, let’s dig into this notion of hypervisor tenancy.  I have a couple of diagrams to show my point.  Assume we have 6 customers with 4 instances each on a cloud with 6 compute nodes.  Randomly distributed we see something roughly like this:

Voila!  Multi-tenancy.  Everyone is happy.  We have a cloud, people.

However, if we re-shuffle these instances and ‘bin pack’ them onto dedicated servers, we suddenly turn off the multi-tenancy:

What’s different here?  Have we truly lost multi-tenancy?  Customers are no longer sharing hypervisors and nothing has changed but that we’ve reshuffled the instances.  But perhaps we haven’t lost multi-tenancy.  Networking, storage, and other resources are still shared.

Let’s look at a more real world example, though, since most clouds don’t run at 100% capacity[3]:

Here we have a cloud running at about 75% utilization rate with instances randomly distributed.  This is in pretty good shape, but of course, all of these open ‘slots’ aren’t generating revenue anyway.  Of course, that’s part of the business model, so no harm, no foul.

Time to reshuffle!

Right, so now we’re still running at 75% for the entire cloud, but some customers are 25% utilization for their dedicated servers, some 50%, and some 100%.  Our cloud wide efficiency hasn’t been reduced significantly, but per customer it has.  This also means that customers are going to control the efficiency rate quite a bit more we would like, holding certain physical servers to themselves if this is the same as the AWS Dedicated Instances model.

This is where AWS rather clever pricing comes in.  They simply charge a sort of ‘tax’ across a single region of $10/hr if you choose to use this capability.  This tax effectively makes up for any inefficiency created by allowing customers to hold open a few more instance slots than normal.

AWS Dedicated Instances Pricing
Again, the confusion on whether this feature is ‘cost effective’ mostly comes from the Register’s biased assessment of the costs.  This feature is not targeted at individual consumers, but large enterprises looking to adopt en masse.  For such customers I’ve heard of monthly run rates between 100K-1M in usage charges.  $12M/year for a large enterprise is a drop in the bucket.  $1.2M/year doesn’t even touch the radar.

As an example, if a large enterprise was spending $1M/month and wants to get slightly better security, much better compliance, they would have to spend a whopping $10/hr per AWS region, roughly $7200/month[4].  That’s $86,400/year.  Let’s see, that’s an addition of .7% to their total annual spend on AWS.  Is slightly better security and ability to meet compliance standards worth >1% in additional cost?

If that same enterprise was only spending $100K/month, then we are looking at a 7% addition to total annual spend.  I don’t know what the value is of the AWS Dedicated Instances feature is to such a large customer, but I’m certain it’s more than 1-7% addition in additional spending.  Probably much more.

This pricing makes AWS Dedicated Instances extremely good value for money for a large business.  Combined with the new VPC features and being able to ride Amazon’s innovation curve, constant cost reduction cycle, and the other benefits of a large commodity public cloud provider, it’s hard not to find the whole offering rather compelling.

Conclusion
Better security, better compliance, less impedance mismatch with legacy applications, ability to onboard enterprise customers, and still cloudy.  This is a net win for everyone involved: AWS, enterprise customers, and the cloud community as a whole.

BTW, there are whispers that AWS has significant amounts of other related features that will further reduce impedance mismatch with enterprise clouds.  I expect that anyone sitting on an enterprise cloud (public or private) that doesn’t have an innovation cycle matching Amazon’s is going to get run over in the next year or two.  More from us on remaining competitive soon, though.

UPDATE: Cleaned up some language and fixed some typos.

Regardless, a bit more light has been shed on Amazon’s controls and measures in their recent security webinar.  You can access it here.

At a high level, CJ Moses, who presents the webinar talks to the core areas they covered in the control objectives, which are:

1. Security organization
2. Amazon employee lifecycle
3. Logical security
4. Physical security
5. Environmental safeguards
6. Change management
7. Data integrity, availability, and redundancy
8. Incident handling

This looks pretty reasonable at a high level.  Of course, it would be nice to see the actual controls and objectives, but at least they are covering the appropriate areas of security.  I do notice that there isn’t much around perimeter or related security.  I’m guessing they are trying to gloss over the AWS distributed firewall.  It would be nice if someone besides Amazon was vetting the way this was built.  They appear to consider it a piece of core intellectual property despite the fact it would be trivial to reproduce.  I’m not exactly certain why.

Unfortunately, a SAS70 audit isn’t what most people think it is. Worse yet, Amazon’s reluctance to provide details of the audit provides a false sense of security with no tangible benefits.

Let me explain.

Understanding the SAS70 Audit
The SAS70 is a methodology for performing an audit, not the audit rules themselves. The SAS70 can prove whatever you decide it needs to prove. From taking the garbage out to turning the lights on.

From Wikipedia:

For a SAS70, you must specify a series of “controls” and “control objectives”. Like it sounds, you are asserting that a given ‘control’ meets a goal or objective. An example of a control might be the ‘new user creation process’ or a ‘firewall’. An example of a control objective might be the following[2]:

Now here’s the rub: Who decides what the control objectives are? An outside agency? A regulatory body?

None of the above. The company being audited decides and can make the control objectives anything they like. Here’s a SAS70 FAQ response on the topic right from the SAS70.com website.

Again, the SAS70 is just an auditing framework. Why then do so many think it’s useful?

Background on the SAS70 Audit
The SAS70 comes out of the financial industry and is a relatively generic framework for that reason. The financial industry has tons of different regulatory requirements that vary from state to state and country to country. Moreover, within the financial industry these kinds of audits are undertaken all of the time, the parties involved know what they are testing for, and how to negotiate it.

For example, a large bank might outsource work to a secondary institution and have a desire to see that institution provide proof they are following certain guidelines or regulations. A good example is the Bank Secrecy Act. The large bank in this case knows what the BSA requires and how to evaluate the secondary institution’s SAS70. This knowledge allows them to assess secondary institution’s level of compliance with the BSA. At the same time, the secondary institution is familiar with what its large partners will require and sets up its annual Type 2 to cover the ‘usual suspects’ of controls and control objectives.

So how did we get here?

Hosting Companies and the SAS70
In recent years as financial institutions began to outsource they required that various hosting (and other) businesses perform the audit as well. Unlike their usual partners it hasn’t been clear what hosters need to be compliant with. Because of this most folks have simply done these SAS70s as simple Type 1s that are one-offs. This allowed the hosters to keep their costs down while allowing the bank to outsource and the hosters to generate revenue.

Here’s the problem: Cloud computing is ushering in whole new ways of delivering IT services.

It demands greater transparency than ever, especially when it comes to security. If the average person doesn’t understand the SAS70 and if you don’t provide your control objectives so that others can vet the objectives you sold then you are creating a false sense of security.

You could have one control objective that simply says: “we must keep the power in the data center on” and successfully pass by fulfilling that over 3 days or 6 months.

The Need For A Cloud Security Standard
There are a couple of security and IT standards that can be used as the basis for a good SAS70 audit. For example there is CoBIT and the ISO27002 (formerly ISO17799). There are probably others I’m unfamiliar with. Unfortunately, most of these standards really focus on the Enterprise and not on a multi-tenant public cloud or hosting companies, who have some issues specific to their particular business models and architectures.

So, even if Amazon used one of these, it’s still not good enough for them to keep their controls and control objectives hidden from public view. How are we to be certain that they are sufficient? [3]

Summary
Until there is a security standard for running a cloud then SAS70 audits with unpublished controls and control objectives like the recent AMZN announcement are simply smoke and mirrors. They provide little or no real assurance to the average consumer of the AWS public cloud and serve only to provide a false sense of security.

UPDATE: @wpauley says he has a copy of the AWS controls, but I haven’t seen them yet. When I get a copy I will post them.
UPDATE2: Apparently @wpauley was a special case. AWS is keeping the controls under wraps. If you have a copy send them to me anonymously and I will get them posted.