In a previous post I used jq to parse the responses from the aws cli for Lambdas to search for or parse the results for specific property values. Querying Lambda properties can also be done via the aws cli itself without using jq (although using jq is significantly more powerful).
If you’ve received an email from AWS about runtimes that are reaching End of Life, the emails usually contain an example use of the cli showing how to query for specific runtimes, for example:
aws lambda list-functions --function-version ALL --region us-west-1 --output text --query "Functions[?Runtime=='nodejs14.x'].FunctionArn"
The long term solution for upgrading a runtime should be to redeploy and test with the latest runtime and then redeploy your production value after testing. It is possible for a quick fix to update the runtime of a deployed Lambda directly via the aws cli. Once you’ve identified which Lambdas need to update, use this command to update:
aws lambda update-function-configuration --function NAME --runtime RUNTIMENAME
I’ve been sharing updates on updating my AWS Lambdas related to my Twitter bot projects recently and I’ve still got a way to go. Just leaving this here as a reminder. Still got a lot of Lambdas that I haven’t touched for years running on long out of support Node runtimes:
I just got prompted to switch to the new AWS Console and found this new feature that I’ve always though would be useful, and now here it it 🙂 You can now flag specific services as your ‘favorites’ and they appear in a ribbon bar across the top of your console and in a widget on the console page. Here’s my 3 ‘favorited’ services in the bar at the top of the console:
If you go to ‘Action’ then ‘Add widgets’ you can also add a favorites section and drag it to a location on your console page:
Here it is at the top of my console page:
Previously we had the ‘Recently visited’ section on the Console, but the items in the list would move around depending which you most recently used. Now with favorites you can pin the services you’re most often using so you can more easily access them.
If you work on many projects deployed to AWS over time, it can become more difficult to track what resources are where and what relates to what. Tagging can help a lot, so can regions. For example I can deploy one project to us-west-1 and another to us-west-2.
Another idea is to take advantages of multiple AWS accounts and manage them as an Organization. There’s no additional cost for each account or setting up the Organization, the costs are still only for the resources you are using.
Now you have multiple accounts to segregate various projects or other things you’re working on, instead of logging off one account and logging on to the other and switching back a forth, you can assume a role within other accounts from the Account dropdown and ‘Switch Roles’. This option is only visible if you are signed on as an IAM user and not the root account user.
Before you get to this step, in the account you want to switch to, create a new IAM role with the permissions you need to use, and in the Trust section, add the account id for the other account where you want to assume the role from. The complete the fields above and insert the ARN id for the role.
After the first time you’ve used this switch role feature, you’ll see the role in the Account dropdown to reuse later.