Last month a client's AWS bill jumped $4,300 in nine days. AWS Cost Anomaly Detection caught it on day two and sent a perfectly correct, perfectly useless email: "Anomaly detected. Service: Amazon Elastic Compute Cloud. Impact: $312." Nobody opened it. It looked like the other 40 cost emails that month. Here is the thing about AWS Cost Anomaly Detection: the detection part works. It uses a machine learning model on your historical spend, it's free, and it will find the spike. What it will not do is tell you WHY. It gives you a service name, a region, a usage type, and a dollar figure. Then it stops, and a human has to go do 45 minutes of archaeology across CloudTrail, Auto Scaling activity, and the tagging report. That gap is where the Claude API fits. Not as a detector - AWS already detects. As a translator and a triage layer. The pattern is three steps and it takes about 200 lines of Python: 1. boto3 client for ce (Cost Explorer is global, pin it to us-east-1). Call get_cost_and_usage with DAILY granularity, 30-day window, grouped by SERVICE. Then call get_anomalies to pull what AWS already flagged. 2. Format that into a compact text block - anomaly window, actual vs expected spend, root cause dimensions, and the 14-day daily series per service. 3. Send it to Claude with a system prompt that says "you are a senior FinOps engineer writing for an on-call engineer who needs to act in 15 minutes." What comes back on the real bill I mentioned: "NAT Gateway data processing charges in eu-west-1 rose from $18/day to $340/day starting July 22, while EC2 compute stayed flat. Flat compute plus rising NAT egress means traffic pattern change, not scale-up. Most likely cause (high confidence): a workload started routing S3 or ECR traffic through the NAT Gateway instead of a VPC endpoint. Verify with: aws ec2 describe-vpc-endpoints. Action: add a Gateway endpoint for S3, estimated saving $9,600/year." That's the difference. The alert said EC2 is expensive. Claude said you're missing a VPC endpoint.

A friend of mine runs platform engineering at a mid-size fintech. In March they got an alert that a production S3 bucket had been emptied. That was the moment they found out they'd been compromised. When they pulled the CloudTrail logs and walked backwards, the actual break-in had happened seventy-one hours earlier. Here's what those three days looked like. Day one, an access key belonging to a contractor who'd left eight months earlier gets used from a residential IP in a country the company doesn't operate in. It makes exactly four API calls, all of them read-only. ListRoles, ListAttachedRolePolicies, GetRole, SimulatePrincipalPolicy. Nothing fires, because nothing should fire on a read. Day two, the same key calls iam:PassRole and lambda:CreateFunction, eleven minutes apart. Individually both of those are things their deploy pipeline does forty times a day. Day three, the Lambda gets invoked once, it assumes a role with AdministratorAccess, mints a new access key, and then the fun starts. Total time from first suspicious call to full admin: about seventy-two hours of extremely patient, extremely quiet work. Their SIEM saw every single one of those events. It just never saw a reason to care about any of them. That's the part that keeps me up. The logs were perfect. The detection was the failure. The reason static rules lose this fight is that privilege escalation isn't an action, it's a sentence made out of actions, and the grammar is enormous. You can write a rule for iam:CreateUser followed by iam:AttachUserPolicy followed by iam:CreateAccessKey, and you should. But then the attacker uses iam:CreatePolicyVersion plus iam:SetDefaultPolicyVersion to quietly rewrite a policy that's already attached to something they control, and your rule never fires. So you write another rule. Then they use iam:UpdateAssumeRolePolicy to add themselves to a role's trust policy and just assume it. Another rule. Then iam:PassRole with ec2:RunInstances and they read the credentials off the instance metadata service. Another rule. There are somewhere north of thirty documented escalation paths in AWS and the number of two-and-three step orderings across them runs into the thousands. You will always be writing the rule for the technique they used last time.

Every cost post here starts with some version of "nobody did anything wrong, and then the bill was $40k." Curious what yours looks like. Drop the story — service, root cause, how you found out (Slack alert? Finance email? Console at 2am?). Doesn't have to be dramatic, the boring ones ("forgot to delete a NAT gateway," "left a dev cluster running for 3 months") are usually the most useful for everyone else to read. I'll pull the best patterns into next week's post.

Your Terraform state is a lie. Not on day one. On day one it's perfect. But then there's a Sev-1 at 2am, someone adds an ingress rule in the console to unblock traffic, the incident closes, and nobody goes back and codifies it. Three weeks later a junior runs terraform plan on an unrelated change and sees 47 lines of red. Now they're scared to apply. So they don't. And the gap widens. Every team I've worked with has this problem. The causes are boring and universal: - Emergency hotfixes clicked in the console during an incident - Auto-healing services (ASG, GKE node pools, AKS autoscaler) mutating things Terraform thinks it owns - Providers changing default behaviour between versions - One person with AdministratorAccess and a deadline The real cost isn't the ugly diff. It's that you can no longer tell the difference between "that's fine, the autoscaler did it" and "someone opened 0.0.0.0/0 on port 3389 in March and nobody noticed." Both look identical in plan output. Human eyes stop reading after the third resource. That's a classification problem, and classification is exactly what an LLM is good at. The mini-workflow I run nightly: 1. terraform plan -refresh-only -json in a read-only role. Refresh-only is the key flag — it shows you reality vs state, not your pending config changes. 2. Parse the JSON stream into structured records: address, resource_type, action, changed attributes with before/after values. 3. Strip noise before sending anything to the model — tags_all, arns, timestamps, etag, anything matching /secret|password|private_key/. 4. Send each drift record to Claude with a system prompt that forces one of four labels: benign, cost_risk, security_risk, compliance_violation — plus a severity and short reasoning grounded in the actual attribute values. 5. Route by label. benign gets logged and skipped. cost_risk goes in the Slack digest. security_risk and compliance_violation get a GitHub PR opened automatically with the corrected HCL and the reasoning in the description.