Last week, I headed down to London for the 2018 AWS Summit. AWS Summits are free events that Amazon run to try and educate people about their cloud, and the benefits of running your workloads on it. Hosted at the ExCeL in the Docklands, I believe the London summit is the largest in the EU – and this year had over 12,000 attendees which doubled the number who attended last year.
This was my second AWS Summit, and my first since I’d achieved my AWS certification so this time I was a bit more clued up as to what was going on and what sessions would be useful for me. This year, I opted for a track comprised almost entirely of security and infrastructure sessions as these were the most relevant talks for my current role. I’ll talk here about some of the sessions I went to, and some of the most interesting points from them. The slides for all of the sessions can be found here.
The keynote was done by Amazon.com’s CTO Werner Vogels, who’s a good speaker and powered through a two and a half hour keynote talking about the main areas that AWS is focusing on in the coming months – which seems to be a significant push towards AI services and serverless architectures. There were also a number of slots where some industry partners who had done cool things with AWS got to talk about them. The most interesting of these was Babylon Health, a company who build an AI powered product to help diagnose medical conditions and provide virtual access to a GP, intended for people in countries with poor access to healthcare. They presented a slick demo, and their CEO Ali Parsa explained that their trials in Rwanda had been so successful that they now have one third of the country’s entire population on their platform.
AWS Multi Account Management and Security
Given that I’d recently introduced a new multi-account strategy in my workplace, I thought this would be a useful session to see if there was anything I’d missed or pick up some tips on how to secure such a deployment. This session was done by a couple of engineers from Hive, the smart home company, and had some really interesting stats about the AWS estate that they run:
- They originally started out with 2 accounts in 2012: dev and prod, and since then have gradually expanded this to have one for every product and environment, leading them to where they are today with 110 separate accounts.
- Their infrastructure and services across this estate generates a combined total of 100,000 points of telemetry every second.
- They generate 230,000 log files every day with CloudTrail, a service which logs details of every single API call made across your AWS accounts.
They also talked a lot about the reasons behind why you might want multiple accounts, and some of the challenges they faced doing this. I’m not going to go into that too much here, because I’m intending to write my own blog post soon about a multi account strategy with AWS.
Building a Monitoring Plan
This session was really interesting, and not at all what I had expected. I had anticipated an overview of the plethora of monitoring and logging tools that AWS give you access to right out of the box, but it was instead a thoughtful introduction to how to design a good monitoring plan that actually provides the value you need.
This session began with asking a pretty fundamental question – why monitor? It’s surprisingly easy to skip this part on AWS, and just configure monitoring on absolutely everything because they make it easy to do so. It’s worth considering whether this is actually the right course of action – you probably don’t need to monitor absolutely every metric that AWS offers you, and doing so can end up giving you alert fatigue. In other words, it’s worth spending the time up front designing the monitoring that you actually need to ensure you’re focusing on what’s important for your workload. I started to write this talk up here, but it got pretty long because there was a lot of good content – I’ll follow this up with a post specifically about this topic too.
Security By Design
This is probably one of the most intense, information overload sessions I’ve ever been to from AWS – but in a good way. Delivered by Shafreen Sayyed, an extremely knowledgeable Solutions Architect from AWS who has assisted my company with architectural work before, this talk was a rapid tour of all the AWS security controls that you should know about and use within your environments to ensure that security is built into your architecture from the beginning. Her slides were a wealth of useful links and examples, and I’ll post a link to it here when they’re uploaded – it’ll be better to just go through them yourself.
Update: Slides available here: https://www.slideshare.net/AmazonWebServices/aws-security-by-design
Come Out From Behind Your Firewall
This session talked about how traditional security methods don’t always apply to cloud environments, or at least that they might not be the best way to proceed. The key takeaway from this is that cloud security should help us to stay secure without getting in the way of progress – it needs to be flexible and responsive enough that we can still move quickly. They talked about a threat lifecycle for AWS:
- Monitor – use tools which give you insights into your environment like CloudTrail, VPC Flow Logs, CloudWatch and GuardDuty.
- Respond – Use these tools along with further automation to ensure you’ll be alerted if security events occur which should be brought to your attention. Hook into functionality like CloudWatch Rules or use SNS to notify you by email or text.
- Remediate – the tools that AWS provide you with allow you to automatically perform remedial action based on alerts. For example, if GuardDuty alerts you to suspicious network traffic on one of your instances, you could trigger a Lambda function which would change the security group to a locked down one, isolating your instance from the network.
The AWS Summits are fantastic events, and I’d recommend them if you do work on AWS or you’re looking to start moving your workloads to the cloud. They’re full of knowledgeable people running sessions on a variety of topics and you’ll come away from it having learned a lot. The events are getting bigger every time – this year’s was double the size of the 2017 summit in terms of number of attendees, but it was obvious they had some teething trouble because of this – poor crowd mamagement and ropey WiFi is something that there really isn’t an excuse for. That aside, the sessions were excellent and I’m hoping to be back again next year!