There were a couple of recent AWS updates that can have a positive impact on your AWS usage: Lambda is now in the Savings Plan, and the new CalledVia IAM property allows you to limit calls to be through an AWS service.

Lambda in Savings Plan

There isn’t a whole lot to say about the inclusion of Lambda in the Savings Plan, except that I realise I never talked about the Savings Plan here. Which is strange considering I’ve talked about it in many other places (including episode 1 of the Ambassador Lounge podcast).

So, a quick recap for those of you unfamiliar with it. The Savings Plan is the new way AWS offers discounts for long running services. You may already be familiar with Reserved Instances which allowed you to reserve an instance type (or family) for a 1 or 3-year period at a discount. This had a number of limitations on how much you could do with it, in particular it limited you to a region, instance type, and even OS of your instances. That said, the discount was often worth this limitation.

However, with the Savings Plan that is now different. While there is an EC2 specific option to it, you will get most flexibility with the Compute options. Using this, you promise¹ to consume a certain amount of compute services. This amount is determined purely in monetary value. For example, you promise to pay at least 10 dollars worth of compute and in return you get 12-15 dollars worth of compute. The big thing here is that it’s not limited to EC2 instances, but includes Fargate and now even Lambda functions.

Your discount is calculated based on your usage and is based on the biggest discount percentage you will get. Obviously it comes with its own caveats, but these are similar to those of Reserved Instances such as that if you use less than the compute you put in the plan, you will still pay the value of the plan. Similar to how you would still pay for a Reserved Instance even if you didn’t have the instance running.

With the inclusion of Lambda however, this has become an even more attractive plan. So if you haven’t already done so I highly recommend to at least go through Cost Explorer’s recommendations² to see what kind of savings you may get.

IAM CalledVia

A fairly constant battle³ in the AWS world is between the desire for people to get access and the desire for controlling that access. In part this is because until now it wasn’t really possible to grant access in such a way that you can only create or delete resources through CloudFormation. Ok, that’s not completely true. Technically you can limit a user/role to only allow them to create CloudFormation templates and use a dedicated IAM role to create the resources. However, the new aws:CalledVia IAM property allows even more control over this.

Following an example in the linked blogpost, this allows you to grant a user or role access to create or delete a DynamoDB table only if this is done through CloudFormation, while at the same time giving them access to a KMS key only if used in that DynamoDB table. Let’s unpack that for a moment: this means that someone has access to KMS, but only if they are interacting via the DynamoDB table, which in turn they can only interact with through CloudFormation.

Technically speaking this would mean that you can limit the access to data to only be through certain tools. The other example in the blogpost highlights this, where you can give data analysts access to the data that you store in S3, but only by way of Athena and Glue. They don’t get direct access to the raw data itself. And if the data is encrypted⁴ the same goes for the KMS key used to encrypt it.

I can see a lot of potential to improve security and workflows with this. For one, ensuring that everything that is created goes through CloudFormation makes me happy⁵, but the ability to lock down access to data and secrets is even better from a security standpoint.