Home > Cloud Computing, Cloud Security, Cloud Security Alliance > Dedicated AWS VPC Compute Instances – Strategically Defensive or Offensive?

Dedicated AWS VPC Compute Instances – Strategically Defensive or Offensive?

Chugging right along on the feature enhancement locomotive, following the extension of networking capabilities of their Virtual Private Cloud (VPC) offerings last week (see: AWS’ New Networking Capabilities – Sucking Less 😉 ,) Amazon Web Services today announced the availability of dedicated (both on-demand and dedicated) compute instances within a VPC:

Dedicated Instances are Amazon EC2 instances launched within your Amazon Virtual Private Cloud (Amazon VPC) that run hardware dedicated to a single customer. Dedicated Instances let you take full advantage of the benefits of Amazon VPC and the AWS cloud – on-demand elastic provisioning, pay only for what you use, and a private, isolated virtual network, all while ensuring that your Amazon EC2 compute instances will be isolated at the hardware level.

That’s interesting, isn’t it?  I remember writing this post ” Calling All Private Cloud Haters: Amazon Just Peed On Your Fire Hydrant… and chuckling when AWS announced VPC back in 2009 in which I suggested that VPC:

  • Legitimized Private Cloud as a reasonable, needed, and prudent step toward Cloud adoption for enterprises,
  • Substantiated the value proposition of Private Cloud as a way of removing a barrier to Cloud entry for enterprises, and
  • Validated the ultimate vision toward hybrid Clouds and Inter-Cloud

That got some hackles up.

So this morning, people immediately started squawking on Twitter about how this looked remarkably like (or didn’t) private cloud or dedicated hosting.  This is why, about two years ago, I generated this taxonomy that pointed out the gray area of “private cloud” — the notion of who manages it, who owns the infrastructure, where it’s located and who it’s consumed by:

I did a lot of this work well before I utilized it in the original Cloud Security Alliance Guidance architecture chapter I wrote, but that experienced refined what I meant a little more clearly and this version was produced PRIOR to the NIST guidance which is why you don’t see mention of “community cloud”:

  1. Private
    Private Clouds are provided by an organization or their designated service provider and offer a single-tenant (dedicated) operating environment with all the benefits and functionality of elasticity* and the accountability/utility model of Cloud.  The physical infrastructure may be owned by and/or physically located in the organization’s datacenters (on-premise) or that of a designated service provider (off-premise) with an extension of management and security control planes controlled by the organization or designated service provider respectively.
    The consumers of the service are considered “trusted.”  Trusted consumers of service are those who are considered part of an organization’s legal/contractual umbrella including employees, contractors, & business partners.  Untrusted consumers are those that may be authorized to consume some/all services but are not logical extensions of the organization.
  2. Public
    Public Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the  accountability/utility model of Cloud.
    The physical infrastructure is generally owned by and managed by the designated service provider and located within the provider’s datacenters (off-premise.)  Consumers of Public Cloud services are considered to be untrusted.
  3. Managed
    Managed Clouds are provided by a designated service provider and may offer either a single-tenant (dedicated) or multi-tenant (shared) operating environment with all the benefits and functionality of elasticity and the  accountability/utility model of Cloud.The physical infrastructure is owned by and/or physically located in the organization’s datacenters with an extension of management and security control planes controlled by the designated service provider.  Consumers of Managed Clouds may be trusted or untrusted.
  4. Hybrid
    Hybrid Clouds are a combination of public and private cloud offerings that allow for transitive information exchange and possibly application compatibility and portability across disparate Cloud service offerings and providers utilizing standard or proprietary methodologies regardless of ownership or location.  This model provides for an extension of management and security control planes.  Consumers of Hybrid Clouds may be trusted or untrusted.

* Note: the benefits of elasticity don’t imply massive scale, which in many cases is not a relevant requirement for an enterprise.  Also, ultimately I deprecated the “managed” designation because it was a variation on a theme, but you can tell that ultimately the distinction I was going for between private and hybrid is the notion of OR versus AND designations in the various criteria.

AWS’ dedicated VPC options now give you another ‘OR’ option when thinking about who manages, owns the infrastructure your workloads run on, and more importantly where.  More specifically, the notion of ‘virtual’ cloud becomes less and less important as the hybrid nature of interconnectedness of resources starts to make more sense — regardless of whether you use overlay solutions like CloudSwitch, “integrated” solutions from vendors like VMware or Citrix or from AWS.  In the long term, the answer will probably be “D) all of the above.”

Providing dedicated compute atop a hypervisor for which you are the only tenant will be attractive to many enterprises who have trouble coming to terms with sharing memory/cpu resources with other customers.  This dedicated functionality costs a pretty penny – $87,600 a year, and as Simon Wardley pointed out that this has an interesting effect inasmuch as it puts a price tag on isolation:

