In my post Graviton2: ARM comes to Lambda I showed that it is very easy to cross-compile Go code to run on ARM64 AWS Lambda functions. That's true as long as your code is 100% Go - as soon as there's any C code involved it feels impossible. I mean, who wants to deal with this error message?
In my post AWS federation comes to GitHub Actions I wrote about GitHub Actions' new ability to federate access into AWS (and other clouds) via OpenID Connect. This is really great, much better than the prior state of affairs, but needs improvement on the AWS side.
AWS Step Functions are cool. Express Step Functions have always felt like they had the potential to be cool, but were missing some key features when they launched. I think they're worth revisiting in light of recent releases.
Today, Amazon Web Services has unveiled AWS Lambda Functions Powered By AWS Graviton2 Processors, offering a 20% reduction in the GB-second price compared to their x86-powered cousins. But first, some short history.
At the time of writing, this functionality exists but has yet to be announced or documented. It works, though!
EDIT: Here is the functionality on the GitHub roadmap.
GitHub Actions has new functionality that can vend OpenID Connect credentials to jobs running on the platform. This is very exciting for AWS account administrators as it means that CI/CD jobs no longer need any long-term secrets to be stored in GitHub.
A while ago I asked on Twitter if anyone knew how to knew how to set
message attributes when using AWS API Gateway (HTTP API flavour)'s integration
for SQS-SendMessage. I didn't get very far.
But today that changed! Here is how you do it. Hopefully this helps someone else.
AWS Lambda has supported function versions since October 2015, only
a couple of months after the service itself was publicly launched. Versions are
an optional feature - you can develop and use Lambda functions without versioning,
in which case you are working with the implicit $LATEST version.
A couple of months ago, Thai Duong wrote an interesting post about
problems with the AWS Encryption SDK. Most of it goes way over my head, but my
curiosity was piqued by the mention of reverse-engineering the format of the
"ciphertext" returned by KMS Encrypt. There wasn't much detail on
that (it wasn't the primary topic) so I thought I'd do some digging into it.
At the end of October, AWS released Nitro Enclaves. My mental model of these is essentially a secure virtual machine within a virtual machine - the outer VM being an EC2 instance. The secure qualifier is to distinguish that the inner VM has many restrictions: by default it has no network access, no persistent disk, no access to processes running on the host and crucially, vice-versa: the host likewise doesn't have access to resources inside the enclave. All communication instead happens over vsock sockets.
Update: In April 2022, AWS released aws:ResourceOrgID (and a couple of other related
condition keys). This blog post does a great job of describing
how it works. I'll leave the rest of this blog post in place for historical
interest, but it's now outdated.