Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles

By (4 minutes read)

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 functions1 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 same2 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 resolved3. 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 magic4 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 Key5, attach IAM roles to the nodes that could access everything needed by any of the services6, or use tools like kube2iam or kiam7.

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. Which8 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


  1. Technically speaking these functions could be large, but that sort of defeats the purpose. [return]
  2. Or even different. [return]
  3. Well, it will be soon… [return]
  4. They disguise it as VPC to VPC NAT on their Hyperplane platform. [return]
  5. Not exactly great from a security standpoint. [return]
  6. Yeah, that’s even worse than the keys. [return]
  7. Both good tools, but not exactly a native solution. [return]
  8. Apart from being great news. [return]
comments powered by Disqus