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 promise1 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 recommendations2 to see what kind of savings you may get.
A fairly constant battle3 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 encrypted4 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 happy5, but the ability to lock down access to data and secrets is even better from a security standpoint.
- By way of handing over money. [return]
- Go to Cost Explorer -> Savings Plan -> Recommendations [return]
- For lack of a better term. [return]
- As it probably should be. [return]
- You’ll probably want to have somewhere that people can play around without that, but at least your production environments won’t have anyone “forgetting” to put it in code. [return]
Read more like this:
- Building and Testing CloudFormation Macros
- Personal access to your servers
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 32, 2019 - ECS Multiple Target Groups; CloudWatch Logs Insights; PartiQL; CloudFormation Roadmap
- Week 27, 2019 - AWS Security Hub; AWS Control Tower, VPC Traffic Mirroring
Or always get the latest by subscribing through RSS, Twitter, or email!