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.
It's long been considered "best practice" to avoid having IAM users in AWS. Where possible IAM roles are preferable as role session credentials are short-lived. As far as I can tell, the only justification for AWS IAM users that I hear nowadays is for usage on non-interactive systems outside of AWS (so AWS SSO won't work), e.g. a Raspberry Pi in your closet.
I created a proof-of-concept project cloudkey to show that even that
scenario can avoid IAM users. It uses the little-known iot:AssumeRoleWithCertificate
functionality to avoid that.
Since November 2020, EventBridge has supported two methods of creating cross-account event subscriptions. Both require a level of indirection in the form of an "intermediary" bus in the subscriber's account. Here are examples of how they work. We will refer to the account whose bus has interesting events as account B. We will refer to the subscriber account as account S.
Say you find yourself doing silly things with AWS APIs on a lazy Sunday afternoon. And you are getting an inexplicable error when using perfectly valid credentials.
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.