Here’s the interesting thing that goes to the title of this post:

Is this a capability that AWS really expects to be utilized as they further blur the lines between public, private and hybrid cloud models OR is it a defensive strategy hinged on the exorbitant costs to further push enterprises into shared compute and overlay security models?

Specifically, one wonders if this is a strategically defensive or offensive move?

A single tenant atop a hypervisor atop dedicated hardware — that will go a long way toward addressing one concern: noisy (and nosy) neighbors.

Now, keep in mind that if an enterprise’s threat modeling and risk management frameworks are reasonably rational, they’ll realize that this is compute/memory isolation only.  Clearly the network and storage infrastructure is still shared, but the “state of the art” in today’s cloud of overlay encryption (file systems and SSL/IPSec VPNs) will likely address those issues.  Shared underlying cloud management/provisioning/orchestration is still an interesting area of concern.

So this will be an interesting play for AWS. Whether they’re using this to take a hammer to the existing private cloud models or just to add another dimension in service offering (logical, either way) I think in many cases enterprises will pay this tax to further satisfy compliance requirements by removing the compute multi-tenancy boogeyman.


Enhanced by Zemanta
  1. March 28th, 2011 at 06:08 | #1

    An interesting read.

  2. March 28th, 2011 at 10:54 | #2

    Hey Beaker – Great Post. Quick question for you on the subject of network isolation. In the first paragraph (the Amazon press release) they state an "and a private, isolated virtual network" but in the end you state that the SAN and network back end is shared and only CPU and memory are isolated. Can you clarify that point for me? Are you talking shared wired but then VLANs, encryption and the like? Thanks!


  3. March 28th, 2011 at 10:59 | #3

    @Aaron Delp

    Good question as I should be more clear — specifically the shared networking to which I am referring is the same shared networking we experience when using any public network (the egress transport and "internal" networks used once traffic leaves the physical NIC) — the "shared wire" you refer to.

    Nothing really new there.

    As I mentioned, VPN technology can be used here…

    Now, the "nice part" of having dedicated CPU/memory means that there is less likelihood of a sidechannel attack capability via the VMM (except perhaps via management interfaces?) wherein a nosy neighbor might be able to somehow gain access to keys in shared memory…

    Most fears stem from sharing resources with other tenants using the same hypervisor.


  4. March 28th, 2011 at 12:03 | #4

    I guess that Amazon is responding to the reluctance of enterprise security departments to trust multi-tenancy cloud security.

    The cloud providers have not articulated very well a multi-tenant security model.

    Pre-cloud security models have preferred air-gap as the "best" security posture. Amazon's offering appears to me to address this preference directly

    I believe that there are other models that can address multi-tenant security issues more directly, rather than offering single-tenancy. But, this paradigm shift has yet to occur.


    /brook schoenfield

  5. March 28th, 2011 at 12:38 | #5

    Actually, if you are using local storage, then the storage is not shared. AWS uses DAS+RAID for the ephemeral storage. Only EBS is shared and in that case, for high security use cases, it's easy enough to encrypt the filesystem.

  6. Beaker
    March 28th, 2011 at 13:18 | #6


    …I'm pretty sure that's what I meant when I wrote "…but the “state of the art” in today’s cloud of overlay encryption (file systems and SSL/IPSec VPNs) will likely address those issues."

    Perhaps this was just another victim of the TL;DNR trauma? ;p

    However, good point re: DAS; I implied EBS bit didn't state it.

  7. March 30th, 2011 at 07:36 | #7

    @Randy Bias

    In theory, in environments like EC2 or pretty much any other IaaS cloud, one still has to look at DAS as a possible security concern. It could not be shared in real time, but it's shared nevertheless – what if a background process that removes old instance and installs a new instance in its slot fails to properly clean up old instance's data and new instance gets access to it.

    Encryption is indeed a possible solution for ephemeral storage as well.

  8. March 30th, 2011 at 07:42 | #8


    Do you think most people, when asked about risks of multi-tenancy, are more worried about sidechannel attacks?

    From my observations, in blogosphere and on Twitter, it looks to me like most people are more worried about unpredictable performance of their instances on multitenant hardware, which is also a huge security risk that could impact availability. I jokingly proposed a solution to a "noisy neighbor" problem in a blog post at http://www.somic.org/2010/09/28/dealing-with-nois….

  9. geonerstiem
    June 28th, 2011 at 11:18 | #9


  1. March 28th, 2011 at 14:56 | #1
  2. March 29th, 2011 at 11:23 | #2
  3. April 1st, 2011 at 16:01 | #3
  4. April 2nd, 2011 at 23:19 | #4
  5. April 5th, 2011 at 15:42 | #5