re:Invent was a blast: five days packed with announcements of new services and features. We have created a top 10 list for our re:Invent recap. Here is all you need to know about re:Invent 2019.

Michael has collected some voices in Las Vegas. Listen to what Aleksandar Simovic, Anders Bjørnestad, and Thorsten Höger have to say in our podcast episode. On top of that, the podcast episode includes our top 10 of re:Invent announcements as well.

Provisioned Concurrency for AWS Lambda

Provisioned concurrency clears an obstacle out of the way: cold starts. By default, AWS Lambda scales on-demand. However, initializing a new executor takes a while - something between 100 ms and 1 s. Typically, only a small portion of the requests is affected by cold starts. However, there are scenarios where latencies above 200 ms are not acceptable, not even for a small number of requests.

Provisioning memory for concurrent invocations of your Lambda function allows you to reduce or avoid cold starts. For example, provisioning 4 GB memory will pre-warm 16 executors for your Lambda function with 512 MB memory size. As long as the Lambda function does not have to process more than 16 requests in parallel, there will be no cold starts at all. Check out Danilo’s blog post Provisioned Concurrency for Lambda Functions for a latency benchmark between a Lambda function with and without provisioned concurrency.

But provisioned concurrency does not only come with technical implications, but it also affects your AWS bill as well. Provisioning capacity for your Lambda function comes with a discount of about 15%. But keep in mind that you pay for provisioned capacity no matter if your Lambda function processes requests or not.

The following figure illustrates the costs for every GB-second at different utilization in US East (N. Virginia). On top of that, you pay $0.20 per 1M requests.

Good news, Provisioned Concurrency for AWS Lambda is ready to build something great!

Ready to build? General Available? ✅ Available in all regions? ✅ Manage with CloudFormation? ✅

HTTP API

Building a REST API with AWS Lambda is getting easier and cheaper with HTTP APIs, a new service under the Amazon API Gateway umbrella.

HTTP APIs come with a small but powerful set of features.

Forward incoming requests to AWS Lambda or any other HTTP endpoint.

Cross-origin resource sharing (CORS).

Authentication and authorization via JWT.

Custom domain names, as well as TLS/SSL.

I can’t wait to build a Serverless application with HTTP APIs. However, HTTP APIs are in beta and should not be used for production workloads yet. There is also an important feature missing: throttling. At the moment, you cannot rate-limit requests per client in any way.

Ready to build? General Available? ❌ Available in all regions? ❌ Manage with CloudFormation? ✅

Fargate for EKS

One of my most essential arguments, why I prefer ECS over EKS, is no longer valid: Fargate is available for EKS as well now. Why is that important? Because there is rarely a business case in which it makes economic sense to take responsibility for two layers of abstraction: virtual machines and containers. Fargate provides compute capacity at the abstraction layer of a container. No virtual machines to manage!

Fargate pricing is the same, no matter if you orchestrate the containers with EKS or ECS. On top of that, you pay $144 per EKS cluster per month. Whereas running an ECS cluster is free of charge.

To use Fargate with EKS, you need to upgrade your cluster to Kubernetes version 1.14 and platform version eks.5 . Next, create a Fargate profile that tells the cluster master to launch pods on Fargate for a particular namespace. If needed, you can also use tags to define which pods should launch on Fargate.

Unfortunately, Fargate for EKS is only available in the following regions: US East (Ohio), US East (N. Virginia), Asia Pacific (Tokyo), and EU (Ireland).

Ready to build? General Available? ✅ Available in all regions? ❌ Manage with CloudFormation? ❌

ALB: Least Outstanding Requests Algorithm and Weighted Target Groups

AWS improved the Application Load Balancer (ALB) significantly with the following new features:

Least Outstanding Requests algorithm for load balancing

Weighted Target Groups to distribute traffic among multiple target groups

Why are those new features important?