Re:Invent 2016 took place last week, and AWS didn’t disappoint in how much they released. I’ll go through some of what I see as the highlights, but there is far too much to cover everything.

I’ll save some of the announcements, particularly the AI related ones, for next week to prevent this note from getting too big. Also, my apologies for the longer than planned absence. After returning from my holiday I got sick and spend a while unable to do anything.

Unsung heroes

First a couple of releases that are interesting but that I don’t have much to say about. Snowmobile (and the actual appearance of a truck on stage) is a good concept and I’d love to have a chance to work with it. Unfortunately the number of companies that require this amount of data to be shipped isn’t very high.

Aurora support for Postgres is a good move, as it means that highly distributed database system is now even more useful. Similarly, the ability to run Aurora on low end hardware makes it a lot more feasible for development work.

Codebuild was the missing step in the Code* line of products and works as a build system. It’s designed as a completely managed service where you define the type of build systems you want and these will then spin up for you. It’s Docker based as well, so I’ll probably give it a spin to compare it to similar solutions like Wercker or Bitbucket Pipelines.

Athena allows you to run SQL queries over your S3 data. It can handle various types of data, including json and csv, and more complex commands like JOINs. No doubt this will be very useful for some people.

Lambda

It won’t come as a surprise that a lot of my attention was on the Lambda announcements. While unfortunately there still is no built-in support for Go, they did add C# support. Probably as a way to attract customers who might otherwise use Azure Functions¹.

More interesting is the dead letter queue functionality. This allows you to set a handling method (or rather, an SQS queue) for dealing with failures. So, instead of having your function contain error handling code (at least the non-interacting part) you can have Lambda send the error message to an SQS queue. Then of course you can parse this queue however you wish. The idea is that this will allow your code to be more simple, and make it easier to deal with complex microservice architectures.

A related new feature, though not limited to Lambda, is X-Ray. X-Ray² allows you to trace requests across services, including Lambda, EC2, RDS, ECS containers etc. This means that it’s potentially a great debugging tool you can use for optimizing your applications. It’s not the first tool like this, but the biggest advantage is that it comes built into the services where other tools often can’t go due to the restrictions from AWS. As always though, these sort of tools often promise more than they can actually do as not every use case works with it so I recommend trying out if it seems to fit your needs before you spend a lot of time with it. Especially if you wish to remain free to switch away from AWS³.

The last major Lambda feature announced was Lambda@Edge. This allows you to run JavaScript Lambda functions at the edge locations of your Cloudfront distribution. The advantage of this is that you can make business decisions about how the visitor of your site needs to be treated at an earlier time in the process: before the site gets loaded, but without the latency you get from calling the main source. While the example given is pre-rendering results for search engines, I can imagine plenty of use cases for it.

Before Re:Invent, a couple of other Lambda announcements were made as well. The introduction of environment variables and the serverless application model. Both of these are very interesting, and open up new possibilities, but it’s clear that the Re:Invent announced features are the real stars from AWS' perspective.

Lightsail and AWS Shield

While these two announcements don’t really have anything directly to do with each other, they are both similar in that they’re aimed at keeping people within AWS. Lightsail seems clearly aimed at Digital Ocean, while Shield is aimed at companies like Cloudflare.

Lightsail is a VPS offering, basically a 1-click solution to having a server up and running for a low monthly fee and no hassle. If this sounds familiar, you’re probably aware of Digital Ocean’s offering. I haven’t gotten around to trying out Lightsail, so I can’t say if it’s better or not. That said, for companies that consider doing more than a simple VPS this will sound very attractive. Similarly for people who would do development work on Digital Ocean to eventually port their work to AWS.

Lightsail has its own interface though, separate from the usual AWS Console⁴. Which is a good thing if you want to attract more casual users as the Console isn’t the easiest thing to deal with when starting out. There’s simply too much there.

Instead Lightsail has a simple page with an overview of your existing Lightsail instances and an easy way to start new ones. It also comes with a bunch of predefined applications such as Wordpress or Magento which means you can start your site with a few clicks. The interface seems quite slick, and combined with the actual ability to extend into the wider AWS infrastructure it certainly has a lot of potential.

AWS Shield on the other hand is a DDoS protection service. It consists of a free tier that is applied to the major services aimed at stopping most DDoS attacks and a paid tier that is also aimed at stopping volumetric attacks and which gives you access to a team of security people at AWS. I’ve mentioned many attacks by IoT devices over the past months and I’ll be interested to see how Shield holds up to things like that. As of now, I suspect that the free tier will be a good first protection against common attacks, but it won’t stand against the bigger attacks. That is where the paid tier would come in, but I would need to see some reports on how it holds up before I’d even consider suggesting it over Cloudflare for this kind of protection.