I know "serverless" is sometimes called out as a buzzword, but the model #AWS#Lambda introduced quite literally changed my career (and consequently, my life). (Thread)
A few years ago, I started an open source security auditing tool called CloudSploit. It got a lot of users, but many were asking me if I could offer a hosted version as an API (and they were willing to pay for it!).
I had some experience with server side dev, but CloudSploit had unique challenges. It would have to horizontally scale out / back very quickly as it was running these security scans. I built a quick set of services using EC2, but it quickly became expensive and hard to manage.
Since it was just a side project at the time, I decided to try out AWS Lambda to run everything. I made a choice to run the entire thing not using a single server. I even wrote a blog post about it at the time: blog.cloudsploit.com/we-made-the-wh…
Throughout the entire time that I operated CloudSploit on Lambda, we never spent more than $100 a month on infrastructure costs. And we were running a massive number of scans per day after several months. That would easily have been 10x in a traditional environment.
I was also not woken up a single time by disk space alerts and we never experienced a single outage in 4 years that was the result of the infrastructure. It let me and our very small team actually focus on building an amazing product.
Last year, CloudSploit was acquired by Aqua Security, but we're still serverless (and joined a team of serverless fans themselves!). I am still amazed how such a seemingly-minor technology choice has led to this series of events.
It's probably minor in terms of what the @awscloud Lambda team has seen, but I can't thank them enough for creating the technology that put all of this into motion.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I've been using #AWS for 8+ years now, so IAM is relatively second-nature to me. But I just sat down to explain it to someone new to AWS and... wow, it is a confusing service. (thread) #aws#cloud#security#cloudcomputing
First, we've got policies - what can the role do and what services can it access? Policies are JSON-based (although AWS added a "friendlier" UI recently, which honestly creates some really confusing output). Most common security mistake here: using wildcards.
An IAM user or role can then have multiple policies, each with 1+ statements. Policies can be inline, AWS-managed, or account-managed (i.e. shared). Policies can be attached directly to users or roles or to the groups those users are in.
Been thinking a lot about #cloud#security lately and I am starting to believe that the "shared responsibility model" is fundamentally broken. Securing an storage bucket or server in the cloud shouldn't be as difficult as it is. Thread...
The big providers advertise how easy it is to deploy infrastructure in the cloud, but they don't seem to talk about how easy it is to screw it up and loose half the country's SSNs because of an extra * in a JSON policy. It doesn't help that the default settings are rarely secure.
We've got companies with 100s of engineers and combined decades of cloud security experience who are still getting it wrong. Not a day goes by without mass exfiltration of user data because of what amounts to really tiny mistakes.