As I’m sitting on the plane back from 5 days of AWS, I’m reflecting back on this immersive experience. There is still a lot to process, but I would like to share a few general outlines and observations in this post.
More AWSome then IaaS
The NIST cloud model has gone the way of the OSI network model. Just as much as the 7 layers of the OSI model provide a good way of thinking about networking, but doesn’t reflect reality. IaaS, PaaS, SaaS is a great way of thinking about cloud services, but it should not be taken as absolute reality. Or as one of the speakers put it, it is not a neat layered cake, but more of a tiramisu. Some ingredients are still recognizable on their own, but a lot of the flavors have melted and blended together. AWS has become a comprehensive set of services that solve common IT problems. By taking care of the common problems they enable more people to get more done.
In the first generations of automobiles, a car operator had to be as much a mechanic as a driver to get any use out of the product. Over time the car improved and you did not need to be a mechanic anymore to drive a car. Services like Uber and self-driving cars are going to take this development to a next level, where, for many people, there is no need to be able to drive a car to get the benefit of mobility.
AWS is well under way to get to these same levels. It has enabled non-engineers to leverage infrastructure and bring functionality to the end-users quicker and with less effort. However, AWS is not inherently safe (yet?).
AWSome security functionality?
Security within AWS is a shared responsibility. AWS makes sure that the service they provide are themselves secure. But AWS is a very large and complex set of tools. And these tools, which themselves are safe, can be configured and chained together to become an unsafe system.
You can really tell, if you listen to AWS, that security is top of mind. It was the dominant non-functional. And I am very impressed with the security, control and compliance capabilities that AWS has put together and integrated with their services. IAM (Identity and Access Management) is at the core of Amazons security. It is very possible to use AWS’ security functionality and use it to provide non-engineers with a controlled environment that prevents them, to a high degree, from creating insecure systems.
However, Amazon’s security functionality is currently still at the level where it requires a great degree of engineering. A lot of talks at re:Invent explained how AWS services like e.g. S3, CloudWatch, CloudTrail, Kinesis and Lambda functions can be chained together to ensure that infrastructure is deployed in a secure and compliant way. However, it still requires per customer engineering to put it together.
Good news is that AWS seems to realise that this isn’t sustainable. The old answer to: “How do I ensure that S3 buckets are always encrypted at rest?”, involved Lambda functions to check S3 bucket settings and remediate those buckets that where not encrypted. The new answer is a checkbox in an S3 policy that can be applied across the board and prevents unencrypted S3 bucket to be created in the first place.
AWS services are becoming richer and broader all the time. In it lies the greatest value of AWS, but there is a flipside. In a pure IaaS world, it was possible to argue that a VM was just a VM, regardless of who provided the VM. This cannot be said for the richer set of services that AWS now provided, or of a VM that has been integrated with one of these services. This leads to a dilemma: using the rich features of AWS means (vendor-)locking yourself into AWS, but not using the richer services means missing out on a lot of value.
Going to AWS’ re:Invent conference was a great experience and I learned a lot. It is good to be immersed so much that for a few days you forget the existence of other clouds. AWS is undeniably here to stay and will improve much over the years to come. AWS has become a specialty and needs to be treated as such. I’m already looking forward to re:Inforce 2019, the first AWS Security conference.