A few years ago, I wrote about determining AWS account IDs from AWS
access keys, i.e. those strings that begin with AKIA or ASIA. It's also
possible to determine information from other AWS IAM unique IDs, specifically
these two from the table in Amazon's docs.
Back in 2021, I requested that AWS add some kind of "claim-to-tag mapping" functionality to OIDC IDPs, so that we could have role session tags based on claims in OIDC tokens issued by GitHub Actions. That hasn't happened yet, but today I learned (thanks to this comment and associated blog post by Daniel Jonsén) that the same outcome can be achieved by using AWS Cognito identity pools as an intermediary.
Last week AWS published a blog post advising that the go1.x Lambda
runtime will be deprecated and people should migrate to provided.al2. I was
already using the newer runtime, but I also learned from the blog post that AWS
SAM can now build Go Lambda functions for the newer runtime - no more Makefiles
required!
I switched from BuildMethod: makefile to BuildMethod: go1.x and noticed that
my Lambda packages were now twice the size. This means slower cold starts and
slower deployments - especially from my laptop in Australia. I also noticed that
my CI pipelines were slower because every commit was causing Lambda updates, even
when no code had changed.
Today I was experimenting with CloudTrail data events for Lambda invocations, because I learned that as of 2021, these data events log the ENI ID used by a Lambda function invocation.
tl;dr: You can now pass an IAM role to every EC2 instance in your account + region.
On Feb 17th 2023, AWS Systems Manager released Default Host Management Configuration.
This is a way to use Systems Manager on all your EC2 instances: they don't need
ssm:* permissions in their instance profiles, nor do they even need an instance
profile at all.
GitHub Actions has supported using OIDC tokens for about 15 months now. It is a much better way of providing AWS credentials to workflows than creating IAM users and storing long-lived access keys in GitHub Actions secrets.
One issue holding back larger organisations from adopting this solution is the lack of useful granular controls. I touched on this in an earlier article AWS IAM OIDC IDPs need more controls.
AWS CloudWatch Logs supports automatic forwarding of logs to AWS Kinesis Data Streams and AWS Kinesis Data Firehose. These destinations are can even be in a different AWS account and region. This is very handy for aggregating logs from thousands of log groups and forwarding them to a single place, like Axiom, Datadog, Splunk, etc.
Here are the environment variables available to an AWS Lambda extension in
the provided.al2 runtime. This is really just some context for myself so I
don't have to write code to sanity-check myself each time.
A couple of days ago, Announcing AWS Parameters and Secrets Lambda Extension appeared on the AWS What's New site. The general thrust of the motivation behind this (providing an easier way to vend credentials securely to AWS Lambda functions) is something that's absolutely needed, but I'm not sure that this approach will move the needle - and it confuses me.
In April 2022, AWS Lambda announced the launch of function URLs - a
way to invoke websites powered by Lambda functions without needing API Gateway.
A common complaint was the lack of support for custom domains: it only supported
the URLs it would generate that look like lprqaxgvt4f6ab3dbj3ixftr640uzgie.lambda-url.ap-southeast-2.on.aws.
But that's where CloudFront comes in useful. Not only can it provide us with custom domain functionality, but we get caching, WAF support, etc as well.