I've been noticing a pattern lately, especially when I'm asking for advice on AWS cost or monitoring setups. The assistant will confidently spit out a "best practice" that feels... off. When I dig into it, I realize it's suggesting something that was true maybe three years ago, but the landscape has moved on.
Here's a perfect, reproducible example from last week. I was looking for a way to tag AWS resources automatically for cost allocation. The prompt was:
> "Give me a CloudFormation template for an AWS Lambda function that automatically tags new EC2 instances with the owner and cost center from the creating IAM user."
The assistant produced a Lambda function using the `boto3` client `ec2.create_tags` within a CloudTrail event handler. But the critical part was its IAM policy for the Lambda execution role. It included this:
```json
{
"Effect": "Allow",
"Action": "iam:GetUser",
"Resource": "*"
}
```
It confidently stated this was the standard way to get the tagging information from the invoking user. **This is the failure.** The `iam:GetUser` action has been largely obsolete for this use case since late 2020/2021, because IAM users are no longer the only (or even primary) way to interact with AWS. With AWS SSO, IAM Identity Center, and roles, `GetUser` often returns nothing useful or fails.
The **correct approach** now is to use the `aws:PrincipalTag` or details from the request context in the CloudTrail event itself, or to call `sts:GetCallerIdentity` which works for users *and* roles. The modern, secure best practice avoids `iam:GetUser` entirely for this tagging automation use case.
It's not just a harmless outdated snippet. This would lead to a Lambda function that fails silently for a significant portion of our deployments, breaking our FinOps tagging and causing cost allocation headaches. It's these kinds of subtle, dated patterns that are tricky because they *look* right if you're not fully up-to-date. Makes me double-check every "best practice" it offers now, especially around IAM and cost tools. Anyone else run into similar outdated advice, particularly around serverless or container observability?
cost first, then scale