AWS says responsibility is split between the cloud provider & the customer but with over 305 services not everything is as simple as it first seems.
Understanding the Shared Responsibility Model is probably one of the first steps towards understanding how AWS works and it makes sense the concept is covered as part of “AWS 101”, or the AWS Certified Cloud Practitioner exam.
It goes without saying that before you start to utilise the cloud for yourself or for your organisation you should really understand what parts of the cloud you are actually responsible for. You wouldn’t rent a car without first understanding the lease agreement, right?
It is often broken down into the simplistic term:
“Amazon is responsible for the Security of the Cloud and the Customer is responsible for the Security in the Cloud”
The key difference being the use of two words, ‘of’ and ‘in’.
So, what is the ‘of’ part of the cloud that AWS is responsible for? It is all the elements of owning, maintaining, managing and securing a traditional data centre. It includes elements of physical security such as controlling access controls to the data centre itself and managing the underlying hardware, physical networking and boot management of servers and devices.
In fact, AWS themselves use this handy diagram to help users understand it better.
If you’ve been in the cloud game for a long time you might recognise that this diagram hasn’t changed much over the years. As far as I can tell it hasn’t changed in at least 6 years.
Here is the 2015 version complete with a tie wearing stickman – they have cleaned up their graphic design skills over the years but fundamentally it is the same picture.
I’ve tried to track down the origins of the shared responsibility model and as far as I can tell it was first referred to in this way by Jeff Barr in a presentation at AWS Summit 2011 (Before re:invent was even hosted for the first time). However let me know if you can find it being used before this!
In fact, the first version was even simpler than the current version.
Previously it had been referred to here and there as the ‘Shared Responsibility Environment’, for example in this AWS Security Whitepaper published in January 2011.
However, AWS’ service offerings have changed substantially over the last 6 (And 14!) years and there are more managed or “SaaS” services than ever before.
This is fundamentally, where I start to struggle with the simplistic definition of the shared responsibility model.
There are over 305 services available on AWS and each of them require you to manage them in different ways. For some services the customer might be responsible for key management & authentication while for others they’re only responsible for the code they’re running on it.
As an enterprise customer it becomes even more difficult to keep track of what everyone is responsible for or should be doing in the cloud.
If an “Application Team” use one set of 10 AWS services then they will have to care about their own responsibilities and the “Billing Infrastructure” team on the other side of the organisation with their own set of AWS services have to worry about another set of responsibilities.
Here is something that I have used in our organisation to help demonstrate some of the ambiguity when it comes to responsibilities.
There is definitely room to expand for this model but the one thing it highlights is that there are only 3 things the cloud provider is always responsible for and 5 things the customers is always responsible for. The rest is dependent on whether you’re using IaaS, PaaS or SaaS products.
What I would love to see from AWS’ product teams are product specific responsibility models that include up to date considerations for cloud management such as information of AWS Organizations integrations and Service Control Policy details. Even just a simple visual for how a service can work with AWS Organizations would be a bonus.
This has actually already been done specifically for Lambda and it would be great to see more product specific versions out there.
Let me know what you think, should the “Shared Responsibility Model” remain in its current simplistic form or could AWS do more to help customers understand the differences when it comes down to individual services?
I’d love to expand on this topic in the future so if you found this interesting then be sure to let me know and share this post.
[Update 1]
After I published this article, Ben Bridts (@benbridts) shared this Lambda specific shared responsibility model with me on twitter and it is exactly what I think more services should have as part of their service documentation: The Shared Responsibility Model — Security Overview of AWS Lambda (amazon.com)
[Update 1]
After I published this article, Ben Bridts (@benbridts) shared this Lambda specific shared responsibility model with me on twitter and it is exactly what I think more services should have as part of their service documentation: The Shared Responsibility Model — Security Overview of AWS Lambda
Top comments (0)