Today is focused once again on a couple of very welcome improvements. This time that concerns Lambda’s shared ENIs and IAM Roles for EKS services.

Lambda Shared ENIs

Unless this is your first time reading about AWS, I probably don’t need to explain what’s great about AWS Lambda. It allows you to run small functions¹ in a serverless manner. As in, you don’t need to care about the infrastructure at all. Except when you do.

One of the features of Lambda is that it’s possible to inject a function into your VPC so that it can connect to resources that are inside that VPC. Often this would be some kind of data store like a database, but technically speaking it can be anything. There was a big downside to this though, due to the way Lambda works this meant that you would have an ENI spin up for every function separately.

Ok, you might think. What exactly is so bad about that? This approach generally had two issues: first, spinning up an ENI takes time. It takes many seconds, sometimes ten or more, all for a function that might only need to run for less than a second. The second issue comes with scaling. If you have many instances of the same² function trying to get an ENI and associated IP address in your VPC, you can run out of IPs quite quickly.

Considering the title of this section, it’s probably obvious that this is now resolved³. This post on the AWS Compute Blog has a good breakdown of the exact changes, but what it boils down to is that when you create a function with a VPC connection, that function will automatically get a dedicated ENI in that VPC. Once this is in place, AWS uses black magic⁴ to ensure that each invocation of the function uses this ENI. This solves both of the problems mentioned above, by not needing to spin up and only requiring a single IP.

The only downside to this? It’s rolling out per region, but not actually available today. Hopefully, this changes soon because this is quite a game-changer for Lambda.

EKS IAM Roles

While we’re on the subject of game-changers, EKS gained another feature that makes it work a lot better with the rest of the AWS ecosystem. Up until now when it came to providing access for your services to another AWS service, you had to either provide an AWS Access Key⁵, attach IAM roles to the nodes that could access everything needed by any of the services⁶, or use tools like kube2iam or kiam⁷.

Which is where the announcement regarding fine-grained IAM Roles for Service Accounts comes in. You can now assign IAM Roles to a service/pod by way of a service account which can then be assumed from your code. It’s not as straightforward or easy to set up as doing so in ECS (where it’s all automatic), but it is a massive improvement over not having the support at all. The code for this is available on GitHub so you can use it for non-EKS clusters as well.

As a side note, while from a technical perspective I enjoy playing around with Kubernetes, I also often see it used in situations where it’s overkill. If your workload is in AWS and you need something to orchestrate your containers, I always recommend to first have a look at ECS (and in particular Fargate) to see if that does what you need. It has far better integration and is easier to set up. Which means it might just save you a lot of time.

Case in point, EKS now supports Kubernetes 1.14. Which⁸ means that 1.11 is deprecated and any EKS cluster running that version will be automatically upgraded in less than two months. If you have a cluster running on 1.11, I highly recommend you manage that upgrade yourself instead of waiting for the deadline. Of course, the fine-grained IAM controls only work on 1.13 and above so you should probably skip 1.12 altogether.

Ambassador Corner

• Why CDK?
• AWS Outposts bring a new Shared Responsibility Model
• Multi-stage Geospatial data lake with Step Functions (video)