Lambda extension environment variables
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.
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.
Sometimes I need to run a long-lived app. In those cases I reach for AWS ECS Fargate instead of AWS Lambda. You can run a container on Fargate for as little as $9/month, or $2.70/month if you're happy to roll the dice with Fargate Spot (I usually do!)
If you have a web app, you almost certainly use a load balancer in front of your containers. And this is where the cost goes from "fun side project" to "oh, I'm not sure I'm willing to spend that much money on this." The load balancer by itself is at least $16.40/month - you could run six containers for that price!
Update: AWS now has an open source implementation of a Roles
Anywhere credential_process provider - and it even supports PKCS#11. I'll
keep the following project online for historical purposes, but there's not
much need for it.
I just published a proof-of-concept CLI tool named openrolesanywhere.
It lets you assume a role in AWS using IAM Roles Anywhere and a private key
stored in your SSH agent - rather than on-disk as required by the official client.
It implements AWS4-X509-RSA-SHA256, AWS4-X509-ECDSA-SHA256 via a forked
copy of the SigV4 signer in the AWS SDK for Go.
UPDATE: This issue has been fixed. See the end of the article for timeline and details.
In September 2020, I published a guest blog post on Ian Mckay's blog. The tl;dr is that "escaping" a privileged container running in an Amazon-managed AWS account isn't a security concern for Amazon, thanks to defence-in-depth on both an EC2 and IAM level. Here's a few paragraphs I left out of that blog post at the time.
AWS introduced Gateway Load Balancers back in November 2020. A reasonably accurate tl;dr would be that they are like having highly available, auto-scaling NAT instances. That intro blog post will explain them better than I can.
The blog post mentions a dozen AWS partners that implement various flavours of firewalls, deep packet inspection, DDoS protection, etc. It's all useful and serves a genuine need, but not very exciting from a developer perspective.
What's the silliest use for 281 trillion IP addresses that you can think of? That's the question I asked myself when AWS launched support for assigning IPv6 prefixes to EC2 instances.
AWS launched VPC sharing in January 2019, two years ago. It feels to me that there hasn't been much chatter about it since then. Which is a shame, because I suspect they are quite useful. I'm going to focus on cost and security.
The CloudWatch embedded metric format (EMF) is a convenient way to publish metrics to CloudWatch from your apps running in AWS - especially Lambda functions. You just need to emit logs in the right JSON format and CloudWatch Logs will automatically publish them to CloudWatch Metrics.
This is okay for basic use cases where you have zero or few dimensions on your metrics and those dimensions are low cardinality. If they're high cardinality, Amazon advises that you instead do not create dimensions and instead treat the metrics as logs and query them using CloudWatch Log Insights. So you have to make a trade-off between something useful, something affordable and something easy to use.