AWS re:Invent is over, and I finally have time to breathe. I’ve been going to the NY Summit since it was “only” a few thousand people and watched it grow into a 12,000-person behemoth, but this was my first re:Invent. I assumed it would be like the Summit, but bigger. I was wrong.
Summits are single-day events, and half of that day is taken by the keynote, leaving time for just a few sessions for the afternoon. By comparison, re:Invent is four and a half days, and the keynotes are “just another session”; other tracks run concurrently. As a result, the opportunities for learning are several orders of magnitude more than a summit. Not just talks, but hands-on workshops ranging from one to four hours.
So what did I learn? Well, perhaps the most important thing was the lack of new service announcements at the keynotes. This is, in my opinion, a Good Thing: Amazon is devoting effort to making its existing services better and easier to use.
For me, the best example of this is Lambda Provisioned Concurrency: the ability to keep Lambda functions “warm” and ready to respond to requests. Pricing is, as you might expect, in the same range as maintaining an always-on server. What is strange to me is that the pricing models all focus on high concurrency for short lengths of time. I would expect this feature to be more valuable for organizations that might have low request volumes but like the Lambda deployment model, and could use provisioned concurrency to ensure that requests will always be serviced. This requires more research on my part.
For sessions, my favorite was GPSTEC405, a two-hour workshop presented by the team that manages transient accounts for AWS events (such as the workshops at re:Invent). At Chariot, we’ve been doing the same thing, albeit at much smaller scale (in fact, my next blog post — which I was holding pending any new announcements — is about the related task of managing developer sandboxes). It was nice to see that they used many of the techniques that we do, but more valuable was to learn about the techniques that they tried and rejected.
That session probably won’t appear on the re:Invent YouTube channel, but my second favorite, DOP310, “Amazon’s approach to security during development” has. I took nearly a full page of notes from this talk, which explained how AWS has adopted a “security culture” that is tied to the Amazon Leadership Principles. This is, I think, the right way to do it: in my experience security that’s “bolted on” after the fact is rarely very good.